Android アプリの開発方法 - 経過#
#シリーズ
#2022-01-06
#android
#article/done/published
経過#
ステージ 1：単一のアプリ、単一のモジュール#
最初の要件は非常にシンプルで、単一のアプリが必要で、すべての機能を 1 つのモジュールに直接配置します。
component app
ステージ 2：単一のアプリ、複数の機能モジュール#
独立した機能モジュールが必要で、カスタマイズが必要です。DynamicFeature という 1 つの解決策があります。
component app
component dynamic_feature_a
component dynamic_feature_b
component dynamic_feature_n
dynamic_feature_a --> app
dynamic_feature_b --> app
dynamic_feature_n --> app
DynamicFeature はアプリストアのサポートが必要です。
独立したデプロイメントの場合はあまり使用しないかもしれませんが、https://github.com/iqiyi/Qigsaw を使用して動的機能をサポートするアプリストアを自分でデプロイすることもできます。ただし、デプロイは非常に複雑です。
もう 1 つの解決策はプラグイン化であり、ランタイムプラグイン化とコンパイル時プラグイン化の 2 つの方法があります。
コンパイル時プラグイン化は比較的簡単に実装でき、アプリの依存関係を動的に変更するだけで済みます。ランタイムでは、すべてのプラグインの実装を反射で取得し、対応するメソッドを呼び出すだけです。
component app
component feature_a
component feature_b
component feature_n
app --> feature_a
app --> feature_b
app --> feature_n
異なるプラグインモジュールをコンパイルする
build.gradle
dependencies{
if(useFeature("feature_a")){
implementation ":feature_a"
}
if(useFeature("feature_b")){
implementation ":feature_b"
}
}
ステージ 3：単一のアプリ、複数の機能モジュール、単一の共通モジュール#
機能モジュールの数が増えるにつれて、異なるモジュールには多くの重複したライブラリの依存関係があり、バージョンの競合が発生する可能性があります。
ツールライブラリのバージョンと使用方法を統一するために、共通ライブラリを導入する必要があります。
原則として、機能モジュール以外のコア機能の依存関係はすべて共通ライブラリに配置する必要があります。例えば、ネットワークリクエスト、画像処理、キーバリューストア、データベースなどです。
また、機能モジュールは直接サードパーティのライブラリに依存するべきではなく、将来のアップグレードや移行を容易にするために、共通ライブラリのラッピングを経る必要があります。
component app
component feature_a
component feature_b
component feature_n
app --> feature_a
app --> feature_b
app --> feature_n
component common
feature_a --> common
feature_b --> common
feature_n --> common
ステージ 4：機能モジュール間の相互依存#
機能モジュールの増加に伴い、機能モジュール間でも関連する呼び出しが必要になりますが、機能モジュールは階層的に同じレベルに属しているため、直接の依存関係を持つべきではありません。そうしないと、循環依存関係が形成されやすくなります。
そのため、共通機能モジュール（サービス）またはサービスバスを導入する必要があります。すべての機能モジュールは、サービス内のインターフェースを実装して他のモジュールにサービスを提供します。
共通モジュールと共通機能モジュールはここでフレームワークとして一緒になります。
package apps{
component app
}
package features{
component feature_a
component feature_b
component feature_n
}
app --> feature_a
app --> feature_b
app --> feature_n
package framework{
component common
component services {
component feature_a_service
component feature_b_service
component feature_n_service
}
}
features --> common
feature_a --> feature_a_service
feature_b --> feature_b_service
feature_n --> feature_n_service
モジュール間でのパブリックサービス呼び出しには、別の方法もあります。各機能モジュールが他のモジュールから呼び出されるためのパブリックサービスコンポーネントを個別に定義する方法ですが、依存関係が指数関数的に複雑になる可能性があるため、すべてのモジュールのパブリックサービスを統一的に管理する方法を採用しています。
component feature_a
component feature_a_service
feature_a --|> feature_a_service
component feature_b
component feature_b_service
feature_b --|> feature_b_service
component feature_n
component feature_n_service
feature_n --|> feature_n_service
feature_a --> feature_b_service
feature_b --> feature_a_service
feature_n --> feature_a_service
feature_n --> feature_b_service
ステージ 5：機能に特化#
機能をマーケットに登録し、アプリが自動的に機能を検出する
package framework{
package apps{
component app
}
component common
component services {
component feature_a_service
component feature_b_service
component feature_n_service
}
}
package features{
component feature_a
component feature_b
component feature_n
}
features --> common
app --> feature_a
app --> feature_b
app --> feature_n
feature_a --> feature_a_service
feature_b --> feature_b_service
feature_n --> feature_n_service