Android?Jetpack組件Lifecycle源碼解析
更新時間：2023年03月13日 08:22:52 作者：孫先森Blog
這篇文章主要為大家介紹了Android?Jetpack組件Lifecycle源碼解析，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪
前言
Lifecycle 到現(xiàn)在大家應(yīng)該都很熟悉了，是 Jetpack 中管理生命周期的一個工具。除了 Activity、Fragment 中能夠提供給我們生命周期回調(diào)，任何自定義 View 同樣可以實現(xiàn)類似的回調(diào)功能。在沒有 Lifecycle 之前我們都需要定義接口，手動在生命周期方法中調(diào)用接口的實現(xiàn)。而 Lifecycle 僅僅需要一行代碼即可實現(xiàn)！對于我們來說不僅應(yīng)該學(xué)會使用 Lifecycle 更應(yīng)該了解其原理，學(xué)習(xí)其優(yōu)秀的設(shè)計。那么本文就來淺析一下 Lifecycle 的原理，看看 Google 官方是如何對生命周期回調(diào)這個需求進(jìn)行設(shè)計。
源碼版本
// lifecycle 的擴展很多 這里用 * 代替了 implementation androidx.lifecycle:lifecycle-*:2.4.0
2.4 相對于 2.3 版本將 @OnLifecycleEvent 注解標(biāo)記了廢棄，因為其使用了反射性能不佳，這塊我們下面再說。
簡單使用
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è)計，既然可以在對應(yīng)的生命周期中觸發(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 點進(jìn)去查看其源碼：
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 獲取當(dāng)前 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，當(dāng) Activity 生命周期發(fā)生變化時 Fragment 中會觸發(fā)對應(yīng)的生命周期，在 Fragment 的生命周期方法中調(diào)用 dispatch 傳遞生命周期階段。這個辦法和圖片加載庫 Glide 中的設(shè)計有異曲同工之妙，關(guān)于 Glide 系列的博客后續(xù)會隨緣寫寫。
Google 對代碼兼容處理也非常不錯，sdk >=29 時直接使用了更為方便的 Application 的ActivityLifecycleCallbacks 在其對應(yīng)方法中調(diào)用 dispatch，這個 dispatch 中主要調(diào)用了 LifecycleRegistry 的 handleLifecycleEvent 方法。對于這部分我們先按下不表。
到這里可以看出 Lifecycle 對于 Activity 來說是通過添加 Fragment 來處理生命周期回調(diào)的。
初始化工作
我在學(xué)習(xí) 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 中又進(jìn)行了一次注入空白 Fragment 操作，當(dāng)然這個操作也不會重復(fù)，因為在添加 Fragment 前就先通過 TAG 獲取了一次，為 null 時才會進(jìn)行添加。
兩個重要枚舉類
先貼一張網(wǎng)圖：
Event 和 State 是兩個枚舉類，其中的枚舉類型是對應(yīng)狀態(tài)，如圖所示 Event 的 ON_CREATE 對應(yīng)的 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ù)當(dāng)前 Event 獲取當(dāng)前對應(yīng)的 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)的意思，表示當(dāng)前對象的生命周期處于什么樣的狀態(tài)
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
// 比較 聲明的順序進(jìn)行比較
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<>();
// 當(dāng)前狀態(tài)
private State mState;
// 弱引用保存當(dāng)前要監(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) {
// 保存當(dāng)前被觀察的對象
mLifecycleOwner = new WeakReference<>(provider);
// 狀態(tài)初始為 INITIALIZED
mState = INITIALIZED;
// 默認(rèn)為 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 不進(jìn)入 if
if (previous != null) {
return;
}
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
return;
}
// 是否重復(fù)進(jìn)入
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
State targetState = calculateTargetState(observer);
// ++ 操作進(jìn)行標(biāo)記 操作完成后進(jìn)行 --
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) {
// 進(jìn)行同步 將所有的 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 時一樣進(jìn)行同步
// 這里是外部調(diào)用 handleLifecycleEvent 導(dǎo)致 event 發(fā)生變化進(jìn)行同步
sync();
mHandlingEvent = false;
}
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
// isSynced 判斷 map （鏈表結(jié)構(gòu)） 第一個元素和最后一個元素的 state 以及當(dāng)前的 state 是否相同
while (!isSynced()) {
mNewEventOccurred = false;
// 不同的話 則根據(jù)大小不同調(diào)用 backwardPass、forwardPass 進(jìn)行同步
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 的包裝類，當(dāng)外部調(diào)用 handleLifecycleEvent 傳入的 Event 和當(dāng)前對應(yīng)的 State 不同時，就會進(jìn)行同步，遍歷鏈表觸發(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) {
// 前面這部分對應(yīng)了文章開頭所說的 廢棄了 @OnLifecycleEvent 注解
// 推薦我們的 observer 都繼承 FullLifecycleObserver
boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
if (isLifecycleEventObserver && isFullLifecycleObserver) {
// 如果繼承自 FullLifecycleObserver 那么直接返回 FullLifecycleObserverAdapter
// FullLifecycleObserverAdapter 內(nèi)部的 onStateChange 方法直接根據(jù)當(dāng)前 Event 觸發(fā)了對應(yīng)的生命周期回調(diào)方法
// 我們繼承 FullLifecycleObserver 接口實現(xiàn)其方法即可
// 這里主要是避免了反射調(diào)用 提高性能 源碼很簡單 點進(jìn)去一看便知 就不貼了
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 注解反射對應(yīng)方法進(jìn)行調(diào)用
return new ReflectiveGenericLifecycleObserver(object);
}
可以看出 lifecycleEventObserver 方法主要根據(jù)傳入的 observer 進(jìn)行了不同的處理，使用 adapter 適配器觸發(fā)回調(diào)的代碼比較簡單，大家自行查看不難理解。通過 @OnLifecycleEvent 注解反射方法調(diào)用的情況應(yīng)該目前使用的比較多，這里就著重分析下這種情況。
@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 進(jìn)行包裝
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 進(jìn)行了解析，將標(biāo)有 @OnLifecycleEvent 注解的方法進(jìn)行了包裝，存入了 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 進(jìn)行反射調(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 中對應(yīng)注解中的回調(diào)方法。
總結(jié)
最初版本的 Lifecycle 都使用 @OnLifecycleEvent 注解對 observer 中的方法進(jìn)行標(biāo)記，達(dá)到生命周期回調(diào)的目的，2.4.0 提供了 FullLifecycleObserver 根據(jù) Event 不同直接調(diào)用對應(yīng)的方法，省去了反射方法、進(jìn)行緩存的步驟，提高了整體性能。其中用到了適配器設(shè)計模式來實現(xiàn)，非常值得我們開發(fā)中借鑒。
在項目中可以能會有大量的 observer 需要解析，Lifecycle 中多處用到了 map 緩存，足可見其重要性，對重復(fù)大量的操作做緩存也是非常值得我們開發(fā)中借鑒。
Lifecycle 并不僅僅限于使用在 Activity 上，任何類實現(xiàn) LifecycleOwner 都可以被 LifecycleObserver 觀察其生命周期，不過 Activity 是 Google 官方幫我添加了 RepoFragment 主動觸發(fā)了生命周期回調(diào)，而對于我們自己寫的類而言需要在合適的時機主動觸發(fā) onStateChanged 方法。
換個思路來想我們不僅僅可以讓任何類實現(xiàn) LifecycleOwner 也可以讓任何類成為 LifecycleObserver，舉個例子，你有一個 WebView 想讓它跟隨 Activity 的生命周期進(jìn)行自動銷毀，那么 Activity 作為 LifecycleOwner，WebView 可以作為 LifecycleObserver。這個例子就不在這里贅述了，歡迎查看我之前的博客關(guān)于 WebView 優(yōu)化的兩篇博客中對這部分的實現(xiàn)有具體的代碼。
以上就是Android Jetpack組件Lifecycle源碼解析的詳細(xì)內(nèi)容，更多關(guān)于Android Jetpack組件Lifecycle的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
今天小編就為大家分享一篇android6.0運行時權(quán)限完美封裝方法，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2018-07-07
本篇文章小編為大家介紹，Android Content Provider的使用。需要的朋友參考下2013-04-04
webview添加參數(shù)與修改請求頭的user-agent實例
這篇文章主要介紹了webview添加參數(shù)與修改請求頭的user-agent實例，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2020-03-03
Android數(shù)據(jù)共享 sharedPreferences 的使用方法
這篇文章主要介紹了Android數(shù)據(jù)共享 sharedPreferences 的使用方法的相關(guān)資料,希望通過本文能幫助到大家，讓大家理解使用sharedpreferences，需要的朋友可以參考下2017-10-10
這篇文章主要介紹了獲取Android手機中所有短信的實現(xiàn)代碼,需要的朋友可以參考下2014-08-08
這篇文章主要介紹了Android中dumpsys命令用法簡單介紹的相關(guān)資料,需要的朋友可以參考下2017-03-03
Android跳轉(zhuǎn)系統(tǒng)設(shè)置Settings的各個界面詳解
系統(tǒng)設(shè)置Settings中定義的一些常用的各界面ACTION常量,下面這篇文章主要給大家介紹了關(guān)于Android跳轉(zhuǎn)系統(tǒng)設(shè)置Settings的各個界面,文中介紹非常詳細(xì),需要的朋友可以參考下2023-01-01
這篇文章主要針對Android WebView 上傳文件支持進(jìn)行全面解析，感興趣的小伙伴們可以參考一下2016-06-06
Android開發(fā)使用Message對象分發(fā)必備知識點詳解
這篇文章主要為大家介紹了Android開發(fā)使用Message對象分發(fā)必備知識點詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2022-10-10
在項目開發(fā)中為了給用戶帶來極好的體驗效果，通常需要實現(xiàn)驗證碼的自動填充功能，怎么實現(xiàn)呢？今天小編給大家分享Android自動填充短信驗證碼功能的實現(xiàn)方法，需要的朋友參考下吧2017-02-02