Androidライフサイクルのソースコード分析-100日を読み取るソースコード(1)

1.使用する

ライフサイクルフレームワークは、別のコンポーネント(アクティビティやフラグメントなど)のライフサイクル状態の変化に応じて操作を実行するコンポーネントを認識するために使用されます。これらのコンポーネントは、整理が容易で、多くの場合軽量で、保守が容易なコードを生成するのに役立ちます。
例:
アクティビティまたはフラグメントのライフサイクルで何らかの処理を行う必要がある場合:

override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        presenter.onCreate()
    }
override fun onStart(){
   super.onStart()
   presenter.onStart()
}
...
override fun onDestroy(){
   super.onDestroy()
   presenter.onDestroy()
}

この書き込み方法は、アクティビティまたはフラグメントの対応するライフサイクル関数でプレゼンターの対応するメソッドを呼び出す必要があります。この書き込み方法は、比較的重く、十分に軽くなく、プレゼンターとアクティビティを切り離しません。ライフサイクルの出現により、これが解決されます。問題。

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        lifecycle.addObserver(Presenter())
    }
}

class Presenter():LifecycleObserver {

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    fun onCreate(){

        println("presenter oncreate")

    }

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart(){
        println("presenter onstart")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun onResumse(){

        println("presenter on resume")
    }
    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun onPause(){

        println("presenter on pause")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    fun onStop(){
        println("presenter on stop")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun onDestroy(){

        println("presenter on destroy")
    }

このようにして、プレゼンターとアクティビティの関係が関連付け関係から依存関係に変わり、結合が減少します。同時に、プレゼンターを使用して、アクティビティの対応するライフサイクルを認識できるようになりました。アクティビティのライフサイクル機能におけるプレゼンターメソッド。

2.分析

2.1オブザーバーモード

インターフェイスとメソッドの名前から、ライフサイクル全体が実際にはオブザーバーパターンであることがわかります。以下はオブザーバーパターンのUMLクラス図
ここに画像の説明を挿入
です。duiyingLifecycleはどのようになっていますか?以下は、
ここに画像の説明を挿入
私が描いたライフサイクルのUMLクラス図です。カスタムアクティビティはSupportActivityから継承されます。SupportActivityはLifecycleOwnerインターフェイスを実装し、Lifecycleを実装するLifecycleRegistryオブジェクトを保持していることがわかります。このオブジェクトはオブザーバーとして理解できます。パターン内のLifecycleRegistrは、複数のLifecycleObserverを集約し、ライフサイクルが変更されたときに対応するメソッド呼び出しを行うようにLifecycleObserverに通知します。

2.2ライフサイクルの認識

ライフサイクルはライフサイクル認識のフレームワークですが、アクティビティのライフサイクルをどのように認識しますか?SupportActivityのonCretaeメソッドを見てください

protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ReportFragment.injectIfNeededIn(this);
    }

ここでは、最初にReportFragment.injectIfNeededIn(this)メソッドを呼び出し、このメソッドを確認します

public static void injectIfNeededIn(Activity activity) {
        // ProcessLifecycleOwner should always correctly work and some activities may not extend
        // FragmentActivity from support lib, so we use framework fragments for activities
        android.app.FragmentManager manager = activity.getFragmentManager();
        if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
            manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
            // Hopefully, we are the first to make a transaction.
            manager.executePendingTransactions();
        }
    }

非常に簡単です。現在のアクティビティにReportFragmentを追加することです。ReportFragmentのライフサイクル関数を見てください。

 @Override
    public void onActivityCreated(Bundle savedInstanceState) {
        super.onActivityCreated(savedInstanceState);
        dispatchCreate(mProcessListener);
        dispatch(Lifecycle.Event.ON_CREATE);
    }

    @Override
    public void onStart() {
        super.onStart();
        dispatchStart(mProcessListener);
        dispatch(Lifecycle.Event.ON_START);
    }

    @Override
    public void onResume() {
        super.onResume();
        dispatchResume(mProcessListener);
        dispatch(Lifecycle.Event.ON_RESUME);
    }

    @Override
    public void onPause() {
        super.onPause();
        dispatch(Lifecycle.Event.ON_PAUSE);
    }

    @Override
    public void onStop() {
        super.onStop();
        dispatch(Lifecycle.Event.ON_STOP);
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        dispatch(Lifecycle.Event.ON_DESTROY);
        // just want to be sure that we won't leak reference to an activity
        mProcessListener = null;
    }

    private void dispatch(Lifecycle.Event event) {
        Activity activity = getActivity();
        if (activity instanceof LifecycleRegistryOwner) {
            ((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
            return;
        }

        if (activity instanceof LifecycleOwner) {
            Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
            if (lifecycle instanceof LifecycleRegistry) {
                ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
            }
        }
    }

ディスパッチメソッドが呼び出され、ディスパッチメソッドがアクティビティがLifecycleOwnerインターフェイスを実装するかどうかを決定します。インターフェイスが実装されている場合は、LifecycleRegisterのhandleLifecycleEventが呼び出されるため、ライフサイクルのステータスがLifecycleRegistryによる各LifecycleObserverを呼び出します。Lifecycle.Eventのメソッドに対応します。フラグメントを介してアクティビティのライフサイクルを認識するこの方法は、実際にはグライドに反映されています。これはアクティビティのライフサイクル認識ですが、フラグメントについてはどうでしょうか。Fragmentのソースコードを見ると、FragmentはLifecycleOwnerインターフェイスも実装しており、LifecycleRegistryオブジェクトにも関連付けられていることがわかります。

void performCreate(Bundle savedInstanceState) {
        if (this.mChildFragmentManager != null) {
            this.mChildFragmentManager.noteStateNotSaved();
        }

        this.mState = 1;
        this.mCalled = false;
        this.onCreate(savedInstanceState);
        this.mIsCreated = true;
        if (!this.mCalled) {
            throw new SuperNotCalledException("Fragment " + this + " did not call through to super.onCreate()");
        } else {
            this.mLifecycleRegistry.handleLifecycleEvent(Event.ON_CREATE);
        }
    }

mLifecycleRegistry.handleLifecycleEventがperformCreateで呼び出され、performStartメソッドとperformResumeメソッドでも同じように呼び出されることを確認してください。実際、ここで興味深い現象は、ReportFragmentのdispatch(Lifecycle.Event.ON_CREATE)メソッドがonActivityCreatedで呼び出され、フラグメントのLifecycle.Event.ON_CREATEイベントの送信がperformCreateで呼び出されることです。これは問題。アクティビティのonCreateメソッドにフラグメントを追加し、このフラグメントがLifecycleObserverモニタリングも追加する場合、誰が最初にリッスンしますか?
例えば:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        lifecycle.addObserver(Presenter())
        supportFragmentManager.beginTransaction().replace(R.id.container,MainFragment()).commit()
    }

}

class Presenter:LifecycleObserver {

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    fun onCreate(){

        println("presenter oncreate")

    }

class MainFragment:Fragment() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        lifecycle.addObserver(FragmentPresenter())
    }
}

class FragmentPresenter:LifecycleObserver {

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    fun onCreate(){

        println("presenter fragment oncreate")
    }

}

プログラムを実行すると、印刷結果がプレゼンターoncreate、次にプレゼンターフラグメントoncreateであることがわかります。
これは非常に混乱します。フラグメントonCreateのライフサイクルはonActivityCreatedより前であることがわかっています。FragmentPresenterのonCreateメソッドを最初に実行しなかったのはなぜですか。理由は実際にはコミットです。非同期です。フラグメントが送信されると、その時点で呼び出されるため、MainFragmentはまだ追加されていませんが、ReportFragmentはmanager.executePendingTransactions()メソッドを呼び出し、既存のメソッドを実行します。このReportFragmentはFragmentManagerに追加されているため、ライフサイクルは状況に対応していません。MainActivityでMainFragmentがコミットした後にmanager.executePendingTransactions()も追加すると、印刷結果が逆になります。

2.3LifecycleRegister分析

LifecycleRegisterが焦点です。まず、addObserverメソッドを見てください。

@Override
    public void addObserver(@NonNull LifecycleObserver observer) {
        State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
        ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
        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;
        }

        boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
        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);
        }

        if (!isReentrance) {
            // we do sync only on the top level.
            sync();
        }
        mAddingObserverCounter--;
    }

ここで、ObserverWithStateが生成され、FastSafeIterableMapに配置されます。このクラス
は、オブザーバーを保存し、トラバーサル中に削除/追加を処理するためのカスタムリストです。
オブザーバー1とオブザーバー2はいつでも:addition_order(observer1)<addition_order(observer2)の場合、state(observer1)> = state(observer2)
次にhandleLifecycleEventメソッドを見てください。

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

まず、着信イベントに応じて対応する状態を取得します。具体的なオブジェクトの関係を下図に示します
ここに画像の説明を挿入
。moveToStateメソッドでは、syncメソッドが呼び出されます。

private void sync() {
        LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
        if (lifecycleOwner == null) {
            Log.w(LOG_TAG, "LifecycleOwner is garbage collected, you shouldn't try dispatch "
                    + "new events from it.");
            return;
        }
        while (!isSynced()) {
            mNewEventOccurred = false;
            // no need to check eldest for nullability, because isSynced does it for us.
            if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
                backwardPass(lifecycleOwner);
            }
            Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
            if (!mNewEventOccurred && newest != null
                    && mState.compareTo(newest.getValue().mState) > 0) {
                forwardPass(lifecycleOwner);
            }
        }
        mNewEventOccurred = false;
    }

ここで、ObserverWithStateの状態が現在の状態よりも小さい場合は、forwardPassメソッドが呼び出されます。現在の状態よりも大きい場合は、backwardPassメソッドが呼び出されます。ObserverWithStateのデフォルトの状態は、addObserverで決定されます。方法。

State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
        ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);

次に、forwardPassメソッドを見てください

private void forwardPass(LifecycleOwner lifecycleOwner) {
        Iterator<Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
                mObserverMap.iteratorWithAdditions();
        while (ascendingIterator.hasNext() && !mNewEventOccurred) {
            Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
            ObserverWithState observer = entry.getValue();
            while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
                    && mObserverMap.contains(entry.getKey()))) {
                pushParentState(observer.mState);
                observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));
                popParentState();
            }
        }
    }

ここでは、ObserverWithStateのdispatchEventメソッドを呼び出します。このメソッドを見てください。

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

真実が明らかになり、最終的にmLifecycleObserver.onStateChanged(owner、event);と呼ばれると同時に、状態を更新しました。このmLifecycleObserverはどのように取得し、具体的に何をしたのでしょうか。具体的には言いません。興味があれば、この記事の呼び出しメソッドは、ReflectiveGenericLifecycleObserverオブジェクトを生成します。このオブジェクトは、Presenterで宣言された@OnLifecycleEventアノテーションが付けられたメソッドのMethodオブジェクトを保持し、最後に呼び出します。

ここに画像の説明を挿入

私の公式アカウントをフォローすることを歓迎します

おすすめ

転載: blog.csdn.net/skateboard1/article/details/84254787