生命週期組件 Lifecycle 源碼解析（一）

在上篇文章:Android生命週期組件Lifecycle使用詳解中，咱們講了 Lifecycle 的簡單使用，本篇咱們來研究下它的源碼。

基礎環境搭建

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

添加 Lifecycle 輕量級依賴庫：

implementation "android.arch.lifecycle:runtime:1.1.1"複製代碼

添加support library 28.0.0的支持庫（但願你們能先保持一致，由於不一樣版本的源碼是有區別的，後面會將到）：

implementation 'com.android.support:appcompat-v7:28.0.0'複製代碼

再添加個註解處理器相關的依賴，至於用處，後面會講：

annotationProcessor "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() 方法中有這一行代碼：

ReportFragment.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進行事件分發：

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(...)方法中調用的：

getLifecycle().addObserver(new MyObserver());複製代碼

到這裏，總算跟咱們的 MyObserver 關聯上了。查看

LifecycleRegistry#addObserver(LifecycleObserver observer)方法源碼：

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

ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);複製代碼

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

ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);複製代碼

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

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

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

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

看到這裏，就要提到文章開頭要你們添加的一個註解處理器的依賴：

annotationProcessor "android.arch.lifecycle:compiler:1.1.1"複製代碼

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

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

1. 若是傳進來的的參數 object 是 FullLifecycleObserver 類型，就把它構形成FullLifecycleObserverAdapter 對象，並返回
2. 若是傳進來的的參數 object 是GenericLifecycleObserver類型，直接返回該對象
3. 若是1，2都不知足，就解析該類的的構造器的Type（該類是反射獲取的，仍是經過註解處理器生成的）。若是是經過註解處理器生成的類來調用回調函數，就返回一個SingleGeneratedAdapterObserver/CompositeGeneratedAdaptersObserver 對象
4. 若是以上條件都不知足，就經過反射來調用各回調函數。返回一個 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 這種狀況下，原理是什麼呢？

鑑於篇幅，將放在下篇文章。歡迎關注個人公衆號獲取。