Androidで使用されているアーキテクチャパターンはどれですか？[閉まっている]

モバイルプラットフォームの小規模な調査を行っていますが、Androidで使用されているデザインパターンを知りたいのですが？

たとえば、iOSでは、ビューモデルコントローラーは委任やその他のパタ​​ーンと共に非常に広く使用されています。

Androidはどのようなパターンで、特にどこで使用しますか？

編集

カーネルやdalvikなどで深く使用されているデザインパターンを求めるのではなく、アプリケーション開発者がアプリケーションの開発中に出会うパターンについて尋ねます。

Android開発を行うために、モデルビューコントローラー（MVC）とモデルビュープレゼンターの両方のアーキテクチャパターンを使用してみました。私の調査結果は、モデル、ビュー、コントローラーが適切に機能することですが、「問題」がいくつかあります。すべては、Android Activityクラスをどのように認識するかによって決まります。それはコントローラーですか、それともビューですか？

実際のActivityクラスはAndroidのViewクラスを拡張しませんが、ユーザーへのウィンドウの表示とそのウィンドウのイベント（onCreate、onPauseなど）を処理します。

つまり、MVCパターンを使用している場合、コントローラーは実際には疑似ビューコントローラーになります。これは、ユーザーへのウィンドウの表示と、setContentViewを使用して追加したビューコンポーネントを処理し、少なくともさまざまなアクティビティライフサイクルイベントのイベントを処理するためです。

MVCでは、コントローラがメインのエントリポイントであると想定されています。アクティビティはほとんどのアプリケーションの自然なエントリポイントであるため、これをAndroid開発に適用する場合は少し議論の余地があります。

このため、私は個人的に、モデル-ビュー-プレゼンターパターンがAndroid開発に最適であることを発見しました。このパターンでのビューの役割は次のとおりです。

• エントリポイントとして機能する
• レンダリングコンポーネント
• ユーザーイベントをプレゼンターにルーティングする

これにより、次のようにモデルを実装できます。

ビュー -UIコンポーネントが含まれ、それらのイベントを処理します。

プレゼンター -これはモデルとビューの間の通信を処理します。モデルへのゲートウェイとしてそれを見てください。つまり、複雑なドメインモデルを表現している場合、神は何を知っていて、ビューにはこのモデルの非常に小さなサブセットしか必要ない場合、プレゼンターの仕事はモデルをクエリしてビューを更新することです。たとえば、テキストの段落、見出し、単語数を含むモデルがあるとします。ただし、特定のビューでは、ビューに見出しを表示するだけで済みます。次に、プレゼンターはモデルから必要なデータを読み取り、それに応じてビューを更新します。

モデル -これは基本的に完全なドメインモデルでなければなりません。うまくいけば、上記のようにケースを処理するための特別なメソッドは必要ないため、ドメインモデルをより「タイト」にするのに役立ちます。

（プレゼンターを使用して）ビューからすべてのモデルを切り離すことにより、モデルをテストするのもはるかに直感的になります。ドメインモデルのユニットテストとプレゼンターのユニットテストを持つことができます。

やってみよう。私は個人的にはAndroid開発に最適だと思っています。

2018年11月の更新

数年間AndroidでMVCとMVPについて働き、ブログを書いた後（以下の回答の本文を参照）、自分の知識と理解をより包括的で消化しやすい形で取り込むことにしました。

そこで、Androidアプリケーションアーキテクチャに関する本格的なビデオコースを公開しました。したがって、Android開発で最も高度なアーキテクチャパターンを習得することに興味がある場合は、こちらの包括的なコースをご覧ください。

この回答は、2016年11月の時点で関連性を維持するために更新されました

デザインパターンではなく、建築パターンを探しているようです。

設計パターンは、プログラマが繰り返し実行する特定のソフトウェアタスクセットを処理するために実装する可能性のある一般的な「トリック」を記述することを目的としています。例：OOPでは、オブジェクトが他のオブジェクトのセットにいくつかのイベントについて通知する必要がある場合、オブザーバーデザインパターンを使用できます。

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アプリケーションの優れたアーキテクチャパターンを探している場合は、AndroidのMVCおよびMVPアーキテクチャパターンに関する私の投稿で1つの説明を見つけることができます。

この投稿に到達すると、例を使用してパターンを理解するのに本当に役立つので、以下の表を作成して、Android Frameworkのデザインパターンとその例を明確に確認します

参考になれば幸いです。

• 参照用の便利なリンク：
  

  1. Kotlinを使用したAndroidの一般的なデザインパターン

  2. Androidデザインパターンの概要

  3. デザインパターン

Androidフレームワークでは、次のようなさまざまなパターンが使用されています。

• ブロードキャストレシーバーはObserverパターンを使用します
• リモートサービスの呼び出しはプロキシパターンを使用します
• ビューおよびビューグループは複合パターンを使用します
• メディアフレームワークはファサードパターンを使用します

Androidの一般的なデザインパターンに関するすばらしい記事を次に示します。

創造的なパターン：

• ビルダー（例 AlertDialog.Builderなど））
• 依存性注入（例：Dagger 2）
• シングルトン

構造パターン：

• アダプター（例：RecyclerView.Adapter）
• ファサード（例：後付け）

行動パターン：

• コマンド（例：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、プレゼンテーションモデル）はAndroidアプリに適用できますが、サードパーティのフレームワークがないと、適切に構成された構造とクリーンなコードを取得するのは簡単ではありません。

MVVMはPresentationModelに由来しています。MVC、MVVM、プレゼンテーションモデルを適用する場合をAndroidアプリ、私たちが本当に望んでいるのは、明確に構造化されたプロジェクトを作成し、ユニットテストをより簡単に行えるようにすることです。

現時点では、サードパーティのフレームワークがなければ、通常、ビジネス価値を追加しない多くのコード（addXXListener（）、findViewById（）など）があります。さらに、通常のJUnitテストの代わりにAndroidユニットテストを実行する必要があります。これにより、実行に時間がかかり、ユニットテストがやや実用的でなくなります。

これらの理由により、数年前にオープンソースプロジェクトである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はインテントを受け取り、ワーカースレッドを起動し、必要に応じてサービスを停止します。すべてのリクエストは単一のワーカースレッドで処理されます。

バインダーは、Death Recipient通知に「Observer Pattern」を使用します。