Google Jetpack 自從推出以后幢码，極大地改變了 Android 開發(fā)者們的開發(fā)模式，并降低了開發(fā)難度唠摹。這也要求我們對當中一些子組件的實現(xiàn)原理具有一定的了解魂务，所以我就打算來寫一系列 Jetpack 源碼解析的文章，希望對你有所幫助 ??????

Lifecycle 是 Jetpack 整個家族體系內(nèi)最為基礎(chǔ)的組件之一考阱，正是因為有了 Lifecycle 的存在翠忠，使得如今開發(fā)者搭建依賴于生命周期變化的業(yè)務(wù)邏輯變得簡單高效了許多，使得我們可以用一種統(tǒng)一的方式來監(jiān)聽 Activity乞榨、Fragment秽之、Service当娱、甚至是 Process 的生命周期變化，且大大減少了業(yè)務(wù)代碼發(fā)生內(nèi)存泄漏和 NPE 的風險

本文就來對 Lifecycle 進行一次全面的源碼解讀政溃，基于以下版本來進行講解

implementation 'androidx.appcompat:appcompat:1.2.0'
implementation "androidx.lifecycle:lifecycle-common:2.2.0"
implementation "androidx.lifecycle:lifecycle-common-java8:2.2.0"
implementation "androidx.lifecycle:lifecycle-runtime:2.2.0"

一趾访、Lifecycle

現(xiàn)如今，如果我們想要根據(jù) Activity 的生命周期狀態(tài)的變化來管理我們的業(yè)務(wù)邏輯的話董虱，那么可以很方便的使用如下方式來進行監(jiān)聽扼鞋。以基于回調(diào)接口方法的形式來進行事件通知，每當 Activity 的生命周期方法被觸發(fā)時愤诱，該接口的相應(yīng)同名方法就會在之前或者之后被調(diào)用

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    lifecycle.addObserver(object : DefaultLifecycleObserver {
        override fun onCreate(owner: LifecycleOwner) {

        }

        override fun onResume(owner: LifecycleOwner) {

        }

        override fun onDestroy(owner: LifecycleOwner) {

        }
    })
}

此外還有一種基于 @OnLifecycleEvent 注解來進行回調(diào)的方式云头，這種方式不對方法名做要求，但是對方法的入?yún)㈩愋鸵搿⑷雲(yún)㈨樞蚶；薄⑷雲(yún)€數(shù)有特定要求，這個在后續(xù)章節(jié)會有介紹科吭。這種方式面向的是基于 Java 7 作為編譯版本的平臺昏滴，但在以后會被逐步廢棄，Google 官方也建議開發(fā)者盡量使用接口回調(diào)的形式

lifecycle.addObserver(object : LifecycleObserver {

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    fun onCreateEvent(lifecycleOwner: LifecycleOwner) {

    }

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    fun onDestroyEvent(lifecycleOwner: LifecycleOwner) {

    }

    @OnLifecycleEvent(Lifecycle.Event.ON_ANY)
    fun onAnyEvent(lifecycleOwner: LifecycleOwner, event: Lifecycle.Event) {

    }

})

Lifecycle 是一個抽象類对人，其本身的邏輯比較簡單谣殊，在大多數(shù)時候我們會接觸到的是其子類 LifecycleRegistry。Lifecycle 內(nèi)部僅包含一個全局變量牺弄，三個抽象方法姻几、兩個枚舉類

mInternalScopeRef 用于在引入了 lifecycle-common-ktx 包的情況，即只有在使用 kotlin 協(xié)程庫的時候才有用势告，在這里無需理會
三個抽象方法則分別用于添加 LifecycleObserver 蛇捌、移除 LifecycleObserver、獲取當前 Lifecycle 所處的狀態(tài)值
Event 類用于抽象 Activity/Fragment 的生命周期事件發(fā)生變化時所對應(yīng)的事件咱台。例如络拌，當 Activity 的 onCreate 方法被回調(diào)時就會被抽象為 ON_CREATE事件
State 類用于標記 Lifecycle 的當前生命周期狀態(tài)。例如回溺，當 Activity 即將回調(diào) onDestory 方法時則處于 DESTROYED 狀態(tài)

public abstract class Lifecycle {

    @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)
    @NonNull
    AtomicReference<Object> mInternalScopeRef = new AtomicReference<>();

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

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

    @MainThread
    @NonNull
    public abstract State getCurrentState();

    public enum Event {
        ON_CREATE,
        ON_START,
        ON_RESUME,
        ON_PAUSE,
        ON_STOP,
        ON_DESTROY,
        ON_ANY
    }

    @SuppressWarnings("WeakerAccess")
    public enum State {
        DESTROYED,
        INITIALIZED,
        CREATED,
        STARTED,
        RESUMED;
        public boolean isAtLeast(@NonNull State state) {
            return compareTo(state) >= 0;
        }
    }
}

二春贸、相關(guān)的接口

在 Lifecycle 體系中，很多事件回調(diào)和類型定義都是通過接口的形式來實現(xiàn)的馅而，這里再來羅列下開發(fā)者經(jīng)常會使用到的幾個接口及其作用

LifecycleOwner

LifecycleOwner 接口用于標記其實現(xiàn)類具備 Lifecycle 對象祥诽，實現(xiàn)了該接口即意味著實現(xiàn)類具有生命周期。我們?nèi)粘Ｊ褂玫?androidx.appcompat.app.AppCompatActivity 和 androidx.fragment.app.Fragment 均實現(xiàn)了該接口

public interface LifecycleOwner {
    @NonNull
    Lifecycle getLifecycle();
}

LifecycleObserver

LifecycleObserver 是一個空接口瓮恭，大部分情況下真正具有使用意義的是它的子接口雄坪，LifecycleObserver 可以說僅是用于類型標記

public interface LifecycleObserver {

}

LifecycleEventObserver

LifecycleEventObserver 用于監(jiān)聽 Lifecycle 的生命周期變化，可以獲取到生命周期事件發(fā)生的具體變化

public interface LifecycleEventObserver extends LifecycleObserver {
    
    void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event);
    
}

FullLifecycleObserver

FullLifecycleObserver 根據(jù) Activity 的生命周期回調(diào)方法擴展了幾個同名的抽象方法屯蹦，可以看成是對 LifecycleEventObserver 進行更加具體的事件拆分

interface FullLifecycleObserver extends LifecycleObserver {

    void onCreate(LifecycleOwner owner);

    void onStart(LifecycleOwner owner);

    void onResume(LifecycleOwner owner);

    void onPause(LifecycleOwner owner);

    void onStop(LifecycleOwner owner);

    void onDestroy(LifecycleOwner owner);
}

DefaultLifecycleObserver

DefaultLifecycleObserver 接口繼承于 FullLifecycleObserver维哈，DefaultLifecycleObserver 對父接口的所有方法都進行了默認實現(xiàn)绳姨。大多數(shù)情況下我們只需要一兩種生命周期事件的通知，DefaultLifecycleObserver 的存在就使得我們可以按需重寫父接口的方法而無需實現(xiàn)所有抽象方法阔挠。而接口可以聲明默認方法這一特性是從 Java 8 開始才有的飘庄，所以只有當你的項目是以 Java 8 作為目標編譯版本時才可以使用 DefaultLifecycleObserver。如果使用 FullLifecycleObserver 的話我們就必須實現(xiàn)所有抽象方法

public interface DefaultLifecycleObserver extends FullLifecycleObserver {
    @Override
    default void onCreate(@NonNull LifecycleOwner owner) {
    }
    @Override
    default void onStart(@NonNull LifecycleOwner owner) {
    }
    @Override
    default void onResume(@NonNull LifecycleOwner owner) {
    }
    @Override
    default void onPause(@NonNull LifecycleOwner owner) {
    }
    @Override
    default void onStop(@NonNull LifecycleOwner owner) {
    }
    @Override
    default void onDestroy(@NonNull LifecycleOwner owner) {
    }
}

DefaultLifecycleObserver 包含于androidx.lifecycle:lifecycle-common-java8:xxx 這個依賴庫內(nèi)购撼，該依賴庫也只包含該接口跪削，從依賴庫的命名也可以看出它是用于 Java 8 平臺的。Google 官方也建議開發(fā)者盡量使用 DefaultLifecycleObserver 迂求，因為 Java 8 最終是會成為 Android 開發(fā)的主流碾盐，而 Java 7 平臺下通過注解來實現(xiàn)生命周期回調(diào)的方式最終會被廢棄

FullLifecycleObserverAdapter

FullLifecycleObserverAdapter 實現(xiàn)了 LifecycleEventObserver 接口，用于在收到 Lifecycle 生命周期事件狀態(tài)變化時對 FullLifecycleObserver揩局、LifecycleEventObserver 進行事件轉(zhuǎn)發(fā)

class FullLifecycleObserverAdapter implements LifecycleEventObserver {

    private final FullLifecycleObserver mFullLifecycleObserver;
    private final LifecycleEventObserver mLifecycleEventObserver;

    FullLifecycleObserverAdapter(FullLifecycleObserver fullLifecycleObserver,
            LifecycleEventObserver lifecycleEventObserver) {
        mFullLifecycleObserver = fullLifecycleObserver;
        mLifecycleEventObserver = lifecycleEventObserver;
    }

    @Override
    public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {
        switch (event) {
            case ON_CREATE:
                mFullLifecycleObserver.onCreate(source);
                break;
            case ON_START:
                mFullLifecycleObserver.onStart(source);
                break;
            case ON_RESUME:
                mFullLifecycleObserver.onResume(source);
                break;
            case ON_PAUSE:
                mFullLifecycleObserver.onPause(source);
                break;
            case ON_STOP:
                mFullLifecycleObserver.onStop(source);
                break;
            case ON_DESTROY:
                mFullLifecycleObserver.onDestroy(source);
                break;
            case ON_ANY:
                throw new IllegalArgumentException("ON_ANY must not been send by anybody");
        }
        if (mLifecycleEventObserver != null) {
            mLifecycleEventObserver.onStateChanged(source, event);
        }
    }
}

三毫玖、ReportFragment

再來回顧下我們?nèi)缃袷侨绾瓮ㄟ^ Lifecycle 來實現(xiàn) Activity 的生命周期監(jiān)聽的

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    lifecycle.addObserver(object : LifecycleEventObserver {
        override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
            when (event) {
                Lifecycle.Event.ON_CREATE -> TODO()
                Lifecycle.Event.ON_START -> TODO()
                Lifecycle.Event.ON_RESUME -> TODO()
                Lifecycle.Event.ON_PAUSE -> TODO()
                Lifecycle.Event.ON_STOP -> TODO()
                Lifecycle.Event.ON_DESTROY -> TODO()
                Lifecycle.Event.ON_ANY -> TODO()
            }
        }
    })
}

用是這樣就能用了，但深究起來凌盯，此時一個很顯而易見的問題就是付枫，LifecycleEventObserver 是如何取得各個生命周期狀態(tài)變化的事件 Lifecycle.Event 呢？或者說驰怎，是誰回調(diào)了onStateChanged 方法呢阐滩？

現(xiàn)在我們在日常開發(fā)中使用的 Activity 往往都是繼承于 androidx.appcompat.appcompat:xxx 這個包內(nèi)的 AppCompatActivity，而 AppCompatActivity 最終會繼承于 androidx.core.app.ComponentActivity砸西， ComponentActivity 的 onCreate 方法是這樣的：

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

而正是通過 ReportFragment 使得 LifecycleEventObserver 可以接收到 Activity 所有的的 Lifecycle.Event叶眉。這里就來詳細看看 ReportFragment 的內(nèi)部源碼址儒，一步步了解其實現(xiàn)邏輯

injectIfNeededIn() 是一個靜態(tài)方法芹枷，以 android.app.Activity 對象作為入?yún)?shù)

public static void injectIfNeededIn(Activity activity) {
    if (Build.VERSION.SDK_INT >= 29) {
        // On API 29+, we can register for the correct Lifecycle callbacks directly
        //直接向 android.app.Activity 注冊生命周期回調(diào)
        activity.registerActivityLifecycleCallbacks(
                new LifecycleCallbacks());
    }
    // Prior to API 29 and to maintain compatibility with older versions of
    // ProcessLifecycleOwner (which may not be updated when lifecycle-runtime is updated and
    // need to support activities that don't extend from FragmentActivity from support lib),
    // use a framework fragment to get the correct timing of Lifecycle events
    //向 activity 添加一個不可見的 fragment
    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();
    }
}

injectIfNeededIn() 方法會根據(jù)兩種情況來進行事件分發(fā)：

運行設(shè)備的系統(tǒng)版本號小于 29。此情況會通過向 Activity 添加一個無 UI 界面的 Fragment（即 ReportFragment）莲趣，間接獲得 Activity 的各個生命周期事件的回調(diào)通知
運行設(shè)備的系統(tǒng)版本號大于等于29鸳慈。此情況會向 Activity 注冊一個 LifecycleCallbacks ，以此來直接獲得各個生命周期事件的回調(diào)通知喧伞。這里應(yīng)該還牽扯到對舊版本 ProcessLifecycleOwner 和 support 庫的兼容走芋，所以此時也會同時執(zhí)行第一種情況的操作

之所以會進行這兩種情況區(qū)分，是因為 registerActivityLifecycleCallbacks 中的 onActivityPostXXX 和 onActivityPreXXX 等方法是 SDK 29 時新添加的方法潘鲫。當版本小于 29 時翁逞，就還是需要通過 ReportFragment 來間接取得事件通知

SDK >= 29

先來看下 LifecycleCallbacks，其作用就是會在 Activity 的 onCreate溉仑、onStart挖函、onResume 等方法被調(diào)用后通過 dispatch(activity, Lifecycle.Event.ON_XXX) 方法發(fā)送相應(yīng)的 Event 值，并在 onPause浊竟、onStop怨喘、onDestroy 等方法被調(diào)用前發(fā)送相應(yīng)的 Event 值

static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {
    @Override
    public void onActivityCreated(@NonNull Activity activity,
            @Nullable Bundle bundle) {
    }

    @Override
    public void onActivityPostCreated(@NonNull Activity activity,
            @Nullable Bundle savedInstanceState) {
        dispatch(activity, Lifecycle.Event.ON_CREATE);
    }

    ···

    @Override
    public void onActivityPreDestroyed(@NonNull Activity activity) {
        dispatch(activity, Lifecycle.Event.ON_DESTROY);
    }

    @Override
    public void onActivityDestroyed(@NonNull Activity activity) {
    }
}

dispatch() 方法拿到 Event 值后津畸，就會先通過 Activity 拿到 Lifecycle 對象，再通過類型判斷拿到 LifecycleRegistry 對象必怜，最終通過調(diào)用 handleLifecycleEvent() 方法將 Event 值傳遞出去肉拓，從而使得外部得到各個生命周期事件的通知

@SuppressWarnings("deprecation")
static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) {
    //LifecycleRegistryOwner 已被廢棄，主要看 LifecycleOwner
    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);
        }
    }
}

從這也可以猜到梳庆，androidx.appcompat.app.AppCompatActivity 實現(xiàn)了 LifecycleOwner 接口后返回的 Lifecycle 對象就是 LifecycleRegistry暖途，實際上 androidx.fragment.app.Fragment 也一樣

SDK < 29

再來看下向 Activity 添加的 ReportFragment 是如何生效的。由于 ReportFragment 是掛載在 Activity 身上的膏执，ReportFragment 本身的生命周期方法和所在的 Activity 是相關(guān)聯(lián)的丧肴，通過在 ReportFragment 相應(yīng)的生命周期方法里調(diào)用 dispatch(Lifecycle.Event.ON_XXXX) 方法發(fā)送相應(yīng)的 Event 值，以此來間接獲得 Activity 的各個生命周期事件的回調(diào)通知

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

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

@Override
public void onDestroy() {
    super.onDestroy();
    dispatch(Lifecycle.Event.ON_DESTROY);
    ···
}

dispatch() 方法內(nèi)部會判斷目標設(shè)備的版本號來決定是否真的分發(fā) Event 值胧后，避免當 SDK 版本號大于 29 時和 LifecycleCallbacks 重復(fù)發(fā)送

private void dispatch(@NonNull Lifecycle.Event event) {
    if (Build.VERSION.SDK_INT < 29) {
        dispatch(getActivity(), event);
    }
}

這樣芋浮，ReportFragment 就通過上述邏輯向外部轉(zhuǎn)發(fā)了 Activity 發(fā)生的 Event 值

四、LifecycleRegistry

ReportFragment 最終在向外傳出 Lifecycle.Event 值時壳快，調(diào)用的都是 LifecycleRegistry 對象的 handleLifecycleEvent(Lifecycle.Event) 方法纸巷，既然需要的 Event 值已經(jīng)拿到了，那再來看下 LifecycleRegistry 是如何將 Event 值轉(zhuǎn)發(fā)給 LifecycleObserver 的

LifecycleRegistry 是整個 Lifecycle 家族內(nèi)一個很重要的類眶痰，其屏蔽了生命周期持有類（Activity / Fragment 等）的具體類型瘤旨，使得外部（Activity / Fragment 等）可以只負責轉(zhuǎn)發(fā)生命周期事件，由 LifecycleRegistry 來實現(xiàn)具體的事件回調(diào)和狀態(tài)管理竖伯。androidx.activity.ComponentActivity 和 androidx.fragment.app.Fragment 都使用到了 LifecycleRegistry

 public class ComponentActivity extends androidx.core.app.ComponentActivity implements
        LifecycleOwner,
        ViewModelStoreOwner,
        HasDefaultViewModelProviderFactory,
        SavedStateRegistryOwner,
        OnBackPressedDispatcherOwner {
            
    private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
            
    @NonNull
    @Override
    public Lifecycle getLifecycle() {
        return mLifecycleRegistry;
    }
            
}

public class Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner,
        ViewModelStoreOwner, HasDefaultViewModelProviderFactory, SavedStateRegistryOwner {
            
    LifecycleRegistry mLifecycleRegistry;
           
    @Override
    @NonNull
    public Lifecycle getLifecycle() {
        return mLifecycleRegistry;
    }
        
}

在具體看 LifecycleRegistry 的實現(xiàn)邏輯之前存哲，需要先對 LifecycleRegistry 的定位和必須具備的功能有一個大致的了解，可以從我們想要的效果來逆推實現(xiàn)這個效果所需要的步驟：

不單單是 Activity 和 Fragment 可以實現(xiàn) LifecycleOwner 接口七婴，像 Service祟偷、Dialog 等具有生命周期的類一樣可以實現(xiàn) LifecycleOwner 接口，而不管 LifecycleOwner 的實現(xiàn)類是什么打厘，其本身所需要實現(xiàn)的功能和邏輯都是一樣的：addObserver修肠、removeObserver、getCurrentState户盯、遍歷循環(huán) observers 進行 Event 通知等嵌施。所以 Google 官方勢必需要提供一個通用的 Lifecycle 實現(xiàn)類，以此來簡化開發(fā)者實現(xiàn) LifecycleOwner 接口的成本莽鸭，最終的實現(xiàn)類即 LifecycleRegistry（之后假設(shè)需要實現(xiàn) LifecycleOwner 接口的僅有 Activity 一種吗伤，方便讀者理解）
LifecycleRegistry 需要持有 LifecycleOwner 對象來判斷是否可以向其回調(diào)，但為了避免內(nèi)存泄漏不能直接強引用 LifecycleOwner
LifecycleRegistry 向 Observer 發(fā)布 Event 值的觸發(fā)條件有兩種：
- 新添加了一個 Observer硫眨，需要向其同步 Activity 當前的 State 值足淆。例如，當 Activity 處于 RESUMED 狀態(tài)時向其添加了一個 LifecycleEventObserver ，此時就必須向 LifecycleEventObserver 同步當前的最新狀態(tài)值缸浦，所以 LifecycleEventObserver 就會先后收到 CREATED夕冲、STARTED、RESUMED 三個 Event
- Activity 的生命周期狀態(tài)發(fā)生了變化裂逐，需要向 Observer 同步最新的 State 值

有了以上的幾點認知后歹鱼，再來看下 LifecycleRegistry 的大致邏輯

LifecycleRegistry 自然是 Lifecycle 的子類，其構(gòu)造函數(shù)需要傳入 LifecycleOwner 對象

public class LifecycleRegistry extends Lifecycle {

    //mState 用來標記 LifecycleOwner 對象所處的當前生命周期狀態(tài)
    private State mState;

    //持有對 LifecycleOwner 的弱引用卜高，避免內(nèi)存泄露
    private final WeakReference<LifecycleOwner> mLifecycleOwner;

    public LifecycleRegistry(@NonNull LifecycleOwner provider) {
        mLifecycleOwner = new WeakReference<>(provider);
        mState = INITIALIZED;
    }
    
}

addObserver() 方法的主要邏輯是：將傳入的 observer 對象包裝為 ObserverWithState 類型弥姻，方便將 注解形式的 LifecycleObserver（Java 7）和接口實現(xiàn)的 LifecycleObserver（Java 8） 進行狀態(tài)回調(diào)時的入口統(tǒng)一為 dispatchEvent() 方法。此外掺涛，由于當添加 LifecycleObserver 時 Lifecycle 可能已經(jīng)處于非 INITIALIZED 狀態(tài)了庭敦，所以需要通過循環(huán)檢查的方式來向 ObserverWithState 逐步下發(fā) Event 值

//Lifecycle 類中對 addObserver 方法添加了 @MainThread 注解，意思是該方法只能用于主線程調(diào)用
//所以此處不考慮多線程的情況
@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) {
        //如果 observer 之前已經(jīng)傳進來過了薪缆，則不重復(fù)添加秧廉，直接返回
        return;
    }
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        //如果 LifecycleOwner 對象已經(jīng)被回收了，則直接返回
        return;
    }

    //如果 isReentrance 為 true拣帽，意味著當前存在重入的情況：
    //1. mAddingObserverCounter != 0疼电。會出現(xiàn)這種情況，是由于開發(fā)者先添加了一個 LifecycleObserver减拭，
    //   當還在向其回調(diào)事件的過程中蔽豺，在回調(diào)方法里又再次調(diào)用了 addObserver 方法添加了一個新的 LifecycleObserver
    //2.mHandlingEvent 為 true。即此時正處于向外回調(diào) Lifecycle.Event 的狀態(tài)
    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;

    State targetState = calculateTargetState(observer);

    //遞增加一拧粪，標記當前正處于向新添加的 LifecycleObserver 回調(diào) Event 值的過程
    mAddingObserverCounter++;

    //statefulObserver.mState.compareTo(targetState) < 0 成立的話說明 State 值還沒遍歷到目標狀態(tài)
    //mObserverMap.contains(observer) 成立的話說明 observer 還沒有并移除
    //因為有可能在遍歷過程中開發(fā)者主動在回調(diào)方法里將 observer 給移除掉了修陡，所以這里每次循環(huán)都檢查下
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        //將 observer 已經(jīng)遍歷到的當前的狀態(tài)值 mState 保存下來
        pushParentState(statefulObserver.mState);
        //向 observer 回調(diào)進入“statefulObserver.mState”前需要收到的 Event 值
        statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
        //移除 mState
        popParentState();
        // mState / subling may have been changed recalculate
        targetState = calculateTargetState(observer);
    }

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

向 LifecycleObserver 回調(diào)事件的過程可以用以下這張官方提供的圖來展示

假設(shè)當前 LifecycleRegistry 的 mState 處于 RESUMED 狀態(tài)，此時通過 addObserver 方法新添加的 LifecycleObserver 會被包裝為 ObserverWithState可霎，且初始化狀態(tài)為 INITIALIZED魄鸦。由于 RESUMED 大于INITIALIZED，ObserverWithState 就會按照 INITIALIZED -> CREATED -> STARTED -> RESUMED 這樣的順序先后收到事件通知
假設(shè)當前 LifecycleRegistry 的 mState 處于 STARTED 狀態(tài)啥纸。如果 LifecycleRegistry 收到 ON_RESUME 事件号杏，mState 就需要變更為 RESUMED婴氮；如果 LifecycleRegistry 收到 ON_STOP 事件斯棒，mState 就需要變更為 CREATED；所以說主经，LifecycleRegistry 的 mState 會先后向不同方向遷移

ObserverWithState 將外界傳入的 LifecycleObserver 對象傳給 Lifecycling 進行類型包裝荣暮，將反射邏輯和接口回調(diào)邏輯都給匯總綜合成一個新的 LifecycleEventObserver 對象，從而使得 Event 分發(fā)過程都統(tǒng)一為 mLifecycleObserver.onStateChanged

static class ObserverWithState {
    State mState;
    LifecycleEventObserver mLifecycleObserver;

    ObserverWithState(LifecycleObserver observer, State initialState) {
        mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
        mState = initialState;
    }

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

在上文提到過罩驻，ReportFragment 最終在向外傳出 Lifecycle.Event 值時穗酥，調(diào)用的都是 LifecycleRegistry 對象的 handleLifecycleEvent(Lifecycle.Event) 方法，該方法會根據(jù)接收到的 Event 值換算出對應(yīng)的 State 值，然后更新本地的 mState砾跃，再向所有 Observer 進行事件通知骏啰，最終還是會調(diào)用到 ObserverWithState 的 dispatchEvent 方法，所以后邊我們再來重點關(guān)注 dispatchEvent 方法即可

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

private void moveToState(State next) {
    if (mState == next) {
        return;
    }
    mState = next;
    if (mHandlingEvent || mAddingObserverCounter != 0) {
        mNewEventOccurred = true;
        // we will figure out what to do on upper level.
        return;
    }
    mHandlingEvent = true;
    sync();
    mHandlingEvent = false;
}

需要注意的一點是抽高，對 androidx.fragment.app.Fragment 生命周期事件的監(jiān)聽一樣需要使用到 LifecycleRegistry判耕，F(xiàn)ragment 內(nèi)部最終也是通過調(diào)用其 handleLifecycleEvent(Lifecycle.Event) 方法來完成其本身的生命周期事件通知，代碼較為簡單翘骂，這里不再贅述

五壁熄、Lifecycling

上面說到了，LifecycleRegistry 會將外部傳入的所有 LifecycleObserver 根據(jù) Lifecycling 包裝成 LifecycleEventObserver 對象碳竟，這里先來解釋下為什么需要進行這層包裝

LifecycleEventObserver 和 FullLifecycleObserver 都是繼承于 LifecycleObserver 的接口草丧，開發(fā)者自己實現(xiàn)的自定義 Observer 可能同時實現(xiàn)了這兩個接口或者實現(xiàn)了任一接口，LifecycleRegistry 必須在有事件觸發(fā)的時候回調(diào)存在的所有接口方法
除了通過接口方法來實現(xiàn)回調(diào)外莹桅，Google 也提供了通過注解來實現(xiàn)回調(diào)的方式昌执，此時就需要通過反射來實現(xiàn)回調(diào)

基于以上要求，如果在 LifecycleRegistry 中直接對外部傳入的 Observer 來進行類型判斷诈泼、接口回調(diào)仙蚜、反射調(diào)用等一系列操作的話，那勢必會使得 LifecycleRegistry 整個類非常的臃腫厂汗，所以 Lifecycling 的作用就是來將這一系列的邏輯給封裝起來委粉，僅僅開放一個 onStateChanged 方法即可讓 LifecycleRegistry 完成整個事件分發(fā)，從而使得整個流程會更加清晰明了且職責分明

那現(xiàn)在就來看下 lifecycleEventObserver 方法的邏輯

@NonNull
static LifecycleEventObserver lifecycleEventObserver(Object object) {
    //對應(yīng)于上述的第一點
    boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
    boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
    if (isLifecycleEventObserver && isFullLifecycleObserver) {
        //如果 object 對象同時繼承了 LifecycleEventObserver 和 FullLifecycleObserver 接口
        //則將其包裝為 FullLifecycleObserverAdapter 對象來進行事件轉(zhuǎn)發(fā)
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,
                (LifecycleEventObserver) object);
    }
    if (isFullLifecycleObserver) {
        //同上
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
    }
    if (isLifecycleEventObserver) {
        //object 已經(jīng)是需要的目標類型了（LifecycleEventObserver）娶桦，直接原樣返回即可
        return (LifecycleEventObserver) object;
    }


    //對應(yīng)于上述所說的第二點贾节，即反射操作
    final Class<?> klass = object.getClass();
    int type = getObserverConstructorType(klass);
    if (type == GENERATED_CALLBACK) {
        List<Constructor<? extends GeneratedAdapter>> constructors =
                sClassToAdapters.get(klass);
        if (constructors.size() == 1) {
            GeneratedAdapter generatedAdapter = createGeneratedAdapter(
                    constructors.get(0), object);
            return new SingleGeneratedAdapterObserver(generatedAdapter);
        }
        GeneratedAdapter[] adapters = new GeneratedAdapter[constructors.size()];
        for (int i = 0; i < constructors.size(); i++) {
            adapters[i] = createGeneratedAdapter(constructors.get(i), object);
        }
        return new CompositeGeneratedAdaptersObserver(adapters);
    }
    return new ReflectiveGenericLifecycleObserver(object);
}

第一種情況

FullLifecycleObserver 根據(jù) Activity / Fragment 這兩個類的生命周期回調(diào)方法擴展了幾個同名的抽象方法，可以看成是對 LifecycleEventObserver 進行更加具體的事件拆分衷畦，讓使用者可以只處理自己關(guān)心的生命周期事件栗涂，這一般是用于 Java 8 以上的編譯平臺

interface FullLifecycleObserver extends LifecycleObserver {

    void onCreate(LifecycleOwner owner);

    void onStart(LifecycleOwner owner);

    void onResume(LifecycleOwner owner);

    void onPause(LifecycleOwner owner);

    void onStop(LifecycleOwner owner);

    void onDestroy(LifecycleOwner owner);
}

FullLifecycleObserverAdapter 實現(xiàn)了 LifecycleEventObserver 接口，用于在收到 Lifecycle 生命周期事件狀態(tài)變化時祈争，對兩個構(gòu)造參數(shù) FullLifecycleObserver斤程、LifecycleEventObserver 進行事件轉(zhuǎn)發(fā)

class FullLifecycleObserverAdapter implements LifecycleEventObserver {

    private final FullLifecycleObserver mFullLifecycleObserver;
    private final LifecycleEventObserver mLifecycleEventObserver;

    FullLifecycleObserverAdapter(FullLifecycleObserver fullLifecycleObserver,
            LifecycleEventObserver lifecycleEventObserver) {
        mFullLifecycleObserver = fullLifecycleObserver;
        mLifecycleEventObserver = lifecycleEventObserver;
    }

    @Override
    public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {
        switch (event) {
            case ON_CREATE:
                mFullLifecycleObserver.onCreate(source);
                break;
            case ON_START:
                mFullLifecycleObserver.onStart(source);
                break;
            case ON_RESUME:
                mFullLifecycleObserver.onResume(source);
                break;
            case ON_PAUSE:
                mFullLifecycleObserver.onPause(source);
                break;
            case ON_STOP:
                mFullLifecycleObserver.onStop(source);
                break;
            case ON_DESTROY:
                mFullLifecycleObserver.onDestroy(source);
                break;
            case ON_ANY:
                throw new IllegalArgumentException("ON_ANY must not been send by anybody");
        }
        if (mLifecycleEventObserver != null) {
            mLifecycleEventObserver.onStateChanged(source, event);
        }
    }
}

第二種情況

對于第二種情況的反射操作，其邏輯相對來說會比較復(fù)雜菩混，需要進行一系列的類型判斷忿墅、類型緩存、反射調(diào)用等操作沮峡，這里主要來看下 ClassesInfoCache 對于使用 OnLifecycleEvent 進行注解的方法是如何進行限制的

我們知道疚脐，Java 平臺的反射操作是一個比較低效和耗費性能的行為，為了避免每次需要進行事件回調(diào)時都再來對包含 OnLifecycleEvent 注解的 class 對象進行反射解析邢疙，所以 Lifecycling 內(nèi)部對 Class棍弄、Method 等進行了緩存望薄，以便后續(xù)復(fù)用。而 Lifecycling 就將這些緩存信息都封裝存放在了 ClassesInfoCache 內(nèi)部呼畸。此外痕支，被注解的方法的入?yún)㈩愋汀⑷雲(yún)㈨樞蚵⑷雲(yún)€數(shù)都有著嚴格的限制采转，畢竟如果開發(fā)者為回調(diào)方法聲明了一個 String 類型的入?yún)?shù)的話，這種情況肯定是不合理的

ClassesInfoCache 內(nèi)部會判斷指定的 class 對象是否包含使用了 OnLifecycleEvent 進行注解的方法瞬痘，并將判斷結(jié)果緩存在 mHasLifecycleMethods 內(nèi)故慈，緩存信息會根據(jù) createInfo(klass, methods) 來進行獲取

//判斷指定的 class 對象是否包含使用了 OnLifecycleEvent 進行注解的方法
boolean hasLifecycleMethods(Class<?> klass) {
    Boolean hasLifecycleMethods = mHasLifecycleMethods.get(klass);
    if (hasLifecycleMethods != null) {
        //如果本地有緩存的話則直接返回緩存值
        return hasLifecycleMethods;
    }
    //本地還沒有緩存值，以下邏輯就是來通過反射判斷 klass 是否包含使用 OnLifecycleEvent 進行注解的方法

    //獲取 klass 包含的所有方法
    Method[] methods = getDeclaredMethods(klass);
    for (Method method : methods) {
        OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
        if (annotation != null) {
            // Optimization for reflection, we know that this method is called
            // when there is no generated adapter. But there are methods with @OnLifecycleEvent
            // so we know that will use ReflectiveGenericLifecycleObserver,
            // so we createInfo in advance.
            // CreateInfo always initialize mHasLifecycleMethods for a class, so we don't do it
            // here.
            createInfo(klass, methods);
            return true;
        }
    }
    mHasLifecycleMethods.put(klass, false);
    return false;
}

而正是在 createInfo方法內(nèi)部對被注解方法的入?yún)㈩愋涂蛉⑷雲(yún)㈨樞虿毂痢⑷雲(yún)€數(shù)等進行了限制，如果不符合規(guī)定津辩，在運行時就會直接拋出異常

//以下三個整數(shù)值用于標記被注解的方法的入?yún)?shù)的個數(shù)
//不包含入?yún)?shù)
private static final int CALL_TYPE_NO_ARG = 0;
//包含一個入?yún)?shù)    
private static final int CALL_TYPE_PROVIDER = 1;
//包含兩個入?yún)?shù)      
private static final int CALL_TYPE_PROVIDER_WITH_EVENT = 2;

private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) {
    Class<?> superclass = klass.getSuperclass();
    Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
    if (superclass != null) {
        CallbackInfo superInfo = getInfo(superclass);
        if (superInfo != null) {
            handlerToEvent.putAll(superInfo.mHandlerToEvent);
        }
    }

    Class<?>[] interfaces = klass.getInterfaces();
    for (Class<?> intrfc : interfaces) {
        for (Map.Entry<MethodReference, Lifecycle.Event> entry : getInfo(
                intrfc).mHandlerToEvent.entrySet()) {
            verifyAndPutHandler(handlerToEvent, entry.getKey(), entry.getValue(), klass);
        }
    }

    Method[] methods = declaredMethods != null ? declaredMethods : getDeclaredMethods(klass);
    boolean hasLifecycleMethods = false;
    for (Method method : methods) {
        //找到包含 OnLifecycleEvent 注解的方法
        OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
        if (annotation == null) {
            continue;
        }
        hasLifecycleMethods = true;

        //以下的所有邏輯是這樣的：
        //1. 獲取 method 所對應(yīng)的方法的參數(shù)個數(shù)和參數(shù)類型拆撼，即 params
        //2. 如果參數(shù)個數(shù)為 0，則 callType = CALL_TYPE_NO_ARG喘沿，method 不包含入?yún)?shù)
        //3. 如果參數(shù)個數(shù)大于 0闸度，則第一個參數(shù)必須是 LifecycleOwner 類型的對象，否則拋出異常
        //3.1蚜印、如果參數(shù)個數(shù)為 1莺禁，則 callType = CALL_TYPE_PROVIDER
        //3.2、如果參數(shù)個數(shù)為 2窄赋，則注解值 annotation 必須是 Lifecycle.Event.ON_ANY
        //     且第二個參數(shù)必須是 Lifecycle.Event 類型的對象哟冬，否則拋出異常
        //     如果一切都符合條件，則 callType = CALL_TYPE_PROVIDER_WITH_EVENT
        //3.3忆绰、如果參數(shù)個數(shù)大于 2浩峡，則拋出異常，即要求 method 最多包含兩個參數(shù)错敢，且對參數(shù)類型和參數(shù)順序進行了限制
        Class<?>[] params = method.getParameterTypes();
        int callType = CALL_TYPE_NO_ARG;
        if (params.length > 0) {
            callType = CALL_TYPE_PROVIDER;
            if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
                throw new IllegalArgumentException(
                        "invalid parameter type. Must be one and instanceof LifecycleOwner");
            }
        }
        Lifecycle.Event event = annotation.value();

        if (params.length > 1) {
            callType = CALL_TYPE_PROVIDER_WITH_EVENT;
            if (!params[1].isAssignableFrom(Lifecycle.Event.class)) {
                throw new IllegalArgumentException(
                        "invalid parameter type. second arg must be an event");
            }
            if (event != Lifecycle.Event.ON_ANY) {
                throw new IllegalArgumentException(
                        "Second arg is supported only for ON_ANY value");
            }
        }
        if (params.length > 2) {
            throw new IllegalArgumentException("cannot have more than 2 params");
        }
        MethodReference methodReference = new MethodReference(callType, method);
        verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
    }
    CallbackInfo info = new CallbackInfo(handlerToEvent);
    mCallbackMap.put(klass, info);
    mHasLifecycleMethods.put(klass, hasLifecycleMethods);
    return info;
}

然后在 MethodReference 類內(nèi)部的 invokeCallback() 方法完成最終的反射調(diào)用翰灾。MethodReference 用于緩存具有 OnLifecycleEvent 注解的方法（Method）以及該方法所具有的入?yún)€數(shù)（知道了入?yún)€數(shù)就知道了該如何進行反射調(diào)用），通過 invokeCallback() 方法來進行 Lifecycle.Event 事件通知

static class MethodReference {
    final int mCallType;
    final Method mMethod;

    MethodReference(int callType, Method method) {
        mCallType = callType;
        mMethod = method;
        mMethod.setAccessible(true);
    }

    void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
        //noinspection TryWithIdenticalCatches
        //根據(jù)入?yún)€數(shù)來傳遞特定的參數(shù)并進行反射回調(diào)
        //因此用 OnLifecycleEvent 進行注解的方法稚茅，其入?yún)€數(shù)纸淮、入?yún)㈩愋汀⑷雲(yún)⒙暶黜樞蚨加泄潭ǖ囊?        //當不符合要求時會導(dǎo)致反射失敗從而拋出異常
        try {
            switch (mCallType) {
                case CALL_TYPE_NO_ARG:
                    mMethod.invoke(target);
                    break;
                case CALL_TYPE_PROVIDER:
                    mMethod.invoke(target, source);
                    break;
                case CALL_TYPE_PROVIDER_WITH_EVENT:
                    mMethod.invoke(target, source, event);
                    break;
            }
        } catch (InvocationTargetException e) {
            throw new RuntimeException("Failed to call observer method", e.getCause());
        } catch (IllegalAccessException e) {
            throw new RuntimeException(e);
        }
    }

    //省略無關(guān)方法
    ····
}

六峰锁、總結(jié)

Lifecycle 的整個事件流程都在上文大致講述完畢了萎馅，這里再來做下總結(jié)

我們?nèi)粘Ｊ褂玫?androidx.appcompat.app.AppCompatActivity 和 androidx.fragment.app.Fragment 都實現(xiàn)了 LifecycleOwner 接口，其 getLifecycle() 方法返回的都是 LifecycleRegistry
androidx.core.app.ComponentActivity默認掛載了一個無 UI 界面的 ReportFragment虹蒋，ReportFragment 會根據(jù)用戶手機的系統(tǒng)版本號來選擇用不同的方式獲取到 Activity 的生命周期事件糜芳，最終調(diào)用 LifecycleRegistry 的 handleLifecycleEvent(Lifecycle.Event) 方法將 Lifecycle.Event 傳遞出去。此時 LifecycleRegistry 就拿到了 Lifecycle.Event魄衅。ReportFragment 的存在意義就是完全屏蔽了系統(tǒng)版本差異峭竣，使得外部可以通過一個統(tǒng)一的方法得到回調(diào)通知
androidx.fragment.app.Fragment會直接在內(nèi)部調(diào)用 LifecycleRegistry 的 handleLifecycleEvent(Lifecycle.Event) 方法完成事件通知
LifecycleRegistry 會將外部 addObserver 傳進來的 LifecycleObserver 對象都給包裝成 LifecycleEventObserver 對象，屏蔽了外部 LifecycleObserver 的差異性（可能是接口晃虫，也可能是注解）
LifecycleRegistry 通過直接調(diào)用 LifecycleEventObserver 對象的 onStateChanged 方法來完成最終的事件回調(diào)皆撩，至此整個流程就完成了

從源碼看 Jetpack（1）- Lifecycle 源碼解析