Androidの4つの主要コンポーネントの完全な解釈

「APPをどのように設計する必要がありますか？どのアーキテクチャパターンを採用する必要がありますか？イベントバスを使用する必要がありますか？」

Androidプラットフォームの開発者が、アプリで使用されるデザインパターンやアーキテクチャについて質問することがよくあります。しかし、その答えはあなたを驚かせる可能性があります。つまり、私たち（つまり、Androidプラットフォームチーム）はこれについて明確な見解を持っておらず、まったく見解がないとさえ言えます。

MVCまたはMVPまたはMVVMを使用する必要がありますか？私は知らない。実際、私は学校にいるときだけMVCを知っていました。他のアーキテクチャパターンは、一時的なGoogle検索を行った後にここに書き込まれました。

Androidは、アプリの作成方法について非常に強い見解を持っていると人々に感じさせるため、これは驚くべきことかもしれません。この見解は、Java APIや4つの主要コンポーネントなど、いくつかの高レベルの概念に反映されています。典型的なアプリケーション開発フレームワーク、開発者に教えてください、あなたはこの方法であなたの機能を実装するべきです。しかし、現実には、これはまったく当てはまりません。

AndroidコアAPI（コアAPI）を「システムフレームワーク」と呼ぶことができます。プラットフォームAPIの主な機能は、APPがオペレーティングシステムと対話する方法を定義することであり、APPの内部オペレーティングロジックとは関係ありません。

個人的な理解：コアAPIはオペレーティングシステムカーネルと見なすことができ、プラットフォームAPIは私たちがよく言うAndroidフレームワークと見なすことができます。

つまり、プラットフォームAPIの場合、プラットフォームAPIの機能と機能は、開発者の観点からもオペレーティングシステムの観点からも一貫性がないことが多く、ユーザーの使用を混乱させる可能性があります。

たとえば、オペレーティングシステムが「APPの実行方法」をどのように定義しているかを考えてみましょう。従来のシステムでは、最も基本的なことは、APPに実行方法を定義するmainメソッドを含めるように要求することです。

int main(...){
//我的APP从这里开始运行
}

個人的な理解：この記事の中心的なアイデアは、いわゆる4つの主要なコンポーネントによって、APPがオペレーティングシステムに実行方法を指示するだけであり、独自のAPPの設計方法とは関係がないことを説明することです。従来のアプリケーションでは、メインメソッドを使用してオペレーティングシステムに通知します。「ねえ、メインメソッドは私の入り口です。このメソッドから実行を開始してください。」Androidには4つの選択肢があり、各コンポーネントはオペレーティングシステム用です。 APPを実行します。

オペレーティングシステムがAPPを実行しようとしているので、mainメソッドが呼び出され、アプリケーションが実行を開始します。タスクが完了したと思うまで、好きなことを実行できます。ここでmainメソッドを定義するための要件は、何もしたり、mainと呼ばれる関数を完了したりすることではないことに注意してください。mainメソッドのmain関数は、APPを実行するためのエントリポイントを提供することだけです。

しかし、Androidの世界では、APPの入り口として明確なメインメソッドは必要ないと判断しました。APPの実行方法をシステムがより細かく制御できるようにする必要があるためです。では我们希望构建一个这样的系统，在该系统中，用户永远不需要考虑开启和停止一个APP，而把这些事交给系统去管理特に、。したがって、システムは、各APPの内部操作について詳しく知る必要があります。これにより、その時点でAPPが実行されていなくても、必要なときに定義された方法でAPPを起動できます。

個人的な理解：このシステムが理解する必要のある各APPの内部操作は、実際にはManifest.xmlファイルの内容です。

これを実現するために、APPのメインメソッドをシステムが相互作用できるいくつかの形式に分解します。これは、いくつかの形式でActivity、BroadcastReceiver、ServiceとContentProviderのAPI、Androidの開発者の大半は彼らに精通しています。

这些类好像在告诉你，你的APP内部应当怎样工作，但这是一种误解！事实上，这些类只是定义你的APP需要怎样与系统交互（以及系统怎样协调你的APP与其他APP进行交互）。这种与系统的交互一旦开始，系统就不再关心你的APP内部是怎样运行了。

この点をわかりやすく説明するために、これらのAPIがAndroidシステムにとって何を意味するかを簡単に見てみましょう。

アクティビティ

これは、APPがユーザーと対話するためのエントリポイントです。システムの観点から、アクティビティ用にシステムによって提供される主要な対話アクションは次のとおりです。

現在のプロセスが実行され続けることを保証するために、ユーザーが現在気にかけていること（つまり、画面に表示されていること）を追跡します。

個人的な理解：ここで、作成者は実際には、アクティビティからシステムによってアプリケーションが開始されると、アクティビティの開始状態と停止状態の間で、システムがアクティビティが常にデバイスの画面を占有し、アプリケーションがアプリケーションを占有することを保証することを意味しますシステムによって殺されることはありません。これは、アクティビティから独自のAPPを起動するときに、システムからAPPに与えられる一種の約束（単なる約束）です。
以前に使用されたプロセスを把握します。これらのプロセスには、ユーザーが戻る可能性のある停止されたアクティビティが含まれているため、これらのプロセスの優先度が高くなります。
ユーザーが前のアクティビティに戻ることができ、これらのアクティビティが前の状態をロードできるように、アプリケーションがプロセスが強制終了される状況を処理できるようにします。

個人的な理解：もちろん、リカバリ機能を約束したシステムのこの状態はに依存しているとあなたがあなた、その後、あなたは保存方法の活動状況に殺されるの過程で保存したい、それを維持したい、である、方法これらの状態をRestoreメソッドで取得して、アクティビティを復元できます。これを行うと、残りはシステムのビジネスになります。メモリ不足のためにアクティビティが強制終了された場合、システムはアプリケーションプロセスを再構築し、状態の復元を支援します。前のアクティビティ。ActivityonSaveInstanceStateonRestoreInstanceState
異なるアプリケーション間のユーザーフローの方法を提供します。もちろん、これは調整するシステムによって異なります。最も典型的な例は、共有機能の実現です。

アクティビティの場合、システムが気にしないのは次のとおりです。

システムがアクティビティの入り口からAPPUIに入ると、システムはアクティビティの内部ロジックの構成を気にしなくなります。すべてのアプリケーションロジックをこのアクティビティに含めることができます。たとえば、ビューを手動で変更したり、フラグメントやその他のフレームワークを使用したり、アプリケーションロジックを追加の内部アクティビティに分割したりできます。3つを同時に使用することもできます（ビューの変更、fragemntの使用、およびそれらを追加のアクティビティに分割することを参照）。アクティビティとシステムの間の合意に従う限り、システムはこれらのことを気にしません（適切な状態で起動し、状態を正しく保存/復元します）。

BroadcastReceiver

これは、システムが通常のユーザーフローに加えてイベントをAPPに渡すことを可能にするメカニズムです。最も重要なことは、これが別の明確に定義されたAPPへの入り口であるため、APPが現在実行されていない場合でも、システムはAPPにブロードキャストを配信できることです。そのため、たとえば、APPは事前にアラームをスケジュールして、ユーザーに次のイベントを通知できます。アラームをAPPのBroadcastReceiverに渡すことにより、アラームが発生する前にAPPを実行する必要がありません。

BroadcastReceiverの場合、システムが気にしないのは次のとおりです。

在APP内部分发事件BroadcastReceiverであり、イベントバスフレームワークを使用している場合でも、独自のコールバックシステムを実装している場合でも、その他のメソッドを使用している場合でも、イベントの受信はまったく異なります你都没有理由使用系统的广播机制，因为你并不是在App之间分发事件。

実際、システムのブロードキャストメカニズムを使用しないのには十分な理由があり、不必要な負担が多くなります。グローバルブロードキャストメカニズムを使用してAPP内でイベント配信を実装すると、多くのセキュリティ問題が発生します。

もちろん、純粋なインテント配信システムを実装するLocalBroadcastManagerコンビニエンスクラスも提供しています。そのAPIはシステムBroadcastReceiver APIと非常によく似ているため、必要に応じて使用できます。但再次强调，你没有理由在仅仅发生在APP中的事情上使用BroadcastReceiver机制。

サービス

さまざまな理由でAPPをバックグラウンドで実行する必要がある場合、サービスはそのようなエントリの1つです。APPの管理方法をシステムに指示するために、2つの意味的に異なるサービス（1つは開始サービス、もう1つはバインドされたサービス）があります。

開始サービスは、何らかの理由でAPPがシステムに通知するのと同じです。「ビッグブラザー、何かすることがあります。完了したと通知するまで実行させてください。」（現時点ではAPPと同等です。サービスはAPPを表し、システムはAPPとのみ通信します）ここでの「目的」は、ユーザーがAPPを離れた後、バックグラウンドでデータを同期したり、音楽を再生したりすることです。

同時に、開始サービスには2種類あり、1つはユーザーが認識できるもので、もう1つはユーザーが認識できないものです。これらの2つの異なる開始サービスにより、システムはそれらに対して異なる管理方法を採用できます。

音楽を再生するサービスはユーザーが直接認識できるため、サービスはシステムに「フォアグラウンドになり、通知バーに通知を掛けて、ユーザーが自分の存在を感じられるようにしたい」と言います。、システムこのサービスプロセスの操作を確実にするために最善の努力を払わなければならないことを知っています。なぜなら、このプロセスがダウンすると、ユーザーは不幸になるからです。
別のバックグラウンドサービスはユーザーが直接認識できないため、システムはこのサービスのプロセスをより柔軟に処理できます。システムがユーザーの即時の正常な動作を保証するために緊急にRAMを必要とする場合、システムはプロセスの強制終了を許可する場合があります（その後、サービスが可能になったときにサービスを開始できます）。

バウンドサービスは、他のアプリまたはシステムが使用するために実行されます。通常、サービスは他のプロセスにAPIを提供します。この場合、システムは2つのプロセス間に依存関係があることを認識しています。したがって、プロセスAがプロセスBのサービスにバインドされている場合、システムは、プロセスBとそのサービスがプロセスAに対して正常に動作することを保証する必要があることを認識します。さらに、プロセスAがユーザーが現在気にかけているプロセスである場合、システムは、プロセスBがユーザーが気にかけているプロセスでもあることを認識します。

サービスの柔軟性（良いものと悪いものの両方）により、サービスはさまざまなタイプのシステムで非常に便利なビルディングブロックになりました。リアルタイムの壁紙、通知リスナー、およびその他の多くのシステムコア機能はサービスとして構築されており、それらを実行する必要がある場合、システムはそれらをバインドします。

サービスの場合、システムが気にしないのは次のとおりです。

Androidは、プロセスの処理方法に影響を与えないAPPの内容を考慮しないため、このような状況でサービスを使用する理由はありません。たとえば、UIのデータをバックグラウンドでダウンロードする場合は、サービスを使用してこれを行うべきではありません。これらのことを行うときは、プロセスを実行し続けるようにシステムに指示しないことが非常に重要です。これは本当に不要だからです。！！！そうすることで、ユーザーが行っていることと調整するために、システムがプロセスをより自由に管理できるようになります（注：可以让系统在内存紧急的情况下，杀死你的进程，优先保证用户正在做的事情，这里忍不住吐槽一句：每个APP肯定都会觉得自己是最重要的哈，Google开发Android的人也是典型的理想主义！）

バックグラウンドスレッドを開始してデータ（またはサービスではない他のメソッド）をダウンロードするだけで、希望する結果が得られます。ユーザーがUIを使用している場合、システムはプロセスが実行されていることを確認します。したがって、ダウンロードは中断されることはありません。ユーザーがUIを離れても、RAMが急いでいない限り、プロセスは引き続き維持（キャッシュ）されるため、データのダウンロードを続行できます。

同様に、APPのさまざまな部分を接続するために、同じプロセスでサービスをバインドする理由はありません。システムはプロセスがそれ自体に依存していることを認識し、この依存関係を無視し、APPを通常のプロセスとして扱うため、そうすることに明らかな害はありません。しかし、これは実際にはあなたとシステムにとって不要です。別の方法として、シングルトンまたはその他のインプロセスパターンを使用して、アプリの一部を相互に接続することもできます。

ContentProvider

最後に、ContentProviderは、APPデータを他の場所に公開するために使用される専用のメソッドです。ContentProviderをこのように使用する多くのAPIとサポートライブラリがあるため、人々は通常、それらをデータベースの抽象化と見なします。しかし、システム設計の観点からは、これはContentProviderの本来の意図ではありません。

システムの場合、ContentProviderは、実際にはAPP内でパブリックに名前が付けられたデータアイテム（データアイテム）を取得するためのエントリポイントであり、各データアイテムはURIスキームによって識別されます。このようにして、APPは独自のデータ項目をURIスキームにマップする方法、およびこのURIスキームを他のAPPまたはシステムに公開する方法を決定できるため、APPまたはシステムはこのURIスキームを使用して独自の内部データを取得できます。。これにより、システムはいくつかの非常にユニークな方法でAPPを管理できるようになります。

URIスキームを公開する場合、APPは実行を継続する必要がないため、APPが実行されていない場合でも、これらのURIスキームは任意のアプリやシステムに公開できます。誰かがシステムに「このURIで表されるデータを教えてください」と言った場合にのみ、システムはAPPを実行させ、URIに対応するデータ項目を要求し、それをリクエスターに返します。
これらのURIは、重要なきめ細かいセキュリティモデルも提供します。たとえば、アプリは画像を表すURIをクリップボードに置くことができますが、そのContendProviderはロックされたままなので、誰も自由に取得することはできません。別のAPPがクリップボードからこのURIを取得し、対応する画像を取得するようにシステムに要求すると、システムは一時的な「URI権限」を付与して、URI、つまりAPPに対応する画像のみを取得できるようにします。残りのコンテンツ安全です。

ContentProviderの場合、システムが気にしないのは次のとおりです。

ContentProviderの背後では、システムはAPPがデータを管理する方法を気にしません。SQLiteデータベースに構造化データが必要ない場合は、SQLiteを使用する必要はありません。たとえば、FileProviderヘルパークラスを使用すると、APP内の元のファイルをContentProviderを介して簡単に取得できます。

同様に、他の人が使用できるようにアプリ内のデータを開示する予定がない場合は、ContentProviderを実装する必要はありません。これが当てはまるのは、ContentProviderの周りに便利なメソッドがたくさんあるためです。これらのメソッドを使用すると、SQLiteデータベースにデータを簡単に格納し、ListViewなどのUI要素にこれらのデータを入力できます。ただし、これらの方法で自分のアイデアを実現するのが難しいと感じた場合は、使用する必要はありません。APPに適したデータモデルを自由に選択してください。