1、Lifecycle的用法
1、使用接口回调的形式
如果想要根据Activity的生命周期状态的变化来管理业务逻辑的话，那么可以很方便的使用类似如下代码来监听其生命周期状态的变化：
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
lifecycle.addObserver(object : DefaultLifecycleObserver{
override fun onCreate(owner: LifecycleOwner) {}
override fun onResume(owner: LifecycleOwner) {}
override fun onDestroy(owner: LifecycleOwner) {}
})
}
2、OnLifecycleEvent注解的方式
public class MyObserver implements LifecycleObserver {
private String TAG = "Lifecycle_Test";
@OnLifecycleEvent(value = Lifecycle.Event.ON_RESUME)
public void connect(){
Log.i(TAG, "connect: ");
}
@OnLifecycleEvent(value = Lifecycle.Event.ON_PAUSE)
public void disConnect(){
Log.i(TAG, "disConnect: ");
}
}
该方式在以后会被逐步废弃，Google官方也建议尽量使用接口回调的形式。基于注解的方式不对函数名做特定要求，但是对于函数的入参类型、入参顺序、入参个数有特定要求。
2、Lifecycle源码--分发事件
1、Lifecycle使用两种主要枚举跟踪其关联组件的生命周期状态：
A、Event：生命周期事件，这些事件对应Activity/Fragment生命周期方法； B、State：生命周期状态，而Event是指进入一种状态的事件。
public abstract class Lifecycle {
//添加观察者
@MainThread
public abstract void addObserver(@NonNull LifecycleObserver observer);
//移除观察者
@MainThread
public abstract void removeObserver(@NonNull LifecycleObserver observer);
//获取当前状态
public abstract State getCurrentState();
//生命周期事件，对应Activity生命周期方法
public enum Event {
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY //可以响应任意一个事件
}
//生命周期状态（Event是进入这种状态的事件）
public enum State {
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
//判断至少是某一状态
public boolean isAtLeast(@NonNull State state) {
return compareTo(state) >= 0;
}
}
}
构成Android Activity生命周期的状态和事件：
2、Activity对LifecycleOwner的实现
多数情况下使用的Activity都是继承于androidx.appcompat.appcompat:xxx这个包内的AppCompatActivity，而AppCompatActivity最终是会继承于ComponentActivity。
ComponentActivity实现了接口LifecycleOwner，并在getLifecycle()返回了LifecycleRegistry实例，LifecycleRegistry是Lifecycle具体实现。然后在onSaveInstanceState()中设置mLifecycleRegistry的状态为State.CREATED。使用ReportFragment分发生命周期事件。
//LifecycleOwner是一个接口，只有一个方法返回Lifecycle的实现类
public interface LifecycleOwner {
@NonNull
Lifecycle getLifecycle();
}
//ComponentActivity继承LifecycleOwner
public class ComponentActivity extends androidx.core.app.ComponentActivity implements LifecycleOwner{
、、、、、、、、
//LifecycleRegistry是Lifecycle的实现类，调用Activity的getLifecycle实际获取的是LifecycleRegistry
private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
、、、、、、、、
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mSavedStateRegistryController.performRestore(savedInstanceState);
//使用ReportFragment分发生命周期事件
ReportFragment.injectIfNeededIn(this);
if (mContentLayoutId != 0) {
setContentView(mContentLayoutId);
}
}
@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);
}
//调用Activity的getLifecycle实际获取的是LifecycleRegistry
@NonNull
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
、、、、、、、、
}
3、ReportFragment--生命周期事件分发
ReportFragment的injectIfNeededIn()函数会根据两种情况来进行事件分发：
A、运行设备的系统版本号小于 29。此情况会通过向Activity添加一个无UI界面的 Fragment（即 ReportFragment），间接获得Activity的各个生命周期事件的回调通知；
B、运行设备的系统版本号大于或等于29。此情况会向Activity注册一个LifecycleCallbacks，以此来直接获得各个生命周期事件的回调通知。此时也会同时执行第一种情况的操作，即调用dispatch(Event)方法。
之所以会进行这两种情况区分，是因为registerActivityLifecycleCallbacks是SDK29时android.app.Activity新添加的方法，从这个版本开始支持直接在 LifecycleCallbacks 中取得事件通知。当用户的设备 SDK 版本小于 29 时，就还是需要通过 ReportFragment 来间接取得事件通知。且为了保证 support 包的兼容性，即使 SDK 版本号大于 29，也依然会添加 ReportFragment。
//专门用于分发生命周期事件的Fragment
public class ReportFragment extends Fragment {
public static void injectIfNeededIn(Activity activity) {
if (Build.VERSION.SDK_INT >= 29) {
//在API29及以上，可以直接注册LifecycleCallbacks回调，获取生命周期
activity.registerActivityLifecycleCallbacks(new LifecycleCallbacks());
}
//API29以前，使用fragment获取生命周期
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
manager.executePendingTransactions();
}
}
@SuppressWarnings("deprecation")
static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) {
、、、、、、、、、、
if (activity instanceof LifecycleOwner) {
Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
//使用LifecycleRegistry的handleLifecycleEvent方法处理事件
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
}
}
}
//在API29以下，使用Fragment的生命周期回调
@Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
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);
}
、、、、、、、、省略onStop、onDestroy
private void dispatch(@NonNull Lifecycle.Event event) {
if (Build.VERSION.SDK_INT < 29) {
dispatch(getActivity(), event);
}
}
//在API29及以上，使用Activity的生命周期回调
static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {
...
@Override
public void onActivityPostCreated(@NonNull Activity activity,@Nullable Bundle savedInstanceState) {
dispatch(activity, Lifecycle.Event.ON_CREATE);
}
@Override
public void onActivityPostStarted(@NonNull Activity activity) {
dispatch(activity, Lifecycle.Event.ON_START);
}
@Override
public void onActivityPostResumed(@NonNull Activity activity) {
dispatch(activity, Lifecycle.Event.ON_RESUME);
}
@Override
public void onActivityPrePaused(@NonNull Activity activity) {
dispatch(activity, Lifecycle.Event.ON_PAUSE);
}
、、、、、、、、省略onStop、onDestroy
}
}
4、LifecycleRegistry--生命周期事件处理
无论LifecycleCallbacks、还是fragment的生命周期方法，最后都走到了dispatch(Activity activity, Lifecycle.Event event)方法，其内部使用LifecycleRegistry的handleLifecycleEvent方法处理事件。
使用getStateAfter()获取event发生之后的将要处于的状态（看前面那张图很好理解），moveToState()是移动到新状态，最后使用sync()把生命周期状态同步给所有观察者。 注意到sync()中有个while循环，很显然是在遍历观察者。
//LifecycleRegistry类
//系统自定义的保存Observer的map，observer作为key，ObserverWithState作为value
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap<>();
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
//获取event发生之后的将要处于的状态
State next = getStateAfter(event);
//移动到这个状态
moveToState(next);
}
private void moveToState(State next) {
//如果和当前状态一致，不处理
if (mState == next) {
return;
}
//赋值新状态
mState = next;
if (mHandlingEvent || mAddingObserverCounter != 0) {
mNewEventOccurred = true;
return;
}
mHandlingEvent = true;
//把生命周期状态同步给所有观察者
sync();
mHandlingEvent = false;
}
//遍历所有的Observer观察者，同步最新的状态
private void sync() {
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
throw new IllegalStateException("LifecycleOwner of this LifecycleRegistry is state.");
}
//如果没有全部同步完，进行下一次循环
while (!isSynced()) {
mNewEventOccurred = false;
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
backwardPass(lifecycleOwner);
}
Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null && mState.compareTo(newest.getValue().mState) > 0) {
forwardPass(lifecycleOwner);
}
}
mNewEventOccurred = false;
}
//最老的和最新的观察者的状态一致，都是ower的当前状态，说明所有的Observer都已经同步完了
private boolean isSynced() {
if (mObserverMap.size() == 0) {
return true;
}
State eldestObserverState = mObserverMap.eldest().getValue().mState;
State newestObserverState = mObserverMap.newest().getValue().mState;
return eldestObserverState == newestObserverState && mState == newestObserverState;
}
//获取event发生之后的将要处于的状态（看前面那张图很好理解）
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);
}
循环条件是!isSynced()，若最老的和最新的观察者的状态一致，且都是ower的当前状态，说明已经同步完了。 没有同步完就进入循环体：
private void forwardPass(LifecycleOwner lifecycleOwner) {
Iterator<Entry<LifecycleObserver, ObserverWithState>> ascendingIterator = mObserverMap.iteratorWithAdditions();
//正向遍历，从老到新
while (ascendingIterator.hasNext() && !mNewEventOccurred) {
Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
ObserverWithState observer = entry.getValue();
//如果观察者observer状态小于LifecycleOwner的当前状态，反向向回调每一个生命周期方法（比如调用onResume->onPause）
while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred && mObserverMap.contains(entry.getKey()))) {
pushParentState(observer.mState);
//observer获取事件
observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));
popParentState();
}
}
}
private void backwardPass(LifecycleOwner lifecycleOwner) {
Iterator<Entry<LifecycleObserver, ObserverWithState>> descendingIterator = mObserverMap.descendingIterator();
//反向遍历，从新到老
while (descendingIterator.hasNext() && !mNewEventOccurred) {
Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
ObserverWithState observer = entry.getValue();
//如果观察者observer状态大于LifecycleOwner的当前状态，正向回调每一个生命周期方法（比如调用onStart->onResume）
while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred && mObserverMap.contains(entry.getKey()))) {
Event event = downEvent(observer.mState);
pushParentState(getStateAfter(event));
//observer获取事件
observer.dispatchEvent(lifecycleOwner, event);
popParentState();
}
}
}
private static Event downEvent(State state) {
switch (state) {
case INITIALIZED:
throw new IllegalArgumentException();
case CREATED:
return ON_DESTROY;
case STARTED:
return ON_STOP;
case RESUMED:
return ON_PAUSE;
case DESTROYED:
throw new IllegalArgumentException();
}
throw new IllegalArgumentException("Unexpected state value " + state);
}
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);
}
A、mState比最老观察者状态小，走backwardPass(lifecycleOwner)：从新到老分发，循环使用downEvent()和observer.dispatchEvent()，连续分发事件；
如果观察者observer状态大于LifecycleOwner的当前状态，正向回调每一个生命周期方法（比如调用onStart->onResume）。
B、mState比最新观察者状态大，走forwardPass(lifecycleOwner)：从老到新分发，循环使用upEvent()和observer.dispatchEvent()，连续分发事件；
如果观察者observer状态大于LifecycleOwner的当前状态，正向回调每一个生命周期方法（比如调用onStart->onResume）。
5、addObserver--添加新的观察者
用observer创建带状态的观察者ObserverWithState，observer作为key、ObserverWithState作为value，存到mObserverMap。接着做了安全判断，最后把新的观察者的状态 连续地 同步到最新状态mState，意思就是：虽然可能添加的晚，但会把之前的事件一个个分发给你，即粘性。
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
//带状态的观察者，这个状态的作用：新的事件触发后，遍历通知所有观察者时，判断是否已经通知这个观察者了
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
//observer作为key，ObserverWithState作为value，存到mObserverMap
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
//已经添加过，不处理
if (previous != null) {
return;
}
//lifecycleOwner退出了，不处理
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
return;
}
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
State targetState = calculateTargetState(observer);
mAddingObserverCounter++;
//下面代码的逻辑：通过while循环，把新的观察者的状态连续地同步到最新状态mState。
//意思就是：虽然可能添加的晚，但把之前的事件一个个分发给你(upEvent方法)，即粘性
while ((statefulObserver.mState.compareTo(targetState) < 0 && mObserverMap.contains(observer))) {
pushParentState(statefulObserver.mState);
statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
popParentState();
targetState = calculateTargetState(observer);
}
if (!isReentrance) {
sync();
}
mAddingObserverCounter--;
}
3、Lifecycle源码—调用Observer的方法
接着ObserverWithState类型的observer就获取到了事件，即observer.dispatchEvent(lifecycleOwner, event)，下面来看看它是如何让执行Observer的回调方法或者加了对应注解的方法执行的。
ObserverWithState 将外界传入的LifecycleObserver 对象传给 Lifecycling 进行类型包装，将反射逻辑和接口回调逻辑都给汇总综合成一个新的LifecycleEventObserver对象，从而使得 Event 分发过程都统一为一个入口。
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 = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}
}
LifecycleRegistry 会将外部传入的所有 LifecycleObserver 根据 Lifecycling 包装成 LifecycleEventObserver 对象，这里先来解释下为什么需要进行这层包装，LifecycleEventObserver 和 FullLifecycleObserver 都是继承于 LifecycleObserver 的接口。
A、如果开发者自己实现的自定义 Observer 同时实现了这两个接口，那按道理来说 LifecycleRegistry 就必须在有事件触发的情况下同时回调这两个接口的所有方法；
B、如果开发者自己实现的自定义Observer 仅实现了 LifecycleEventObserver 和 FullLifecycleObserver 这两个接口当中的一个，那么也需要在有事件触发的情况下调用相应接口的对应方法；
C、实现了通过以上两个接口来实现回调外，Google 也提供了通过注解的方法来声明生命周期回调函数，此时就只能通过反射来进行回调。
public interface LifecycleEventObserver extends LifecycleObserver {
void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event);
}
interface FullLifecycleObserver extends LifecycleObserver {
void onCreate(LifecycleOwner owner);
void onStart(LifecycleOwner owner);
void onResume(LifecycleOwner owner);
void onPause(LifecycleOwner owner);
void onStop(LifecycleOwner owner);
void onDestroy(LifecycleOwner owner);
}
如果在LifecycleRegistry 中直接对外部传入的 Observer 来进行类型判断、接口回调、反射调用等一系列操作的话，那势必会使得 LifecycleRegistry 整个类非常的臃肿，所以 Lifecycling 的作用就是来将这一系列的逻辑给封装起来，仅仅开放一个 onStateChanged 方法即可让 LifecycleRegistry 完成整个事件分发，从而使得整个流程会更加清晰明了且职责分明。
@NonNull
static LifecycleEventObserver lifecycleEventObserver(Object object) {
//以下对应于上述的第一点和第二点
boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
if (isLifecycleEventObserver && isFullLifecycleObserver) {
//如果 object 对象同时继承了 LifecycleEventObserver 和 FullLifecycleObserver 接口
//则将其包装为 FullLifecycleObserverAdapter 对象来进行事件转发
return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,
(LifecycleEventObserver) object);
}
if (isFullLifecycleObserver) {
//同上
return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
}
if (isLifecycleEventObserver) {
//object 已经是需要的目标类型了（LifecycleEventObserver），直接原样返回即可
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);
}
FullLifecycleObserverAdapter 实现了 LifecycleEventObserver 接口，用于在收到 Lifecycle 生命周期事件状态变化时，对其两个构造函数参数（ 「FullLifecycleObserver、LifecycleEventObserver」）进行事件转发。
class FullLifecycleObserverAdapter implements LifecycleEventObserver {
private final FullLifecycleObserver mFullLifecycleObserver;
private final LifecycleEventObserver mLifecycleEventObserver;
FullLifecycleObserverAdapter(FullLifecycleObserver fullLifecycleObserver,
LifecycleEventObserver lifecycleEventObserver) {
mFullLifecycleObserver = fullLifecycleObserver;
mLifecycleEventObserver = lifecycleEventObserver;
}
@Override
public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {
switch (event) {
case ON_CREATE:
mFullLifecycleObserver.onCreate(source);
break;
case ON_START:
mFullLifecycleObserver.onStart(source);
break;
case ON_RESUME:
mFullLifecycleObserver.onResume(source);
break;
case ON_PAUSE:
mFullLifecycleObserver.onPause(source);
break;
case ON_STOP:
mFullLifecycleObserver.onStop(source);
break;
case ON_DESTROY:
mFullLifecycleObserver.onDestroy(source);
break;
case ON_ANY:
throw new IllegalArgumentException("ON_ANY must not been send by anybody");
}
if (mLifecycleEventObserver != null) {
mLifecycleEventObserver.onStateChanged(source, event);
}
}
}
对于第三种情况的反射操作，其逻辑相对来说会比较复杂，需要进行一系列的类型判断、类型缓存、反射调用等操作，这里主要来看下 ClassesInfoCache 对于使用 OnLifecycleEvent进行注解的函数是如何进行限制的。
开发者应该都知道，Java 平台的反射操作是一个比较低效和耗费性能的行为，为了避免每次有需要进行事件回调时都再来对包含 OnLifecycleEvent 注解的 class 对象进行反射解析，所以 Lifecycling 内部对 Class、Method 等进行了缓存，以便后续复用。而 Lifecycling 就将这些缓存信息都封装存放在了 ClassesInfoCache 内部。
//判断指定的 class 对象是否包含使用了 OnLifecycleEvent 进行注解的函数
boolean hasLifecycleMethods(Class<?> klass) {
Boolean hasLifecycleMethods = mHasLifecycleMethods.get(klass);
if (hasLifecycleMethods != null) {
//如果本地有缓存的话则直接返回缓存值
return hasLifecycleMethods;
}
//本地还没有缓存值，以下逻辑就是来通过反射判断 klass 是否包含使用 OnLifecycleEvent 进行注解的函数
//获取 klass 包含的所有函数
Method[] methods = getDeclaredMethods(klass);
for (Method method : methods) {
OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
if (annotation != null) {
createInfo(klass, methods);
return true;
}
}
mHasLifecycleMethods.put(klass, false);
return false;
}
此外，被注解的函数的入参类型、入参顺序、入参个数都有着严格的限制，毕竟如果开发者为回调函数声明了一个 String 类型的入参参数的话，Lifecycle 也不知道该向其传递什么属性值。
ClassesInfoCache 内部会判断指定的 class 对象是否包含使用了 OnLifecycleEvent 进行注解的函数，并将判断结果缓存在 mHasLifecycleMethods 内，缓存信息会根据 createInfo(klass, methods) 来进行获取。
//以下三个整数值用于标记被注解的函数的入参参数的个数
//不包含入参参数
private static final int CALL_TYPE_NO_ARG = 0;
//包含一个入参参数
private static final int CALL_TYPE_PROVIDER = 1;
//包含两个入参参数
private static final int CALL_TYPE_PROVIDER_WITH_EVENT = 2;
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;
}
hasLifecycleMethods = true;
//以下的所有逻辑是这样的：
//1. 获取 method 所对应的函数的参数个数和参数类型，即 params
//2. 如果参数个数为 0，则 callType = CALL_TYPE_NO_ARG，method 不包含入参参数
//3. 如果参数个数大于 0，则第一个参数必须是 LifecycleOwner 类型的对象，否则抛出异常
//3.1、如果参数个数为 1，则 callType = CALL_TYPE_PROVIDER
//3.2、如果参数个数为 2，则注解值 annotation 必须是 Lifecycle.Event.ON_ANY
// 且第二个参数必须是 Lifecycle.Event 类型的对象，否则抛出异常
// 如果一切都符合条件，则 callType = CALL_TYPE_PROVIDER_WITH_EVENT
//3.3、如果参数个数大于 2，则抛出异常，即要求 method 最多包含两个参数，且对参数类型和参数顺序进行了限制
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);
verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
}
CallbackInfo info = new CallbackInfo(handlerToEvent);
mCallbackMap.put(klass, info);
mHasLifecycleMethods.put(klass, hasLifecycleMethods);
return info;
}
最终在MethodReference 类内部的 invokeCallback() 函数完成最终的反射调用 MethodReference 用于缓存具有 OnLifecycleEvent 注解的函数（Method）以及该函数所具有的入参个数（知道了入参个数就知道了该如何进行反射调用），通过 invokeCallback() 函数来进行 Lifecycle.Event 事件通知。
static class MethodReference {
final int mCallType;
final Method mMethod;
MethodReference(int callType, Method method) {
mCallType = callType;
mMethod = method;
mMethod.setAccessible(true);
}
void invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target) {
//根据入参个数来传递特定的参数并进行反射回调
//因此用 OnLifecycleEvent 进行注解的函数，其入参个数、入参类型、入参声明顺序都有固定的要求
//当不符合要求时会导致反射失败从而抛出异常
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);
}
}
、、、、、、、、、、
}
Lifecycle 的整个事件流程都在上文大致讲述完毕了，这里再来做下总结：
A、日常使用的 androidx.appcompat.app.AppCompatActivity 和 androidx.fragment.app.Fragment 都实现了 LifecycleOwner 接口，其 getLifecycle() 方法返回的 Lifecycle 对象均为 LifecycleRegistry；
B、AppCompatActivity 默认挂载了一个无 UI 界面的 ReportFragment，ReportFragment 会根据用户手机的系统版本号高低，用不同的方式获取到 AppCompatActivity 的事件变化通知，最终调用 LifecycleRegistry 的 handleLifecycleEvent(Lifecycle.Event) 方法将 Lifecycle.Event 传递出去。此时，LifecycleRegistry 就拿到了 Lifecycle.Event
androidx.fragment.app.Fragment 会在内部直接调用 LifecycleRegistry 的 handleLifecycleEvent(Lifecycle.Event) 方法完成事件通知，此时，LifecycleRegistry 也拿到了 Lifecycle.Event；
C、LifecycleRegistry 会将外部 addObserver 传进来的 LifecycleObserver 对象都给包装成 ObserverWithState类内部的LifecycleEventObserver 对象，屏蔽了外部传进来的 LifecycleObserver的差异性（可能是接口，也可能是注解）；
D、LifecycleRegistry 通过直接调用 ObserverWithState 类内部的 LifecycleEventObserver对象的onStateChanged方法来完成最终的事件回调。至此整个流程就完成了。
1、LiveData介绍
LiveData是Jetpack AAC的重要组件，同时也有一个同名抽象类。
LiveData，原意是活着的数据。LiveData 是一种可观察的数据存储器类。与常规的可观察类不同，LiveData 具有生命周期感知能力，意指它遵循其他应用组件（如 Activity/Fragment）的生命周期。这种感知能力可确保 LiveData 仅更新处于活跃生命周期状态的应用组件观察者。
拆解开来：
A、LiveData是一个数据持有者，给源数据包装一层。
B、源数据使用LiveData包装后，可以被observer观察，数据有更新时observer可感知。
C、但observer的感知，只发生在（Activity/Fragment）活跃生命周期状态（STARTED、RESUMED）。
也就是说，LiveData使得数据的更新能以观察者模式被observer感知，且此感知只发生在 LifecycleOwner的活跃生命周期状态。
2、LiveData特点
使用 LiveData 具有以下优势：
1、确保界面符合数据状态，当生命周期状态变化时，LiveData通知Observer，可以在observer中更新界面。观察者可以在生命周期状态更改时刷新界面，而不是在每次数据变化时刷新界面。
2、不会发生内存泄漏，observer会在LifecycleOwner状态变为DESTROYED后自动remove。
3、不会因 Activity 停止而导致崩溃，如果LifecycleOwner生命周期处于非活跃状态，则它不会接收任何LiveData事件。
4、不需要手动解除观察，开发者不需要在onPause或onDestroy方法中解除对LiveData的观察，因为LiveData能感知生命周期状态变化，所以会自动管理所有这些操作。
5、数据始终保持最新状态，数据更新时若LifecycleOwner为非活跃状态，那么会在变为活跃时接收最新数据。例如，曾经在后台的 Activity 会在返回前台后，observer立即接收最新的数据。
3、LiveData的使用
A、创建LiveData实例，指定源数据类型；
B、创建Observer实例，实现onChanged()方法，用于接收源数据变化并刷新UI；
C、LiveData实例使用observe()方法添加观察者，并传入LifecycleOwner；
D、LiveData实例使用setValue()/postValue()更新源数据 （子线程要postValue()）；
public class LiveDataTestActivity extends AppCompatActivity{
private MutableLiveData mLiveData;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_lifecycle_test);
//liveData基本使用
mLiveData = new MutableLiveData<>();
mLiveData.observe(this, new Observer() {
@Override
public void onChanged(String s) {
Log.i(TAG, "onChanged: "+s);
}
});
Log.i(TAG, "onCreate: “);
//activity是非活跃状态，不会回调onChanged。变为活跃时，value被onStart中的value覆盖
mLiveData.setValue("onCreate");
}
@Override
protected void onStart() {
super.onStart();
Log.i(TAG, "onStart: “);
//活跃状态，会回调onChanged。并且value会覆盖onCreate、onStop中设置的value
mLiveData.setValue("onStart");
}
@Override
protected void onResume() {
super.onResume();
Log.i(TAG, "onResume: “);
//活跃状态，回调onChanged
mLiveData.setValue("onResume");
}
@Override
protected void onPause() {
super.onPause();
Log.i(TAG, "onPause: “);
//活跃状态，回调onChanged
mLiveData.setValue("onPause");
}
@Override
protected void onStop() {
super.onStop();
Log.i(TAG, "onStop: “);
//非活跃状态，不会回调onChanged。后面变为活跃时，value被onStart中的value覆盖
mLiveData.setValue("onStop");
}
@Override
protected void onDestroy() {
super.onDestroy();
Log.i(TAG, "onDestroy: “);
//非活跃状态，且此时Observer已被移除，不会回调onChanged
mLiveData.setValue("onDestroy");
}
}
A、首先打开页面，onCreate()中setValue，由于activity是非活跃状态，不会立即回调onChanged。当走到onStart()变为活跃时，onChanged被调用，但value被onStart()中setValue的value覆盖，所以打印的是onChanged: onStart。接着走到onResume()，也setValue了，同样是活跃状态，所以立刻回调onChanged，打印onChanged: onResume
B、按Home键时，onPause()中setValue，活跃状态，立刻回调onChanged方法。onStop()执行时已经变为非活跃状态，此时setValue不会立即回调onChanged方法。
C、再点开时，走到onStart()变为活跃时，onChanged被调用，但value被onStart()中setValue的value覆盖，所以打印的是onChanged: onStart。接着走到onResume()，也setValue了，同样是活跃状态，所以立刻回调onChanged。
D、返回键退出时，onPause()/onStop()的效果和按Home键一样。onDestroy()中setValue，此时非活跃状态，且此时observer已被移除，不会回调onChanged。
//打开页面，
2020-11-22 20:23:29.865 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onCreate:
2020-11-22 20:23:29.867 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onStart:
2020-11-22 20:23:29.868 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onChanged: onStart
2020-11-22 20:23:29.869 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onResume:
2020-11-22 20:23:29.869 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onChanged: onResume
//按Home键
2020-11-22 20:23:34.349 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onPause:
2020-11-22 20:23:34.349 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onChanged: onPause
2020-11-22 20:23:34.368 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onStop:
//再点开
2020-11-22 20:23:39.145 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onStart:
2020-11-22 20:23:39.146 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onChanged: onStart
2020-11-22 20:23:39.147 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onResume:
2020-11-22 20:23:39.147 13360-13360/com.hfy.androidlearning I/Lifecycle_Test: onChanged: onResume
//返回键退出
2020-11-22 20:23:56.753 14432-14432/com.hfy.androidlearning I/Lifecycle_Test: onPause:
2020-11-22 21:23:56.753 14432-14432/com.hfy.androidlearning I/Lifecycle_Test: onChanged: onPause
2020-11-22 20:23:58.320 14432-14432/com.hfy.androidlearning I/Lifecycle_Test: onStop:
2020-11-22 20:23:58.322 14432-14432/com.hfy.androidlearning I/Lifecycle_Test: onDestroy
3、LiveData源码分析
首先是判断LifecycleOwner是DESTROYED状态，就直接忽略，不能添加。接着将LifecycleOwner、observer 组装成LifecycleBoundObserver包装实例wrapper，使用putIfAbsent方法observer-wrapper作为key-value添加到观察者列表mObservers中。
最后给LifecycleOwner添加一个生命周期监听Observer，即上面组装的LifecycleBoundObserver。
//LiveData的observe方法和所有数据观察者的Map集合
private SafeIterableMap<Observer<? super T>, ObserverWrapper> mObservers = new SafeIterableMap<>();
/**
-
添加观察者. 事件在主线程分发. 如果LiveData已经有数据，将直接分发给observer。
-
观察者只在LifecycleOwner活跃时接受事件，如果变为DESTROYED状态，observer自动移除。
-
当数据在非活跃时更新，observer不会接收到。变为活跃时 将自动接收前面最新的数据。
-
LifecycleOwner非DESTROYED状态时，LiveData持有observer和owner的强引用，DESTROYED状态时自动移除引用。
*/
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {
assertMainThread("observe”);
//LifecycleOwner是DESTROYED状态，直接忽略
if (owner.getLifecycle().getCurrentState() == DESTROYED) {
return;
}
//将LifecycleOwner、observer组装成LifecycleBoundObserver，添加到mObservers中
LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
if (existing != null && !existing.isAttachedTo(owner)) {
//!existing.isAttachedTo(owner)说明已经添加到mObservers中的observer指定的owner不是传进来的owner，不能添加同一个observer却不同LifecycleOwner
throw new IllegalArgumentException("Cannot add the same observer with different lifecycles");
}
//这里说明已经添加到mObservers中,且owner就是传进来的owner
if (existing != null) {
return;
}
//给LifecycleOwner添加一个生命周期监听Observer，即上面组装的LifecycleBoundObserver
owner.getLifecycle().addObserver(wrapper);
}
LifecycleBoundObserver是LiveData的内部类，是对原始Observer的包装，把LifecycleOwner和Observer绑定在一起。当LifecycleOwner处于活跃状态，那么LifecycleBoundObserver是活跃的观察者。
它实现自接口LifecycleEventObserver，实现了onStateChanged方法。上一篇Lifecycle中提到onStateChanged是生命周期状态变化的回调。在LifecycleOwner生命周期状态变化时 判断如果是DESTROYED状态，则移除观察者。
LiveData自动移除观察者特点就来源于此。如果不是DESTROYED状态，将调用父类ObserverWrapper的activeStateChanged()方法处理，这个生命周期状态变化，shouldBeActive()的值作为参数，至少是STARTED状态为true，即活跃状态为true。
//LiveData的内部类LifecycleBoundObserver，也是生命周期的观察者
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() {
//至少是STARTED状态
return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
}
@Override
public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {
//LifecycleOwner变成DESTROYED状态，则移除观察者
if (mOwner.getLifecycle().getCurrentState() == DESTROYED) {
removeObserver(mObserver);
return;
}
activeStateChanged(shouldBeActive());
}
@Override
boolean isAttachedTo(LifecycleOwner owner) {
return mOwner == owner;
}
@Override
void detachObserver() {
mOwner.getLifecycle().removeObserver(this);
}
}
LiveData.this.mActiveCount == 0是指LiveData的活跃观察者数量。活跃的观察者数量由0变为1、由1变为0会分别调用LiveData的onActive()、onInactive()方法。这就是前面提到的扩展使用的回调方法。
//LiveData的抽象内部类ObserverWrapper
private abstract class ObserverWrapper {
final Observer<? super T> mObserver;
boolean mActive;
int mLastVersion = START_VERSION;
、、、、、、、、、
void activeStateChanged(boolean newActive) {
//活跃状态未发生变化时，不会处理
if (newActive == mActive) {
return;
}
mActive = newActive;
//没有活跃的观察者
boolean wasInactive = LiveData.this.mActiveCount == 0;
//mActive为true表示变为活跃，观察者数量由0变为1；mActive为false表示变为不活跃，观察者数量由1变为0；
LiveData.this.mActiveCount += mActive ? 1 : -1;
if (wasInactive && mActive) {
onActive();
}
if (LiveData.this.mActiveCount == 0 && !mActive) {
onInactive();
}
if (mActive) {
dispatchingValue(this);
}
}
}
observerWrapper不为空，就使用considerNotify()通知真正的观察者LifecycleBoundObserver.onStateChanged方法里调用了activeStateChanged ，而该方法调用dispatchingValue(this);传入了this ，也就是LifecycleBoundObserver ，这时候不为null。也就是说生命周期改变触发的流程就是这种情况，这种情况下，只会通知跟该 Owner绑定的Observer；
observerWrapper为空，则遍历通知所有的观察者，这个时候的流程则会通知active的mObservers。
//LiveData的dispatchingValue方法
private void dispatchingValue(@Nullable ObserverWrapper initiator) {
//如果当前正在分发，则分发无效，return
if (mDispatchingValue) {
mDispatchInvalidated = true;
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;
}
先进行状态检查：观察者是非活跃就return；若当前observer对应的owner非活跃，就会再调用activeStateChanged方法，并传入false，其内部会再次判断。最后回调真正的mObserver的onChanged方法，值是LivaData的变量mData。
//LiveData的considerNotify方法
private void considerNotify(ObserverWrapper observer) {
//观察者非活跃return
if (!observer.mActive) {
return;
}
//若当前observer对应owner非活跃，就会再调用activeStateChanged方法，并传入false，其内部会再次判断
if (!observer.shouldBeActive()) {
observer.activeStateChanged(false);
return;
}
if (observer.mLastVersion >= mVersion) {
return;
}
observer.mLastVersion = mVersion;
//回调真正的mObserver的onChanged方法
observer.mObserver.onChanged((T) mData);
}
4、LiveData数据更新
setValue()只能在主线程中调用，postValue()可以在任何线程中调用。
首先调用 assertMainThread() 方法来判断当前线程是否为主线程（这里他通过一个ArchTaskExecutor的单例类来实现），如果不是主线程，直接抛异常提醒。 如果是在主线程中调用该方法，自加加一个version，来说明值发生了变化。 再把新的值保存起来。 更新value 。
//LiveData的setValue方法
protected void setValue(T value) {
assertMainThread("setValue");
mVersion++;
mData = value;
dispatchingValue(null);
}
mPendingData == NOT_SET第一次一定是返回true，之后都是返回false，然后到这个值更新完毕之前的一瞬间会调用mPendingData=NOT_SET，这也是为什么多次调用 postValue()只有最后一个值才有效的原因。
//LiveData的postValue方法
protected void postValue(T value) {
//定义一个 postTask 的布尔值，判断是否要更新
boolean postTask;
//加个同步锁，因为可能存在多个子线程同时调用postValue() 的情况
synchronized (mDataLock) {
postTask = mPendingData == NOT_SET;
mPendingData = value;
}
if (!postTask) {
return;
}
ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);
}
private final Runnable mPostValueRunnable = new Runnable() {
@Override
public void run() {
Object newValue;
synchronized (mDataLock) {
newValue = mPendingData;
mPendingData = NOT_SET;
}
//线程已经切换到主线程了，所以直接就是调用setValue()
setValue((T) newValue);
}
};
1、ViewModel前的问题点
1、Activity可能会在某些场景（例如屏幕旋转）销毁和重新创建界面，那么存储在其中的界面相关数据都会丢失。例如，界面含用户信息列表，因配置更改而重新创建 Activity 后，新 Activity 必须重新请求用户列表，这会造成资源的浪费。
对于简单的数据，Activity可以使用 onSaveInstanceState() 方法保存 然后从 onCreate() 中的Bundle恢复数据，但此方法仅适合可以序列化再反序列化的少量数据（IPC对Bundle有1M的限制），而不适合数量可能较大的数据，如用户信息列表或位图。
2、UI层（如 Activity 和 Fragment）经常需要通过逻辑层（如MVP中的Presenter）进行异步请求，可能需要一些时间才能返回结果，如果逻辑层持有UI层应用（如context），那么UI层需要管理这些请求，确保界面销毁后清理这些调用以避免潜在的内存泄露，但此项管理需要大量的维护工作。
2、ViewModel的特点
1、ViewModel最重要的特点是 生命周期长于Activity
因屏幕旋转而重新创建Activity后，ViewModel对象依然会保留。只有Activity真正Finish的时ViewModel才会被清除。 也就是说，因系统配置变更Activity销毁重建，ViewModel对象会保留并关联到新的Activity。而Activity的正常销毁（系统不会重建Activity）时，ViewModel对象是会清除的。
2、不持有UI层引用
而ViewModel是不需要持有UI层引用的，那结果怎么给到UI层呢？答案就是使用上一篇中介绍的基于观察者模式的LiveData。
ViewModel也不能持有UI层引用，因为ViewModel的生命周期更长。ViewModel不需要也不能持有UI层引用，那么就避免了可能的内存泄漏，同时实现了解耦。
3、ViewModel实现Fragment间数据共享
Activity 中的多个Fragment需要相互通信是一种很常见的情况。假设有一个ListFragment，用户从列表中选择一项，会有另一个DetailFragment显示选定项的详情内容。在之前可能会定义接口或者使用EventBus来实现数据的传递共享。
//ViewModel
public class SharedViewModel extends ViewModel {
//被选中的Item
private final MutableLiveData<UserContent.UserItem> selected = new MutableLiveData<UserContent.UserItem>();
public void select(UserContent.UserItem user) {
selected.setValue(user);
}
public LiveData<UserContent.UserItem> getSelected() {
return selected;
}
}
//ListFragment
public class MyListFragment extends Fragment {
private SharedViewModel model;
public void onViewCreated(@NonNull View view, Bundle savedInstanceState) {
super.onViewCreated(view, savedInstanceState);
//获取ViewModel，注意ViewModelProvider实例传入的是宿主Activity
model = new ViewModelProvider(requireActivity()).get(SharedViewModel.class);
adapter.setListner(new MyItemRecyclerViewAdapter.ItemCLickListner(){
@Override
public void onClickItem(UserContent.UserItem userItem) {
model.select(userItem);
}
});
}
}
//DetailFragment
public class DetailFragment extends Fragment {
public void onViewCreated(@NonNull View view, Bundle savedInstanceState) {
super.onViewCreated(view, savedInstanceState);
TextView detail = view.findViewById(R.id.tv_detail);
//获取ViewModel,观察被选中的Item
SharedViewModel model = new ViewModelProvider(requireActivity()).get(SharedViewModel.class);
model.getSelected().observe(getViewLifecycleOwner(), new Observer<UserContent.UserItem>() {
@Override
public void onChanged(UserContent.UserItem userItem) {
//展示详情
detail.setText(userItem.toString());
}
});
}
}
要注意的是，这两个Fragment通过ViewModelProvider获取ViewModel时传入的都是它们宿主Activity。这样，当这两个Fragment各自获取ViewModelProvider 时，它们会收到相同的SharedViewModel 实例。
此方法具有以下优势：
1、Activity 不需要执行任何操作，也不需要对此通信有任何了解。
2、除了 SharedViewModel 约定之外，Fragment 不需要相互了解。如果其中一个 Fragment 消失，另一个 Fragment 将继续照常工作。
3、每个 Fragment 都有自己的生命周期，而不受另一个 Fragment 的生命周期的影响。如果一个 Fragment 替换另一个 Fragment，界面将继续工作而没有任何问题。
4、源码分析--ViewModel的存储和获取
在获取ViewModel实例时，并不是直接new的，而是使用ViewModelProvider来获取。ViewModel类是抽象类，内部没有啥逻辑，有个clear()方法会在ViewModel将被清除时调用。
public abstract class ViewModel {
、、、、、、、
private volatile boolean mCleared = false;
//在ViewModel将被清除时调用
//当ViewModel观察了一些数据，可以在这里做解注册防止内存泄漏
@SuppressWarnings("WeakerAccess")
protected void onCleared() {}
@MainThread
final void clear() {
mCleared = true;
、、、、、、、、
onCleared();
}
、、、、、、、
}
只需传ViewModelStoreOwner的构造方法，最后走到两个参数ViewModelStore、factory的构造方法。继续见名知意：ViewModelStoreOwner——ViewModel存储器拥有者；ViewModelStore——ViewModel存储器，用来存ViewModel的地方；Factory——创建ViewModel实例的工厂。
//实现类有Activity/Fragment，也就是说Activity/Fragment都是ViewModelStore的拥有者
public interface ViewModelStoreOwner {
//获取ViewModelStore，即获取ViewModel存储器
ViewModelStore getViewModelStore();
}
//ViewModelProvider的三个构造方法，前两个构造方法会调用第三个构造方法
public ViewModelProvider(@NonNull ViewModelStoreOwner owner) {
//根据ViewModelStoreOwner即（Activity/Fragment）获取ViewModelStore，调用单例方法获取ViewModel构造工厂
this(owner.getViewModelStore(), owner instanceof HasDefaultViewModelProviderFactory
? ((HasDefaultViewModelProviderFactory) owner).getDefaultViewModelProviderFactory()
: NewInstanceFactory.getInstance());
}
public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {
this(owner.getViewModelStore(), factory);
}
public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {
//给成员mViewModelStore(存储ViewModel)、mFactory(构造ViewModel)赋值
mFactory = factory;
mViewModelStore = store;
}
ViewModelStore代码很简单，viewModel作为Value存储在HashMap中。ViewModelStore实例必须要能在系统配置改变后依然存在。
//ViewModelStore用来存储ViewModel
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 keys() {
return new HashSet<>(mMap.keySet());
}
//清除所有的ViewModel。如果ViewModelStore的拥有者（Activity/Fragment）销毁后不会重建，那么就需要调用此方法
public final void clear() {
for (ViewModel vm : mMap.values()) {
vm.clear();
}
mMap.clear();
}
}
看下创建ViewModel实例的工厂Factory，也就是NewInstanceFactory，单例提供ViewModel的构造工厂类，在create方法中通过传入的class反射获取ViewModel实例。
public static class NewInstanceFactory implements Factory {
private static NewInstanceFactory sInstance;
//单例提供ViewModel的构造工厂类
@NonNull
static NewInstanceFactory getInstance() {
if (sInstance == null) {
sInstance = new NewInstanceFactory();
}
return sInstance;
}
@SuppressWarnings("ClassNewInstance")
@NonNull
@Override
public T create(@NonNull Class modelClass) {
try {
//就是通过传入的class反射获取ViewModel实例
return modelClass.newInstance();
} catch (InstantiationException e) {
throw new RuntimeException("Cannot create an instance of " + modelClass, e);
} catch (IllegalAccessException e) {
throw new RuntimeException("Cannot create an instance of " + modelClass, e);
}
}
}
使用viewModelProvider.get(XXXViewModel.class)来获取XXXViewModel实例。先尝试从ViewModelStore获取ViewModel实例，key是"androidx.lifecycle.ViewModelProvider.DefaultKey:xxx.XXXViewModel"，如果没有获取到，就使用Factory创建，然后存入ViewModelStore。
//ViewModelProvider的get方法
public T get(@NonNull Class modelClass) {
String canonicalName = modelClass.getCanonicalName();
if (canonicalName == null) {
throw new IllegalArgumentException("Local and anonymous classes can not be ViewModels");
}
//拿到Key，也即是ViewModelStore中的Map的用于存ViewModel的Key
return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
}
public T get(@NonNull String key, @NonNull Class modelClass) {
//从ViewModelStore获取ViewModel实例
ViewModel viewModel = mViewModelStore.get(key);
//如果从ViewModelStore获取到，直接返回
if (modelClass.isInstance(viewModel)) {
if (mFactory instanceof OnRequeryFactory) {
((OnRequeryFactory) mFactory).onRequery(viewModel);
}
return (T) viewModel;
} else {
if (viewModel != null) {}
}
//没有获取到，就使用Factory创建
if (mFactory instanceof KeyedFactory) {
viewModel = ((KeyedFactory) (mFactory)).create(key, modelClass);
} else {
viewModel = (mFactory).create(modelClass);
}
//存入ViewModelStore 然后返回
mViewModelStore.put(key, viewModel);
return (T) viewModel;
}
5、源码分析--ViewModelStore的存储和获取
先尝试从NonConfigurationInstance从获取ViewModelStore实例，给ComponentActivity成员mViewModelStore赋值。如果NonConfigurationInstance不存在，就new一个mViewModelStore。
//ComponentActivity的getViewModelStore方法
public ViewModelStore getViewModelStore() {
//activity还没关联Application，即不能在onCreate之前去获取viewModel
if (getApplication() == null) {
throw new IllegalStateException("Your activity is not attached to the Application instance. You can't request ViewModel before it");
}
if (mViewModelStore == null) {
//如果ViewModelStore是空，就先尝试从lastNonConfigurationInstance从获取
NonConfigurationInstances nc = (NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {
//给ComponentActivity成员mViewModelStore赋值
mViewModelStore = nc.viewModelStore;
}
//如果lastNonConfigurationInstance不存在，就new一个ViewModelStore
if (mViewModelStore == null) {
mViewModelStore = new ViewModelStore();
}
}
return mViewModelStore;
}
在onRetainNonConfigurationInstance()方法中会把mViewModelStore赋值给NonConfigurationInstances。在Activity因配置改变而正要销毁时，且新Activity会立即创建，那么系统就会调用此方法onRetainNonConfigurationInstance方法。
//ComponentActivity的onRetainNonConfigurationInstance方法
public final Object onRetainNonConfigurationInstance() {
Object custom = onRetainCustomNonConfigurationInstance();
ViewModelStore viewModelStore = mViewModelStore;
if (viewModelStore == null) {
NonConfigurationInstances nc = (NonConfigurationInstances) getLastNonConfigurationInstance();
if (nc != null) {
viewModelStore = nc.viewModelStore;
}
}
if (viewModelStore == null && custom == null) {
return null;
}
//new了一个NonConfigurationInstances，mViewModelStore赋值过来
NonConfigurationInstances nci = new NonConfigurationInstances();
nci.custom = custom;
nci.viewModelStore = viewModelStore;
return nci;
}
ComponentActivity静态内部类NonConfigurationInstances，即与系统配置无关的实例。屏幕旋转等的配置改变 不会影响到这个实例。
//ComponentActivity静态内部类
static final class NonConfigurationInstances {
Object custom;
ViewModelStore viewModelStore;
}
它返回的是Acticity.java中的NonConfigurationInstances的属性activity，也就是onRetainNonConfigurationInstance()方法返回的实例。（注意上面那个是ComponentActivity中的NonConfigurationInstances，是两个类）
ActivityThread中的ActivityClientRecord是不受activity重建的影响，那么ActivityClientRecord中lastNonConfigurationInstances也不受影响，那么其中的Object activity也不受影响，那么ComponentActivity中的NonConfigurationInstances的viewModelStore不受影响，那么viewModel也就不受影响了。
//Activity的getLastNonConfigurationInstance方法
public Object getLastNonConfigurationInstance() {
return mLastNonConfigurationInstances != null ? mLastNonConfigurationInstances.activity : null;
}
//Activity的attach方法
final void attach(Context context, ActivityThread aThread, 、、、
NonConfigurationInstances lastNonConfigurationInstances, 、、、) {
、、、、、、、
mLastNonConfigurationInstances = lastNonConfigurationInstances;
、、、、、、、
}
//ActivityThread的成员mActivities
final ArrayMap<IBinder, ActivityClientRecord> mActivities = new ArrayMap<>();
6、对比onSaveInstanceState()
onSaveInstanceState的调用遵循一个重要原则，即当系统“未经你许可”时销毁了你的activity，则onSaveInstanceState会被系统调用，这是系统的责任，因为它必须要提供一个机会让你保存你的数据（当然你不保存那就随便你了）。
1、存储方式
ViewModel是存在内存中，读写速度快，而通过onSaveInstanceState序列化到磁盘中。
2、存储数据的限制
ViewModel，可以存复杂数据，大小限制就是App的可用内存。而onSaveInstanceState只能存可序列化和反序列化的对象，且大小有限制（一般Bundle限制大小1M）。
