コンポーネント化の基礎知識
コンポーネント化の概念は、数年前に提案され、いくつかのフレームワークが派生しています.では、コンポーネント化とは何ですか.なぜコンポーネント化を使うのですか.モバイル側のプロジェクトが小さい場合、チームの人も多くなく、一般的にはビジネスロジックも複雑ではありません.この場合、通常のコードを書くと、問題ありません.しかし、プロジェクトが大きくなると、私たちのチームのように、androidは十数人を開発し、論理も乱れており、ボタンの表示はいくつかの論理によって制御されます.このような状況では、何人かの機能が交差している場合、自分の変更で他の人の論理に影響を与えないとは言い難いです.コード量の増加に伴い,1回のコンパイル時間も大幅に増加した.この場合、ビジネスロジックを分割し、n個の異なるmoduleに分割し、各moduleで独自の開発を行い、単独でパッケージ化してコンパイルできると良いのではないでしょうか.コンポーネント化とは,モジュールを分割し,デカップリングし,高度に多重化できる考え方である.では、コンポーネント化の基礎をどうするかについてお話しします.
Android studioではgradleはパッケージ構成を管理するために使用され、ASはメインエンジニアリングとmoduleライブラリを提供し、gradleのapply plugin:'com.android.Application'とapply plugin:'com.android.library'で判別するとgradleではアプリケーションIdでその項目のパッケージ名を指定し、sourceSetsでlib、src、Android Mainfestなどの情報を指定することができる.はい、ここでは、コンポーネント化に必要なものを考えてみましょう.moduleはlibraryライブラリとしても、独立したappとしても、どのように実現しますか.私がコンポーネント化に触れたばかりで、中のものが深いと感じました.実はgradleは私たちに方向を示してくれた.
appディレクトリのgradle構成は動かないで、moduleのgradle構成を変更します.プロジェクトのルートディレクトリのgradle.propertiesでboolean値を定義します.isNeedModule=trueです.これはスイッチです.trueの場合、moduleはlibraryだけです.値がfalseの場合、moduleは独立したappになってコンパイルし、インストールできることを示します.moduleのgradleがどのように書かれているか見てみましょう.まずapply pluginというプラグインです.isNeedModuleに基づいて表示を制御します.
以上、module間ではデータインタラクションがなく、ただの棚なので、このように組み合わせました.これはコンポーネント化の基礎でしょう.gradleの基礎知識を知らないで、直接彼にコンポーネント化を実現すると言ったら、彼はきっと難しいと感じて、手がつけられないに違いない.gradleがパッケージ名や構成リストなどを動的に構成できることを知って、それほど難しくないような気がします.コンポーネント化中のデータとActivityの振り替えは,三方ライブラリで実現できるが,現在の感覚が比較的よいのはアリのArouterであり,興味のあるものは検索できる.
Android studioではgradleはパッケージ構成を管理するために使用され、ASはメインエンジニアリングとmoduleライブラリを提供し、gradleのapply plugin:'com.android.Application'とapply plugin:'com.android.library'で判別するとgradleではアプリケーションIdでその項目のパッケージ名を指定し、sourceSetsでlib、src、Android Mainfestなどの情報を指定することができる.はい、ここでは、コンポーネント化に必要なものを考えてみましょう.moduleはlibraryライブラリとしても、独立したappとしても、どのように実現しますか.私がコンポーネント化に触れたばかりで、中のものが深いと感じました.実はgradleは私たちに方向を示してくれた.
appディレクトリのgradle構成は動かないで、moduleのgradle構成を変更します.プロジェクトのルートディレクトリのgradle.propertiesでboolean値を定義します.isNeedModule=trueです.これはスイッチです.trueの場合、moduleはlibraryだけです.値がfalseの場合、moduleは独立したappになってコンパイルし、インストールできることを示します.moduleのgradleがどのように書かれているか見てみましょう.まずapply pluginというプラグインです.isNeedModuleに基づいて表示を制御します.
if (isNeedModule.toBoolean()){
apply plugin: 'com.android.library'
}else {
apply plugin: 'com.android.application'
}
moduleを独立して実行するときに、独自のパッケージ名を付けたい場合は、同じように、 defaultConfig {
...
if (isNeedModule.toBoolean()) {
applicationId "com.module.lib"
}
...
}
次は構成リストです.moduleの構成リストを知っています.中にはLaunchエントリがありませんが、apkは構成リストにエントリを指定する必要があります.どうすればいいですか.直接moduleの構成リストにエントリActivityを追加しますか?これにより、メインエンジニアリングの構成リストと競合します.同様に、moduleとapkにそれぞれ使用する2つの構成リストを作成します. sourceSets{
main{
if (isNeedModule.toBoolean(){
manifest.srcFile 'src/main/library/AndroidManifest.xml'
}else {
manifest.srcFile 'src/main/AndroidManifest.xml'
}
}
}
これでいいです.指定した場所に構成リストを作成します.moduleにActivityという名前のMainActivity、library/Android Manifestがある場合.xmlの構成は次のとおりです.
独立アプリとしてAndroidManifest.xmlは
// Launch
心の細い友达はandroid:name=「.libApp」という行のコードに気づいたかもしれませんが、libAppはアプリケーションを継承するクラスで、その中で初期化の情報を作ることができます.しかし、問題が発生しました.moduleが独立apkとして使用されるとlibAppが初期化されます.もしそれがmoduleだけであればどうしますか.私が選んだ解決策は、反射を使用して、まず継承ライブラリにインタフェースを定義することです.例えば、public interface IApplication {
void init(Application application);
}
次にmoduleでクラスAを定義し、このインタフェースを実現し、init()メソッドで情報を初期化する.次にappマスターエンジニアリングで定義したApplicationでAのフルパスを書き出し、反射によってオブジェクトを作成し、init()メソッドを呼び出し、現在のApplicationをパラメータとして挿入します.以上、module間ではデータインタラクションがなく、ただの棚なので、このように組み合わせました.これはコンポーネント化の基礎でしょう.gradleの基礎知識を知らないで、直接彼にコンポーネント化を実現すると言ったら、彼はきっと難しいと感じて、手がつけられないに違いない.gradleがパッケージ名や構成リストなどを動的に構成できることを知って、それほど難しくないような気がします.コンポーネント化中のデータとActivityの振り替えは,三方ライブラリで実現できるが,現在の感覚が比較的よいのはアリのArouterであり,興味のあるものは検索できる.