Android aac 組件是我們工程中最常見也是使用最多, 至于使用大家都應該都很熟練，并且也能很好理解單獨個組件的作用和使用場景! 下面我主要分析對應的源碼和流程，為什么能跟我們Activity和Fragment融和在一起。從源碼的角度真正理解每個步驟,方便開發效率和遇到的坑快速排查~`
Lifecycle源碼分析
Lifecycle基本使用很簡單，接下來就是對Lifecycle原理和源碼的解析了。Lifecycle 是具有生命周期感知能力的組件，我們能在 Activity 或者 Fragment 的生命周期發生變化的時候得到通知.
1.Lifecycle的生命周期狀態事件和狀態
- Lifecycle使用兩個枚舉來跟蹤其關聯組件的生命周期狀態，這兩個枚舉分別是Event和State。 State指的是Lifecycle的生命周期所處的狀態。 Event代表Lifecycle生命周期對應的事件，這些事件會映射到Activity和Fragment中的回調事件中。
- Lifecycle是一個抽象類，其內部不僅包括了添加和移除觀察者的方法，還包括了此前說到的Event和State枚舉。可以看到Event中的事件和Activity的生命周期幾乎是對應的，除了ON_ANY，它可用于匹配所有事件。
public abstract class Lifecycle {
@MainThread
public abstract void addObserver(@NonNull LifecycleObserver observer);
@MainThread
public abstract void removeObserver(@NonNull LifecycleObserver observer);
@MainThread
@NonNull
public abstract State getCurrentState();
public enum Event {
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY;
}
public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
public boolean isAtLeast(@NonNull State state) {
return compareTo(state) >= 0;
}
}
}
2.Lifecycle如何觀察Activity和Fragment的生命周期?
Activity和Fragment已經默認實現了LifecycleOwner接口，LifecycleOwner可以理解為被觀察者，那么Lifecycle是如何觀察Activity和Fragment的生命周期的呢？
我們知道AppCompatActivity繼承->FragmentActivity繼承->ComponentActivity,所以我們這邊看下ComponentActivity.java
@RestrictTo(LIBRARY_GROUP)
public class ComponentActivity extends Activity implements LifecycleOwner {
private SimpleArrayMap<Class<? extends ExtraData>, ExtraData> mExtraDataMap =
new SimpleArrayMap<>();
//1
private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
@RestrictTo(LIBRARY_GROUP)
public void putExtraData(ExtraData extraData) {
mExtraDataMap.put(extraData.getClass(), extraData);
}
@Override
@SuppressWarnings("RestrictedApi")
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ReportFragment.injectIfNeededIn(this);//2
}
@CallSuper
@Override
protected void onSaveInstanceState(Bundle outState) {
mLifecycleRegistry.markState(Lifecycle.State.CREATED);//3
super.onSaveInstanceState(outState);
}
@RestrictTo(LIBRARY_GROUP)
public <T extends ExtraData> T getExtraData(Class<T> extraDataClass) {
return (T) mExtraDataMap.get(extraDataClass);
}
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;//4
}
@RestrictTo(LIBRARY_GROUP)
public static class ExtraData {
}
}
注釋1處創建了LifecycleRegistry，它是Lifecycle的實現類。注釋4處實現了LifecycleOwner接口定義的getLifecycle方法，返回了LifecycleRegistry。在注釋3處，將Lifecycle的State設置為CREATED。正常來說應該在ComponentActivity的各個生命周期方法中改變Lifecycle的State，顯然在ComponentActivity中沒有做這些，而是將這個任務交給了ReportFragment，注釋2處的將ComponentActivity注入到ReportFragment中。
ReportFragment.java
@RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)
public class ReportFragment extends Fragment {
private static final String REPORT_FRAGMENT_TAG = "androidx.lifecycle"
+ ".LifecycleDispatcher.report_fragment_tag";
public static void injectIfNeededIn(Activity activity) {
if (Build.VERSION.SDK_INT >= 29) { //1
LifecycleCallbacks.registerIn(activity);
}
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
manager.executePendingTransactions();
}
}
static ReportFragment get(Activity activity) {
return (ReportFragment) activity.getFragmentManager().findFragmentByTag(
REPORT_FRAGMENT_TAG);
}
...
@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);//2
}
@Override
public void onResume() {
super.onResume();
dispatchResume(mProcessListener);
dispatch(Lifecycle.Event.ON_RESUME);
}
...
private void dispatch(Lifecycle.Event event) {
Activity activity = getActivity();
if (activity instanceof LifecycleRegistryOwner) {//3
((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
return;
}
if (activity instanceof LifecycleOwner) {//4
Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
}
}
}
...
}
注釋1處會判斷會做個版本號的區分，首先進行了版本區分：在API 29及以上 直接使用activity的registerActivityLifecycleCallbacks 直接注冊了生命周期回調.然后給當前activity添加了ReportFragment，注意這個fragment是沒有布局的.無論LifecycleCallbacks、還是fragment的生命周期方法 最后都走到了 dispatch(Activity activity, Lifecycle.Event event)方法
ReportFragment的onStart方法中會調用注釋2處的dispatch方法。在dispatch方法的注釋3處，判斷Activity是否實現了LifecycleRegistryOwner接口，LifecycleRegistryOwner繼承了LifecycleOwner接口，這兩個接口不同的是，LifecycleRegistryOwner定義的getLifecycle方法返回的是LifecycleRegistry類型，而LifecycleOwner定義的getLifecycle方法返回的是Lifecycle類型。注釋4處如果Activity實現了LifecycleOwner接口，會調用LifecycleRegistry的handleLifecycleEvent方法。
LifecycleRegistry.java
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
enforceMainThreadIfNeeded("handleLifecycleEvent");
moveToState(event.getTargetState());
}
看下event.getTaargetState()方法
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");
}
這個和文章開頭給出的State與Event關系的時序圖對照看會比較好理解，比如當前執行了ON_CREATE事件或者ON_STOP事件，那么狀態就會處于CREATED。回到handleLifecycleEvent方法，其內部還會調用moveToState方法。
private void moveToState(State next) {
if (mState == next) {
return;
}
mState = next;
if (mHandlingEvent || mAddingObserverCounter != 0) {
mNewEventOccurred = true;
return;
}
mHandlingEvent = true;
sync();
mHandlingEvent = false;
}
如果當前所處的狀態和即將要處于的狀態一樣就不做任何操作，再看看sync()方法
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
throw new IllegalStateException("LifecycleOwner of this LifecycleRegistry is already"
+ "garbage collected. It is too late to change lifecycle state.");
}
while (!isSynced()) { //1 意思是所有觀察者都同步完了
mNewEventOccurred = false;
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
backwardPass(lifecycleOwner); // 2 向前
}
Map.Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0) {
forwardPass(lifecycleOwner); //3 向后
}
}
mNewEventOccurred = false;
}
private boolean isSynced() {
if (mObserverMap.size() == 0) {
return true;
}
//最老的和最新的觀察者的狀態一致，都是ower的當前狀態，說明已經同步完了
State eldestObserverState = mObserverMap.eldest().getValue().mState;
State newestObserverState = mObserverMap.newest().getValue().mState;
return eldestObserverState == newestObserverState && mState == newestObserverState;
}
private void forwardPass(LifecycleOwner lifecycleOwner) {
Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
mObserverMap.iteratorWithAdditions();
while (ascendingIterator.hasNext() && !mNewEventOccurred) {
Map.Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
ObserverWithState observer = entry.getValue();
while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
pushParentState(observer.mState);
final Event event = Event.upFrom(observer.mState); //1
if (event == null) {
throw new IllegalStateException("no event up from " + observer.mState);
}
observer.dispatchEvent(lifecycleOwner, event); //2
popParentState();
}
}
}
private void backwardPass(LifecycleOwner lifecycleOwner) {
Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> descendingIterator =
mObserverMap.descendingIterator();
while (descendingIterator.hasNext() && !mNewEventOccurred) {
Map.Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
ObserverWithState observer = entry.getValue();
while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
Event event = Event.downFrom(observer.mState); //1
if (event == null) {
throw new IllegalStateException("no event down from " + observer.mState);
}
pushParentState(event.getTargetState());
observer.dispatchEvent(lifecycleOwner, event);//2
popParentState();
}
}
}
循環條件是!isSynced()，若最老的和最新的觀察者的狀態一致，且都是ower的當前狀態，說明已經同步完了。
沒有同步完就進入循環體：
mState比最老觀察者狀態小，走backwardPass(lifecycleOwner)：從新到老分發，循環使用downEvent()和observer.dispatchEvent()，連續分發事件；
mState比最新觀察者狀態大，走forwardPass(lifecycleOwner)：從老到新分發，循環使用upEvent()和observer.dispatchEvent()，連續分發事件。
接著ObserverWithState類型的observer就獲取到了事件，即observer.dispatchEvent(lifecycleOwner, event)，下面來看看它是如何讓加了對應注解的方法執行的。
3.Lifecycle觀察到生命周期后,事件回調方法執行
LifecycleRegistry.java-> ObserverWithState
static class ObserverWithState {
State mState;
LifecycleEventObserver mLifecycleObserver;
ObserverWithState(LifecycleObserver observer, State initialState) {
//1
mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
mState = initialState;
}
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = event.getTargetState();
mState = min(mState, newState);
//2
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}
Lifecycling.java
static LifecycleEventObserver lifecycleEventObserver(Object object) {
boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
if (isLifecycleEventObserver && isFullLifecycleObserver) {
return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,
(LifecycleEventObserver) object);
}
if (isFullLifecycleObserver) {
return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
}
if (isLifecycleEventObserver) {
return (LifecycleEventObserver) object;
}
final Class<?> klass = object.getClass();
int type = getObserverConstructorType(klass);
if (type == GENERATED_CALLBACK) {
List<Constructor<? extends GeneratedAdapter>> constructors =
sClassToAdapters.get(klass);
if (constructors.size() == 1) {
GeneratedAdapter generatedAdapter = createGeneratedAdapter(
constructors.get(0), object);
return new SingleGeneratedAdapterObserver(generatedAdapter);
}
GeneratedAdapter[] adapters = new GeneratedAdapter[constructors.size()];
for (int i = 0; i < constructors.size(); i++) {
adapters[i] = createGeneratedAdapter(constructors.get(i), object);
}
return new CompositeGeneratedAdaptersObserver(adapters);
}
return new ReflectiveGenericLifecycleObserver(object);
}
mLifecycleObserver是使用Lifecycling. lifecycleEventObserver(observer)獲取的LifecycleEventObserver是接口，繼承自LifecycleObserver
ReflectiveGenericLifecycleObserver和CompositeGeneratedAdaptersObserver是LifecycleEventObserver的實現類，這里主要查看ReflectiveGenericLifecycleObserver的onStateChanged方法是如何實現的。
ReflectiveGenericLifecycleObserver.java
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
private final Object mWrapped;
private final CallbackInfo mInfo;
ReflectiveGenericLifecycleObserver(Object wrapped) {
mWrapped = wrapped;
//1存放了event與加了注解方法的信息
mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
}
@Override
public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Event event) {
//2執行對應event的觀察者的方法
mInfo.invokeCallbacks(source, event, mWrapped);
}
}
注釋2處會調用CallbackInfo的invokeCallbacks方法，在講這個方法前，需要先了解CallbackInfo是怎么創建的，我們關注注釋1處
ClassesInfoCache.java
CallbackInfo getInfo(Class<?> klass) {
CallbackInfo existing = mCallbackMap.get(klass);
if (existing != null) {
return existing;
}
existing = createInfo(klass, null);
return existing;
}
private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) {
Class<?> superclass = klass.getSuperclass();
Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
if (superclass != null) {
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; //沒有注解OnLifecycleEvent 就return
}
hasLifecycleMethods = true;//有注解OnLifecycleEvent
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");
}
}
Lifecycle.Event event = annotation.value();
if (params.length > 1) {
callType = CALL_TYPE_PROVIDER_WITH_EVENT;
if (!params[1].isAssignableFrom(Lifecycle.Event.class)) {
throw new IllegalArgumentException(
"invalid parameter type. second arg must be an event");
}
if (event != Lifecycle.Event.ON_ANY) {
throw new IllegalArgumentException(
"Second arg is supported only for ON_ANY value");
}
}
if (params.length > 2) { //參數不能超過兩個
throw new IllegalArgumentException("cannot have more than 2 params");
}
MethodReference methodReference = new MethodReference(callType, method);
//校驗方法并加入到map handlerToEvent 中
verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
}
//獲取的 所有注解生命周期的方法handlerToEvent，構造回調信息實例
CallbackInfo info = new CallbackInfo(handlerToEvent);
//把當前觀察者的回調信息存到ClassesInfoCache中
mCallbackMap.put(klass, info);
//記錄 觀察者是否有注解了生命周期的方法
mHasLifecycleMethods.put(klass, hasLifecycleMethods);
return info;
}
- 如果不存在當前觀察者回調信息，就使用createInfo()方法收集創建
- 先反射獲取觀察者的方法，遍歷方法 找到注解了OnLifecycleEvent的方法，先對方法的參數進行了校驗。
- 第一個參數必須是LifecycleOwner；第二個參數必須是Event；有兩個參數 注解值只能是ON_ANY；參數不能超過兩個
- 校驗方法并加入到map，key是方法，value是Event。map handlerToEvent是所有的注解了生命周期的方法。
- 遍歷完，然后用 handlerToEvent來構造 當前觀察者回調信息CallbackInfo，存到ClassesInfoCache的mCallbackMap中，并記錄 觀察者是否有注解了生命周期的方法。
最后看CallBackInfo里面的invokeCallBacks
CallbackInfo.java
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<>();
//1
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());
}
}
@SuppressWarnings("ConstantConditions")
void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {
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--) {
handlers.get(i).invokeCallback(source, event, mWrapped);
}
}
}
}
MethodReference(int callType, Method method) {
mCallType = callType;
mMethod = method;
mMethod.setAccessible(true);
}
void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
//noinspection TryWithIdenticalCatches
try {
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;
}
} catch (InvocationTargetException e) {
throw new RuntimeException("Failed to call observer method", e.getCause());
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
}
}
注釋1處的循環的意義在于將handlerToEvent進行數據類型轉換，轉化為一個HashMap，key的值為事件，value的值為MethodReference。注釋2處的invokeMethodsForEvent方法會傳入mEventToHandlers.get(event)，也就是事件對應的MethodReference的集合。invokeMethodsForEvent方法中會遍歷MethodReference的集合，調用MethodReference的invokeCallback方法。
LiveData 源碼分析
LiveData原理是觀察者模式，下面就先從LiveData.observe()方法看起
1.LiveData 添加觀察者
LiveData.java
@MainThread
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {
assertMainThread("observe");
if (owner.getLifecycle().getCurrentState() == DESTROYED) {
// ignore
// LifecycleOwner是DESTROYED狀態，直接忽略
return;
}
//1 使用LifecycleOwner、observer 組裝成LifecycleBoundObserver，添加到mObservers中
LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
//2
ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
if (existing != null && !existing.isAttachedTo(owner)) {
throw new IllegalArgumentException("Cannot add the same observer"
+ " with different lifecycles");
}
if (existing != null) {
return;
}
//3
owner.getLifecycle().addObserver(wrapper);
}
下面就先從LiveData.observe()方法看起：
(1)首先是判斷LifecycleOwner是DESTROYED狀態，就直接忽略，不能添加。接著使用LifecycleOwner、observer 組裝成LifecycleBoundObserver包裝實例wrapper，使用putIfAbsent方法observer-wrapper作為key-value添加到觀察者列表mObservers中。（putIfAbsent方法和put方法有區別，如果傳入key對應的value已經存在，就返回存在的value，不進行替換。如果不存在，就添加key和value，返回null）
(2)然后對添加的結果進行判斷，如果mObservers中已經存在此observer key，但value中的owner不是傳進來的owner，就會報錯“不能添加同一個observer卻是不同LifecycleOwner”。如果是相同的owner，就直接returne。
(3)最后如果等于null，在注釋3處會將LifecycleBoundObserver添加到Lifecycle中完成注冊，這樣當我們調用LiveData的observe方法時，實際上是LiveData內部完成了Lifecycle的觀察者的添加，這樣LiveData自然也就有了觀察組件生命周期變化的能力。
2.LiveData的observe方法回調
class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {
@NonNull
final LifecycleOwner mOwner;
LifecycleBoundObserver(@NonNull LifecycleOwner owner, Observer<? super T> observer) {
super(observer);
mOwner = owner;
}
@Override
boolean shouldBeActive() {
return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
}
@Override
public void onStateChanged(@NonNull LifecycleOwner source,
@NonNull Lifecycle.Event event) {
Lifecycle.State currentState = mOwner.getLifecycle().getCurrentState();
if (currentState == DESTROYED) { //1
removeObserver(mObserver);
return;
}
Lifecycle.State prevState = null;
while (prevState != currentState) {
prevState = currentState;
activeStateChanged(shouldBeActive()); //2
currentState = mOwner.getLifecycle().getCurrentState();
}
}
@Override
boolean isAttachedTo(LifecycleOwner owner) {
return mOwner == owner;
}
@Override
void detachObserver() {
mOwner.getLifecycle().removeObserver(this);
}
}
LifecycleBoundObserver是LiveData的內部類，是對原始Observer的包裝，把LifecycleOwner和Observer綁定在一起。當LifecycleOwner處于活躍狀態，就稱 LifecycleBoundObserver是活躍的觀察者。它實現自接口LifecycleEventObserver，實現了onStateChanged方法。onStateChanged是生命周期狀態變化的回調。
在LifecycleOwner生命周期狀態變化時,注釋1處判斷如果是DESTROYED狀態，則移除觀察者。LiveData自動移除觀察者特點就來源于此。 如果不是DESTROYED狀態，注釋2處將調用父類ObserverWrapper的activeStateChanged()方法處理 這個生命周期狀態變化，shouldBeActive()的值作為參數，至少是STARTED狀態為true，即活躍狀態為true。
private abstract class ObserverWrapper {
final Observer<? super T> mObserver;
boolean mActive;
int mLastVersion = START_VERSION;
ObserverWrapper(Observer<? super T> observer) {
mObserver = observer;
}
abstract boolean shouldBeActive();
boolean isAttachedTo(LifecycleOwner owner) {
return false;
}
void detachObserver() {
}
void activeStateChanged(boolean newActive) {
if (newActive == mActive) {
return;//活躍狀態 未發生變化時，不會處理。
}
mActive = newActive;
changeActiveCounter(mActive ? 1 : -1);
if (mActive) {//1
dispatchingValue(this);//觀察者變為活躍，就進行數據分發
}
}
}
注釋1處，如果是Active狀態，會調用dispatchingValue方法，并將自身傳進去
void dispatchingValue(@Nullable ObserverWrapper initiator) {
if (mDispatchingValue) {
//1
mDispatchInvalidated = true;//如果當前正在分發，則分發無效，return
return;
}
mDispatchingValue = true;//標記正在分發
do {
mDispatchInvalidated = false;
if (initiator != null) {
//observerWrapper不為空，使用considerNotify()通知真正的觀察者
considerNotify(initiator);
initiator = null;
} else {//observerWrapper為空，遍歷通知所有的觀察者
for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =
mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
considerNotify(iterator.next().getValue());
if (mDispatchInvalidated) {
break;
}
}
}
} while (mDispatchInvalidated);
mDispatchingValue = false;
}
mDispatchingValue用于標記當前是否處于分發狀態中，如果處于該狀態，則在注釋1處標記當前分發無效，直接return。一路調用過來，ObserverWrapper是不為null的，ObserverWrapper為null的情況在setValue和postValue會講到，無論是那種情況，都會調用considerNotify方法，代碼如下所示。
private void considerNotify(ObserverWrapper observer) {
if (!observer.mActive) { //1
return;
}
if (!observer.shouldBeActive()) {
observer.activeStateChanged(false); //2
return;
}
if (observer.mLastVersion >= mVersion) {
return;
}
observer.mLastVersion = mVersion;
//回調真正的mObserver的onChanged方法
observer.mObserver.onChanged((T) mData);//3
}
considerNotify方法中做了多次的判斷，注釋1處，如果ObserverWrapper的mActive值不為true，就直接return。注釋2處，如果當前observer對應組件的狀態不是Active，就會再次調用activeStateChanged方法，并傳入false，其方法內部會再次判斷是否執行onActive方法和onInactive方法回調。如果判斷條件都滿足會調用Observer的onChanged方法，這個方法正是使用LiveData的observe方法的回調。
3.LiveData的postValue/setValue方法分析(數據更新)
當調用MutableLiveData的observe方法后，還需要通過postValue/setValue方法來更新數據。
protected void postValue(T value) {
boolean postTask;
synchronized (mDataLock) {
postTask = mPendingData == NOT_SET;
mPendingData = value;
}
if (!postTask) {
return;
}
ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable); //1
}
private final Runnable mPostValueRunnable = new Runnable() {
@SuppressWarnings("unchecked")
@Override
public void run() {
Object newValue;
synchronized (mDataLock) {
newValue = mPendingData;
mPendingData = NOT_SET;
}
setValue((T) newValue); //2
}
};
@MainThread //3
protected void setValue(T value) {
assertMainThread("setValue");
mVersion++;
mData = value;
dispatchingValue(null);
}
postValue/setValue方法都定義在LiveData中，根據注釋1和注釋2處，可以發現postValue方法實際上就是將setValue方法切換到主線程調用。注釋3處說明setValue方法是運行在主線程中的，其內部調用了dispatchingValue方法,此時傳了null進去。也就是dispatchingValue方法的參數ObserverWrapper為null的情況第二節上面說過此方法.
從這里我們可以知道，無論是LiveData的observe方法還是LiveData的postValue/setValue方法都會調用dispatchingValue方法。
4.LiveData的Transformations原理
最后來看下Transformations的map原理，如何實現數據修改的。switchMap類似的。
Transformations.java
@MainThread
@NonNull
public static <X, Y> LiveData<Y> map(
@NonNull LiveData<X> source,
@NonNull final Function<X, Y> mapFunction) {
final MediatorLiveData<Y> result = new MediatorLiveData<>();
result.addSource(source, new Observer<X>() {
@Override
public void onChanged(@Nullable X x) {
result.setValue(mapFunction.apply(x));
}
});
return result;
}
new了一個MediatorLiveData實例，然后將 傳入的livaData、new的Observer實例作為參數 調用addSource方法
@MainThread
public <S> void addSource(@NonNull LiveData<S> source, @NonNull Observer<? super S> onChanged) {
Source<S> e = new Source<>(source, onChanged);
Source<?> existing = mSources.putIfAbsent(source, e); //1
if (existing != null && existing.mObserver != onChanged) {
throw new IllegalArgumentException(
"This source was already added with the different observer");
}
if (existing != null) {
return;
}
if (hasActiveObservers()) {
//MediatorLiveData有活躍觀察者，就plug
e.plug(); //2
}
}
注釋1處將傳進來的LiveData和onChanged封裝到Source類中，注釋2處調用了Source的plug方法：
private static class Source<V> implements Observer<V> {
final LiveData<V> mLiveData;
final Observer<? super V> mObserver;
int mVersion = START_VERSION;
Source(LiveData<V> liveData, final Observer<? super V> observer) {
mLiveData = liveData;
mObserver = observer;
}
void plug() {
mLiveData.observeForever(this); //1
}
void unplug() {
mLiveData.removeObserver(this);
}
@Override
public void onChanged(@Nullable V v) {
if (mVersion != mLiveData.getVersion()) {
mVersion = mLiveData.getVersion();
mObserver.onChanged(v); //2
}
}
}
注釋2處可以看到，Transformations.map方法傳入的Observer的回調在這里進行處理。注釋1處，Source的plug方法會調用LiveData的observeForever方法，observeForever和observe又有啥區分呢?
@MainThread
public void observeForever(@NonNull Observer<? super T> observer) {
assertMainThread("observeForever");
AlwaysActiveObserver wrapper = new AlwaysActiveObserver(observer); //1
ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
if (existing instanceof LiveData.LifecycleBoundObserver) {
throw new IllegalArgumentException("Cannot add the same observer"
+ " with different lifecycles");
}
if (existing != null) {
return;
}
wrapper.activeStateChanged(true);
}
注釋1處用AlwaysActiveObserver來對Observer進行包裝，緊接著調用AlwaysActiveObserver的activeStateChanged方法，其內部實際調用的是ObserverWrapper的activeStateChanged方法這個上面已經說過。來看AlwaysActiveObserver類是如何定義的。
private class AlwaysActiveObserver extends ObserverWrapper {
AlwaysActiveObserver(Observer<? super T> observer) {
super(observer);
}
@Override
boolean shouldBeActive() { //1
return true;
}
}
AlwaysActiveObserver是LiveData的內部類，它繼承自ObserverWrapper，AlwaysActiveObserver是LiveData的內部類和ObserverWrapper的區別就是，它是永遠處于Active狀態的。
這里為啥使用observeForever方法呢，這是因為源LiveData在外部使用時不會調用observer方法添加觀察者，這里永久觀察是為了在源LiveData數據變化時及時回調到 mObserver.onChanged(v)方法，也就是Transformations map方法中的onChanged方法。 而在e.plug()前是有判斷 MediatorLiveData 確認有活躍觀察者的。
最后map方法中的onChanged方法中有調用MediatorLiveData實例的setValue(mapFunction.apply(x)); 并返回實例。而mapFunction.apply()就是map方法傳入的修改邏輯Function實例。
ViewModel 源碼分析
首先ViewModel有2個特點:
(1)生命周期比Activity長
(2)不持有UI層引用
看到在因屏幕旋轉而重新創建Activity后，ViewModel對象依然會保留。 只有Activity真正Finish的時ViewModel才會被清除。
也就是說，因系統配置變更Activity銷毀重建，ViewModel對象會保留并關聯到新的Activity。而Activity的正常銷毀（系統不會重建Activity）時，ViewModel對象是會清除的。
1.ViewModel的創建
先來看下ViewModel類
public abstract class ViewModel {
// Can't use ConcurrentHashMap, because it can lose values on old apis (see b/37042460)
@Nullable
private final Map<String, Object> mBagOfTags = new HashMap<>();
private volatile boolean mCleared = false;
@SuppressWarnings("WeakerAccess")
protected void onCleared() {
}
@MainThread
final void clear() {
mCleared = true;
if (mBagOfTags != null) {
synchronized (mBagOfTags) {
for (Object value : mBagOfTags.values()) {
// see comment for the similar call in setTagIfAbsent
closeWithRuntimeException(value);
}
}
}
onCleared();
}
@SuppressWarnings("unchecked")
<T> T setTagIfAbsent(String key, T newValue) {
T previous;
synchronized (mBagOfTags) {
previous = (T) mBagOfTags.get(key);
if (previous == null) {
mBagOfTags.put(key, newValue);
}
}
T result = previous == null ? newValue : previous;
if (mCleared) {
closeWithRuntimeException(result);
}
return result;
}
@SuppressWarnings({"TypeParameterUnusedInFormals", "unchecked"})
<T> T getTag(String key) {
if (mBagOfTags == null) {
return null;
}
synchronized (mBagOfTags) {
return (T) mBagOfTags.get(key);
}
}
private static void closeWithRuntimeException(Object obj) {
if (obj instanceof Closeable) {
try {
((Closeable) obj).close();
} catch (IOException e) {
throw new RuntimeException(e);
}
}
}
}
ViewModel類 是抽象類，內部沒有啥邏輯，有個clear()方法會在ViewModel將被清除時調用。
然后ViewModel實例的獲取是通過ViewModelProvider類，見名知意，即ViewModel提供者，來看下它的構造方法
public ViewModelProvider(@NonNull ViewModelStoreOwner owner) {
this(owner.getViewModelStore(), owner instanceof HasDefaultViewModelProviderFactory
? ((HasDefaultViewModelProviderFactory) owner).getDefaultViewModelProviderFactory()
: NewInstanceFactory.getInstance());
}
public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {
this(owner.getViewModelStore(), factory);//1
}
//1
public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {
mFactory = factory;
mViewModelStore = store;
}
ViewModelProivder 有很多構造方法，不過最終都調到同一個地方,這個方法中,ViewModelStoreOwner——ViewModel存儲器擁有者；ViewModelStore——ViewModel存儲器，用來存ViewModel的地方；Factory——就是我們預期的工廠類創建ViewModel實例的工廠。
注釋1處可以看到ViewModelStoreOwner獲取ViewModelStore的代碼
public interface ViewModelStoreOwner {
//獲取ViewModelStore，即獲取ViewModel存儲器
ViewModelStore getViewModelStore();
}
ViewModelStoreOwner是一個接口,那么哪些類是這個接口的實現類呢？如你所料，我們熟悉的ComponentActivity 和 Fragment 都實現了這個接口
我們再來看看ViewModelStore這個類如何存儲ViewModel、以及ViewModel實例如何獲取的
ViewModelStore.java
public class ViewModelStore {
private final HashMap<String, ViewModel> mMap = new HashMap<>();
final void put(String key, ViewModel viewModel) {
ViewModel oldViewModel = mMap.put(key, viewModel);
if (oldViewModel != null) {
oldViewModel.onCleared();
}
}
final ViewModel get(String key) {
return mMap.get(key);
}
Set<String> keys() {
return new HashSet<>(mMap.keySet());
}
public final void clear() {
for (ViewModel vm : mMap.values()) {
vm.clear();
}
mMap.clear();
}
}
ViewModelStore代碼很簡單，比如同一個 Activity 的onCreate() 方法可能會多次回調，我們在 onCreate()方法初始化ViewModel，但是不可能每次 onCreate() 回調都會創建新的 ViewModel 對象，所以需要有一個東西用來存儲的我們之前創建過的 ViewModel，這個就是ViewModelStore 的作用
我們再來看一下 get 方法，因為真正獲取 ViewModel 對象就是通過這個方法的。
public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {
String canonicalName = modelClass.getCanonicalName();
if (canonicalName == null) {
throw new IllegalArgumentException("Local and anonymous classes can not be ViewModels");
}
return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
}
@MainThread
public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
ViewModel viewModel = mViewModelStore.get(key);
if (modelClass.isInstance(viewModel)) {
if (mFactory instanceof OnRequeryFactory) {
((OnRequeryFactory) mFactory).onRequery(viewModel);
}
return (T) viewModel;
} else {
//noinspection StatementWithEmptyBody
if (viewModel != null) {
// TODO: log a warning.
}
}
if (mFactory instanceof KeyedFactory) {
viewModel = ((KeyedFactory) mFactory).create(key, modelClass);
} else {
viewModel = mFactory.create(modelClass);
}
mViewModelStore.put(key, viewModel);
return (T) viewModel;
}
這個get方法總的來說邏輯清晰,主要分2步:
- 先通過 key 從 ViewModelStore (緩存)獲取 ViewModel 對象，如果緩存中存在，直接返回。Activity 經過橫屏重建之后，返回 ViewMode 的對象就是這里返回。
- 如果緩存不存在，那么通過 Factory 創建一個對象，然后放在緩存中，最后返回。
2.ViewModel 如何保證生命周期長
我們都知道 ViewModel 是從一個 ViewModelStore 緩存里面的獲取，我們看了 ViewModelStore 的源碼，發現它的內部并沒有通過靜態緩存實現。那么它是怎么實現Activity 在 onDestroy 之后(重建)，還繼續保留已有的對象呢？這個我們可以從 ComponentActivity 的 getViewModelStore 方法去尋找答案
ComponentActivity.java
@NonNull
@Override
public ViewModelStore getViewModelStore() {
if (getApplication() == null) {
throw new IllegalStateException("Your activity is not yet attached to the "
+ "Application instance. You can't request ViewModel before onCreate call.");
}
ensureViewModelStore();
return mViewModelStore;
}
@SuppressWarnings("WeakerAccess") /* synthetic access */
void ensureViewModelStore() {
if (mViewModelStore == null) {
NonConfigurationInstances nc =
(NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {//1
// Restore the ViewModelStore from NonConfigurationInstances
mViewModelStore = nc.viewModelStore;
}
if (mViewModelStore == null) {//2
mViewModelStore = new ViewModelStore();
}
}
}
public final Object onRetainNonConfigurationInstance() {
// Maintain backward compatibility.
Object custom = onRetainCustomNonConfigurationInstance();
ViewModelStore viewModelStore = mViewModelStore;
if (viewModelStore == null) {
//3
NonConfigurationInstances nc =
(NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {
viewModelStore = nc.viewModelStore;
}
}
if (viewModelStore == null && custom == null) {
return null;
}
NonConfigurationInstances nci = new NonConfigurationInstances();
nci.custom = custom;
nci.viewModelStore = viewModelStore; //4
return nci;
}
static final class NonConfigurationInstances {
Object custom;
ViewModelStore viewModelStore;
}
注釋1處先嘗試 從NonConfigurationInstance從獲取 ViewModelStore實例，如果NonConfigurationInstance不存在，就new一個mViewModelStore。 并且還注意到，在onRetainNonConfigurationInstance()方法中 會把mViewModelStore賦值給NonConfigurationInstances
如果不存在就會new個NonConfigurationInstances,然后賦值
NonConfigurationInstances 其實就是一個 Wrapper，用來包裝一下因為不受配置更改影響的數據，包括我們非常熟悉的 Fragment，比如說，一個 Activity 上面有一個 Fragment，旋轉了屏幕導致 Activity 重新創建，此時Activity 跟之前的不是同一個對象，但是 Fragment 卻是同一個,這就是通過 NonConfigurationInstances 實現的。也就是說在 getViewModelStore 方法里面，從 NonConfigurationInstances 獲取的 ViewModelStore 對象其實就是上一個 Activity的
接著我們來看 NonConfigurationInstances 為啥能保證 Activity 重建前后，ViewModeStore 是同一個對象呢？我們直接從ActivityThread的performDestroyActivity方法去尋找答案。我們知道，performDestroyActivity 方法最后會回調到 Activity 的 onDestroy 方法，我們可以通過這個方法可以找到ActivtyThread 在 Activity onDestroy 之前做了保存操作。
ActivityClientRecord performDestroyActivity(IBinder token, boolean finishing,
int configChanges, boolean getNonConfigInstance, String reason) {
// ······
performPauseActivityIfNeeded(r, "destroy");
// Activity的onStop方法回調
if (!r.stopped) {
callActivityOnStop(r, false /* saveState */, "destroy");
}
if (getNonConfigInstance) {
// ······
// retainNonConfigurationInstances方法的作用就是創建一個對象
r.lastNonConfigurationInstances= r.activity.retainNonConfigurationInstances();
// ······
}
// ······
// Activity的onDestroy方法回調
mInstrumentation.callActivityOnDestroy(r.activity);
// ······
return r;
}
從上面的代碼中看出，在 Activity 的 onStop 和 onDestroy之間，會回調 retainNonConfigurationInstances方法，同時記錄到ActivityClientRecord中去。這里retainNonConfigurationInstances 方法返回的對象就是我們之前看到的 NonConfigurationInstances 對象。那么又在哪里恢復已保存的 NonConfigurationInstances 對象呢？這個可以從 performLaunchActivity 方法找到答案。performLaunchActivity 方法的作用就是啟動一個 Activity，Activity 重建肯定會調用這個方法。在performLaunchActivity方法里面，調用了Activity的attach方法，在這個方法，Google將已有的NonConfigurationInstances 賦值給了新的 Activity 對象。
Activity.java
final void attach(Context context, ActivityThread aThread,
Instrumentation instr, IBinder token, int ident,
Application application, Intent intent, ActivityInfo info,
CharSequence title, Activity parent, String id,
NonConfigurationInstances lastNonConfigurationInstances,
Configuration config, String referrer, IVoiceInteractor voiceInteractor,
Window window, ActivityConfigCallback activityConfigCallback, IBinder assistToken) {
//....
mLastNonConfigurationInstances = lastNonConfigurationInstances;
//....
}
我們回過頭來看ComponentActivity里面的onRetainNonConfigurationInstance的getLastNonConfigurationInstance其實調用的是父類Activity的getLastNonConfigurationInstance()
Activity.java
public Object getLastNonConfigurationInstance() {
return mLastNonConfigurationInstances != null
? mLastNonConfigurationInstances.activity : null;//1
}
static final class NonConfigurationInstances {
Object activity;
HashMap<String, Object> children;
FragmentManagerNonConfig fragments;
ArrayMap<String, LoaderManager> loaders;
VoiceInteractor voiceInteractor;
}
這里的lastNonConfigurationInstances是存在 ActivityClientRecord中的一個組件信息,ActivityThread 中的 ActivityClientRecord 是不受 activity 重建的影響，那么ActivityClientRecord中lastNonConfigurationInstances也不受影響，那么其中的Object activity也不受影響，那么ComponentActivity中的NonConfigurationInstances的viewModelStore不受影響，那么viewModel也就不受影響了。
到這里，我們就知道為啥 NonConfigurationInstances 能保證 ViewModelStore 在 Activity 重建前后是同一個對象，同時也知道為啥 ViewModel 的生命周期比 Activity 的生命周期要長一點。
3.ViewModel Activity被銷毀后恢復數據
我們知道ViewModel 的 Saved State ,SaveStateHandle 目前在一個獨立的模塊中，我們都要額外添加依賴對應的類我們看看
我們來看看ComponentActivity
public class ComponentActivity extends androidx.core.app.ComponentActivity implements
ContextAware,
LifecycleOwner,
ViewModelStoreOwner,
HasDefaultViewModelProviderFactory,
SavedStateRegistryOwner,
OnBackPressedDispatcherOwner,
ActivityResultRegistryOwner,
ActivityResultCaller {
//....
}
final SavedStateRegistryController mSavedStateRegistryController =
SavedStateRegistryController.create(this);
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
mSavedStateRegistryController.performRestore(savedInstanceState);
//...
}
@CallSuper
@Override
protected void onSaveInstanceState(@NonNull Bundle outState) {
Lifecycle lifecycle = getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
((LifecycleRegistry) lifecycle).setCurrentState(Lifecycle.State.CREATED);
}
super.onSaveInstanceState(outState);
mSavedStateRegistryController.performSave(outState);
//...
}
SavedStateRegistryController 主要分為兩個過程：
在 onCreate 方法調用了 performRestore 方法，主要的作用是恢復已保存的數據。
在 onDestroy 方法調用了 performSave 方法，主要的作用保存數據。
因此，我們也分為兩個過程來分析，分別從保存數據和恢復和數據來分析。
1.數據保存
mSavedStateRegistryController.performSave(outState)的方法會調到performSave
SavedStateRegistry.java
@MainThread
void performSave(@NonNull Bundle outBundle) {
Bundle components = new Bundle();
if (mRestoredState != null) {
components.putAll(mRestoredState);//1
}
for (Iterator<Map.Entry<String, SavedStateProvider>> it =
mComponents.iteratorWithAdditions(); it.hasNext(); ) {
Map.Entry<String, SavedStateProvider> entry1 = it.next();
//2
components.putBundle(entry1.getKey(), entry1.getValue().saveState());
}
//3
outBundle.putBundle(SAVED_COMPONENTS_KEY, components);
}
performSave 主要做了三件事:
- 如果 mRestoredState 不為空，表示之前恢復的數據還沒有被消費完，需要將沒有消費的數據再一次保存。
- 遍歷所有注冊的 SavedStateProvider，將所有的 SavedStateProvider 提供的數據保存起來。
- 最后保存Activity 的bundle里面, 注意：outBundle是Activity 需要保存的數據Bundle。
2.恢復數據
void performRestore(@NonNull Lifecycle lifecycle, @Nullable Bundle savedState) {
if (mRestored) {
throw new IllegalStateException("SavedStateRegistry was already restored.");
}
if (savedState != null) {
mRestoredState = savedState.getBundle(SAVED_COMPONENTS_KEY);
}
lifecycle.addObserver(new GenericLifecycleObserver() {
@Override
public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) {
if (event == Lifecycle.Event.ON_START) {
mAllowingSavingState = true;
} else if (event == Lifecycle.Event.ON_STOP) {
mAllowingSavingState = false;
}
}
});
mRestored = true;
}
SavedStateRegistry 的 performRestore 方法做的操作從 savedState 獲取之前保存的數據，然后賦值給mRestoredState. 現在是不是還沒看見mRestoredState做取數據的操作，搜索mRestoredState這個變量還在那用到了，其實在consumeRestoredStateForKey這個方法
public Bundle consumeRestoredStateForKey(@NonNull String key) {
if (!mRestored) {
throw new IllegalStateException("You can consumeRestoredStateForKey "
+ "only after super.onCreate of corresponding component");
}
if (mRestoredState != null) {
//1
Bundle result = mRestoredState.getBundle(key);
mRestoredState.remove(key);
if (mRestoredState.isEmpty()) {
mRestoredState = null;
}
return result;
}
return null;
}
注釋1處consumeRestoredStateForKey 方法的作用就是通過 key 從 mRestoredState 獲取保存的數據。
然后此方法被外部類調用獲取對應的數據~
