在上篇文章：

warmcheng：Android生命周期組件 Lifecycle 使用詳解?zhuanlan.zhihu.com

中，我們講了 Lifecycle 的簡單使用，本篇我們來研究下它的源碼。

基礎環境搭建

首先，按照上篇文章所講，快速搭建環境。

添加 Lifecycle 輕量級依賴庫：

1 implementation "android.arch.lifecycle:runtime:1.1.1"

添加support library 28.0.0的支持庫（希望大家能先保持一致，因為不同版本的源碼是有區別的，后面會將到）：

1implementation 'com.android.support:appcompat-v7:28.0.0'

再添加個注解處理器相關的依賴，至于用處，后面會講：

1annotationProcessor "android.arch.lifecycle:compiler:1.1.1"

接下來創建實現了 LifecycleObserver 接口的 MyObserver 類：

讓我們的 Activity 繼承自 AppCompatActivity，并在 onCreate() 方法中通過 getLifecycle().addObserver(new MyObserver())綁定 MyObserver ：

核心代碼就一句，getLifecycle().addObserver(new MyObserver()) ，就能讓我們創建的 MyObserver 類，擁有生命周期感知能力。我們知道，這里主要的對象就兩個。一個是 getLifecycle() 方法返回來的 LifecycleRegistry 對象(繼承自抽象類 Lifecycle)，一個是我們創建的需要監聽生命周期的類 MyObserver。那我們不禁要問：LifecycleRegistry 是如何感知到生命周期的？它又是如何把生命周期事件分發給 LifecycleObserver 的？

我們先來解決第一個問題，LifecycleRegistry 是如何感知到生命周期的。

LifecycleRegistry 是如何感知到生命周期的

首先，我們Command/Ctrl + 鼠標左鍵跟蹤 getLifecycle() 代碼，發現它的具體實現是在 AppCompatActivity 的祖先類 SupportActivity 中，該類實現了 LifecycleOwner 接口。

在 onSaveInstanceState() 方法中將 mLifecycleRegistry 的狀態置為了 Lifecycle.State.CREATED，這點我們在前篇也講到過。但從這我們還是看不到跟生命周期有關的東西。此時，我們發現在 onCreate() 方法中有這一行代碼：

1ReportFragment.injectIfNeededIn(this);

ReportFragment 是做什么的？點進去看:

可以看到， ReportFragment 的 injectIfNeededIn(Activity activity)方法向 Activity 中添加了一個未設置布局的 Fragment ：

然后又在重寫的生命周期事件中調用dispatch(Lifecycle.Event event)方法，來分發生命周期事件，這就是“生命周期感知能力”的來源。這種通過一個空的 Activity 或者 Fragment 來實現特定功能的技巧還是挺常見的，比如權限請求庫 RxPermission ，以及 airbnb 開源的用于URL跳轉的 DeepLinkDispatch（前者是使用空的 Fragment，后者使用的是空的 Activity）

ReportFragment#dispatch(Lifecycle.Event event)

這里面，又調用了 LifecycleRegistry 的handleLifecycleEvent(event)方法。至此，就引入了第二個問題，事件是如何分發到 LifecycleObserver 的。

事件是如何分發到 LifecycleObserver 的

進入 LifecycleRegistry#handleLifecycleEvent(Lifecycle.Event event)方法，發現它又調用了 moveToState(State next) 方法：

而在 sync() 方法中，根據 state 的狀態，最終會調用到backwardPass(...)或者forwardPass(...)：

以 forwardPass(...) 為例：

上圖可以看到，通過 mObserverMap 最終獲取到一個 ObserverWithState 類型的 observer 對象，并調用它的dispatchEvent進行事件分發：

1 observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));

ObserverWithState 又是個什么鬼？我們繼續追蹤，發現 ObserverWithState 是 LifecycleRegistry 的一個靜態內部類。

從名稱上就能看出，該類封裝了 Observer 對象和 State 對象（具體就是 State 和 GenericLifecycleObserver，GenericLifecycleObserver 是個接口，繼承自 LifecycleObserver），在其 dispatchEvent 方法中，最終會回調 mLifecycleObserver 的 onStateChanged(...)方法。

追蹤到這里，我們知道了，Lifecycle在監聽到生命周期變化之后，最終會回調 GenericLifecycleObserver 的 onStateChanged() 方法。我們不由得疑惑，我們定義的 MyObserver 哪去了？沒看到有調用我們定義的回調方法啊。它和 GenericLifecycleObserver 又有什么關系？

我們看到，ObserverWithState 的構造函數里傳進來了一個 LifecycleObserver 類型的 observer 對象，這個參數是從哪傳進來的？繼續追蹤，發現追到了LifecycleRegistry#addObserver(LifecycleObserver observer)方法。
而這個方法，就是我們在MainActivity#onCreate(...)方法中調用的：

1 getLifecycle().addObserver(new MyObserver());

到這里，總算跟我們的 MyObserver 關聯上了。查看LifecycleRegistry#addObserver(LifecycleObserver observer)方法源碼：

這里面的核心代碼就兩行，一行是：

1 ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);

這行代碼，通過傳進來的Observer對象，創建出 ObserverWithState 對象。還有一行是：

1 ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);

這行代碼是將 LifecycleObserver 對象放入一個FastSafeIterableMap 中,以便進行迭代。

接下來我們就進入 ObserverWithState 的構造方法中看看：

在構造方法中，通過 Lifecycling.getCallback(observer)根據傳進來的 observer ，構造了一個 GenericLifecycleObserver 類型的 mLifecycleObserver ，那秘密應該也就在這個方法里，繼續跟進。

這個方法的本質，其實就是根據傳進來的一個LifecycleObserver 對象，構造出來一個 GenericLifecycleObserver 對象(目前有四個子類:FullLifecycleObserverAdapter、SingleGeneratedAdapterObserver、CompositeGeneratedAdaptersObserver、ReflectiveGenericLifecycleObserver)，而最終構造出來的對象，就包含了我們創建的 LifecycleObserver 的所有信息，包括各種回調方法等。

看到這里，就要提到文章開頭要大家添加的一個注解處理器的依賴：

1annotationProcessor "android.arch.lifecycle:compiler:1.1.1"

當我們通過注解的方式來自定義LifecycleObserver 的時候，按照傳統方式，必定要通過反射來對注解進行解析，這樣就會對性能造成影響。一方面，我們通過緩存，來避免每次都通過反射獲取構造器。另一方面，又通過注解處理器，在編譯時對那些被@OnLifecycleEvent注解標注的普通方法，進行預處理，生成以“類名_LifecycleAdapter”命名的類，將各種回調方法直接進行邏輯轉換，避免反射，進而來提高性能。

明白了這點，再看Lifecycling.getCallback(observer)方法就比較容易理解了。

如果傳進來的的參數 object 是 FullLifecycleObserver 類型，就把它構造成FullLifecycleObserverAdapter 對象，并返回

如果傳進來的的參數 object 是GenericLifecycleObserver類型，直接返回該對象

如果1，2都不滿足，就解析該類的的構造器的Type（該類是反射獲取的，還是通過注解處理器生成的）。如果是通過注解處理器生成的類來調用回調函數，就返回一個SingleGeneratedAdapterObserver/CompositeGeneratedAdaptersObserver 對象

如果以上條件都不滿足，就通過反射來調用各回調函數。返回一個 ReflectiveGenericLifecycleObserver 對象

現在我們在 app 目錄下的 bulid.gradle 中添加上上面的注解處理器依賴，然后編譯下項目，會發現在build目錄下生成了對應的類：MyObserver_LifecycleAdapter.java

點進去，看看生成的這個類的源碼：

可以看到，我們在 MyObserver 中通過@OnLifecycleEvent注解標注的那些方法，在這里都根據條件進行判斷了，而非通過注解。

這時候我們就能理清這個這個流程了，當添加了注解處理器之后，我們這里的Lifecycling.getCallback(observer)方法將會把我們的MyObserver對象構建成一個 SingleGeneratedAdapterObserver對象返回（因為這里只有一個構造器），之后的 mLifecycleObserver.onStateChanged(owner, event);其實調用的就是SingleGeneratedAdapterObserver的onStateChanged(owner, event)方法：

這里面就可以看到，它調用了內部包裹的類的callMethods(...)方法，也就是我們上面提到的MyObserver_LifecycleAdapter的callMethonds(...)方法。

到這里，就完成了 Lifecycle 源碼的解析。

通過反射獲取注解信息

這順便提下通過注解的方式調用各回調方法的過程。主要相關類就是 ReflectiveGenericLifecycleObserver.java

這里我們主要關注回調信息 CallbackInfo 的獲取方式的代碼： mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());

因為反射的代價是比較大的，所以又通過 ClassesInfoCache.java這個單例類，為 ReflectiveGenericLifecycleObserver 類要調用的各種方法的相關信息進行了緩存。

點進去看下它的 getInfo(...) 方法內部，是如何獲取方法信息的。

里面又調用了createInfo()方法：

這里，就能看到對注解進行處理的代碼了。

到這，我們就算完成了繼承自 AppCompactActivity 的情況下的源碼解析，而繼承自普通 Activity 這種情況下，原理是什么呢？

鑒于篇幅，將放在下篇文章。歡迎關注我的公眾號獲取。

總結

以上是生活随笔為你收集整理的android 生命周期_Android生命周期组件 Lifecycle 源码详解（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。