今日、私はAndroidアーキテクチャのベストプラクティスプロジェクトを推進しています。
一目で記事ディレクトリ
- 序文
- 標準化に向けた開発が現実になりました
- この記事の目的
-
Jetpackライフサイクル
- ライフサイクル前の無秩序な世界
-
ライフサイクルがこれらの問題を解決できるのはなぜですか？
-
Jetpack LiveData
- LiveDataが存在する前の混沌とした世界
- LiveDataがこれらの問題を解決できるのはなぜですか？
-
LiveDataには注意すべき穴があります
-
Jetpack ViewModel
- ViewModelが存在する前の混沌とした世界
-
なぜViewModelはこれを実行できるのですか？
-
Jetpack DataBinding
- DataBindingの前の無秩序な世界
-
DataBindingはこれらの問題を解決することです
- 要約すると
Jetpackライフサイクル
ライフサイクルの存在は主にライフサイクル管理の一貫性の問題を解決することです
ライフサイクル前の無秩序な世界
ライフサイクルが市場に出る前は、ライフサイクル管理は純粋に手動によるメンテナンスでした。そのため、多くの一貫性の問題を簡単に発生させることができました。
たとえば、ページ間で共有されるGpsManagerコンポーネントは、それに依存するアクティビティの各onResumeおよびonPauseで手動でアクティブ化、バインド解除、および停止する必要があります。
次に、アクティビティの増加に伴い、この隠れた手動操作の危険性が指数関数的に増加します。
一方では、手動で保守する傾向のある開発者は、特に作業が他の同僚に引き渡される場合に過失を犯しがちであり、同僚はこれらの詳細に時間内に気付くことができません。
一方、散在するコードは変更の助けにはなりません。アクティベーションと将来の停止に加えて、補足する必要がある他の操作（ステータスモニタリングなど）がある場合は、各アクティビティを再度書き込む必要があります。
ライフサイクルがこれらの問題を解決できるのはなぜですか？
ライフサイクルは、ライフサイクル管理のすべての複雑な操作をテンプレートメソッドモードとオブザーバーモードを通じてLifecycleOwnerの基本クラス（ビューコントローラーの基本クラスなど）にカプセル化し、その背後の開発者のために静かに戦略化します。
したがって、開発者はビューコントローラ（サブクラス）で1つの文のみを使用できます。
getLifecycle（）。addObserver（GpsManager.getInstance）は、内部のサードパーティコンポーネントによるLifecycleOwnerライフサイクルの認識をエレガントに完了します。
一貫性の問題を解決することに加えて、これは偶然にも2つの他の利点を提供します：
1.状態を監視するためにビューコントローラーを挿入する習慣を避ける
状態を監視する必要がある場合、以前は、メソッドを通じてアクティビティやその他のパラメータを手動で注入する方法がありました。これは、メモリリークの隠れた危険を埋めるものでした。これは、アクティビティであるため、チームの初心者は将来このコンポーネントに依存する傾向があるためです。他のメンバー。
現在では、コンポーネント内のLifecycleOwnerの状態を直接監視して、この不適切な使用を回避できます。
2.事故の原因を追跡するためにビューコントローラを注入する習慣を避ける
事故が発生したときに、過去に事故の原因をコンポーネントで追跡したい場合は、メソッドからアクティビティなどを直接注入する必要があり、メモリリークの隠れた危険も埋められていました。コンポーネントがDefaultLifecycleObserverを実装するようになったので、ライフサイクルコールバックメソッドのLifecycleOwnerパラメーターを介して、メソッドスコープの事故の原因を知ることができます。非表示の操作を追加する必要はありません。
これがわからない場合は、「実際のJetpackライフサイクルを復元する」で提供したGpsManagerのケースを参照してください。この記事は完全ではありません。
Jetpack LiveData
LiveDataの存在は、主に初心者や退役軍人が、考えずに唯一の信頼できるソースを介して状態を配布するという標準化された開発コンセプトに従うのを助け 、それにより、迅速な開発プロセスで追跡が困難で、トラブルシューティングが困難で、予期しない問題の可能性を減らします最小。
LiveDataが存在する前の混沌とした世界
LiveDataのリリース前は、主にEventBusまたはJavaインターフェイスを介してステータスを配布していました。ネットワークリクエストコールバックまたはクロスページ通信に使用するかどうかは関係ありません。
問題は何ですか？まず、EventBusは純粋なバスであり、上記の標準化された開発コンセプトの制約が欠けているため、このフレームワークを使用すると、分散化されて乱用されやすく、予期しない受信などの予測できないソースが発生します。古いデータをプッシュして取得し、イベントソースの複雑さをn²の状況まで追跡します。
さらに、EventBus自体はライフサイクルのサポートを欠いており、ライフサイクル管理の一貫性の問題があります。これはEventBusの欠陥であり、EventBusの使用を拒否する主な理由でもあります。
上記の状況がよくわからない場合は、「ほとんど知られていない背景とLiveDataのユニークな使命」で私から提供されたプレーヤーステータスのグローバル通知のケースを参照してください。
LiveDataがこれらの問題を解決できるのはなぜですか？
まず、LiveDataは、Googleが標準化および標準化された開発モデルを確立することを望んでいるという背景の下で生まれました。したがって、この困難な使命を達成するために、Googleは状態入力と監視のみをサポートするように非常に制限して設計しました。シングルトンと連携して、唯一の信頼できるソースからビューコントローラへの状態の転送を完了する必要があります。
（ViewModelは、とりあえずシングルトンであり、ファクトリパターンによって実装された疑似シングルトンです。唯一の信頼できるソースは、ライフサイクルがView Controllerに依存しないデータコンポーネントで、通常はシングルトンまたは共有ViewModelです）
これにより、イベントトレーサビリティの複雑さがn²の迷路で時間を浪費することなく、予測可能な便利な方法でステータスプッシュをソースまで追跡できます。（つまり、どのビューコントローラが共有状態変更のリクエストを開始したかに関係なく、最終的な状態変更は、唯一の信頼できるソースとしてシングルトンまたはSharedViewModelによって1対多に通知されます。）
さらに、この浮き沈みのアプローチにより、一方向の依存関係が可能になります。シングルトンはJavaインターフェースコールバックを介してビューコントローラーに通知する必要がないため、ライフサイクルの長い単一ライフの依存関係によってビューコントローラーによって埋め込まれたメモリリークの隠れた危険を回避できます。 。
LiveDataには注意すべき穴があります
ただし、LiveDataのデザインには穴があります。
ビューコントローラーの再構築後に監視されるLiveDataの最後のデータを自動的に注ぐことができるようにするために、LiveDataはスティッキーイベントとして設計されています。
-これはバグでさえ、拡張性の低い設計だと思います。
MVVMは全体であるので、ViewModelは共有スコープをサポートし、公式ドキュメントはViewModelを共有してページ間通信を実現する必要性を認識しています。
「オープンおよびクローズの原則」に基づいて、LiveDataは、特に非スティッキーイベント通信のために、MutableLiveDataで低レベルのサポートを提供する必要があります。予期されるエラー。
スティッキーでないLiveDataの実装に関して、インターネットでそれを解決するには、「イベントラッパークラス」（kotlinの場合のみ）と「リフレクション介入LastVersion」（Javaの場合）の2つの方法があります。
juejin.im/post/5b2b1b…
blog.csdn.net/geyuecang/a…
使用する実装に関係なく、従来のLiveDataに続く開発哲学に従い、唯一の信頼できるソースの配布ステータスを介してイベントのソースを追跡することをお勧めします。「分散型」バス方式では、プロジェクトでこれを使用することを拒否します。
（具体的には、将来のオープンソースのベストプラクティスプロジェクトでのUnPeekLiveDataの使用を示します）
Jetpack ViewModel
ViewModelの存在は、主に状態管理とページ通信の問題を解決することです。
ViewModelが存在する前の混沌とした世界
ViewModelの主な仕事は、状態ホスティングと状態管理の分離です。つまり、View Controllerが再構築されるとき、
軽量な状態の場合、ビューコントローラの基本クラスのsaveInstanceStateメカニズムを使用して、シリアル化された方法でストレージとリカバリを完了することができます。
ネットワークリクエストを通じて取得したリストなどの重い状態の場合、ビューコントローラーよりもライフサイクルが長いViewModelで保持できるため、効率の悪いシリアル化の方法ではなく、ViewModelから直接回復できます。
Jetpack ViewModelのリリース前は、MVPのPresenterもMVVM-CleanのViewModelも、状態管理を分割して征服することができませんでした。
PresenterとClean ViewModelのライフサイクルは、ビューコントローラーでライブとダイの両方が行われるため、最大でDataBindingの状態ホスティングを提供し、状態を分割して征服することはできません。
Jetpackのバージョンでは、ViewModelは絶妙なデザインで状態管理と共有可能なスコープを実現します。
なぜViewModelはこれを実行できるのですか？
実際、このバージョンは主にファクトリモデルに基づいているため、ViewModelはLifecycleOwnerによって保持され、ViewModelProviderを通じて参照されます。
したがって、それは単一のケースに似ています：-LifecycleOwnerのアクティビティとして保持されている場合、アクティビティの下でフラグメントのライフサイクルから分離でき、それによってスコープの共有を実現します。
実際、これは単一のケースではありません：-ライフサイクルはLifecycleOwnerとしてView Controllerに従います。Owner（アクティビティまたはフラグメント）が破棄されると、それもクリアされます。
さらに、ビューコントローラーの再構築を考慮して、Googleは保持メカニズムを通じてViewModelをビューコントローラーの基本クラスに保持しました。
したがって、スコープの共有とビューの再構築の場合、状態はそのまま保持され、ビューコントローラーは復元時に直接使用できます。
さらに、スコープの共有を考慮しているため、ViewModel自体もページ間通信（イベントコールバックなど）の責任を負います。以前にLiveDataを導入すると、イベント通信中のLiveDataの粘着性のあるデザインの問題が導入されたため、ここでは説明しません。
Jetpack DataBinding
DataBindingの存在は、主にビュー呼び出しの一貫性の問題を解決することです。
DataBindingの前の無秩序な世界
DataBindingが表示される前に、ビューの状態を変更する場合は、まずtextView.setText（）などのビューを参照する必要があります。
問題は何ですか？
ページに水平レイアウトと垂直レイアウトがあり、2つのレイアウトコントロールに違いがある場合、たとえば、水平画面にtextViewコントロールがあるが、垂直画面がない場合、ビューコントローラーでtextViewに対して空の判定処理を実行する必要があり、一貫性が生まれます性的な問題-怠慢になりやすく、空気を判断するのを忘れがちです。結局のところ、何十ページものページと無数のコントロールが各ページにあります。
どうすればいいですか？
DataBindingはこれらの問題を解決することです
レイアウト内の監視可能なデータとバインドすることにより、データが新しいコンテンツに設定されると、コントロールにも通知され、更新されます。
つまり、DataBindingを使用した後の唯一の変更点は、ビューを手動で呼び出して新しい状態を設定する必要がなく、データ自体を設定するだけです。
したがって、DataBindingは多くの人が考えずに考えるものではなく、UIロジックをXMLに移動して書き込むことでデバッグするのは困難です。実際は次のようではありません。
DataBindingは、データのバインドとUIロジックの最後の状態の変更（つまり、デバッグする必要のない分離不可能なアトミック操作）のみを担当し、ビューコントローラーでのUIロジックの記述方法、それでも書き込みますが、textView.setText（xxx）は不要ですが、直接xxx.set（）です。
それでは、DataBindingの助けを借りて、合計でいくつの利点がありますか？
1.ビューステートの一貫性の問題を回避します。手動で空と判断する必要はありません。
2.ビューステートの一貫性の問題が回避され、ビューの呼び出しも行われないため、findViewByIdを記述する必要がありません。
3.ビューを呼び出したい場合でも、findViewByIdを指定する必要はありませんが、バインディングを通じて直接参照します。
4.以前のUIロジックは基本的に変更する必要はありませんが、端末の状態を変更する方法としてのみです。
さらに、DataBindingには、コントロールにカスタムプロパティを提供できるBindingAdapterという大きなキラーがあります。これにより、丸みを帯びたDrawableの多重化の問題（ご存知）を解決できるだけでなく、imageViewダイレクトバインディングURLやその他の要件も実現できます。それができないこと、あなたが考えることができないことだけです。DataBindingの利点は、あなたが採掘するのを待っています。
DataBindingの注意点や、繰り返し試行する際の注意点については、「Jetpack DataBindingを誤解せず本当の香りに！」をご覧ください。"、ここでは完全ではありません。
要約すると
ライフサイクルの存在は、主にライフサイクル管理の一貫性の問題を解決することです。
LiveDataの存在は主に、初心者やベテランが標準の開発コンセプトに従って、考えずに唯一の信頼できるソースを介して状態を配布することを支援し、迅速な開発プロセス中に追跡が困難でトラブルシューティングが困難で予測不可能な一連の問題を回避することを目的としています。
ViewModelの存在は、主に状態管理とページ通信の問題を解決することです。
DataBindingの存在は、主にビュー呼び出しの一貫性の問題を解決することです。
それらのほとんどは、ソフトウェアエンジニアリングのコンテキストで一貫性の問題を解決し、エラーが発生しやすい操作をバックグラウンドでカプセル化し、ユーザーが予期しないエラーを生成せずに迅速かつ安定してエンコードできるようにするために存在します。
ということで、分かりますか？
あなたがこの記事を気に入った場合、物品は、容易ではない、またはあなたが、私たちが助けるという希望をたくさん持って親指がアップし、前方に、関係します。記事は継続的に更新されます。絶対ドライグッズ！！！