私たちが知っているように、Androidのは、ローカル放送、プロセスなどの匿名の間のメモリ共有、テントバンドル転送、の間、そのように多くの方法で渡さAIDL 4つの主要コンポーネント、などの情報を渡すのさまざまな方法の多くを提供するものタイプは、それを直接渡す組立部品に適しています。
LoacalBroadcastRecevierあるローカル放送、。複数の通信は、システムの異なる構成要素の規定、その利点の同一アプリケーション内で行われる：他のAPPに漏れないブロードキャスト送信にのみ、それらのAPPに広がっていく、他のAPPは、そのアプリにブロードキャストを送信することはできません他のAPPによる干渉なし。ローカルブロードキャストインターホン通信、低コスト、高効率、しかしような欠点は、すべての通信メカニズムがシステムとの両方を委託することであるがあるが、我々は送信中に介入することができない任意の工程は、制御不能な、一般的に使用される比率は、通信プロセスの成分ではありません高いです。
プロセス間のAIDL。私たちが達成するためにAndroidのテンプレートを提供していますが、理解することがしばしば困難ユーザーとの対話がより複雑であるが、AIDL通信以外に、我々はスレッドで通信プロセスの要素になる傾向があり、そのプロセスの大きさ、およびは、システムレベルの通信、バインダーへの根底にある機構の一部であります、多くの場合、適用される部品の通信時には適用されません。
匿名メモリを共有しました。そのような場面では、Sharedpreferencesを使用するなど、マルチスレッド、しばしばスレッドセーフ、さらにいくつかのそのようなコンフィギュレーション情報中の成分として格納ほとんど情報の変更、などです。
テントバンドル配信。明示的および暗黙的の移転を含め、明示的なパッケージ名の転送が明確なパスが必要で、部品やアセンブリは、多くの場合、お互いに依存する必要があり、SOP（関心事の分離）のコンポーネントからこの出発は、隠されている場合、パッケージ名パスではないであろうだけではなく、繰り返し、あなたが一連のルールを定義する必要があり、唯一のパッケージ名間違ったパスが存在し、調査とそれがやや面倒でもあり、このアプローチは、コンポーネント間のより適切な内部転送、他のコンポーネント多くのシーンを使用して外付け部品取引する傾向があります。
主な困難は、（開発中のAndroid結節あるモジュールとモジュールを交換するために）通信する方法の質問には直接言及モジュラーモジュール間ではありません、私たちは、次の主要なアイデアを学びました：
- 共通モジュールの確立は、各機能モジュールは、共通モジュールにインタフェースを露出する必要があり、一般に公衆にインタフェースモジュール管理クラスが存在し、各モジュール内の実装クラスは、初期化時に、各モジュールマップでありますそれらのインタフェースと実装クラスときマップ（インターフェイス登録）に、各モジュールは、インタフェースの実装クラスを介して取得するために追加のモジュール機能、関数呼び出し（アクセスへのインターフェース）を必要とします。これは、インタフェースが構造体として有利である、共通モジュールは、機能モジュール用のインタフェースとデータ構造を提供し、これはまた、初期のプロジェクトの多くを使用するための方法を考えるための最も簡単な方法で、ソート「SDK」道のようなのでした明確かつ直感的、簡単に、より親しみやすいIDEのために、呼び出しチェーンをトレースする（あなたはIDEに直接ジャンプすることができます）、プロトコルを直接保守インタフェースはシンプルで、コンパイルに反映変わります。欠点は、初期設定の登録に起因して、呼び登録、正しい設計のライフサイクルの順序に厳密に従って、相互依存の関係チェーンの設計にも時間がかかり、このプロセスは「危険」である。しかし、言い訳のすべての種類は、従属変数であります。
- このようなバスやRxBusの方法としてEventBusイベントを使用するなど、イベント通知の種類は、あなたがデカップリング、対応するクロスモジュールを完了することができますが、それは最も推奨される方法ではありませんが、この方法は、それぞれの時間は、通信の種類を定義する必要があり、面倒な、本質的には適していませんが、EventBusまたは複数の通知、多くの1つの有利になるように偏っしなければならないと思ったRxBusが、戻り値は良いの契約ではありません。イベントイベントバスは最も不適切な方法でなければならないので、モジュール間通信機能は、より可能性が高い一般的に一つずつ、時々同期戻り値を提供することです。
- ルーティングフレームワークを使用して、一般的に使用されるオープンソースライブラリはARouterもサポートサービスを提供しながら、このモデルは今も多くのプロジェクトで使用することができ、ページ間の結合を低減、URLでページ間のジャンプを達成するためにARouter、ActivityRouterなどを、持っています文字がでているための方法が、私はこのルートは、ページジャンプシーンのフレームワークをより重視することができ、プロジェクトのほとんどが唯一のインターフェースモジュール間の単純なページやジャンプを提供して実現することができると思うことは十分であり、文字列を表し、界面を形成するためのプロトコルは、のように直感的に比較されません。
- 反射モード：APPは、反射モジュールクラスまたはメソッドによって相互に特性を統合と呼ぶことができます。反射がクラスパスとクラス名をハードコードされているので、別のモジュールのクラス名が変更された場合、それは反射につながるジャンプページを達成することはできません対応するクラスを見つけることができません。
使用AIDL：https://cloud.tencent.com/developer/article/1151076
：ベースAIDL IPC https://www.ctolib.com/yifei8-ABridge.html
モジュラープラクティスの要約：https://github.com/LiushuiXiaoxia/AndroidModular
米国の組立工程フレーム群：https://tech.meituan.com/2018/12/20/modular-event.html
ドライ仕上げブログ：Androidのモジュラー/コンポーネント・ベースの通信フレームワーク https://www.ctolib.com/heimashi-module-service-manager.html#articleHeader3
Googleの公式ウェブサイトの例：
https://developer.android.com/topic/libraries/architecture/index.html
https://developer.android.com/jetpack/docs/guide#best-practices
