Android?Jetpack組件Lifecycle源碼解析
前言
Lifecycle 到現(xiàn)在大家應該都很熟悉了,是 Jetpack 中管理生命周期的一個工具。除了 Activity、Fragment 中能夠提供給我們生命周期回調(diào),任何自定義 View 同樣可以實現(xiàn)類似的回調(diào)功能。在沒有 Lifecycle 之前我們都需要定義接口,手動在生命周期方法中調(diào)用接口的實現(xiàn)。而 Lifecycle 僅僅需要一行代碼即可實現(xiàn)!對于我們來說不僅應該學會使用 Lifecycle 更應該了解其原理,學習其優(yōu)秀的設(shè)計。那么本文就來淺析一下 Lifecycle 的原理,看看 Google 官方是如何對生命周期回調(diào)這個需求進行設(shè)計。
源碼版本
// lifecycle 的擴展很多 這里用 * 代替了 implementation androidx.lifecycle:lifecycle-*:2.4.0
2.4 相對于 2.3 版本將 @OnLifecycleEvent 注解標記了廢棄,因為其使用了反射性能不佳,這塊我們下面再說。
簡單使用
Lifecycle 使用起來非常簡單,以給 Activity 增加生命周期回調(diào)為例,新建回調(diào)類 ActivityLifecycleObserver:
ActivityLifecycleObserver.kt
class ActivityLifecycleObserver: DefaultLifecycleObserver { private val TAG = "LifecycleObserver" override fun onCreate(owner: LifecycleOwner) { super.onCreate(owner) Log.d(TAG, "onCreate") } override fun onStart(owner: LifecycleOwner) { super.onStart(owner) Log.d(TAG, "onStart") } override fun onResume(owner: LifecycleOwner) { super.onResume(owner) Log.d(TAG, "onResume") } override fun onPause(owner: LifecycleOwner) { super.onPause(owner) Log.d(TAG, "onPause") } override fun onStop(owner: LifecycleOwner) { super.onStop(owner) Log.d(TAG, "onStop") } override fun onDestroy(owner: LifecycleOwner) { super.onDestroy(owner) Log.d(TAG, "onDestroy") } }
在 Activity 中添加一行代碼:
class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { // ... // 一行代碼搞定 lifecycle.addObserver(ActivityLifecycleObserver()) } }
效果:
源碼分析
原理探究
Lifecycle 不是魔法,只是一種優(yōu)秀的設(shè)計,既然可以在對應的生命周期中觸發(fā)回調(diào)那么其生命周期方法中肯定有相關(guān)代碼調(diào)用,順著這個想法翻一下 Activity 的源碼,果不其然,在 ComponentActivity 的 onCreate 中就找到了線索:
ComponentActivity.java
// 繼承關(guān)系只貼出了關(guān)鍵信息 // ComponentActivity 實現(xiàn)了 LifecycleOwner 接口 public class ComponentActivity implements LifecycleOwner{ @Override protected void onCreate(@Nullable Bundle savedInstanceState) { // ... ReportFragment.injectIfNeededIn(this); // ... } }
ReportFragment.injectIfNeededIn 點進去查看其源碼:
public class ReportFragment extends android.app.Fragment { // ... public static void injectIfNeededIn(Activity activity) { // sdk >= 29 則使用 Application.ActivityLifecycleCallbacks 來處理 activity 的生命周期回調(diào) if (Build.VERSION.SDK_INT >= 29) { LifecycleCallbacks.registerIn(activity); } // sdk 小于 29 的兼容處理 android.app.FragmentManager manager = activity.getFragmentManager(); if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) { // 給 activity 添加一個空白的 Fragment 并且設(shè)置 TAG manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit(); manager.executePendingTransactions(); } } // 通過固定 TAG 獲取當前 activity 中的空白 Fragment static ReportFragment get(Activity activity) { return (ReportFragment) activity.getFragmentManager().findFragmentByTag( REPORT_FRAGMENT_TAG); } @Override public void onActivityCreated(Bundle savedInstanceState) { super.onActivityCreated(savedInstanceState); // 所有的生命周期方法中都調(diào)用了 dispatch dispatch(Lifecycle.Event.ON_CREATE); } @Override public void onStart() { super.onStart(); dispatch(Lifecycle.Event.ON_START); } @Override public void onResume() { super.onResume(); 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); } // 內(nèi)部調(diào)用了 雙參數(shù) dispatch 方法 private void dispatch(@NonNull Lifecycle.Event event) { // sdk >= 29 時利用 LifecycleCallbacks 中的回調(diào)直接調(diào)用雙參數(shù) dispatch 方法 if (Build.VERSION.SDK_INT < 29) { dispatch(getActivity(), event); } } static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) { // ... // activity 一定要先實現(xiàn) LifecycleOwner if (activity instanceof LifecycleOwner) { Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle(); if (lifecycle instanceof LifecycleRegistry) { // 調(diào)用 handleLifecycleEvent ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event); } } } static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks { static void registerIn(Activity activity) { activity.registerActivityLifecycleCallbacks(new LifecycleCallbacks()); } @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); } // 其他的生命周期回調(diào)和 onCreate 是一樣的都是調(diào)用 dispatch 就不全貼了... } // ... }
ReportFragment 的源碼很簡單,可以看出通過調(diào)用 injectIfNeededIn 會給 Activity 添加一個空白的 Fragment,當 Activity 生命周期發(fā)生變化時 Fragment 中會觸發(fā)對應的生命周期,在 Fragment 的生命周期方法中調(diào)用 dispatch 傳遞生命周期階段。這個辦法和圖片加載庫 Glide 中的設(shè)計有異曲同工之妙,關(guān)于 Glide 系列的博客后續(xù)會隨緣寫寫。
Google 對代碼兼容處理也非常不錯,sdk >=29 時直接使用了更為方便的 Application 的ActivityLifecycleCallbacks 在其對應方法中調(diào)用 dispatch,這個 dispatch 中主要調(diào)用了 LifecycleRegistry 的 handleLifecycleEvent 方法。對于這部分我們先按下不表。
到這里可以看出 Lifecycle 對于 Activity 來說是通過添加 Fragment 來處理生命周期回調(diào)的。
初始化工作
我在學習 Lifecycle 到這部分時產(chǎn)生了一個想法,ReportFragment 既然是在 ComponentActivity 中添加的,我偏不按照官方的來,我不繼承 ComponentActivity 這種情況是不是就無法觸發(fā)回調(diào)了?先說答案:Google 官方給你治的明明白白的,依然會給你的 Activity 添加 ReportFragment。
修改 MainActivity 如下:
class MainActivity : Activity(), LifecycleOwner { val mLifecycle = LifecycleRegistry(this) override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) getLifecycle().addObserver(ActivityLifecycleObserver()) } override fun getLifecycle(): Lifecycle = mLifecycle }
這么寫會發(fā)現(xiàn) log 依舊正常輸出,這里就不賣關(guān)子了直接給出結(jié)論,不過不能按照 2.4.0 版本來講了這部分的代碼改動比較大 2.4.0 版本的這部分內(nèi)容牽扯到了另一個庫 starup。所以這一小節(jié)的內(nèi)容以 Lifecycle 2.2.0 版本來講,原理肯定是差不多的,重在理解原理。
在 lifecycle-process:2.2.0 源碼中有一個 ContentProvider 源碼如下:
public class ProcessLifecycleOwnerInitializer extends ContentProvider { @Override public boolean onCreate() { // 注意這一行 LifecycleDispatcher.init(getContext()); // ... } }
繼續(xù)查看其源碼:
class LifecycleDispatcher { private static AtomicBoolean sInitialized = new AtomicBoolean(false); static void init(Context context) { if (sInitialized.getAndSet(true)) { return; } // 又看到了熟悉的 registerActivityLifecycleCallbacks ((Application) context.getApplicationContext()) .registerActivityLifecycleCallbacks(new DispatcherActivityCallback()); } // DispatcherActivityCallback 源碼也非常簡單 static class DispatcherActivityCallback extends EmptyActivityLifecycleCallbacks { @Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) { // 這里借助 Application.ActivityLifecycleCallbacks 又對 Activity 添加了 ReportFragment ReportFragment.injectIfNeededIn(activity); } @Override public void onActivityStopped(Activity activity) { } @Override public void onActivitySaveInstanceState(Activity activity, Bundle outState) { } } private LifecycleDispatcher() { } }
Google 官方一個 ContentProvider 已然看穿我的小九九,專門防止有些開發(fā)者不繼承 ComponentActivity 特意在 ContentProvider 中又進行了一次注入空白 Fragment 操作,當然這個操作也不會重復,因為在添加 Fragment 前就先通過 TAG 獲取了一次,為 null 時才會進行添加。
兩個重要枚舉類
先貼一張網(wǎng)圖:
Event 和 State 是兩個枚舉類,其中的枚舉類型是對應狀態(tài),如圖所示 Event 的 ON_CREATE 對應的 State 即為 CREATED,以此類推。
在下面理解兩個類的源碼時一定要結(jié)合這張圖。
Lifecycle.Event
public enum Event { // ON_XXX 是 Event 定義的幾種生命周期,可以參考 Activity 的生命周期來理解 // Lifecycle 不僅僅是給 Activity 用,可以讓任何類都有生命周期,并且觸發(fā)回調(diào) ON_CREATE, ON_START, ON_RESUME, ON_PAUSE, ON_STOP, ON_DESTROY, ON_ANY; // downFrom downTo upFrom upTo 分別是四個根據(jù) State 獲取 Evnent 的方法 public static Event downFrom(@NonNull State state) { switch (state) { case CREATED: return ON_DESTROY; case STARTED: return ON_STOP; case RESUMED: return ON_PAUSE; default: return null; } } public static Event downTo(@NonNull State state) { switch (state) { case DESTROYED: return ON_DESTROY; case CREATED: return ON_STOP; case STARTED: return ON_PAUSE; default: return null; } } public static Event upFrom(@NonNull State state) { switch (state) { case INITIALIZED: return ON_CREATE; case CREATED: return ON_START; case STARTED: return ON_RESUME; default: return null; } } public static Event upTo(@NonNull State state) { switch (state) { case CREATED: return ON_CREATE; case STARTED: return ON_START; case RESUMED: return ON_RESUME; default: return null; } } // 根據(jù)當前 Event 獲取當前對應的 State public State getTargetState() { switch (this) { case ON_CREATE: case ON_STOP: return State.CREATED; case ON_START: case ON_PAUSE: return State.STARTED; case ON_RESUME: return State.RESUMED; case ON_DESTROY: return State.DESTROYED; case ON_ANY: break; } throw new IllegalArgumentException(this + " has no target state"); } }
Lifecycle.State
public enum State { // State 就是狀態(tài)的意思,表示當前對象的生命周期處于什么樣的狀態(tài) DESTROYED, INITIALIZED, CREATED, STARTED, RESUMED; // 比較 聲明的順序進行比較 public boolean isAtLeast(@NonNull State state) { return compareTo(state) >= 0; } }
枚舉類的代碼比較簡單,結(jié)合圖片去理解 Event 中的升降操作方法也很簡單,就不贅述了。
LifecycleRegistry
在上述 RepoFragment 中 dispatch 方法可謂是核心代碼,dispatch 方法中調(diào)用了 LifecycleRegistry 的 handleLifecycleEvent,先來看看 LifecycleRegistry 是什么,LifecycleRegistry 繼承自 Lifecycle 源碼如下:
LifecycleRegistry.java
public class LifecycleRegistry extends Lifecycle { // 我們調(diào)用 addObserver 時就將對象添加到了這個 map 中 private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap<>(); // 當前狀態(tài) private State mState; // 弱引用保存當前要監(jiān)聽的對象 private final WeakReference<LifecycleOwner> mLifecycleOwner; //... public LifecycleRegistry(@NonNull LifecycleOwner provider) { this(provider, true); } // 構(gòu)造函數(shù) private LifecycleRegistry(@NonNull LifecycleOwner provider, boolean enforceMainThread) { // 保存當前被觀察的對象 mLifecycleOwner = new WeakReference<>(provider); // 狀態(tài)初始為 INITIALIZED mState = INITIALIZED; // 默認為 true,執(zhí)行在主線程 mEnforceMainThread = enforceMainThread; } // 添加觀察者 public void addObserver(@NonNull LifecycleObserver observer) { // mEnforceMainThread 為ture時 判斷是否為主線程 // 內(nèi)部通過 Handler 判斷的 enforceMainThreadIfNeeded("addObserver"); State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED; // 傳入的 Observer 包裝為 ObserverWithState ObserverWithState statefulObserver = new ObserverWithState(observer, initialState); // 添加到 map 中,第一次添加返回 null,后續(xù)添加返回 map 中的 value ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver); // 第一次添加 為null 不進入 if if (previous != null) { return; } LifecycleOwner lifecycleOwner = mLifecycleOwner.get(); if (lifecycleOwner == null) { return; } // 是否重復進入 boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent; State targetState = calculateTargetState(observer); // ++ 操作進行標記 操作完成后進行 -- mAddingObserverCounter++; while ((statefulObserver.mState.compareTo(targetState) < 0 && mObserverMap.contains(observer))) { pushParentState(statefulObserver.mState); final Event event = Event.upFrom(statefulObserver.mState); if (event == null) { throw new IllegalStateException("no event up from " + statefulObserver.mState); } statefulObserver.dispatchEvent(lifecycleOwner, event); popParentState(); targetState = calculateTargetState(observer); } if (!isReentrance) { // 進行同步 將所有的 observer state event 保持一致 sync(); } mAddingObserverCounter--; } // 在 RepoFragment 生命周期中調(diào)用的方法 public void handleLifecycleEvent(@NonNull Lifecycle.Event event) { enforceMainThreadIfNeeded("handleLifecycleEvent"); // 內(nèi)部調(diào)用了 moveToState moveToState(event.getTargetState()); } 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; // 和 addObserver 時一樣進行同步 // 這里是外部調(diào)用 handleLifecycleEvent 導致 event 發(fā)生變化進行同步 sync(); mHandlingEvent = false; } private void sync() { LifecycleOwner lifecycleOwner = mLifecycleOwner.get(); // isSynced 判斷 map (鏈表結(jié)構(gòu)) 第一個元素和最后一個元素的 state 以及當前的 state 是否相同 while (!isSynced()) { mNewEventOccurred = false; // 不同的話 則根據(jù)大小不同調(diào)用 backwardPass、forwardPass 進行同步 if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) { // 重點 backwardPass(lifecycleOwner); } Map.Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest(); if (!mNewEventOccurred && newest != null && mState.compareTo(newest.getValue().mState) > 0) { // 重點 forwardPass(lifecycleOwner); } } mNewEventOccurred = false; } private void forwardPass(LifecycleOwner lifecycleOwner) { // ... // 循環(huán)調(diào)用每一個 observer 的 dispatchEvent // 也就是 ObserverWithState while (descendingIterator.hasNext() && !mNewEventOccurred) { //... observer.dispatchEvent(lifecycleOwner, event); //... } } } private void backwardPass(LifecycleOwner lifecycleOwner) { // ... // 循環(huán)調(diào)用每一個 observer 的 dispatchEvent // 也就是 ObserverWithState while (descendingIterator.hasNext() && !mNewEventOccurred) { //... observer.dispatchEvent(lifecycleOwner, event); //... } } } // ... }
可以看出 LifecycleRegistry 內(nèi)部維護了一個 <LifecycleObserver, ObserverWithState>
類型的 map,并且將 map 搞成了一個鏈表結(jié)構(gòu)來存放我們傳入的 observer;ObserverWithState 是對我們傳入的 observer 的包裝類,當外部調(diào)用 handleLifecycleEvent 傳入的 Event 和當前對應的 State 不同時,就會進行同步,遍歷鏈表觸發(fā) ObserverWithState 的 dispatchEvent 方法。
LifecycleRegistry 并沒有直接觸發(fā)生命周期回調(diào)的操作,具體操作就在 ObserverWithState 類中。
ObserverWithState
ObserverWithState 是 LifecycleRegistry 的內(nèi)部類,其源碼如下:
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 = event.getTargetState(); mState = min(mState, newState); // 這里就是觸發(fā)回調(diào)的具體方法了 mLifecycleObserver.onStateChanged(owner, event); mState = newState; } }
ObserverWithState 的源碼很少,重點就在于其中的 mLifecycleObserver 的初始化。查看 Lifecycling.lifecycleEventObserver 方法源碼:
static LifecycleEventObserver lifecycleEventObserver(Object object) { // 前面這部分對應了文章開頭所說的 廢棄了 @OnLifecycleEvent 注解 // 推薦我們的 observer 都繼承 FullLifecycleObserver boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver; boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver; if (isLifecycleEventObserver && isFullLifecycleObserver) { // 如果繼承自 FullLifecycleObserver 那么直接返回 FullLifecycleObserverAdapter // FullLifecycleObserverAdapter 內(nèi)部的 onStateChange 方法直接根據(jù)當前 Event 觸發(fā)了對應的生命周期回調(diào)方法 // 我們繼承 FullLifecycleObserver 接口實現(xiàn)其方法即可 // 這里主要是避免了反射調(diào)用 提高性能 源碼很簡單 點進去一看便知 就不貼了 return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, (LifecycleEventObserver) object); } if (isFullLifecycleObserver) { return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null); } if (isLifecycleEventObserver) { return (LifecycleEventObserver) object; } // 沒有繼承 FullLifecycleObserver 的處理 也就是 2.4.0 版本之前的注解處理 final Class<?> klass = object.getClass(); // 重點代碼 下面再分析 int type = getObserverConstructorType(klass); if (type == GENERATED_CALLBACK) { // 這個 if 表示存在和上述 FullLifecycleObserverAdapter 類似的 adapter // 僅僅利用構(gòu)造函數(shù)反射創(chuàng)建 adapter // ... return new CompositeGeneratedAdaptersObserver(adapters); } // 表示根據(jù) @OnLifecycleEvent 注解反射對應方法進行調(diào)用 return new ReflectiveGenericLifecycleObserver(object); }
可以看出 lifecycleEventObserver 方法主要根據(jù)傳入的 observer 進行了不同的處理,使用 adapter 適配器觸發(fā)回調(diào)的代碼比較簡單,大家自行查看不難理解。通過 @OnLifecycleEvent 注解反射方法調(diào)用的情況應該目前使用的比較多,這里就著重分析下這種情況。
@OnLifecycleEvent 注解回調(diào)原理
getObserverConstructorType
從上面說到的一處重點方法開始分析,getObserverConstructorType 源碼如下:
private static int getObserverConstructorType(Class<?> klass) { // 這里用 map 做了一層緩存 提高性能 Integer callbackCache = sCallbackCache.get(klass); if (callbackCache != null) { return callbackCache; } // 重點在于 resolveObserverCallbackType int type = resolveObserverCallbackType(klass); sCallbackCache.put(klass, type); return type; }
resolveObserverCallbackType 源碼如下:
private static int resolveObserverCallbackType(Class<?> klass) { // 根據(jù)命名也不難看出 // REFLECTIVE_CALLBACK 表示需要反射調(diào)用 // GENERATED_CALLBACK 表示生成 也就是生成 adapter if (klass.getCanonicalName() == null) { return REFLECTIVE_CALLBACK; } // 這里的 generatedConstructor 內(nèi)部有生成 adapter 構(gòu)造的邏輯 這里就不具體分析了 Constructor<? extends GeneratedAdapter> constructor = generatedConstructor(klass); if (constructor != null) { sClassToAdapters.put(klass, Collections .<Constructor<? extends GeneratedAdapter>>singletonList(constructor)); return GENERATED_CALLBACK; } // 重點看注解反射 這種情況 boolean hasLifecycleMethods = ClassesInfoCache.sInstance.hasLifecycleMethods(klass); if (hasLifecycleMethods) { return REFLECTIVE_CALLBACK; } // ... }
通過 hasLifecycleMethods 方法獲取是否存在 LifecycleMethods ,其源碼如下:
boolean hasLifecycleMethods(Class<?> klass) { // 同樣做了一層 map 緩存 Boolean hasLifecycleMethods = mHasLifecycleMethods.get(klass); if (hasLifecycleMethods != null) { return hasLifecycleMethods; } // 獲取類中的 方法 Method[] methods = getDeclaredMethods(klass); // 遍歷 for (Method method : methods) { // 嘗試獲取 @OnLifecycleEvent 注解 OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class); if (annotation != null) { // 存在注解 則說明是生命周期回調(diào)方法 createInfo(klass, methods); return true; } } mHasLifecycleMethods.put(klass, false); return false; } private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) { Class<?> superclass = klass.getSuperclass(); Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>(); if (superclass != null) { // 這里同樣又是 map 緩存 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; 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"); } } // 獲取 @OnLifecycleEvent 注解中的 value Lifecycle.Event event = annotation.value(); // ... // 生成 method 包裝類 callType 表示參數(shù)個數(shù) MethodReference methodReference = new MethodReference(callType, method); // 放入到 handlerToEvent map 容器中 verifyAndPutHandler(handlerToEvent, methodReference, event, klass); } // 對 handlerToEvent 進行包裝 CallbackInfo info = new CallbackInfo(handlerToEvent); // 放入 map 緩存 mCallbackMap.put(klass, info); // class 是否存在生命周期回調(diào)方法 map 緩存 mHasLifecycleMethods.put(klass, hasLifecycleMethods); return info; }
可以看出通過 getObserverConstructorType 獲取 observer 回調(diào)類型時還額外對 observer 進行了解析,將標有 @OnLifecycleEvent 注解的方法進行了包裝,存入了 map 中;
ReflectiveGenericLifecycleObserver
通過上述的分析,如果使用 @OnLifecycleEvent 注解處理生命周期回調(diào),則 ObserverWithState 中的 mLifecycleObserver 最終生成的為 ReflectiveGenericLifecycleObserver;
我們再看一下其 onStateChanged 方法如何實現(xiàn)的:
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver { // mWrapped 即為我們傳入的 observer private final Object mWrapped; // mInfo 即為上一小節(jié)中 createInfo 創(chuàng)建的 private final androidx.lifecycle.ClassesInfoCache.CallbackInfo mInfo; ReflectiveGenericLifecycleObserver(Object wrapped) { mWrapped = wrapped; // 通過 map 獲取 mInfo // 如果不存在 會再走一次 createInfo 流程 mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass()); } @Override public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Event event) { mInfo.invokeCallbacks(source, event, mWrapped); } }
最終又調(diào)回到了 CallbackInfo 中的 invokeCallbacks,查看其源碼:
static class CallbackInfo { final Map<Lifecycle.Event, List<MethodReference>> mEventToHandlers; final Map<MethodReference, Lifecycle.Event> mHandlerToEvent; CallbackInfo(Map<MethodReference, Lifecycle.Event> handlerToEvent) { mHandlerToEvent = handlerToEvent; mEventToHandlers = new HashMap<>(); // 對 mEventToHandlers 初始化 for (Map.Entry<MethodReference, Lifecycle.Event> entry : handlerToEvent.entrySet()) { Lifecycle.Event event = entry.getValue(); List<MethodReference> methodReferences = mEventToHandlers.get(event); if (methodReferences == null) { methodReferences = new ArrayList<>(); mEventToHandlers.put(event, methodReferences); } methodReferences.add(entry.getKey()); } } void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) { // 最終調(diào)用到 invokeMethodsForEvent 中 invokeMethodsForEvent(mEventToHandlers.get(event), source, event, target); invokeMethodsForEvent(mEventToHandlers.get(Lifecycle.Event.ON_ANY), source, event, target); } private static void invokeMethodsForEvent(List<MethodReference> handlers, LifecycleOwner source, Lifecycle.Event event, Object mWrapped) { if (handlers != null) { for (int i = handlers.size() - 1; i >= 0; i--) { // 又調(diào)用到了 MethodReference 的 invokeCallback handlers.get(i).invokeCallback(source, event, mWrapped); } } } }
繼續(xù)跟著源碼往里跳,查看 MethodReference 的 invokeCallback 的源碼:
// mMethod 即為 observer 中的回調(diào)方法 final Method mMethod; void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) { try { // 根據(jù)參數(shù)不同對 mMethod 進行反射調(diào)用 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; } } // ... }
到此位置,就成功觸發(fā)了 observer 中對應注解中的回調(diào)方法。
總結(jié)
最初版本的 Lifecycle 都使用 @OnLifecycleEvent 注解對 observer 中的方法進行標記,達到生命周期回調(diào)的目的,2.4.0 提供了 FullLifecycleObserver 根據(jù) Event 不同直接調(diào)用對應的方法,省去了反射方法、進行緩存的步驟,提高了整體性能。其中用到了適配器設(shè)計模式來實現(xiàn),非常值得我們開發(fā)中借鑒。
在項目中可以能會有大量的 observer 需要解析,Lifecycle 中多處用到了 map 緩存,足可見其重要性,對重復大量的操作做緩存也是非常值得我們開發(fā)中借鑒。
Lifecycle 并不僅僅限于使用在 Activity 上,任何類實現(xiàn) LifecycleOwner 都可以被 LifecycleObserver 觀察其生命周期,不過 Activity 是 Google 官方幫我添加了 RepoFragment 主動觸發(fā)了生命周期回調(diào),而對于我們自己寫的類而言需要在合適的時機主動觸發(fā) onStateChanged 方法。
換個思路來想我們不僅僅可以讓任何類實現(xiàn) LifecycleOwner 也可以讓任何類成為 LifecycleObserver,舉個例子,你有一個 WebView 想讓它跟隨 Activity 的生命周期進行自動銷毀,那么 Activity 作為 LifecycleOwner,WebView 可以作為 LifecycleObserver。這個例子就不在這里贅述了,歡迎查看我之前的博客關(guān)于 WebView 優(yōu)化的兩篇博客中對這部分的實現(xiàn)有具體的代碼。
以上就是Android Jetpack組件Lifecycle源碼解析的詳細內(nèi)容,更多關(guān)于Android Jetpack組件Lifecycle的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Android啟動頁優(yōu)化之實現(xiàn)應用秒開
現(xiàn)在很多應用都會在進入主界面之前,添加一個啟動頁,然后加入幾秒鐘的廣告,我覺得這個不能算是 “真正意義上的 “ 啟動頁,應該叫廣告頁。2021-05-05Android編程動態(tài)修改RelativeLayout寬高的方法
這篇文章主要介紹了Android編程動態(tài)修改RelativeLayout寬高的方法,涉及Android動態(tài)布局的相關(guān)技巧,需要的朋友可以參考下2015-12-12新版Flutter集成到已有Android項目的實現(xiàn)
這篇文章主要介紹了新版Flutter集成到已有Android項目的實現(xiàn),文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2020-03-03Android中定時執(zhí)行任務的3種實現(xiàn)方法(推薦)
下面小編就為大家?guī)硪黄狝ndroid中定時執(zhí)行任務的3種實現(xiàn)方法(推薦)。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2016-11-11詳解如何在Android Studio中添加RecyclerView-v7支持包
本篇文章主要介紹了詳解如何在Android Studio中添加RecyclerView-v7支持包,具有一定的參考價值,感興趣的小伙伴們可以參考一下2018-02-02android基于dialog實現(xiàn)等待加載框示例
本篇文章主要介紹了android基于dialog實現(xiàn)等待加載框示例,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2017-02-02Android Studio 3.6安裝全過程及AVD安裝運行步驟詳解
這篇文章主要介紹了Android Studio 3.6安裝全過程及AVD安裝運行步驟詳解,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2020-03-03