Lifecycle源码分析1

前言

对于Android开发，Activity/Fragment的生命周期我们肯定非常熟悉，下图是官方的Activity的生命周期图：

然后下图是Fragment的生命周期图：

对于组件的生命周期函数的回调在Android中有严格顺序，它是我们能正常开发、展示数据的基础，是由Android系统控制，我们无法干预。

所以我们经常需要在Activity/Fragment的生命周期函数中做一些逻辑处理，这个也是很正常的事，不过这再正常不过的事却有着一些缺陷，我们来逐步分析。

正文

缺陷

这里的缺陷其实不是什么大问题，我们在日常使用一般都会如此使用，主要有俩点：

生命周期函数中太多逻辑代码，比如我们会在onCreate里初始化各种数据，然后在onResume中进行数据展示等，这样的话逻辑太多会导致逻辑混乱。
假如我需要在onStart中开启一个服务，然后在onStop中进行关闭，但是这个服务是耗时操作，这就有可能会出现界面的onStop已经调用但是服务还没有开启，而从导致的错误。

其实仔细想一下，生命周期是啥，不就是那几个回调函数吗，那假如把这几个回调函数单独抽离出来，放在一个类中，我在什么周期该干的事直接在这个类的回调函数里做即可，所以这就是Lifecycle。

Lifecycle概述

Lifecycle保存着Activity/Fragement的生命周期，而且允许其他其他组件观察其状态。

基本用法1

我们这里来看一下最基本的用法：

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    lifecycle.addObserver(object : LifecycleEventObserver {
        override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
            Logger.d("source = $source  event = $event")
        }
    })
}
复制代码

可以看出这里使用的观察者模式，通过给Lifecycle添加观察者，当Lifecycle的生命周期变化时通知观察者，这里非常简单，运行结果如下：

会发现这里回调的结果是Event，那这个Event是什么呢，从命名可以看出，它是一个事件，同时对应着之前Activity的生命周期函数。

那如果是Fragement呢，其实不用测试了，也是这几个回调事件，不再赘述。

基本用法2

除了这个作用，Lifecycle还有一个最常用的作用就是判断当前View的状态，比如我们熟悉的LiveData就有一个特性就是当Activity/Fragment在非前台时是不会更新数据的，代码如下：

这里会判断LifecycleOwner(即Activity/Fragemnt)的当前State，因为前面说的Event事件回调是瞬间的，所以要有个变量来保存当前View的状态即这个State，那如果按照正常的想法可能需要6 - 7种状态，在每个Event发生后把状态设置为该状态，那么我们来看一下这个State：

public enum State {
    
    DESTROYED,

    INITIALIZED,

    CREATED,

    STARTED,

    RESUMED;
}
复制代码

会发现这里就5种，那假如我要判断当Activity在onPause方法执行后的状态呢，该用哪个表示呢，所以这里就来探究一下源码，理解为什么这样设计。

State和Event的关系

上面我们说了所有State的所有枚举，那Event的枚举我们也看一下：

public enum Event {
   
    ON_CREATE,
  
    ON_START,
   
    ON_RESUME,
    
    ON_PAUSE,
    
    ON_STOP,
    
    ON_DESTROY,
    
    ON_ANY;
    }
复制代码

这里要明确一点就是Lifecycle就是通过Event来回调说明当前Activity/Fragment的生命周期回调情况，然后通过State来保存当前Lifecycle的状态。

这2者的关系在官网有一张图可以完美诠释，也就是ON_CREATE和ON_STOP回调事件发生后都是CREATED状态，这也就说明了为什么State的枚举少几种，那既然如此我获取到了当前状态是CREATED，那Activity是刚执行完ON_CREATE还是刚执行完ON_STOP呢，带着疑问，我们在源码探究。

几个主要类的关系

其实Lifecycle的代码非常少，但是很重要，它是Jetpack组件的基础，所以我们需要明确几点。

LifecycleOwner

生命周期持有者，如果一个类实现了该接口，就说明它有了Lifecycle的功能，这个接口的代码如下：

Lifecycle

这个就是生命周期的核心类，它的代码也非常简单，主要包括3个方法，和2个枚举类，枚举类就是上面的State和Event，那3个方法是啥呢：

public abstract void addObserver(@NonNull LifecycleObserver observer);
复制代码

public abstract void removeObserver(@NonNull LifecycleObserver observer);
复制代码

public abstract State getCurrentState();
复制代码

所以当一个类继承了Lifecycle必须要能够实现这几个方法。

LifecycleObserver

生命周期观察者，一个合格的生命周期系统必须能观察到它生命周期的变化，所以定义了LifecycleObserver这个接口。

所以分析完上面3个基本接口，我们就理解了大致设计原理，接下来我们带着问题来看一下源码，主要就是以下几个问题：

Activity/Fragment的生命周期是如何传递给Lifecycle来保存的。
生命周期方法回调时如何设置当前的状态。
观察者模型是如何实现的。

源码分析

我们直接来看一下源码，虽然这部分的逻辑不复杂，但是多看看源码的实现有助于我们平时写代码。

同名类

我们平时写的Activity继承至 androidx.appcompat.app.AppComponentActivity，

它继承至androidx.appcompat.app.FragmentActivity，

它继承至 androidx.activity.ComponentActivity，

而它继承至 androidx.core.app.ComponentActivity，

会发现这里居然有同名的类，不太懂官方为什么要这样设计，按照之前的思路，这2个类肯定会实现LifecycleOwner接口，我们来看一下：

居然2个同名类都实现了这个接口，不仅如此，这2个类的实现方法是一样的：

可以发现这里真正的实现类就是LifecycleRegistry了。

ReportFragment

本来我以为会在ComponentActivity中的onCreate、onResume等方法中传递生命周期回调事件给mLifecycleRegistry，结果我发现它专门有个类来分发这些事件，这个类就是ReportFragment，在ComponentActivity的onCreate方法中：

在ReportFragment中：

我们发现这个也是正常的Fragment，但是生命周期的分发，这里还判断了2种情况，当SDK >= 29时，由LifecycleCallbacks类来做，否则由Fragment的生命周期来分发。

因为Activity和Fragment的关系，所以有下面代码，可以在Fragment的生命周期回调中来派发Activity的生命周期回调：

这里在Fragment的回调中进行分发6种Event：

会发现最终6种Event都被传递到了LifecycleRegistry的handleLifecycleEvent函数中。

那当SDK >= 29时又是什么情况呢，我们来简单看一下：

首先这个类是静态类，而且调用的ReportFragment中的dispatch方法，所以在registerActivityLifecycleCallbacks中肯定有在Activity的生命周期回调函数中回调这几个方法的地方，我们来看一下：

这些方法都是Activity的方法，也就是我最开始的想法，直接在Activity的各个生命周期函数里派发事件。

所以接下来看看LifecycleRegistry的实现。

LifecycleRegistry

既然我们知道了Activity/Fragment如何把生命周期的事件传递给Lifecycle，也就是调用LifecycleRegsitry中的方法，这个LifecycleRegistry的作用就是负责整理派发的生命周期事件，同时保存当前的State。

虽然我们知道LifecycleRegistry要实现的效果，不过这个类处理起来还挺麻烦，我们来仔细分析。

外部调用方法

上面的代码调用该方法来处理生命周期事件：

其中event.getTargetState()我们需要注意：

会发现这里就是把6种生命周期事件给转换成了4种State，然后调用moveToState()方法：

所以这里的核心就是moveToState函数，不过它定义了很多Boolean的标志位，如果不仔细了解的话，将很难理解该类设计的巧妙之处。

我们暂且按下不表，先总体看看这个类。

整体功能

我们简单了解一下LifecycleRegistry的3个功能：

外部Activity/Fragment发送Event事件到LifecycleRegistry中
把传递进来的Event转换成State，可以通过getCurrentState来获取
LifecycleRegistry可以注册观察者，当LifecycleRegistry的State发生变化时通知观察者

FastSafeIterableMap

看一下源码：

private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap =
        new FastSafeIterableMap<>();
复制代码

FastSafeIterableMap是一个容器类，听名字它是一个快速、安全的Map，其中key就是添加进来的LifecycleObserver即订阅者，value就是对订阅者的封装。

为什么要用这个Map来保存观察者呢，这里就涉及一个原则叫做状态有序性，即在任意时刻新添加进来的订阅者的状态小于等于所有之前订阅的订阅者。

首先这里要明确一个就是状态不仅仅保存在LifecycleRegistry中，每个观察者也要保存状态，在改变时把这个状态给回调走，但是我们来看一下添加观察者的代码：

会发现新添加进来的观察者携带的状态是DESTROYED 或者 INITALIZED，也就是最小值，那这个是不符合原则的，至于为什么是最小值，我们在前面State的枚举能看得见，State的值关系是：

DESTROYED < INITIALIZED < CREATED < STARTED < RESUMED
复制代码

假如当前LifecycleRegistry保存的状态是RESUMED，所以即使这个观察者是在onResume方法执行后添加进来的，这个观察者保存的State也要设置位RESUMED，而不是INITIALIZED，这也就导致一个特性，LifecycleObserver会回调添加之前的状态。

我们可以验证一下，我们在Activity的onResume函数中添加一个Observer：

override fun onResume() {
    super.onResume()
    lifecycle.addObserver(object : LifecycleEventObserver{
        override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
            Logger.d("event 变化 : $event")
        }
    })
}
复制代码

会发现这个LifecycleObserver把之前的3个Event都进行了回调

至于如何实现的这个，我们后面细说。

添加LifecycleObserver

我们还是来看添加LifecycleObserver的代码，代码如下：

public void addObserver(@NonNull LifecycleObserver observer) {
    enforceMainThreadIfNeeded("addObserver");
    //封装observer，生成一个ObserverWithState实例
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
    //以observer为key保存该键值对
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
    //如果previous不为空，说明已经添加过
    if (previous != null) {
        return;
    }
    //使用弱引用来保存LifecycleOwner
    LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
    if (lifecycleOwner == null) {
        // it is null we should be destroyed. Fallback quickly
        return;
    }
    //这里定义的变量为了防止嵌套操作
    boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
    //计算需要把这个新的observer的状态提高到哪个层次
    State targetState = calculateTargetState(observer);
    mAddingObserverCounter++;
    //当observer保存的State小于期望State，进行循环提升保存的State
    while ((statefulObserver.mState.compareTo(targetState) < 0
            && mObserverMap.contains(observer))) {
        //这个
        pushParentState(statefulObserver.mState);
        //提升状态，这里要根据State来提高状态，返回这个状态下一个Event
        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--;
}
复制代码

这里我已经把添加LifecycleObserver的代码都简单加了注释，整体流程应该明白，下面我们来挖掘一下细节和原理。

ObserverWithState的工作原理

这部分代码设计的很有意思，这里为什么要封装一下呢，假如是我来设计这个，我或许就直接保存在Map中的键值对的key就是LifecycleObserver，而value就是State，这样岂不是更方便？

我们来看一下代码：

static class ObserverWithState {
    //观察者保存的State
    State mState;
    //另一个实现了LifecycleObserver的类
    LifecycleEventObserver mLifecycleObserver;

    ObserverWithState(LifecycleObserver observer, State initialState) {
        mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
        mState = initialState;
    }
    //分发事件
    void dispatchEvent(LifecycleOwner owner, Event event) {
        State newState = event.getTargetState();
        mState = min(mState, newState);
        //回调出去State
        mLifecycleObserver.onStateChanged(owner, event);
        mState = newState;
    }
}
复制代码

这里为什么不直接在构造函数中把observer给保存起来，然后回调呢我们来看一下这个LifecycleObserver的代码：

public interface LifecycleObserver {

}
复制代码

哈哈，这里居然是一个没有方法的接口，所以就尴尬了，那我们看一下LifecycleEventObserver的代码：

public interface LifecycleEventObserver extends LifecycleObserver {
    /**
     * Called when a state transition event happens.
     *
     * @param source The source of the event
     * @param event The event
     */
    void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event);
}
复制代码

这里就比较正常了，有个方法，我们可以通过这个方法进行回调。这也就解释了为什么要封装一层，因为LifecycleObserver接口没有定义方法。

那这里问题就来了，我如何不使用LifecycleEventObserver来达到期望效果呢，当然有办法，就是使用注解，实例代码如下：

lifecycle.addObserver(object : LifecycleObserver{

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    fun create(){
        Logger.d("zyh create")
    }


    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun start(){
        Logger.d("zyh start")
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun resume(){
        Logger.d("zyh resume")
    }
})
复制代码

这里的意思就是在哪个Event发生时，它注解下的方法就会被调用，我们验证一下，看一下打印：

这里就比较有意思，我们平时写代码很少有这种，看他是如何把不同实现类都给回调到的，话不多说直接看代码：

@NonNull
static LifecycleEventObserver lifecycleEventObserver(Object object) {
    //判断是否是常用的2个类
    boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
    boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
    //如果是这2个类，那好解决，直接封装成FullLifecycleObserverAdapter即可，在里面
    //进行回调
    if (isLifecycleEventObserver && isFullLifecycleObserver) {
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,
                (LifecycleEventObserver) object);
    }
    if (isFullLifecycleObserver) {
        return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
    }

    if (isLifecycleEventObserver) {
        return (LifecycleEventObserver) object;
    }
    //下面判断是当使用了注解处理器(Annotation Processor)时给转换成的Observer
    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);
    }
    //通过反射生成的Observer，当使用上面代码使用注解在函数上添加注解的方式，会生成
    //这种Observer
    return new ReflectiveGenericLifecycleObserver(object);
}
复制代码

先看一下简单的FullLifecycleObserverAdapter的源码，这个是当注册的Observer是LifecycleEventObserver和FullLifecycleObserver时调用，代码如下：

class FullLifecycleObserverAdapter implements LifecycleEventObserver {
    //包含了2个类的实例
    private final FullLifecycleObserver mFullLifecycleObserver;
    private final LifecycleEventObserver mLifecycleEventObserver;

    FullLifecycleObserverAdapter(FullLifecycleObserver fullLifecycleObserver,
            LifecycleEventObserver lifecycleEventObserver) {
        //当是一个时，另一个传入null即可
        mFullLifecycleObserver = fullLifecycleObserver;
        mLifecycleEventObserver = lifecycleEventObserver;
    }

    //这个方法不必多说，在封装的ObserverWithState中就是返回这个
    @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);
        }
    }
}
复制代码

这个方法我们理解肯定没问题，就和我们平时写回调一样，难点是下面使用注解的。

我们来看一下使用注解的情况，需要使用的Observer源码:

//类名就是反射生成的Observer
class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
    private final Object mWrapped;
    //需要回调的方法
    private final CallbackInfo mInfo;

    ReflectiveGenericLifecycleObserver(Object wrapped) {
        mWrapped = wrapped;
        mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
    }

    @Override
    public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Event event) {
        //进行回调
        mInfo.invokeCallbacks(source, event, mWrapped);
    }
}
复制代码

接着看一下这个关键的ClassesInfoCache类的实现，其实我们大致就能猜的出来，应该通过注解找到需要对应的方法，然后进行调用，我们来看看是不是这样：

CallbackInfo getInfo(Class<?> klass) {
    //判断是否有缓存
    CallbackInfo existing = mCallbackMap.get(klass);
    if (existing != null) {
        return existing;
    }
    //新建
    existing = createInfo(klass, null);
    return existing;
}
复制代码

看一下如何创建CallbackInfo:

private CallbackInfo createInfo(Class<?> klass, @Nullable Method[] declaredMethods) {
    Class<?> superclass = klass.getSuperclass();
    //HashMap，其中key是方法，value是对应的Event
    Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
    if (superclass != null) {
        //如果父类有CallbackInfo，也给添加进来
        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 annotation = method.getAnnotation(OnLifecycleEvent.class);
        if (annotation == null) {
            continue;
        }
        //当方法有OnLifecycleEvent注解时
        hasLifecycleMethods = true;
        Class<?>[] params = method.getParameterTypes();
        int callType = CALL_TYPE_NO_ARG;
        if (params.length > 0) {
            callType = CALL_TYPE_PROVIDER;
            if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
                throw new IllegalArgumentException(
                        "invalid parameter type. Must be one and instanceof LifecycleOwner");
            }
        }
        //拿到这个方法的注解信息
        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 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类：

static final 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) {
        //noinspection TryWithIdenticalCatches
        try {
            switch (mCallType) {
                //当被注释的函数分为无参 一参和2参的情况
                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);
        }
    }
}
复制代码

果不其然，这里就是通过找到匿名类里面定义了注解的函数，然后在适当时候invoke调用即可。

总结

本章内容还在继续，这里先介绍到ObserverWithState的原理，以及Lifecycle的大致流程，篇幅已经不少了，下章我们再来看看FastSafeIterableMap的工作原理以及各种标志位的作用。

前言

正文

缺陷