Android lifecyle 原始碼解剖
說在前面
本次推出 Android Architecture Components 系列文章，目前寫好了四篇，主要是關於 lifecycle，livedata 的使用和原始碼分析，其餘的 Navigation， Paging library，Room，WorkMannager 等春節結束之後會更新，歡迎關注我的公眾號，有更新的話會第一時間會在公眾號上面通知。
github sample 地址： ArchiteComponentsSample
Android 技術人，一位不羈的碼農。
Android 技術人
前言
前兩篇部落格，我們已經講解了 lifecycle ，liveData， ViewModel 的使用，這一篇部落格，讓我們一起來看一下 lifecycle 的原理。
從自定義的 lifecycle 說起
首先我們先來複習一下，如果要自定義 lifecycle，我們要這樣做。
public class CustomLifecycleActivity extends FragmentActivity implements LifecycleOwner {
private LifecycleRegistry mLifecycleRegistry;
private static final String TAG = "CustomLifecycleActivity";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_custom_lifecycle);
mLifecycleRegistry = new LifecycleRegistry(this);
mLifecycleRegistry.markState(Lifecycle.State.CREATED);
getLifecycle().addObserver(new GenericLifecycleObserver() {
@Override
public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
Log.d(TAG, "onStateChanged: event = " + event);
}
});
}
@Override
protected void onStart() {
super.onStart();
mLifecycleRegistry.markState(Lifecycle.State.STARTED);
}
@Override
protected void onResume() {
super.onResume();
mLifecycleRegistry.markState(Lifecycle.State.RESUMED);
}
@Override
protected void onDestroy() {
super.onDestroy();
mLifecycleRegistry.markState(Lifecycle.State.DESTROYED);
}
@NonNull
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
}
- 第一步:先實現 LifecycleOwner 介面，並返回 mLifecycleRegistry
- 第二步：在 Activity 生命週期變化的時候，呼叫 mLifecycleRegistry.markState() 方法標記相應的狀態
- 如果想新增 observer，呼叫 addObserver 方法新增觀察者，這樣會在 activity 生命週期變化的時候，回撥 observer 的 onchange 方法。
我們先來看一下 getLifecycle() 方法， getLifecycle() 它返回的是一個 Lifecycle 的例項，sdk 中預設的實現類為 LifecycleRegistry。
接下來，我們一起來看一下它的 observer 方法。
public void addObserver(@NonNull LifecycleObserver observer) {
// 判斷是否是 DESTROYED，如果是將初始狀態置為 DESTROYED，否則為 INITIALIZED
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
// ObserverWithState 包裝
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
//將 observer 作為key，在快取的 mObserverMap 中查詢是否存在
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
// 存在，直接返回回去，證明該 observer 已經新增過了。否則，證明還沒有新增過該 observer
if (previous != null) {
return;
}
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
// it is null we should be destroyed. Fallback quickly
return;
}
// 這裡 mAddingObserverCounter 為 0 ，mHandlingEvent 為 false
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--;
}
在 addObserver 方法中，它主要幹這幾件事情
- 首先，先初始化狀態， 判斷當前 mState 是否是 DESTROYED，如果是將初始狀態置為 DESTROYED，否則為 INITIALIZED，接著用 ObserverWithState 包裝 observer 和 初始化狀態 initialState
- 將 observer 作為 key，在快取的 mObserverMap 中查詢是否存在，如果存在，證明該 observer 已經新增過，直接返回回去，不必再進行處理。
- addObserver 方法中第 21 行 ， isReentrance 一般情況下為 false，什麼情況 為 true，暫時未想到，
接下來我們先來看 calculateTargetState 方法。
private State calculateTargetState(LifecycleObserver observer) {
// 取出 mObserverMap 的上一個 entry，previous
Entry<LifecycleObserver, ObserverWithState> previous = mObserverMap.ceil(observer);
// 如果不為空，獲取它的狀態
State siblingState = previous != null ? previous.getValue().mState : null;
// 判斷 mParentStates 是否為 null，不為 null，去最後的一個狀態，否則，為 null
State parentState = !mParentStates.isEmpty() ? mParentStates.get(mParentStates.size() - 1)
: null;
// 取最小的狀態
return min(min(mState, siblingState), parentState);
}
- 首先，取出 mObserverMap 中上一個的 entry，該 LifecycleRegistry 例項如果是第一次呼叫 addObserver 例項的話，那麼是 null，否則是上一個 observer 的 entry
- 根據 previous 是否為 null，設定 siblingState 的值
- 判斷 mParentStates 是否為 null，不為 null，取 mParentStates 最後一次的狀態
- 取 mState, siblingState 最小的狀態 a，再取 a 與 parentState 的狀態 b
public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
public boolean isAtLeast(@NonNull State state) {
return compareTo(state) >= 0;
}
}
State 中，他們排序的順序是 DESTROYED < INITIALIZED < CREATED < STARTED < RESUMED。
我們知道，我們在 activity 的 onCreate 方法中初始化 LifecycleRegistry，並標記它的狀態為 CREATED。當我們第一次在 onCreate 方法呼叫 addObserver 的時候，在 calculateTargetState 方法中，若是首次呼叫 previous 為 null，則 siblingState，parentState 為 null， 而 mState 為 CREATED，所以最終的狀態為 CREATED，即 State targetState = calculateTargetState(observer); 中 targetState 為 CREATED
// 取最小的狀態 return min(min(mState, siblingState), parentState);
看完 calculateTargetState 方法，我們回過頭再來看一下 addObserver 方法。
public void addObserver(@NonNull LifecycleObserver observer) {
// 省略若干行
// 這裡 mAddingObserverCounter 為 0 ，mHandlingEvent 為 false
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--;
}
這裡 statefulObserver.mState 為 DESTROYED 或者 INITIALIZED，肯定比 CREATED 小。而 mObserverMap.contains(observer) 必定為 true，除非我們手動移除掉 mObserverMap。因而，會走進 while迴圈。
private void pushParentState(State state) {
mParentStates.add(state);
}
private ArrayList<State> mParentStates = new ArrayList<>();
pushParentState(statefulObserver.mState); 很簡單，只是將 statefulObserver 的狀態新增到 mParentStates 集合中。
繼續往下走，接著會呼叫 statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
private static Event upEvent(State state) {
switch (state) {
case INITIALIZED:
case DESTROYED:
return ON_CREATE;
case CREATED:
return ON_START;
case STARTED:
return ON_RESUME;
case RESUMED:
throw new IllegalArgumentException();
}
throw new IllegalArgumentException("Unexpected state value " + state);
}
upEvent 方法也很簡單，只是返回它的下一個 event。這裡因為他們的 state為 INITIALIZED，所以它會返回 ON_CREATE。
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
static State getStateAfter(Event event) {
switch (event) {
case ON_CREATE:
case ON_STOP:
return CREATED;
case ON_START:
case ON_PAUSE:
return STARTED;
case ON_RESUME:
return RESUMED;
case ON_DESTROY:
return DESTROYED;
case ON_ANY:
break;
}
throw new IllegalArgumentException("Unexpected event value " + event);
}
這裡 event 為 ON_CREATE，所以 newState 也為 CREATED。 mState = min(mState, newState); mState newState，兩者狀態相同，所以 mState 也為 CREATED。接著回撥 mLifecycleObserver 的 onStateChanged 方法。所以，這裡，會收到我們的 onCreate 事件，與我們的預想相符。
但是我們並沒有在 onStart，onResume, onPause , onStop 和 onDestroy 方法中呼叫 mLifecycleRegistry.handleLifecycleEvent 方法，它又是怎樣促發 Observer 的 onStateChanged 方法的。這裡先不揭曉，我們先來看一下 26.1.0 以後的 AppCompatActivity，待會你就明白了，會感嘆 google 真的牛逼！
從 26.1.0 以後 AppCompatActivity 的設計說起
我們知道，在 26.1.0 以後，如果我們要使用 lifecycle，我們只需要呼叫以下的方法即可。
SupportActivity
getLifecycle().addObserver(new GenericLifecycleObserver() {
@Override
public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
Log.d(TAG, "onStateChanged: event =" + event);
}
});
跟蹤 getLifecycle() 方法，它會跳轉到 SupportActivity 的 getLifecycle 方法 中。
public class SupportActivity extends Activity implements LifecycleOwner, Component {
private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ReportFragment.injectIfNeededIn(this);
}
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
}
在 SupportActivity 中，它預設為我們初始化 mLifecycleRegistry，作為一個成員變數。接著，他在
onCreate 方法中呼叫了 ReportFragment.injectIfNeededIn(this); 方法。
public class ReportFragment extends Fragment {
private static final String REPORT_FRAGMENT_TAG = "android.arch.lifecycle"
+ ".LifecycleDispatcher.report_fragment_tag";
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();
}
}
在 injectIfNeededIn 方法中，它會判斷我們是否已經新增 ReportFragment，沒有的話，新增進去。
public class ReportFragment extends Fragment {
private static final String REPORT_FRAGMENT_TAG = "android.arch.lifecycle"
+ ".LifecycleDispatcher.report_fragment_tag";
private ActivityInitializationListener mProcessListener;
private void dispatchCreate(ActivityInitializationListener listener) {
if (listener != null) {
listener.onCreate();
}
}
private void dispatchStart(ActivityInitializationListener listener) {
if (listener != null) {
listener.onStart();
}
}
private void dispatchResume(ActivityInitializationListener listener) {
if (listener != null) {
listener.onResume();
}
}
@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;
}
}
然後，它在 onCreat ，onStart， onResume， onPause， onStop， onDestroy 方法中分別呼叫 dispatch 方法進行分發生命週期。
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);
}
}
}
在 dispatch 方法中，會先判斷 activity 是不是實現了 LifecycleRegistryOwner ，如果是，直接分發，不過不是，判斷是否實現 LifecycleOwner，獲取它的 lifecycle，呼叫它 的 handleLifecycleEvent 進行分發。
public class SupportActivity extends Activity implements LifecycleOwner, Component {
private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this
而很明顯，高版本的 SupportActivity 實現了 LifecycleOwner 介面，並寫 LifecycleOwner.getLifecycle() 是 LifecycleRegistry
普通的 Activity
對於 26.1.0 以後的版本，你會發現，對於普通的 Activity，如果你想要使用 lifecycle，你只需要實現
LifecycleOwner 介面即可。當生命週期變化的時候，它也可以回撥 Observer 的 onStateChanged 方法。
回到我們前面的問題：
我們並沒有在 onStart，onResume, onPause , onStop 和 onDestroy 方法中呼叫 mLifecycleRegistry.handleLifecycleEvent 方法，它又是怎樣促發 onStateChanged 方法的
我們猜想它也是通過 ReportFragment 實現的。但是在 Activity 的 onCreate 方法中，我們並沒有發現它有新增 ReportFragment，我們在 As 全域性搜一下，看哪些地方使用到 ReportFragment。如下圖
image
從圖中可以看到，有幾個地方使用到他。我們先來看一下 LifecycleDispatcher
class LifecycleDispatcher {
private static final String REPORT_FRAGMENT_TAG = "android.arch.lifecycle"
+ ".LifecycleDispatcher.report_fragment_tag";
private static AtomicBoolean sInitialized = new AtomicBoolean(false);
static void init(Context context) {
if (sInitialized.getAndSet(true)) {
return;
}
// 在 init 方法中，監聽全域性 activity 的建立，從而來新增 fragment
((Application) context.getApplicationContext())
.registerActivityLifecycleCallbacks(new DispatcherActivityCallback());
}
@SuppressWarnings("WeakerAccess")
@VisibleForTesting
static class DispatcherActivityCallback extends EmptyActivityLifecycleCallbacks {
private final FragmentCallback mFragmentCallback;
DispatcherActivityCallback() {
mFragmentCallback = new FragmentCallback();
}
@Override
public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
if (activity instanceof FragmentActivity) {
((FragmentActivity) activity).getSupportFragmentManager()
.registerFragmentLifecycleCallbacks(mFragmentCallback, true);
}
ReportFragment.injectIfNeededIn(activity);
}
@Override
public void onActivityStopped(Activity activity) {
if (activity instanceof FragmentActivity) {
markState((FragmentActivity) activity, CREATED);
}
}
@Override
public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
if (activity instanceof FragmentActivity) {
markState((FragmentActivity) activity, CREATED);
}
}
}
// 省略若干程式碼
}
可以看到，它 在 init 方法中，通過 context.getApplicationContext() .registerActivityLifecycleCallbacks 監聽全域性 activity 的建立，在 activity oncreate 的時候，呼叫 ReportFragment.injectIfNeededIn(activity) ，從而來新增 fragment，進而分發相應的事件。
那 LifecycleDispatcher 的 init 方法又是在哪裡呼叫的呢？ 我們全域性搜尋一下
public class ProcessLifecycleOwnerInitializer extends ContentProvider {
@Override
public boolean onCreate() {
LifecycleDispatcher.init(getContext());
ProcessLifecycleOwner.init(getContext());
return true;
}
可以看到它是在 ProcessLifecycleOwnerInitializer 的 onCreate 方法中呼叫的。而 ProcessLifecycleOwnerInitializer 是一個 ContentProvider。我們知道 ContentProvider 一般是在 AndroidManifest 中生命的。
果然，在 extensions-1.1.1.aar 中，我們驚喜地發現，它在 Manifest 裡面註冊了。
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="android.arch.lifecycle.extensions" >
<uses-sdk android:minSdkVersion="14" />
<application>
<provider
android:name="android.arch.lifecycle.ProcessLifecycleOwnerInitializer"
android:authorities="${applicationId}.lifecycle-trojan"
android:exported="false"
android:multiprocess="true" />
</application>
</manifest>
而 ContentProvider 的 onCreate 方法優先於 Application 的 onCreate 執行，所以在 Application 之前我們就呼叫了 ProcessLifecycleOwnerInitializer init 方法，監聽了 Activity 的建立，當 Actiivty 建立的時候，會嘗試為 Activity 新增 ReportFragment。而 ReportFragment 會在 Activity 生命週期變化的時候幫助我們分發生命週期。
ContentProvider 的 onCreate 方法優先於 Application 的 onCreate 執行，可以檢視這一篇部落格 Android系統中的Application和四大元件一些方法的啟動順序和一些坑
總結
ok，我們來梳理一下。
對於 26.1.0 以後的 SupportActivity
它在 Activity onCreate 的時候添加了 ReportFragment，這個 ReportFragment 相當於一個代理，它在 onActivityCreated 的時候 dispatch(Lifecycle.Event.ON_CREATE) 進行分發生命週期，onStart， onResume, onPause, onStop, onDestroy 的時候也是如此。而 在 dispatch 中 它呼叫了 LifecycleRegistry handleLifecycleEvent 的方法。而 LifecycleRegistry 方法中經過一系列處理，它又呼叫了 observer 的 onStateChange 方法，去通知相應的 observer。
對於普通的 Activity
它利用了 ContentProvide 的特徵，它是在 Application onCreate 之前初始化的，他在 ProcessLifecycleOwnerInitializer oncreate 的時候監聽 Activity 的建立，在 Activity 建立的時候，判斷是否已經新增過 ReportFragment，沒有的話，新增進去。 這是一個很巧妙的設計，隱式初始化了 lifecycle。
用流程圖表示如下：
該圖片引用自 Android 架構元件（一）——Lifecycle
image
Lifecycle 設計借鑑
- 利用 ProcessLifecycleOwnerInitializer contentProvider 來隱式載入
想一下，如果 ProcessLifecycleOwnerInitializer 不利用 contentProvider 來隱式載入的話，對於 普通的 Activity，舊版本等，如果想使用 lifecycle，那必須在基類中，手動呼叫 ReportFragment.injectIfNeededIn(activity) 的方法。
- 利用 fragment 來分發生命週期
利用 fragment 來分發生命週期有兩個優點
- 將邏輯從 Activity 中剝離出來，減少耦合，方便複用
- 可以做到在 Activity onCreate 之後才回調 observer 的 CREATED Event 事件。如果是通過 Application registerActivityLifecycleCallbacks 方法來分發生命週期的話，因為 ActivityLifecycleCallbacks 的 onActivityCreated 是在 Activity oncreate 之前呼叫的。