Androidは最初からMVVMアーキテクチャを構築します(2)———— ViewModel

私が本当にMVVMアーキテクチャにコンタクトして使用したとき、その人全体は良くありませんでした。個人的には、MVVMはMVCやMVPよりも学習が難しく、デザインの知識も少なからずあると感じています。ゆっくりと自分の成長を記録したいと思います。間違いがあれば修正してください。

ゼロからMVVMアーキテクチャを構築するシリーズ記事(継続的な更新):
AndroidがゼロからMVVMアーキテクチャを構築(1)———— DataBinding
AndroidがゼロからMVVMアーキテクチャを構築(2)———— ViewModel
AndroidがゼロからMVVMアーキテクチャを構築(3)———— LiveData
AndroidビルドMVVMアーキテクチャーをゼロから作成(4)————部屋(エントリーから高度なものまで)
AndroidビルドMVVMアーキテクチャーを最初から作成(5)————ライフサイクル
Androidビルドを最初から作成MVVMアーキテクチャ(6)———— Play Android APIを使用してMVVMフレームワークを構築します(主要記事)
AndroidはMVVMアーキテクチャを最初から構築します(7)———— Play Android APIを使用してMVVMフレームワークを構築します(最終記事)

まだその絵AAC(Androidアーキテクチャコンポーネント)

この記事では、ViewModelについて説明します。ここでは、MVVMのViewModelを簡単に理解します。これらのコンポーネントを理解したら、wanAndroid APIを使用して、トピックMVVMプロジェクトを確認します。


One、ViewModel

MVPのモデルを思い出してください。ここのViewModelは、MVPでのモデルの役割に多少似ています。しかしグーグルは一連のAACコンポーネントをリリースした。これらのコンポーネントにより、開発者は効率的なプロジェクトを開発できます。ViewModelもコンポーネントの1つです。

1.1。なぜこのViewModelコンポーネントがあるのですか

説明:ViewModelは、データ関連のUI
ロールのライフサイクルを保存および管理する方法です
。1、MVVMパターンで、モデルとビューの分離
2、データの準備を担当するUI
3、データストレージ

ここでの最大のハイライトはライフサイクルアプローチです。例:アクティビティで使用される場合。彼はアクティビティ全体のライフサイクルを実行します。最初に写真を見てください:

最初に結果を次のように要約します(例を使用して後で確認します)。

  • ViewModelはアクティビティ内でのみ存続し、一度だけ作成されます。破棄されると、onCleredがアクティブに呼び出されます。

ライフサイクル全体のアプローチが重要なのはなぜですか?例:アプリは、非常に時間がかかるネットワークチューニングインターフェイスのリクエストなど、頻繁に非同期でデータをリクエストする必要があります。たとえば、インターフェイスリクエストはアクティビティが破棄された後にのみ返されますが、メモリリークを考慮すると、複雑な作業がたくさん追加されます。しかし、ViewModelを使用してデータコールバックを処理することで、この問題を解決できます。つまり、ViewModelを継承している限り、発生する可能性のあるバグはすべて、Googleが対処するのに役立ちます。

  • アクティビティが有効なときに一度だけ作成されるため、このアクティビティの下のすべてのフラグメントはViewModelを共有できます
  • ViewModelのライフサイクルはアクティビティのライフサイクルよりも長い場合があるため、メモリリークを回避するために、ViewModelでコンテキストまたはアクティビティまたはビューへの参照を保持することは禁止されています。Contextを使用する必要がある場合
    は、AndroidViewModelクラスからApplicationContextを継承できます
  • 以前は、アクティビティを破棄して再構築すると、アクティビティのonSaveInstanceState()メカニズムを使用してデータを保存および復元できましたが、欠点は明白で、
    シリアル化および逆シリアル化できる少量のデータを保存する場合にのみ適していました。比較的大きなデータを保存する必要がある場合は、今度はViewModelを実現できます。


上記のライフサイクル図をどのように見ますか?

1. ViewModelのスコープに対応するアクティビティが作成されました(3つのライフサイクルが終了しました)。

2.横画面と縦画面の切り替えと同様にroraredアクティビティは、まだスコープ

3に対応しています。Finish()(アクティビティの破棄)、依存関係はスコープ

4、Finished(破棄されています)。ViewModelのonClearedを呼び出します。

それはあいまいで、例を見てください


2つ目は、ViewModelのライフサイクルを探る

まず、ViewModelを継承してMyViewModelを作成します。そしてonCleared()を書き換えます

public class MyViewModel extends ViewModel {
    
    
    @Override
    protected void onCleared() {
    
    
        super.onCleared();
        LogUtils.i("MyViewModel的相关","Activity被杀死后也会被销毁!");
    }
}

ViewModelのソースコードをクリックします。


このレイヤーは、特定のライフサイクルのバインドと破棄の特定の実装を明らかにしないためです。実装クラスを見つける必要があります。ここでは単純な使用の原則に基づいています。次に、アクティビティのMyViewModelのhashCode値を直接出力して、上の図、アクティビティのコードを確認します。ここでそれについてお話しましょう。ここではViewModelProcidersクラスを使用しているため、次の依存関係を導入する必要があります

実装 'android.arch.lifecycle:extensions:1.1.1'

public class ViewModelActivity extends FragmentActivity {
    
    

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
    
    
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_viewmodel);
        MyViewModel myViewModel = ViewModelProviders.of(this).get(MyViewModel.class);
        LogUtils.i("MyViewModel的相关", "onCreate ==> " + myViewModel.hashCode());
    }

    @Override
    protected void onStart() {
    
    
        super.onStart();
        MyViewModel myViewModel = ViewModelProviders.of(this).get(MyViewModel.class);
        LogUtils.i("MyViewModel的相关", "onStart ==> " + myViewModel.hashCode());
    }

    @Override
    protected void onResume() {
    
    
        super.onResume();
        MyViewModel myViewModel = ViewModelProviders.of(this).get(MyViewModel.class);
        LogUtils.i("MyViewModel的相关", "onResume ==> " + myViewModel.hashCode());
    }

    @Override
    protected void onPause() {
    
    
        super.onPause();
        MyViewModel myViewModel = ViewModelProviders.of(this).get(MyViewModel.class);
        LogUtils.i("MyViewModel的相关", "onPause ==> " + myViewModel.hashCode());
    }

    @Override
    protected void onStop() {
    
    
        super.onStop();
        MyViewModel myViewModel = ViewModelProviders.of(this).get(MyViewModel.class);
        LogUtils.i("MyViewModel的相关", "onStop ==> " + myViewModel.hashCode());
    }


    @Override
    protected void onDestroy() {
    
    
        super.onDestroy();
        MyViewModel myViewModel = ViewModelProviders.of(this).get(MyViewModel.class);
        LogUtils.i("MyViewModel的相关", "onDestroy ==> " + myViewModel.hashCode());
    }
}

プロジェクトを実行した後、印刷を確認してください。ここで、hashCode値がすべて同じであることがわかります。

次に、電話を水平方向と垂直方向に切り替えて、印刷を確認します。また、hashCode値が同じで、変更されていないことも確認できます。

最後に、このページを終了して、印刷を確認します。ここでは、ViewModelのonClearedが呼び出されて破棄された後に、hashCode値が再作成されます。ここで唯一疑わしい点は、これが公式のWebサイトマップとは少し異なることです。ViewModelの破棄はonCleredであり、これはOndestroyの前のステップです(グラフィック効果とは異なりますが、プロセスは正しいです。この部分に精通している場合は、ポインターを示してください)。


3.データをフラグメントと共有する

たとえば、アクティビティには多くのフラグメントが表示されています。ここでは、明確にするために、フラグメントのコードを確認するだけです。

//从getActivity()这句,那可不是同一个MyViewModel吗。
ViewModelProviders.of(getActivity()).get(MyViewModel.class)

これまでのところ、シンプルなViewModelの簡単な紹介と使用が行われています。ゆっくりと独自のMVVMフレームワークを一緒に実装してみましょう!

この記事のデモアドレス

おすすめ

転載: blog.csdn.net/leol_2/article/details/102396064