Androidライフサイクル対応アーキテクチャコンポーネント

2017年11月6日、Googleは安定バージョンの発表に関する情報を公開しました

建築コンポーネント 。 Google開発者は、 アプリケーションアーキテクチャに関するガイダンスを提供し、組み込みアーキテクチャを使用したアプリケーションの作成を簡素化し、プロジェクトへの新しいプログラマーの参加を容易にし、Androidシステムのプログラミングを始めたばかりの人々の成人開発の世界に入るためのしきい値を削減する多くのクラスとインターフェイスを導入しました。



Androidのライフサイクルを操作するために提示されたコンポーネントは、目に見えない時計仕掛けと比較できます。 ほんの数行のコードとすべてが機能します。 しかし、すべてがどのように配置されていますか？ とにかく、自宅のプロジェクトで、あるいは数十万のアクティブなインストールがあるプロジェクトでさえ、建築コンポーネントを使用する価値はありますか？

ライフサイクル、ライフサイクルを意識したコンポーネントおよびアクティビティ

ライフサイクルは、Android開発の世界で非常に重要なポイントであり、多くの場合、十分な注目を集めていません。 このため、アプリケーションでエラーが発生する場合があります。 たとえば、電話をかけると、アプリケーションが重大なエラーで終了する場合があります。 これは、アクティビティの再作成と未加工の状態の保存によるものです。



部分的には、アクティビティの再作成の問題を回避できます。 たとえば、再作成を禁止するには、マニフェストのアクティベーション設定をandroid：screenOrientation = "portrait"に設定します。 ただし、これは、構成の変更（たとえば、画面の向きの変更）中にアクティビティを再アクティブ化する問題のみを解決します。 ある時点でオペレーティングシステムがメモリ不足になり、実行可能なアクティビティでプロセスが破壊されるという問題は、この方法を解決しません。 アプリケーションの操作に戻ると、ユーザーが最初に目にするのは重大なエラーです。



いずれにしても、開発者はライフサイクルの状態を処理する必要があります。 ライフサイクル対応のコンポーネントが助けになります。 アーキテクチャコンポーネントには安定したバージョン1.0があり、アプリケーションの製品開発で使用できます。

ライフサイクル対応コンポーネントを使用する長所と短所

コンポーネントを使用する実際的な長所と短所を考慮してください。



間違いなくより多くのプラスがあります

1. 新しい従業員をアプリケーション開発チームに接続します。 すべてのAndroid開発者は、Googleの公式ライブラリを知っており、使用することができます。 アーキテクチャを維持するためにローカルソリューションの学習に時間を費やす必要はありません。
2. 機能を開発する際のコードが少なくなります。
3. コンポーネントの安定性;
4. コンポーネントの実装後のアプリケーションの安定性の向上。

短所

1. コンポーネントに精通し、プロジェクトに追加する時間。
2. 新しい関数を開発するときにアーキテクチャに付随するコードが追加されましたが、このマイナスはコード生成によって簡単に解決されます。 このトピックに関する良い記事はこちらとこちら 。

ライフサイクル対応コンポーネントを使用する方法

サポートライブラリバージョン26.1.0以降、フラグメントとアクティビティはそのままでLifecycleOwnerインターフェイスを実装します。 このインターフェースには、 getLifecycle（）という 1つのメソッドしかありません。

ライフサイクルイベントにオブザーバーを追加するには、オブザーバークラスにLifecycleObserverインターフェイスを実装し、アクティビティ/フラグメントを記述するだけで十分です。

private fun addLifecycleObserver() { lifecycle.addObserver(observer) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それだけですか？ はい、開発者にとって作業はここで終了します。 オブザーバーコードでは、必要なメソッドに注釈を付け、ライフサイクルイベントに応答するだけで十分です。

 @OnLifecycleEvent(Lifecycle.Event.ON_CREATE) fun init(){}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

興味深い事実は、いくつかのメソッドに同じ注釈を付けることができ、ライフサイクルの状態が変化するとそれらすべてが呼び出されることです。



いくつかの線の後ろに隠されているもの、すべてがどのように機能するか、ニュアンスは何ですか？

サンプルのフラグメントを使用して、以下の質問に対する回答を見つけます。

getLifecycle（）メソッドにLifecycleOwnerインターフェースを実装すると、フラグメントは何を返しますか？ 主な方法の説明

このフラグメントは、LifecycleOwnerインターフェースを実装し、 getLifecycle（）：Lifecycleメソッドを実装します。



ライフサイクルは、Androidライフサイクルを持つオブジェクトとしてオブジェクトを定義する抽象クラスです。



このクラスLifecycleRegistryの実装は、追加の制御、オブザーバーの削除、ライフサイクルイベントの処理、ライフサイクルの変更をすべてのオブザーバーに報告するすべての作業を引き受けます。



オブザーバーを追加します。

 @MainThread public abstract void addObserver(@NonNull LifecycleObserver observer);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

重要なニュアンスは、LifecycleObserverがオブザーバーのリストに追加されると、オブザーバーは現在の状態に先行するすべての状態の変更に関するイベントを受け取ることです。



つまり、 LifecycleObserverを追加するときにLifecycleOwnerがLifecycle.State.STARTED状態にある場合、後者は2つのLifecycle.Event.ON_CREATEおよびLifecycle.Event.ON_STARTイベントを受け取ります。



これは、オブザーバーが初期化のすべての段階を経て、ライフサイクルのイベントに依存し、構成のどの段階も見逃さないことを保証していることを意味します。



オブザーバーリストからオブザーバーを削除すると、メソッドで発生します。

 @MainThread public abstract void removeObserver(@NonNull LifecycleObserver observer);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ライフサイクルの状態の変更中にオブザーバーの削除が発生し、削除後に状態変更に関するイベントの送信が呼び出された場合、オブザーバーはこのイベントを受信しません。



オブザーバー内の複数のメソッドが1つのイベントを予期し、オブザーバーのリストからオブザーバーを削除するときに少なくとも1つのメソッドが呼び出された場合、他のすべてのメソッドも呼び出され、これが削除されます。



リクエストに応じて現在のステータスを返します。

 @MainThread public abstract State getCurrentState();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いつでも、ライフサイクルの現在の状態を要求し、その答えに基づいて任意のアクションを実行できます。 このメソッドは、State列挙のインスタンスを返します。



次のタイプの状態



INITIALIZED-この状態は、LifecycleOwnerインターフェイスを実装するエンティティが作成されたが、onCreate（）メソッドがまだ呼び出されていない時間に対応します。



CREATED-この状態は、onCreate（）を呼び出した後、onStop（）を呼び出す前にアクティブです。



STARTED-この状態は、onStart（）メソッドを呼び出した後、onPause（）を呼び出す前にアクティブになります。



RESUMED-この状態は、onResume（）メソッドが呼び出された後に発生します。



DESTROYED-この状態は、onDestroy（）呼び出しの直前に発生します。 この状態が発生すると、LifecycleOwnerは状態変更イベントを送信しなくなります。

オブザーバーがオブザーバーリストに追加されるとどうなりますか？

 @Override public void addObserver(@NonNull LifecycleObserver observer) { State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED; ObserverWithState statefulObserver = new ObserverWithState(observer, initialState); <...> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

lifecycle.addObserver（オブザーバー）メソッドが呼び出されると、オブザーバーはObserverWithStateラッパークラスインスタンスのコンストラクターに配置されます。 クラス名が示すように、このクラスにはライフサイクルの最後に処理された状態を持つオブザーバーが格納されます。 最初に、状態をDESTROYEDまたはINITIALIZEDに設定します。

 @Override public void addObserver(@NonNull LifecycleObserver observer) { <...> ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver); if (previous != null) { return; } LifecycleOwner lifecycleOwner = mLifecycleOwner.get(); if (lifecycleOwner == null) { // it is null we should be destroyed. Fallback quickly return; } <...> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ライフサイクルの最後に処理された状態でオブザーバーのインスタンスを作成した後、putIfAbsent（）メソッドを使用してオブザーバーをFastSafeIterableMapコレクションに追加しようとします。

 @Override public V putIfAbsent(@NonNull K key, @NonNull V v) { Entry<K, V> current = get(key); if (current != null) { return current.mValue; } mHashMap.put(key, put(key, v)); return null; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッドが要素を返す場合、その要素は既にコレクションに存在しているので、再度追加する必要はありません。 これはコードの後半で発生します。 リストにオブザーバーがいる場合、 addObserver（）メソッドの作業は停止します。 また、 lifecycleOwner == nullの場合、作業は終了します 。

 @Override public void addObserver(@NonNull LifecycleObserver observer) { <...> State targetState = calculateTargetState(observer); mAddingObserverCounter++; while ((statefulObserver.mState.compareTo(targetState) < 0 && mObserverMap.contains(observer))) { pushParentState(statefulObserver.mState); statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState)); popParentState(); // mState / subling may have been changed recalculate targetState = calculateTargetState(observer); } <...> }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ライフサイクルの現在の状態が計算され、オブザーバーに保存されている状態が現在の状態よりも小さくなるまでイベントの送信が開始されます。



upEvent（状態：状態）とは何ですか？ また、downEvent（状態：状態）があることに注意してください。 現在の状態に基づいて、ライフサイクルで何が起こっているかに応じて、どのイベントをオブザーバーに送信するかを決定できます。



メソッドの本体と下の図を見ると、これに対処するのは簡単です。

 private static Event downEvent(State state) { switch (state) { case INITIALIZED: throw new IllegalArgumentException(); case CREATED: return ON_DESTROY; case STARTED: return ON_STOP; case RESUMED: return ON_PAUSE; case DESTROYED: throw new IllegalArgumentException(); } throw new IllegalArgumentException("Unexpected state value " + state); } private static Event upEvent(State state) { switch (state) { case INITIALIZED: case DESTROYED: return ON_CREATE; case CREATED: return ON_START; case STARTED: return ON_RESUME; case RESUMED: throw new IllegalArgumentException(); } throw new IllegalArgumentException("Unexpected state value " + state); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LifecycleOwnerは、フラグメントライフサイクルで発生するイベントをLifecycleObserverにどのように通知しますか？

LifecycleOwnerインターフェースを実装するフラグメントには、 performCreate（savedInstanceState：Bundle） 、 performStart（） 、 performStop（）など、ライフサイクルイベントに対応する呼び出しに使用できるメソッドが多数含まれています。



FragmentManagerImplクラスはこれらのメソッドを呼び出し、対応するonStart、onStop、およびその他のメソッドがフラグメントで呼び出されます。 また、LifecycleRegistryクラスのメソッドも呼び出します。

 void performStart() { <...> onStart(); mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LifecycleRegistryクラスは、受信したイベントに基づいて、次のイベントの送信に関する状態を計算します。

 public void handleLifecycleEvent(@NonNull Lifecycle.Event event) { State next = getStateAfter(event); moveToState(next); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、オブザーバーに送信するイベントのタイプ-upEvent（状態：状態）またはdownEvent（状態：状態）が計算されます

 void dispatchEvent(LifecycleOwner owner, Event event) { State newState = getStateAfter(event); mState = min(mState, newState); mLifecycleObserver.onStateChanged(owner, event); mState = newState; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

実際、Googleが作成したクラスとインターフェースの一部のみが説明されています。 しかし、すべてがどのように発生し、数行のコードの背後にあるものを想像するには、これで十分です。

Google開発者は、アーキテクチャをサポートするアプリケーションを開発するための真に強力なツールを提供しています。 開発者は、他のコンポーネントと一緒に、信頼できるアプリケーションを開発し、独自の、必ずしも理想的なソリューションとは限りません。