banner
jzman

jzman

Coding、思考、自觉。
github

Androidコンポーネント化の基礎

PS:あなたが今守っていることは、現時点では効果がないかもしれませんが、将来的には必要になるかもしれません。

アプリのプロジェクトが一定の複雑さに達すると、コンポーネント化は必須です。コンポーネント化により、機能の分割がより効果的に行えます。コンポーネント化について考えると、モジュール化を思い浮かべる人もいますが、実際にはコンポーネント化とモジュール化は本質的に同じです。どちらもコードの再利用とビジネスの解耦を目的としており、モジュール化は主にビジネスに基づいて分割され、コンポーネント化は主に機能に基づいて分割されます。コンポーネント化の基本的な側面を見てみましょう。

  1. コンポーネント間の遷移
  2. 動的な作成
  3. リソースの競合
  4. 静的な定数

コンポーネント間の遷移#

コンポーネント化では、2 つの機能モジュールが直接依存していない場合、ベースモジュールを介して間接的に依存関係を持つようになります。コンポーネント間の Activity の画面遷移では、相互に依存関係がないため、他のモジュールの Activity を参照できないことがよくあります。

暗黙的な遷移#

暗黙的な遷移は、Android のネイティブな Intent マッチングメカニズムを使用して対応する遷移を実現するものであり、Action を使用して対応する Activity に遷移する方法です。このような暗黙的な遷移の方法を使用すると、モジュールをまたいで Activity 間の遷移を実現できます。ただし、Activity がモジュールから削除され、対応する遷移が削除されない場合、引き続き遷移を行うと例外が発生することに注意してください。暗黙的な Intent の遷移を使用する場合は、その Intent を受け取るアプリが存在するかどうかを確認するために、その Intent オブジェクトに対して resolveActivity () メソッドを呼び出す必要があります。また、暗黙的な遷移の方法では、exported を false に設定して、自分自身のアプリのみが対応するコンポーネントを起動できるようにすることもできます。

ARouter の遷移#

Android 開発では、モジュールを異なるネットワークと見なし、対応するルーターは各モジュールを接続する中継点です。この中継点では、ページの遷移パラメータなどを統一的に処理できます。ARouter は、アリババがオープンソースで公開したページの遷移ルーターであり、ARouter を使用すると、隠れた遷移を使用してモジュール間、コンポーネント間の遷移や遷移プロセスの監視、パラメータの受け渡しなどを実現できます。ARouter は、パス遷移と URL 遷移の 2 つの方法をサポートしており、非常に柔軟に使用できます。ARouter の具体的な使用方法については、ここでは説明しませんが、別の記事で詳しく説明します。ARouter と Android の伝統的な遷移方法の比較は次のとおりです。

  1. 明示的な遷移はクラスに依存する必要があり、ルーター遷移は指定されたパスに基づいて遷移します。
  2. 暗黙的な遷移は AndroidManifest で集中管理されるため、協力開発が困難になります。
  3. ネイティブは AndroidManifest を使用して登録され、ルーターは注釈を使用して登録されます。
  4. ネイティブの startActivity の後、遷移プロセスは Android システムによって制御されますが、ルーター遷移は AOP アスペクトプログラミングを使用して遷移プロセスをインターセプトおよびフィルタリングできます。

動的な作成#

コンポーネント化開発では、各モジュールやコンポーネント間の解耦を最大限にする必要があります。そのため、Java のリフレクションメカニズムを使用することを考えるのは自然なことです。リフレクションを使用すると、実行時に特定のクラスのすべての情報を取得し、そのクラスのプロパティやメソッドを動的に操作できます。Fragment を単独のコンポーネントとして使用する場合、通常の Fragment ではその Fragment が削除されたためにアプリがクラッシュする可能性がありますが、リフレクションを使用して Fragment を作成する方法を使用すると、少なくともアプリがクラッシュすることはありません。ここでは例外をキャッチして関連するロジックを実行できます。したがって、リフレクションには一定のパフォーマンスの問題があるかもしれませんが、リフレクションを使用することで耦合をある程度低減できます。コンポーネント化の一環として、Java のリフレクションメカニズムを学ぶことは必須です。

コンポーネント化開発では、各コンポーネントが独立して実行できることが求められます。一般的に、各コンポーネントには一定の初期化手順があります。最良のシナリオは、プロジェクトで必要ないくつかのコンポーネントの初期化が基本的に同じである場合です。その場合、初期化を BaseModule で統一的に行うことができます。ただし、このようなケースは理想的なものであり、一般的には各コンポーネントの初期化が異なる場合がほとんどです。おそらく各自の Application で初期化することを考えるかもしれませんが、各自の Application で初期化すると、最終的なビルド時に Application のマージに関連する問題が発生する可能性があります。この方法も望ましくありません。ここで再びリフレクションを思い浮かべます。各コンポーネントで初期化ファイルを作成し、最終的な Application でリフレクションを使用して各コンポーネントの初期化操作を完了することができます。ここでは、Java のリフレクションメカニズムを使用してコンポーネント化開発の Application の動的な設定を実現しました。

リソースの競合#

コンポーネント化開発の過程で、ModuleA の AmdroidManifest ファイルで android属性を使用して対応する Application を指定し、メイン App Module の AndroidManifest ファイルでも android属性を使用して対応する Application を指定した場合、この場合、メイン App Moduleの AndroidManifest ファイルで tools="android" を使用して競合を解決する必要があります。replace 属性を使用すると、この属性、つまりタグの android属性はコンパイルプロセスで置換可能であることを意味します。これにより、AndroidManifest ファイルの置換ルールに基づいて指定された Application は、最終的には App Module で指定された Application になるはずです。

例を挙げると、プロジェクトのある機能モジュールで SMSSDK を使用して SMS の検証機能を実装していますが、他の場所では使用しないため、使用する機能モジュールにのみ組み込んでいます。他のモジュールが使用する場合は、SMSSDK を BaseModule に組み込むべきです。SMSSDK を使用する場合、そのモジュールの Application を指定しない場合、MobSDK は com.mob.MobApplication をそのモジュールの Application に指定します。この場合、AndroidManifest ファイルの android属性が競合するため、replace 属性を使用する必要があります。AndroidManifest ファイルのマージ後の主な競合はこの問題です。もちろん、タグの他の属性にも競合があり、replace 属性を使用します。実際の開発では、より多くの検証が収穫をもたらすでしょう。

コンポーネント化開発では、リソース名が同じであるために最終的なマージ時にリソースの参照エラーや一部のリソースの欠落などが発生するのを防ぐ必要があります。文字列、色値などのリソースは、後から読み込まれた同じ名前のリソースによって置換されるため、解決策はリソースの命名に一定のルールを設けることです。build.gradle ファイルで "resourcePrefix" コンポーネント名 ""のように設定することで、開発者がリソース名が一意であることを確認することができます。モジュール内のリソースの命名形式は"Module 名_機能_その他 " とすることをお勧めします。

静的な定数#

コンポーネント化開発では、最終的なマージ時に各コンポーネントが Lib Module として存在するため、Lib Module の R.java ファイルで定義された静的変数は final として宣言されていません。これは、コンポーネントモジュールで対応する定数を使用できないことを意味します。たとえば、switch 文を使用することができません。そのため、コンポーネントでは switch 文の代わりに if 文を使用する必要があります。もちろん、コンポーネントが独立して実行される場合は、この問題は発生しません。

開発中には Butterknife をよく使用します。Butterknife は、View や View のイベントなどを注釈操作できる非常に便利なライブラリです。これは、コンパイル時の注釈メカニズムを使用しています。注釈では定数のみを使用できるため、Butterknife をコンポーネント化開発で使用する場合は、R の代わりに R2 を使用する必要があります。R2 は実際には R のコピーであり、R2 に対応する変数は final で宣言されているため、Butterknife をコンポーネント化開発で使用する場合は、該当する注釈で R の代わりに R2 を使用する必要があります。次の記事では、コンポーネント化開発の Application について説明します。

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。