私がAndroidアプリを開発する方法-経過

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：機能モジュールの相互依存#

機能モジュールが増えるにつれて、機能モジュール間でも関連する呼び出しが必要になりますが、機能モジュールは階層的に同じレベルに属しているため、直接の依存関係は持つべきではありません。そうしないと、循環依存が発生する可能性があります。
そのため、共通機能モジュール（サービス）またはサービスバスを導入する必要があります。
すべての機能モジュールは、servcies のインターフェースを実装して他のモジュールにサービスを提供します。
共通モジュールと共通機能モジュールはここでフレームワークとして一緒になります。

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