Androidではどのデザインパターンが使用されていますか？
モバイルプラットフォームの小規模な調査を行っていますが、Androidで使用されているデザインパターンを知りたいですか？
例えばiOSでは、Model-view-controllerは委任およびその他のパターンと一緒に非常に広く使用されています。
Androidはどのようなパターンをどこで使用していますか？
編集
カーネルやdalvikなどで深く使用されているデザインパターンを求めるのではなく、アプリケーション開発者がアプリケーションの開発中に遭遇するパターンについて尋ねています。
Android開発を行うために model–view–controller （MVC）と model–view–presenter の両方のデザインパターンを使用してみました。私の調査結果はモデルビューコントローラーで問題ありませんが、いくつかの「問題」があります。それは、AndroidのActivityクラスをどのように認識するかにかかっています。それはコントローラーですか、それともビューですか？
実際のActivityクラスはAndroidのViewクラスを拡張しませんが、ユーザーへのウィンドウの表示を処理し、そのウィンドウのイベント（onCreate、onPauseなど）も処理します。
つまり、MVCパターンを使用している場合、コントローラーは実際には擬似ビューコントローラーになります。 setContentViewを使用して追加した追加のビューコンポーネントを使用してユーザーへのウィンドウの表示を処理し、少なくともさまざまなアクティビティライフサイクルイベントのイベントも処理しているためです。
MVCでは、コントローラーがメインエントリポイントになるはずです。アクティビティはほとんどのアプリケーションの自然なエントリポイントであるため、これをAndroid開発に適用する場合は少し議論の余地があります。
このため、個人的には、model–view–presenterパターンがAndroid開発に最適であることを発見しました。このパターンでのビューの役割は次のとおりです。
- エントリポイントとして機能
- レンダリングコンポーネント
- プレゼンターへのユーザーイベントのルーティング
これにより、次のようにモデルを実装できます。
View-これにはUIコンポーネントが含まれ、それらのイベントを処理します。
Presenter-これはモデルとビューの間の通信を処理し、モデルへのゲートウェイとして見ます。つまり、表現する複雑なドメインモデルがあり、神が何を知っており、ビューに必要なのがこのモデルの非常に小さなサブセットのみである場合、プレゼンターの仕事はモデルを照会してからビューを更新することです。たとえば、テキストの段落、見出し、および単語数を含むモデルがある場合。ただし、特定のビューでは、ビューに見出しを表示するだけで済みます。次に、プレゼンターはモデルから必要なデータを読み取り、それに応じてビューを更新します。
Model-これは基本的に完全なドメインモデルである必要があります。上記のようにケースを処理するための特別な方法が必要ないので、ドメインモデルをより「タイト」にするのに役立つことを願っています。
（プレゼンターを使用して）モデルをビューからまとめて切り離すことにより、モデルをテストすることもはるかに直感的になります。ドメインモデルの単体テストと、プレゼンターの単体テストを実行できます。
やってみよう。個人的には、Androidの開発に最適です。
2018年11月更新
AndroidでMVCとMVPについて数年間働き、ブログを書いた後（以下の回答の本文を参照）、私は自分の知識と理解をより包括的で簡単に消化できる形式で取り込むことにしました。
そこで、Androidアプリケーションアーキテクチャに関する本格的なビデオコースをリリースしました。したがって、Android開発で最も高度なアーキテクチャパターンを習得することに興味がある場合は、 こちらの包括的なコースをご覧ください 。
この回答は、2016年11月時点で関連性を保つために更新されました
デザインパターン ではなく、 アーキテクチャパターン を探しているようです。
設計パターンは、特定の一連の繰り返しソフトウェアタスクを処理するためにプログラマが実装する一般的な「トリック」を記述することを目的としています。例：OOPでは、オブジェクトがいくつかのイベントについて他のオブジェクトのセットに通知する必要がある場合、 observer design pattern を使用できます。
Androidアプリケーション（およびAOSPのほとんど）はオブジェクト指向のJavaで記述されているため、Androidでは使用されない単一のOOPデザインパターンを探すのは難しいと思います。
一方で、アーキテクチャパターンは、特定のソフトウェアタスクに対処しません-テンプレートを提供することを目的としています問題のソフトウェアコンポーネントのユースケースに基づくソフトウェア組織の場合。
少し複雑に聞こえますが、例が明確になることを願っています：何らかのアプリケーションを使用してリモートサーバーからデータを取得し、構造化された方法でユーザーに提示する場合、 MVC 検討に適した候補です。アプリケーションのソフトウェアタスクとプログラムフローについては何も言わなかったことに注意してください。ユーザーの観点から説明したばかりで、アーキテクチャパターンの候補が出現しました。
質問でMVCについて言及したので、アーキテクチャパターンがあなたが探しているものだと思います。
歴史的に、アプリケーションのアーキテクチャに関するGoogleによる公式のガイドラインはありませんでしたが、これは（他の理由の中でも）Androidアプリのソースコードに完全な混乱をもたらしました。実際、今日でも、私が見るほとんどのアプリケーションは、OOPのベストプラクティスに従っておらず、コードの明確な論理的組織を示していません。
しかし、今日は状況が異なります-Googleは最近、Android Studioと完全に統合された データバインディングライブラリ をリリースしました。さらに、一連の Androidアプリケーションのアーキテクチャブループリント =。
2年前、AndroidでMVCまたはMVPに関する情報を見つけるのは非常に困難でした。今日、MVC、MVP、およびMVVMはAndroidコミュニティの「話題」になっており、MVxはMVyよりも優れていると常に説得しようとする無数の専門家に囲まれています。私の意見では、用語自体が非常に曖昧であるため、MVxがMVyよりも優れているかどうかを議論することはまったく意味がありません- この質問 の答えを見てください完全に異なる構造を持つ。
Androidの最適なアーキテクチャパターンの検索が公式に開始されたという事実により、私たちはさらにいくつかのアイデアが明らかになると考えています。この時点で、どのパターン（1つまたは複数）が将来業界標準になるかを予測することは実際に不可能です。待つ必要があります（1〜2年の問題だと思います）。
ただし、自信を持って作成できる予測が1つあります。データバインディングライブラリの使用は業界標準にはなりません。データバインディングライブラリ（現在の実装）は短期的な生産性の向上と何らかのアーキテクチャガイドラインを提供するため、自信を持って言えますが、長期的にはコードを維持できなくなります。このライブラリの長期的な効果が表面化すると、放棄されます。
さて、今日は何らかの公式のガイドラインとツールがありますが、個人的には、これらのガイドラインとツールが利用可能な最良の選択肢であるとは思いません（そして、それらは間違いなく唯一のものではありません）。私のアプリケーションでは、MVCアーキテクチャの独自の実装を使用しています。シンプルでクリーンで読みやすく、テスト可能で、追加のライブラリを必要としません。
このMVCは、見た目が他のMVCと異なるだけではありません。 AndroidのアクティビティはUI要素ではない という理論に基づいています。これは、コード編成に多大な影響を与えます。
したがって、 SOLID の原則に従うAndroidアプリケーションの優れたアーキテクチャパターンを探している場合、 MVCおよびMVPアーキテクチャパターンに関する以下の記事で私の説明を見つけることができますAndroid 。
この投稿に到達すると、サンプルでパターンを理解するのに本当に役立ちますので、Androidフレームワークのデザインパターンとその例を明確に見るために下の表を作成しました
役立つと思います。
Androidフレームワークでは、次のようなさまざまなパターンが使用されます。
- ブロードキャストレシーバーはObserverパターンを使用します
- リモートサービスの呼び出しはプロキシパターンを使用します
- ビューおよびビューグループは複合パターンを使用します
- メディアフレームワークはファサードパターンを使用します
Androidの一般的なデザインパターン に関する素晴らしい記事を次に示します。
作成パターン：
- ビルダー（例：AlertDialog.Builder）
- 依存性注入（例：Dagger 2）
- シングルトン
構造パターン：
- アダプタ（例：RecyclerView.Adapter）
- ファサード（例Retrofit）
行動パターン：
- コマンド（例：EventBus）
- オブザーバー（例：RxAndroid）
- モデルビューコントローラー
- モデルビューViewModel（上のMVCパターンと同様）
次のAndroidクラスはデザインパターンを使用します
1）ビューホルダーはシングルトンデザインパターンを使用
2）インテントはファクトリーデザインパターンを使用
3）アダプターはアダプター設計パターンを使用します
4）放送受信機はオブザーバーデザインパターンを使用します
5）ビューはコンポジットデザインパターンを使用します
6）Media FrameWorkはファサードデザインパターンを使用します
通知 の場合、NotificationCompat.BuilderはBuilderパターンを使用します
のような、
mBuilder = new NotificationCompat.Builder(this)
.setSmallIcon(R.drawable.ic_stat_notification)
.setContentTitle(getString(R.string.notification))
.setContentText(getString(R.string.ping))
.setDefaults(Notification.DEFAULT_ALL);
AndroidもViewHolderデザインパターンを使用します。
ListViewのスクロール中のパフォーマンスを改善するために使用されます。
ViewHolderデザインパターンを使用すると、ルックアップを必要とせずに各リストアイテムビューにアクセスでき、貴重なプロセッササイクルを節約できます。具体的には、ListViewのスクロール中にfindViewById（）を頻繁に呼び出さないようにします。これにより、スムーズになります。
これらすべてのパターン、MVC、 MVVM 、MVP、および Presentation Model は、Androidアプリに適用できますが、サードパーティのフレームワークでは、よく組織化された構造とクリーンなコードを取得するのは簡単ではありません。
MVVMはPresentationModelから派生しています。 MVC、 MVVM 、および Presentation Model をAndroidアプリに適用する場合、本当に欲しいのは明確にすることです構造化されたプロジェクトであり、さらに重要なのは単体テストです。
現時点では、サードパーティのフレームワークがなければ、通常は多くのコード（addXXListener（）、findViewById（）など）があり、ビジネス上の価値はありません。さらに、通常のJUnitテストの代わりにAndroidの単体テストを実行する必要があります。通常のJUnitテストでは、実行に時間がかかり、単体テストがやや実用的ではありません。
これらの理由から、数年前にオープンソースプロジェクト RoboBinding -Androidプラットフォーム用のデータバインディングプレゼンテーションモデルフレームワークを開始しました。 RoboBindingを使用すると、読みやすく、テストしやすく、保守しやすいUIコードを作成できます。 RoboBindingはaddXXListenerなどの不要なコードの必要性を取り除き、UIロジックを POJO であるプレゼンテーションモデルにシフトします。 通常のJUnitテスト経由。 RoboBinding自体には、品質を保証するために300を超えるJUnitテストが付属しています。
Androidフレームワークに適用されているデザインパターンを追加したいと思います。これは、Asynctask実装で使用されるHalf Sync Half Asyncパターンです。で私の議論を見てください
https://docs.google.com/document/d/1_zihWXAwgTAdJc013-bOLUHPMrjeUBZnDuPkzMxEEj0/edit?usp=sharing
Androidでは、アプリケーションのメインスレッドからタスクをオフロードするために「ワークキュープロセッサ」パターンがよく使用されます。
例：IntentServiceクラスの設計。
IntentServiceはIntentを受け取り、ワーカースレッドを起動し、必要に応じてサービスを停止します。すべての要求は単一のワーカースレッドで処理されます。
バインダーは、死亡者の通知に「オブザーバーパターン」を使用します。