Lifecycle is a library used to perceive the life cycle of Activity and Fragment. What is the use? 现在有这样一个需求在activity的 onStart onStop 分别调用mListener的 start() stop()方法，我们需要在这两个方法中做一些操作, we can use the callback form to achieve the following:
public interface MyListener {
void start();
void stop();
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
mListener = object : MyListener {
override fun start() {
//do something....
}
override fun stop() {
//do something....
}
}
}
override fun onStart() {
super.onStart()
mListener.start()
}
override fun onStop() {
super.onStop()
mListener.stop()
}
复制代码The above code perfectly implements the requirements but it has several problems:
1: The code coupling is high, and the activity is too bloated and difficult to maintain. 2: If we call the mListener.start method in the callback of a time-consuming operation, the activity first enters the onStop life cycle, and when the time-consuming operation is over, we call the mListener.start method, then the mListener will no longer be available. I can't go to the stop method, and because mListener holds the activity, it will cause a memory leak
Lifecycle solves this problem perfectly
use of lifecycle
First, let's take a look at the basic use of lifecycle
class MainActivity : AppCompatActivity() {
private lateinit var mListener :MyListener
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
/**
* Activity（或Fragment）是生命周期的拥有者，通过getLifecycle()方法获取到生命周期Lifecycle对象
* Lifecycle对象使用addObserver方法 给自己添加观察者，即 MyLifecycleObserver 对象
* 当Lifecycle的生命周期发生变化时，MyLifecycleObserver 就可以感知到
*/
lifecycle.addObserver(MyLifecycleObserver())
}
class MyLifecycleObserver : LifecycleObserver {
//在activity的onCreate生命周期执行的时候就会回调到这个方法
@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
fun create() {
Log.e("LifecycleObserver", " create")
}
//在activity的 onStart 生命周期执行的时候就会回调到这个方法
@OnLifecycleEvent(Lifecycle.Event.ON_START)
fun start() {
Log.e("LifecycleObserver", " start")
}
//在activity的 onResume 生命周期执行的时候就会回调到这个方法，使用就是这么简单
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
fun resume() {
Log.e("LifecycleObserver", " resume")
}
}
复制代码Analysis of source code should bring its own problems and purposes to analyze, so as not to fall into
- what is lifecycleOwner
- You can use the lifecycle directly in the activity. What is the lifecycle?
- what exactly does addObserver do
- How does the observer MyLifecycleObserver perceive the life cycle of the activity?
LifecycleOwner
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
复制代码Click to see that the lifecycle is actually the getLifecycle() method. You can get the Lifecycle instance by calling getLifecycle() in the Activity. Where is the method defined by getLifecycle()? It is the interface LifecycleOwner, Gu Minglai means the owner of the life cycle:
public interface LifecycleOwner {
/**
* Returns the Lifecycle of the provider.
*
* @return The lifecycle of the provider.
*/
@NonNull
Lifecycle getLifecycle();
复制代码The first question can be answered here. LifecycleOwner is a common interface that defines a getLifecycle() method. Fragment and Activity of AndroidX have implemented the LifecycleOwner interface, so we can directly use getLifecycle() in Activity, it is just convenient for us Get the Lifecycle instance directly, that's all
Lifecycle、LifecycleRegistry
Lifecycle
在分析lifecycle类的源码之前先看一张来自官网的图：
- Event表示生命周期事件他们对应activity、Fragment的生命周期方法
- State表示生命周期状态，Event是指进入一种状态的事件
- 您可以将状态看作图中的节点，将事件看作这些节点之间的边。
- RESUMED状态是一个分界线，ON_CREATE、ON_START、ON_RESUME事件，是在LifecycleOwner对应的方法执行之后分发；ON_PAUSE、ON_STOP、ON_DESTROY事件，是在LifecycleOwner对应的方法调用之前分发。
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();
//这是生命周期事件，对应activity的生命周期方法
@SuppressWarnings("WeakerAccess")
public enum Event {
/**
* Constant for onCreate event of the {@link LifecycleOwner}.
*/
ON_CREATE,
/**
* Constant for onStart event of the {@link LifecycleOwner}.
*/
ON_START,
/**
* Constant for onResume event of the {@link LifecycleOwner}.
*/
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
//看名字就知道，可以对应所有生命周期方法
ON_ANY;
/**
* 这里需要结合上面官网的图来看
* 根据生命周期状态返回event事件，从名字可以看出来downFrom是指根据给定的状态往下降一级
* 比如CREATED状态要想往下降到DESTROYED就需要走生命周期的onDestroy，event事件即对应ON_DESTROY，其它的同理
*/
@Nullable
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;
}
}
/**
* 下降到指定的生命周期状态比如想要降到CREATED状态就需要调用onStop，event对应的事件为ON_STOP,理解了这两个方法后续的upFrom、upTo也就好理解了
*/
@Nullable
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;
}
}
@Nullable
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;
}
}
@Nullable
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;
}
}
//根据当前event事件判断是处于哪个生命周期状态下
@NonNull
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");
}
}
//生命周期状态
public enum State {
/**
* Destroyed state for a LifecycleOwner. After this event, this Lifecycle will not dispatch
* any more events. For instance, for an {@link android.app.Activity}, this state is reached
* <b>right before</b> Activity's {@link android.app.Activity#onDestroy() onDestroy} call.
*/
//根据注释的解释：来到这个状态后将不再分发事件了，它会在生命周期onDestroy之前调用
//其实也好理解如果都已经调了onDestroy的话事件可能就分发不到这里来了
DESTROYED,
/**
* Initialized state for a LifecycleOwner. For an {@link android.app.Activity}, this is
* the state when it is constructed but has not received
* {@link android.app.Activity#onCreate(android.os.Bundle) onCreate} yet.
*/
INITIALIZED,
//onCreate之后onStop之前
CREATED,
//onStart之后onPause之前
STARTED,
//onResume之后
RESUMED;
/**
* Compares if this State is greater or equal to the given {@code state}.
*
* @param state State to compare with
* @return true if this State is greater or equal to the given {@code state}
*/
public boolean isAtLeast(@NonNull State state) {
return compareTo(state) >= 0;
}
}
}
复制代码LifecycleRegistry
public abstract class Lifecycle
public class LifecycleRegistry extends Lifecycle
复制代码上述代码可以知道Lifecycle就是个抽象类，所以功能实现的重点当然在LifecycleRegistry中，在getLifecycle方法中也看到了返回的是mLifecycleRegistry对象，看一下LifecycleRegistry的构造方法
private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
public LifecycleRegistry(@NonNull LifecycleOwner provider) {
this(provider, true);
}
private LifecycleRegistry(@NonNull LifecycleOwner provider, boolean enforceMainThread) {
//这个provider就是activity
mLifecycleOwner = new WeakReference<>(provider);
//初始状态为INITIALIZED
mState = INITIALIZED;
//强制在主线程操作
mEnforceMainThread = enforceMainThread;
}
复制代码这里记录一个之前对弱引用错误的理解，先看一下弱引用的构造方法
public WeakReference(T referent) {
super(referent);
}
复制代码结合构造方法来看mLifecycleOwner = new WeakReference<>(provider)这里的mLifecycleOwner并不是弱引用，只有 referent 是通过父类的构造函数注册到弱引用的队列里，referent 才是弱引用；因此provider才是弱引用activity是弱引用指向的对象
addObserver
直接上代码
//加入的LifecycleObserver会被加入到这个Map队列中
private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap =
new FastSafeIterableMap<>();
//当前的State状态
private State mState;
//当前正在添加的Observer的数量，注意它不是说一直加
private int mAddingObserverCounter = 0;
//可有理解为是否在进行队列同步State（Sync()方法）状态判断值
private boolean mHandlingEvent = false;
//是否有新的Event值通知进来
private boolean mNewEventOccurred = false;
@Override
public void addObserver(@NonNull LifecycleObserver observer) {
enforceMainThreadIfNeeded("addObserver");
//lifecycleObserver的初始生命周期状态状态
//刚开始LifecycleObserver的默认状态是INITIALIZED
//但是假如当前整个LifecycleRegistry的当前状态是DESTROYED， 那我们也就知道了其实已经回不到其他状态了
//我们就直接把新添加的LifecycleObserver也变成DESTROYED,后续很多逻辑也就走不通了
//就好比Activity已经变成了onDestory了，也不可能在变成其他什么onCraete，onResume状态了，回不去了
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
//ObserverWithState类主要是保存了观察者LifecycleObserver以及它目前的生命周期状态
//因为当前lifecycle的生命周期状态可能是RESUMED，这时候你新增一个观察者他的生命周期状态是INITIALIZED
//我们又希望观察者除了RESUMED之外还可以收到ON_CREATE,ON_START等事件
//所以我们必须知道当前LifecycleObserver的状态， 然后根据它的状态，和需要改变的最终的状态值，然后一步步的变化过去，然后一步步的发送事件
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
//使用的是putIfAbsent方法存入队列，这个putIfAbsent在讲解这个数据结构的时候会讲到
//它不像一般的Map结构，会用新的值覆盖老的值，而是发现有老的值，就直接把已经存的老的值返回。
//所以如果我们把传入的LifecycleObserver在队列中找到了的话， 就说明前面就添加过了，现在是重复添加，直接return返回
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
if (previous != null) {
return;
}
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null) {
// it is null we should be destroyed. Fallback quickly
return;
}
/**
* mAddingObserverCounter：
* 通过字面意思就可以知道是正在添加的LifecycleObserver的数量
* 我们可以看到下面有个mAddingObserverCounnter++ ,然后最后整个addObserver()方法执行完了之后， 又会运行mAddingObserverCounter--
* 所以正常流程是进来一个LifecycleObserver进来添加，我们会用这个mAddingObserverCounter加1，然后LifecycleObserver整个都被添加完了后，我们就减1，正常添加是没问题
* 但是假如正好并发添加多个观察者，这时候可能一个先进行++操作，但是整个addObserver()方法还没走完，另外一个也进来添加了，这时候我们的mAddingObserverCounter就!=0了
*
* mHandlingEvent：
* 字面意思是正在处理事件，它的赋值是在moveToState()方法中，在该方法中又会调用sync()方法，sync之前置为true，sync后又置为false
* 所以这个参数我们可以理解为当前是否正好在处理Event事件
*
* isReentrance：
* 我们认为同时添加多个Observer或者同时发送多个Event进来，都算是重入
*/
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
//获取目标State值
State targetState = calculateTargetState(observer);
mAddingObserverCounter++;
//下面代码的逻辑：通过while循环，把新的观察者的状态连续的同步到最新状态mState
//意思就是：虽然可能添加的晚，但把之前的事件一个个分发给你(upEvent方法)，即粘性
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();
// mState / subling may have been changed recalculate
targetState = calculateTargetState(observer);
}
//如果没有重入，则更新整个队列，因为有重入的话等到最后再更新一次就行了，否则浪费资源
if (!isReentrance) {
// we do sync only on the top level.
sync();
}
mAddingObserverCounter--;
}
复制代码以上就是addObserver的核心，构建ObserverWithState保存观察者以及它的状态，然后再把新增的观察者的状态一步步的更新到mState对应的状态，最后再同步整个队列，如果有多个observer加进来则等到最后再同步一次。
那如果加入一个observer的同时又在处理事件又怎么处理呢？暂时不管先继续往下看，观察者加入后如果再接收到了新事件又是怎么处理的呢？
moveToState
外界可以通过调用lifecycle的 markState ，setCurrentState 和 handleLifecycleEvent 等方法去改变lifecycle的生命周期状态从而分发到每一个观察者中
//该方法已标记废弃，建议使用setCurrentState方法替代
@Deprecated
@MainThread
public void markState(@NonNull State state) {
enforceMainThreadIfNeeded("markState");
setCurrentState(state);
}
@MainThread
public void setCurrentState(@NonNull State state) {
enforceMainThreadIfNeeded("setCurrentState");
moveToState(state);
}
public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
enforceMainThreadIfNeeded("handleLifecycleEvent");
moveToState(event.getTargetState());
}
复制代码这三个方法都强制要求在主线程中操作，还记得lifetccleRegistry的构造方法也提到过，注意这三个方法最终都调用了moveToState方法，顾名思义它应该就是真正开始改变lifecycle生命周期状态、分发到观察者的地方了
private void moveToState(State next) {
if (mState == next) {
return;
}
mState = next;
if (mHandlingEvent || mAddingObserverCounter != 0) {
/**
* 注意这个字段 如果进入是因为mHandlingEvent为true引起的，说明已经在更新队列，当前又有一个新的State发送进来
* 那么没必要去开启一个新的队列更新任务，所以这里会进行return
*
* 同时如果原来的队列更新任务正好更新到一半，那么已经更新好的那些观察者其实也已经不是最新的了， 那么这个任务就要重新整个队列全部重新更新一遍
* 所以需要一个字段在sync()方法的更新队列里面告诉它有新的Event值进来了，为true时就及时打断同步过程，而使用新的state进行同步，这样可以节约时间。
* 具体看sync方法
*
* 如果进入是因为mAddingObserverCounter进入，理由与上面类似
* 因为加入一个观察者后，mAddingObserverCounter != 0说没执行完此时也会执行sync，所以不需要再启动新的
*/
mNewEventOccurred = true;
// we will figure out what to do on upper level.
return;
}
//看这里在sync之前就把mHandlingEvent置为true，这呼应了addObserver
//如果当前在sync那么在addObserver中就不会再sync了
mHandlingEvent = true;
sync();
//sync结束又置为false
mHandlingEvent = false;
}
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()) {
mNewEventOccurred = false;
//当前实际的mState状态值比队列头的状态小，说明队列的状态值太大了，要后退变小
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
//进行后退操作
backwardPass(lifecycleOwner);
}
//当前实际的mState状态值比队列尾的状态大，说明队列的状态值太小了，要前进变大
Map.Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0) {
//前进操作
forwardPass(lifecycleOwner);
}
}
mNewEventOccurred = false;
}
//后退操作
private void backwardPass(LifecycleOwner lifecycleOwner) {
Iterator<Map.Entry<LifecycleObserver, ObserverWithState>> descendingIterator =
mObserverMap.descendingIterator();
//如果有新的事件传进来则while循环停止
while (descendingIterator.hasNext() && !mNewEventOccurred) {
Map.Entry<LifecycleObserver, ObserverWithState> entry = descendingIterator.next();
ObserverWithState observer = entry.getValue();
//从这里可以看出是先把一个观察者状态调整完成过后再调整下一个观察者，如果有新的事件传进来则while循环停止
while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey()))) {
Event event = Event.downFrom(observer.mState);
if (event == null) {
throw new IllegalStateException("no event down from " + observer.mState);
}
pushParentState(event.getTargetState());
observer.dispatchEvent(lifecycleOwner, event);
popParentState();
}
}
}
复制代码为什么我们都判断需要后退操作了，还需要重新去判断是否需要前进操作？ 配合moveToState中的mNewEventOccurred字段和forwardPass、backwardPass操作来看，比如原来的观察者是4个状态分别是：
4 -> 4 -> 4 -> 4
这个时候新来一个状态是2那么满足实际状态比队头状态小，则开始后退
4 -> 4 -> 4 -> 2
4 -> 4 -> 2 -> 2
当执行都这里的时候又来了一个新的状态3那么他就既满足比队头状态小比队尾状态大，则前进后退都通知执行。
在forwardPass和backPass中就会拿到队列里面的每一个观察者以及对应的生命周期状态，和当前lifecycle的生命周期状态做对比，不一样当然就会就行分发，那是怎么分发到每一个观察者的呢？其实很简当来到moveToState方法的时候，mState已经是最新的状态了，而我们又能拿到每一个观察者对象，那么就可以通过反射的方式拿到这个观察者的所有方法及方法的注解信息，然后和当前分发给它的event事件做对比如果都相同那么就反射调用该方法就行了
到此我们已经知道添加观察者和lifecycleRegistry内部是怎样分发生命周期状态的
ReportFragment
那么随着activity生命周期的改变lifecycleRegistry又是怎么知道的呢？或者说activity、fragment这些是在哪里调用handleLifecycleEvent、setCurrentState这些方法的？由于ComponentActivity实现了LifecycleOwner接口现在去看下它的生命周期onCreate做了什么
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
//省略。。。
//核心就是这里了
ReportFragment.injectIfNeededIn(this);
}
public class ReportFragment extends android.app.Fragment {
private static final String REPORT_FRAGMENT_TAG = "androidx.lifecycle"
+ ".LifecycleDispatcher.report_fragment_tag";
public static void injectIfNeededIn(Activity activity) {
//在API 29及以上，可以直接注册回调 获取生命周期
if (Build.VERSION.SDK_INT >= 29) {
// On API 29+, we can register for the correct Lifecycle callbacks directly
androidx.lifecycle.ReportFragment.LifecycleCallbacks.registerIn(activity);
}
//API29以前，使用fragment 获取生命周期
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
manager.beginTransaction().add(new androidx.lifecycle.ReportFragment(), REPORT_FRAGMENT_TAG).commit();
// Hopefully, we are the first to make a transaction.
manager.executePendingTransactions();
}
}
@SuppressWarnings("deprecation")
static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) {
if (activity instanceof LifecycleRegistryOwner) {
((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
return;
}
if (activity instanceof LifecycleOwner) {
Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
}
}
}
static androidx.lifecycle.ReportFragment get(Activity activity) {
return (androidx.lifecycle.ReportFragment) activity.getFragmentManager().findFragmentByTag(
REPORT_FRAGMENT_TAG);
}
private androidx.lifecycle.ReportFragment.ActivityInitializationListener mProcessListener;
private void dispatchCreate(androidx.lifecycle.ReportFragment.ActivityInitializationListener listener) {
if (listener != null) {
listener.onCreate();
}
}
private void dispatchStart(androidx.lifecycle.ReportFragment.ActivityInitializationListener listener) {
if (listener != null) {
listener.onStart();
}
}
private void dispatchResume(androidx.lifecycle.ReportFragment.ActivityInitializationListener listener) {
if (listener != null) {
listener.onResume();
}
}
@Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
dispatchCreate(mProcessListener);
dispatch(Lifecycle.Event.ON_CREATE);
}
@Override
public void onStart() {
super.onStart();
dispatchStart(mProcessListener);
dispatch(Lifecycle.Event.ON_START);
}
@Override
public void onResume() {
super.onResume();
dispatchResume(mProcessListener);
dispatch(Lifecycle.Event.ON_RESUME);
}
private void dispatch(@NonNull Lifecycle.Event event) {
if (Build.VERSION.SDK_INT < 29) {
dispatch(getActivity(), event);
}
}
void setProcessListener(androidx.lifecycle.ReportFragment.ActivityInitializationListener processListener) {
mProcessListener = processListener;
}
interface ActivityInitializationListener {
void onCreate();
void onStart();
void onResume();
}
@RequiresApi(29)
static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {
static void registerIn(Activity activity) {
activity.registerActivityLifecycleCallbacks(new androidx.lifecycle.ReportFragment.LifecycleCallbacks());
}
@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);
}
}
}
复制代码injectIfNeededIn()内进行了版本区分：在API 29及以上 直接使用activity的registerActivityLifecycleCallbacks 直接注册了生命周期回调，然后给当前activity添加了ReportFragment，注意这个fragment是没有布局的。
然后， 无论LifecycleCallbacks、还是fragment的生命周期方法 最后都走到了 dispatch(Activity activity, Lifecycle.Event event)方法，其内部使用LifecycleRegistry的handleLifecycleEvent方法处理事件。
而ReportFragment的作用就是获取生命周期而已，因为fragment生命周期是依附Activity的。
到此就理清了整个流程还是，流程还是很简单的，其实说到底就是activity或者fragment生命周期发生改变时，调用 lifecycleRegistry 的handleLifecycleEvent或者setCurrentState方法，给出最新的生命周期后lifecycleRegistry遍历队列一步一步的通过反射的方式去调用观察者对应的方法，至于lifecycleOwner就更简单了无非就是方便我们获取到lifecycleRegistry实例。至于这里的ReportFragment其实就是把这部分逻辑抽离出来，实现activity的无侵入
lifecycle整体流程理清了现在来看一个很重要的类FastSafeIterableMap
FastSafeIterableMap
Iterator
分析它们之前先来说说为什么用迭代器：
正是由于每一个容器都有删除、获取元素的功能。这些功能定义都一样，只不过实现的具体方式不同（因为每一个容器的数据结构不一样）所以对共性的取出功能进行了抽取，从而出现了Iterator接口。而每一个容器都在其内部对该接口进行了内部类的实现，也就是将取出方式的细节进行封装。
为什么使用迭代器？不是已经有for循环了吗？for循环适合访问顺序结构如 ArrayList，因为可以根据下标快速获取指定元素 ArrayList.get时间复杂度为O(1)。而Iterator 适合访问链式结构如 linkedList，因为迭代器是通过next()和Pre()来定位的可以访问没有顺序的集合 linkedList.get时间复杂度为O(n)，如果再使用for循环的话寻找一个合适的数据linkedList的时间复杂度就位O(n2)，所以对于linkedList使用迭代器是更好的选择。
SafeIterableMap 单纯从名字看以为是个map实际上它是以链表的形式存储数据，在遍历时可以安全的进行删除和增加操作的list，它已经帮我们处理好了不会出现并发修改异常，比如下面代码：
HashMap<Integer,String>map = new HashMap<>();
map.put(1,"1");
map.put(2,"2");
map.put(3,"3");
map.put(4,"4");
map.put(5,"5");
for (Map.Entry<Integer,String>entry :map.entrySet()){
if (entry.getKey() == 2){
//增强for循环，简化了迭代器的书写格式，底层还是使用了迭代器遍历
//这里remove的时候就会发生异常，因为在使用迭代器遍历的时候是不允许迭代器以外的对元素进行新增删除操作的
map.remove(2);
}
}
List<Integer> list = new ArrayList<>();
list.add(1);
list.add(2);
list.add(3);
list.add(4);
for (Integer value : list) {
if (value == 2) {
//也会发生异常
list.remove(value);
}
}
//这段代码就是Integer value : list反编译过后的代码
Integer value;
for(Iterator iterator = list.iterator(); iterator.hasNext()){
value = (Integer)iterator.next();
}
复制代码以上述代码的 ArrayList 来举例看看为什么list.remove(value)会异常
//首先因为使用的是增强for循环，先调用了iterator方法
public Iterator<E> iterator() {
return new Itr();
}
private class Itr implements Iterator<E> {
protected int limit = ArrayList.this.size;
// 游标指向的是下一个元素的index
int cursor; // index of next element to return
int lastRet = -1; // index of last element returned; -1 if no such
//这里是核心 modCount 是list的修改次数，它会随着list的add、remove而增加，可以自己去看一下list的add、remove对于modCount的影响
int expectedModCount = modCount;
public boolean hasNext() {
return cursor < limit;
}
@SuppressWarnings("unchecked")
public E next() {
//这里就是异常抛出的地方
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
int i = cursor;
if (i >= limit)
throw new NoSuchElementException();
Object[] elementData = ArrayList.this.elementData;
if (i >= elementData.length)
throw new ConcurrentModificationException();
cursor = i + 1;
return (E) elementData[lastRet = i];
}
//所以 Iterator 在工作的时候是不允许被迭代的对象被改变的。
//但你可以使用 Iterator 本身的方法 remove() 来删除对象，该方法会在删除当前迭代对象的同时维护索引的一致性
public void remove() {
if (lastRet < 0)
throw new IllegalStateException();
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
try {
ArrayList.this.remove(lastRet);
cursor = lastRet;
lastRet = -1;
expectedModCount = modCount;
limit--;
} catch (IndexOutOfBoundsException ex) {
throw new ConcurrentModificationException();
}
}
}
复制代码我也想过为什么ArrayList需要加modCount != expectedModCount这种判断，导致在使用迭代器的时候不能用list去删除，既然SafeIterableMap能够做到用集合去删除，list肯定也可以
个人更倾向于Fail-Fast机制：快速失败系统，通常设计用于停止有缺陷的过程，这是一种理念，在进行系统设计时优先考虑异常情况，一旦发生异常，直接停止并上报。与 fail-fast 相对的是 fail-safe。顾名思义，fail-safe 在故障发生之后会维持系统继续运行。Java 在容器中用到了这两种机制，当使用迭代器遍历时对于数据结构的修改(**add、remove**)必须使用迭代器 iterator自身的add、remove方法，iterator遵循了 fail-fast 机制，也就是说不按照这个规则来操作数据结构就会报错
由于这些集合是线程不安全的，比如一个读线程正在使用迭代器遍历集合，另一个写线程又在(add、remove)修改集合数据，造成读线程拿到的数据有误。而iterator遵循了fail-fast机制，按照 Fail-fast 的原则应该尽早上报这个错误。为了发现这种情况 Java 在 AbstractList 这个类里面添加了一个成员变量 modCount ，每当通过 List 提供的接口对其进行修改时modCount++，然后在每次操作链表的时候，会先验证当前链表的 modCount 是否和迭代器中记录的一致。如果不一致，说明链表已经发生改变，无法保证迭代器能返回正确的结果。所以我们就看到了这样的错误 throw new ConcurrentModificationException();
如果有大佬还有其它更好的答案欢迎留言，大家一起学习
SafeIterableMap
现在再去看 SafeIterableMap 就更加轻松了，就是一个普通的链表，然后替我们解决了迭代器中不能使用其它去删除元素的问题.来看一下它的remove
public V remove(@NonNull K key) {
Entry<K, V> toRemove = get(key);
if (toRemove == null) {
return null;
}
//链表的大小
mSize--;
if (!mIterators.isEmpty()) {
for (SupportRemove<K, V> iter : mIterators.keySet()) {
//这里调用了迭代器的supportRemove方法
iter.supportRemove(toRemove);
}
}
//以下代码才是真正删除，就是很简单的链表删除节点的代码
step1：省略。。。
}
@NonNull
@Override
public Iterator<Map.Entry<K, V>> iterator() {
//这里把链表的头部和尾部传进去了
ListIterator<K, V> iterator = new AscendingIterator<>(mStart, mEnd);
mIterators.put(iterator, false);
return iterator;
}
static class AscendingIterator<K, V> extends ListIterator<K, V> {
AscendingIterator(Entry<K, V> start, Entry<K, V> expectedEnd) {
super(start, expectedEnd);
}
@Override
Entry<K, V> forward(Entry<K, V> entry) {
return entry.mNext;
}
@Override
Entry<K, V> backward(Entry<K, V> entry) {
return entry.mPrevious;
}
}
//这里的迭代器没有提供真正的删除，只提供了遍历操作
//真正的删除在step1，它只不过会随着迭代动态修改头结点指向的地址，所以叫supportRemove而不叫remove
private abstract static class ListIterator<K, V> implements Iterator<Map.Entry<K, V>>,
SupportRemove<K, V> {
Entry<K, V> mExpectedEnd;
Entry<K, V> mNext;
ListIterator(Entry<K, V> start, Entry<K, V> expectedEnd) {
this.mExpectedEnd = expectedEnd;
this.mNext = start;
}
@Override
public boolean hasNext() {
return mNext != null;
}
@SuppressWarnings("ReferenceEquality")
@Override
public void supportRemove(@NonNull Entry<K, V> entry) {
//就剩自己了，直接干掉
if (mExpectedEnd == entry && entry == mNext) {
mNext = null;
mExpectedEnd = null;
}
//传入的Eentry等于尾节点，则退后移动一个节点
if (mExpectedEnd == entry) {
mExpectedEnd = backward(mExpectedEnd);
}
//传入的Eentry等于头节点，则往前移动一个节点
if (mNext == entry) {
mNext = nextNode();
}
}
@SuppressWarnings("ReferenceEquality")
private Entry<K, V> nextNode() {
if (mNext == mExpectedEnd || mExpectedEnd == null) {
return null;
}
return forward(mNext);
}
@Override
public Map.Entry<K, V> next() {
//这里很重要每次next的时候都把头结点向前移动
//这样在遍历的时候如果要删除一个元素那么它一定等于mNext或者mExpectedEnd，因为每次next的时候mNext都会跟随变化
//至于具体删除节点的操作就交给上述省略的代码了，如此就满足了迭代器遍历，集合还能删除的功能
Map.Entry<K, V> result = mNext;
mNext = nextNode();
return result;
}
}
复制代码以上就是 SafeIterableMap 的核心代码了，而它的子类FastSafeIterableMap，有一个Fast。。。其实就是因为SafeIterableMap是链表在，嫌它在get的时候太慢了，所以又封装了一下用hashMap再去做了一次存储，这样也提高了get的执行速度。