在上篇文章：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)方法就比較容易理解了。
- 如果傳進來的的參數 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 這種情況下，原理是什麼呢？
鑑於篇幅，將放在下篇文章。歡迎關注我的公衆號獲取。
