jetpack源码-lifecycle篇

1 前言

谷歌I/O 发布了一系列辅助android开发者的实用工具，合称Jetpack，其通过提供现代化应用架构以及提供强健的向后兼容能力等方式，让开发者能够快速、轻松地创造拥有卓越性能的高质量应用。本系列文章会介绍一下5个方面：

arch：线程管理、灵活增加删除的map 链接
生命周期lifecycle 链接
数据驱动：livedata、viewmodel 链接
数据库Room 链接
后台作业调度

本文介绍lifecycle基础框架，主要涉及一下的三方引用：

也即是

common库中对lifecycle监听者对象信息的提取
runtime库中对lifecycle监听管理与分发
process是进程对生命周期感知处理
service是对service生命周期感知处理
另外Activity，Fragment类中含有对生命周期感知处理

2 common库

包括：

OnLifecycleEvent注解
LifecycleObserver接口以及实现类
Lifecycle 监听器注册、解绑，以及生命周期状态、事件
ClassesInfoCache，反射处理注解缓存、查找
Lifecycling，注解处理包装
MethodCallsLogger:注解监听调用记录以及是否允许被再次调用

2.1 注解

使用方式如下；其值为Lifecycle.Event枚举对象

@OnLifecycleEvent(Lifecycle.Event.ON_START)

注解的处理方法取决于是否引用了注解编译器，如果使用了注解编译器(如下引用)，则会生成GeneratedAdapter的子类，其子类与注解类存在如下关系：

kapt "androidx.lifecycle:lifecycle-compiler:$lifecycle_version"

名字后加_LifecycleAdapter
构造器参数个数为1，且为注解所在类实例
在其实现方法中，通过event类别和MethodCallsLogger判断，进而决定是否调用相应注解方法

注解静态生成类，使用了适配器模式，实质还是调用注解类的相应事件方法；如果没有引用注解器的话，则使用反射，反射信息缓存在ClassesInfoCache中

2.2 LifecycleObserver监听

其继承和实现类图如下：

主要分为三大类

反射处理的监听器
静态编译类转换而成的监听器
监听全生命周期的监听器

2.3 Lifecycle监听管理

当前模块中，由抽象类Lifecycle定下基础内容和方法框架；LifecycleRegistry类中进行了实现；其定义了注册和解绑方法以及事件类型和状态；

内部枚举类State

public enum State {
        DESTROYED,
        INITIALIZED,
        CREATED,
        STARTED,
        RESUMED;

        public boolean isAtLeast(@NonNull State state) {
            return compareTo(state) >= 0;
        }
    }
}

内部枚举类Event

/**
        ON_CREATE,
        ON_START,
        ON_RESUME,
        ON_PAUSE,
        ON_STOP,
        ON_DESTROY,
        ON_ANY;

        public static Event downFrom(@NonNull State state) {
            switch (state) {
                case CREATED:
                    return ON_DESTROY;
                case STARTED:
                    return ON_STOP;
                case RESUMED:
                    return ON_PAUSE;
                default:
                    return null;
            }
        }

        public static Event downTo(@NonNull State state) {
            switch (state) {
                case DESTROYED:
                    return ON_DESTROY;
                case CREATED:
                    return ON_STOP;
                case STARTED:
                    return ON_PAUSE;
                default:
                    return null;
            }
        }

        public static Event upFrom(@NonNull State state) {
            switch (state) {
                case INITIALIZED:
                    return ON_CREATE;
                case CREATED:
                    return ON_START;
                case STARTED:
                    return ON_RESUME;
                default:
                    return null;
            }
        }


        public static Event upTo(@NonNull State state) {
            switch (state) {
                case CREATED:
                    return ON_CREATE;
                case STARTED:
                    return ON_START;
                case RESUMED:
                    return ON_RESUME;
                default:
                    return null;
            }
        }


        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");
        }

从Event中的方法实现，我们可以知道一下特性；

生命周期一步一步进行变化，不能跳跃
监听者集合状态依据状态有序

由此设计了一种state-event的映射，不仅表明了当前状态，下一个状态可能是什么；其关系如下：

不过为什么会这种映射呢？在后续LifecycleRegistry源码，其实是为了解决事件分发中再次添加监听器的问题；如果不这样做，就解决不了吗？肯定能解决，暂时如果相信google大牛的技术，那么这肯定是当前场景下最优的解决方案了；那首先自己对这种映射的思考，就是场景是什么，如何处理解决的；之后再考虑还有其它方法能解决，优缺点是什么

2.4 MethodCallsLogger类

    private Map<String, Integer> mCalledMethods = new HashMap<>();

    public boolean approveCall(String name, int type) {
        Integer nullableMask = mCalledMethods.get(name);
        int mask = nullableMask != null ? nullableMask : 0;
        boolean wasCalled = (mask & type) != 0;
        mCalledMethods.put(name, mask | type);
        return !wasCalled;
    }

mCalledMethods存储了执行信息；如果不存在，则可以执行，已存入时，判断状态处理，一般来说type=1，也即是执行一次；这个调用在注解处理器生成类中进行了调用，我看到的都是类实例为空，也即是不必判断。。。(也有可能是我的眼界还不够)

2.5 注解反射信息缓存

ClassesInfoCache单例类，缓存了类以及其对应注解方法的发射信息

    private final Map<Class<?>, CallbackInfo> mCallbackMap = new HashMap<>();
    private final Map<Class<?>, Boolean> mHasLifecycleMethods = new HashMap<>();

mCallbackMap:记录注解类-注解方法信息，mHasLifecycleMethods，记录了注解类信息是否已经进行解析过了；先介绍下其两个内部类

静态内部不可修改类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) {
            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);
            }
        }

从上述方法反射调用来看；注解类方法参数不能大于2个，且其参数格式如下：

 void xxx([LifecycleOwner source,][Lifecycle.Event event])

静态内部类CallInfo

        final Map<Lifecycle.Event, List<MethodReference>> mEventToHandlers;
        final Map<MethodReference, Lifecycle.Event> mHandlerToEvent;

        CallbackInfo(Map<MethodReference, Lifecycle.Event> handlerToEvent) {
            mHandlerToEvent = handlerToEvent;
            mEventToHandlers = new HashMap<>();
            for (Map.Entry<MethodReference, Lifecycle.Event> entry : handlerToEvent.entrySet(){
                Lifecycle.Event event = entry.getValue();
                List<MethodReference> methodReferences = mEventToHandlers.get(event);
                if (methodReferences == null) {
                    methodReferences = new ArrayList<>();
                    mEventToHandlers.put(event, methodReferences);
                }
                methodReferences.add(entry.getKey());
            }
        }

        void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {
            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);
                }
            }
        }

mEventToHandlers，存储了事件到方法的映射，方便了反射调用；mHandlerToEvent存储方法和事件的映射，又有什么意思呢？主要是注解处理时以方法到事件的映射，注解的处理，并不是只处理当前类的注解还要包括父类以父接口，因此缓存此对象可以方便后续操作

类方法hasLifecycleMethods(Class<?> klass)

首先通过mHasLifecycleMethods集合来判断是否存在当前类信息，如果已经存入信息，则直接返回结果
1步不存在结果，则对当前类声明的所有方法进行注解处理；只要有一个声明方法存在注解，则调用createInfo方法，并返回true
如果2不存在注解，则表明此类不需要注解处理mHasLifecycleMethods保留其信息，并返回false

类方法CallbackInfo getInfo(Class<?> klass) 其方法也比较简单，通过mCallbackMap获取CallbackInfo，如果不为空，则返回，否则通过createInfo创建，并返回

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 annotation = method.getAnnotation(OnLifecycleEvent.class);
            if (annotation == null) {
                continue;
            }
            hasLifecycleMethods = true;
            Class<?>[] params = method.getParameterTypes();
            int callType = CALL_TYPE_NO_ARG;
            if (params.length > 0) {
                callType = CALL_TYPE_PROVIDER;
                if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
                    throw new IllegalArgumentException(
                            "invalid parameter type. Must be one and instanceof LifecycleOwner");
                }
            }
            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;

此方法可能存在递归调用；也即方法中调用getInfo，而getInfo中有可能调用此方法
类存在的反射调用缓存，不仅限于此类的注解，还包括父类以及父接口
注解处理中对方法的的参数和参数类型进行了校验；并且注解方法如果包含2个参数，则其监听事件类型不能是Lifecycle.Event.ON_ANY

2.6 Lifecycling监听包装

通过类实力获取监听对象；主要成员如下

    private static final int REFLECTIVE_CALLBACK = 1;
    private static final int GENERATED_CALLBACK = 2;

    private static Map<Class<?>, Integer> sCallbackCache = new HashMap<>();
    private static Map<Class<?>, List<Constructor<? extends GeneratedAdapter>>> sClassToAdapters = new HashMap<>();

定义了监听实现的两种类型，sCallbackCache保存类对应实现类型，sClassToAdapters保存注解处理类相关的生成类构造器实例；

向外提供了两个方法获取getCallback、lifecycleEventObserver；getCallback也是通过lifecycleEventObserver来获取；此方法如下

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);
    }

如果当前对象是FullLifecycleObserver接口实现类，则通过FullLifecycleObserverAdapter进行代理，并返回
如果是LifecycleEventObserver子类，则直接返回
如果存在注解器生成类，则根据其父类以及接口类中存在注解的个数来返回SingleGeneratedAdapterObserver或者CompositeGeneratedAdaptersObserver包装对象
返回反射监听ReflectiveGenericLifecycleObserver对象

createGeneratedAdapter方法说明了，相关类生成类，其构造器存在一个参数且是注解器类的实例

generatedConstructor方法，说明注解生成类，类名逻辑

getObserverConstructorType方法

private static int getObserverConstructorType(Class<?> klass) {
        Integer callbackCache = sCallbackCache.get(klass);
        if (callbackCache != null) {
            return callbackCache;
        }
        int type = resolveObserverCallbackType(klass);
        sCallbackCache.put(klass, type);
        return type;
    }

首先通过sCallbackCache获取类注解处理的类型；如果不存在，则通过resolveObserverCallbackType方法去分析获取

resolveObserverCallbackType方法

private static int resolveObserverCallbackType(Class<?> klass) {
        // anonymous class bug:35073837
        if (klass.getCanonicalName() == null) {
            return REFLECTIVE_CALLBACK;
        }

        Constructor<? extends GeneratedAdapter> constructor = generatedConstructor(klass);
        if (constructor != null) {
            sClassToAdapters.put(klass, Collections
                    .<Constructor<? extends GeneratedAdapter>>singletonList(constructor));
            return GENERATED_CALLBACK;
        }

        boolean hasLifecycleMethods = ClassesInfoCache.sInstance.hasLifecycleMethods(klass);
        if (hasLifecycleMethods) {
            return REFLECTIVE_CALLBACK;
        }

        Class<?> superclass = klass.getSuperclass();
        List<Constructor<? extends GeneratedAdapter>> adapterConstructors = null;
        if (isLifecycleParent(superclass)) {
            if (getObserverConstructorType(superclass) == REFLECTIVE_CALLBACK) {
                return REFLECTIVE_CALLBACK;
            }
            adapterConstructors = new ArrayList<>(sClassToAdapters.get(superclass));
        }

        for (Class<?> intrface : klass.getInterfaces()) {
            if (!isLifecycleParent(intrface)) {
                continue;
            }
            if (getObserverConstructorType(intrface) == REFLECTIVE_CALLBACK) {
                return REFLECTIVE_CALLBACK;
            }
            if (adapterConstructors == null) {
                adapterConstructors = new ArrayList<>();
            }
            adapterConstructors.addAll(sClassToAdapters.get(intrface));
        }
        if (adapterConstructors != null) {
            sClassToAdapters.put(klass, adapterConstructors);
            return GENERATED_CALLBACK;
        }

        return REFLECTIVE_CALLBACK;
    }

局部类、匿名内部类或者这两种类的数组，则认为是反射类型
当前实例对应类，存在生成对象，则为注解静态生成对象，并保留器信息，其处理监听为SingleGeneratedAdapterObserver
如果此类存在注解方法，则认为是反射类型
如果父类实现了LifecycleObserver接口，对父类类型进行判断，如果父类是反射，则其是反射类型
如果父类不是反射类型，则把父类的对应注解生成类构造器信息存储
对接口判断，按照父类判断逻辑来处理；
如果对应注解类构造器信息不为空，则为注解处理类型，否则为反射处理类型

当前类可以找到注解处理类，则是单个注解监听，否则进行向父类和父接口查找，逐层查找，只要在此层存在，则把此层所有相关注解类构造器存储起来，这时有可能对应多个注解监听；疑问，为何没有递归查找到最后呢，是不是静态生成时已经处理还是静态注解生成有难处？

2.7 小结

此库中，在外部调用的可能类时Lifecycling，通过其获取相应类的监听器实例
引用注解处理器进行处理注解，性能更好
反射处理时，完全递归类到父类、父接口；而注解类处理时，递归查询，存在即停止下一层查询
反射处理时，采用全局缓存；注意性能和内存处理

3 runtime库

此库包含类仅仅有4个；

LifecycleRegistryOwner接口，继承LifecycleOwner接口，仅有一个方法，返回Lifecycle对象
ViewTreeLifecycleOwner类，工具类，提供view的LifecycleOwner对象管理；通过view的tag机制来处理，获取时从当前view到父容器递归查询，tag id为R.id.view_tree_lifecycle_owner
ReportFragment类，对activity周期进行注入，并在对应生命周期分发事件；fragment对应的tag为androidx.lifecycle.LifecycleDispatcher.report_fragment_tag；activity实现了LifecycleOwner或者LifecycleRegistryOwner接口，才会进行分发
LifecycleRegistry类，监听管理实现类；是一个对声明周期高度封装的类，包括监听注册解注册和分发

这里就主要介绍下LifecycleRegistry类

3.1 LifecycleRegistry类

成员变量如下：

    private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap =
            new FastSafeIterableMap<>();
    private State mState;
    private final WeakReference<LifecycleOwner> mLifecycleOwner;

    private int mAddingObserverCounter = 0;

    private boolean mHandlingEvent = false;
    private boolean mNewEventOccurred = false;
    private ArrayList<State> mParentStates = new ArrayList<>();
    private final boolean mEnforceMainThread;

mObserverMap:观察者数据集合
当前事件状态
mLifecycleOwner，生命周期持有者
mAddingObserverCounter：是否正在增加监听者对象
mHandlingEvent：标志是否进行sync方法处理，也即是否正在分发新生命周期事件
mNewEventOccurred：标志是否有新生命周期事件到来
mParentStates：堆栈，标志是否有嵌套处理
mEnforceMainThread：表示方法是否必须在主线程调用

静态内部类ObserverWithState

    static class ObserverWithState {
        State mState;
        LifecycleEventObserver mLifecycleObserver;

        ObserverWithState(LifecycleObserver observer, State initialState) {
            mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
            mState = initialState;
        }

        void dispatchEvent(LifecycleOwner owner, Event event) {
            State newState = event.getTargetState();
            mState = min(mState, newState);
            mLifecycleObserver.onStateChanged(owner, event);
            mState = newState;
        }
    }

维持当前状态以及事件处理，这里使用了Lifecycling来获取相应对象的监听者实例；同时也说明如果要监听生命周期，当前类必须实现LifecycleObserver接口；疑问，这里的状态为何取最小值？初始化时，不是DESTORY,就是INITIALIZED，已经是最低的了，这个值，除了生命周期结束，否则会变化吗？？？？

LifecycleRegistry实例创建 主要区别在于，是否限定在主线程中进行方法执行

通过公开构造器创建，方法必须在主线程中执行
通过静态方法createUnsafe，方法执行线程不限制

由于代码中未做同步处理，建议通过公开构造器来生成；其中enforceMainThreadIfNeeded方法进行线程校验

注册监听

其中对状态一致性进行了处理，而且在未分发事件在添加监听后继续进行分发

    public void addObserver(@NonNull LifecycleObserver observer) {
        enforceMainThreadIfNeeded("addObserver");
        State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
        ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
        ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);

        if (previous != null) {
            return;
        }
        LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
        if (lifecycleOwner == null) {
            return;
        }

        boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
        State targetState = calculateTargetState(observer);
        mAddingObserverCounter++;
        while ((statefulObserver.mState.compareTo(targetState) < 0
                && mObserverMap.contains(observer))) {
            pushParentState(statefulObserver.mState);
            final Event event = Event.upFrom(statefulObserver.mState);
            if (event == null) {
                throw new IllegalStateException("no event up from " + statefulObserver.mState);
            }
            statefulObserver.dispatchEvent(lifecycleOwner, event);
            popParentState();
            targetState = calculateTargetState(observer);
        }

        if (!isReentrance) {
            sync();
        }
        mAddingObserverCounter--;
    }

如果监听器已经存在集合内，则不重复进行注册，结束
isReentrance记录当前添加结束后是否需要同步，如果正在进行其它监听器添加或者这在处理同步，这时需要分发事件（在其它分发的流程会停止继续处理）
进行当前新添加监听器的状态同步；其从初始化的状态的逐步到当前插入到集合中最小的状态，进行事件分发
根据记录状态进行是否分发事件

解绑监听 很简单，直接从集合中删除数据即可

public void removeObserver(@NonNull LifecycleObserver observer) {
        enforceMainThreadIfNeeded("removeObserver");
        mObserverMap.remove(observer);
    }

事件分发 通过调用handleLifecycleEvent或者setCurrentState方法进行分发，其实际都是通过moveToState方法进行处理

    public void setCurrentState(@NonNull State state) {
        enforceMainThreadIfNeeded("setCurrentState");
        moveToState(state);
    }

    public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
        enforceMainThreadIfNeeded("handleLifecycleEvent");
        moveToState(event.getTargetState());
    }

    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()) {
            mNewEventOccurred = false;
            if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
                backwardPass(lifecycleOwner);
            }
            Map.Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
            if (!mNewEventOccurred && newest != null
                    && mState.compareTo(newest.getValue().mState) > 0) {
                forwardPass(lifecycleOwner);
            }
        }
        mNewEventOccurred = false;
    }

对生命周期持有进行判断，是否已经回收
进行分发；从分发(也结合了添加的过程)可以看出，事件的状态必须是连续的，且集合中的监听器状态必须是递减规律；所以为了保持状态的这种规律，状态减小时，从后往前处理，状态增加时，从前往后处理；在分发时通过pushParentState、popParentState对当前分发堆栈进行标记，如果分发出现嵌套，则在分发前堆栈不为空

3.2 小结

LifecycleRegistry提供了监听管理分发的默认实现
监听器必须是LifecycleObserver子类
LifecycleRegistry实例与生命周期持有一对一对应
ReportFragment提供了Activity生命周期注入

4 进程生命周期感知

借用了ContentProvider启动的生命周期，在Application的onCreate方法调用前进行生命感知处理；利用Application的registerActivityLifecycleCallbacks方法，并利用ReportFragment对每个activity进行生命周期感知注入，进而达到application生命周期感知；

4.1 ProcessLifecycleOwnerInitializer类

继承ContentProvider，在onCreate进行了相应注册操作

    public boolean onCreate() {
        LifecycleDispatcher.init(getContext());
        ProcessLifecycleOwner.init(getContext());
        return true;
    }

4.2 LifecycleDispatcher类

为application注册activity生命周期监听

     private static AtomicBoolean sInitialized = new AtomicBoolean(false);

    static void init(Context context) {
        if (sInitialized.getAndSet(true)) {
            return;
        }
        ((Application) context.getApplicationContext())
                .registerActivityLifecycleCallbacks(new DispatcherActivityCallback());
    }

在监听事件onActivityCreated中利用ReportFragment进行注入

        public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
            ReportFragment.injectIfNeededIn(activity);
        }

4.3 ProcessLifecycleOwner类

进程生命周期感知实现类，单例类；

    static final long TIMEOUT_MS = 700; //mls
    private int mStartedCounter = 0;
    private int mResumedCounter = 0;
    private boolean mPauseSent = true;
    private boolean mStopSent = true;
    private Handler mHandler;
    private final LifecycleRegistry mRegistry = new LifecycleRegistry(this);
    private Runnable mDelayedPauseRunnable = new Runnable() {
        @Override
        public void run() {
            dispatchPauseIfNeeded();
            dispatchStopIfNeeded();
        }
    };

    ActivityInitializationListener mInitializationListener =
            new ActivityInitializationListener() {
                @Override
                public void onCreate() {
                }

                @Override
                public void onStart() {
                    activityStarted();
                }

                @Override
                public void onResume() {
                    activityResumed();
                }
            };

    private static final ProcessLifecycleOwner sInstance = new ProcessLifecycleOwner();

mResumedCounter:标志当前onResumed的activity数量，只有数量等于0时，事件才会分发 mStartedCounter：类似mResumedCounter mPauseSent，mStopSent：表示pause、stop事件是否分发 mDelayedPauseRunnable： pause、stop事件是延时分发事件 mRegistry：进程对应生命周期感知管理分发对象 mHandler：主线程handler，进行任务延时和取消管理

感知到的生命周期事件有： ON_CREATE， ON_START， ON_RESUME， onPaused, onStop

ON_CREATE在静态方法注册时完成

    void activityStarted() {
        mStartedCounter++;
        if (mStartedCounter == 1 && mStopSent) {
            mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START);
            mStopSent = false;
        }
    }

    void activityResumed() {
        mResumedCounter++;
        if (mResumedCounter == 1) {
            if (mPauseSent) {
                mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_RESUME);
                mPauseSent = false;
            } else {
                mHandler.removeCallbacks(mDelayedPauseRunnable);
            }
        }
    }

ON_START、ON_RESUME，通过计数和发送标识来进行决定事件是否分发

ON_PAUSE,ON_STOP事件采用延时发送策略；

    void activityPaused() {
        mResumedCounter--;
        if (mResumedCounter == 0) {
            mHandler.postDelayed(mDelayedPauseRunnable, TIMEOUT_MS);
        }
    }

    void activityStopped() {
        mStartedCounter--;
        dispatchStopIfNeeded();
    }

    void dispatchPauseIfNeeded() {
        if (mResumedCounter == 0) {
            mPauseSent = true;
            mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_PAUSE);
        }
    }

    void dispatchStopIfNeeded() {
        if (mStartedCounter == 0 && mPauseSent) {
            mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);
            mStopSent = true;
        }
    }

首先生命周期感知后，立即改变计数，并发送延时任务；延时任务执行时，则依据计数和发送标识来进行决定事件是否分发

4.4 小结

进程生命周期感知：ProcessLifecycleOwner.get().getLifecycle()获取Lifecycle实例进而管理监听、事件分发
通过ContentProvider原理，不需用户主动注册

5 service生命感知

service的生命周期只有ON_CREATE、ON_START、ON_STOP、ON_DESTROY；而且不会重复；其分别对用Service的onCreate方法、onBind和onStart方法、onDestory、onDestory方法；

service若想有生命周期感知能力，必须继承LifecycleService；其内部通过ServiceLifecycleDispatcher实例进行在相应生命周期进行事件分发

ServiceLifecycleDispatcher类

    private final LifecycleRegistry mRegistry;
    private final Handler mHandler;
    private DispatchRunnable mLastDispatchRunnable;

    /**
     * @param provider {@link LifecycleOwner} for a service, usually it is a service itself
     */
    public ServiceLifecycleDispatcher(@NonNull LifecycleOwner provider) {
        mRegistry = new LifecycleRegistry(provider);
        mHandler = new Handler();
    }

    private void postDispatchRunnable(Lifecycle.Event event) {
        if (mLastDispatchRunnable != null) {
            mLastDispatchRunnable.run();
        }
        mLastDispatchRunnable = new DispatchRunnable(mRegistry, event);
        mHandler.postAtFrontOfQueue(mLastDispatchRunnable);
    }

其具体分发通过postDispatchRunnable方法来完成的

静态内部类DispatchRunnable

    static class DispatchRunnable implements Runnable {
        private final LifecycleRegistry mRegistry;
        final Lifecycle.Event mEvent;
        private boolean mWasExecuted = false;

        DispatchRunnable(@NonNull LifecycleRegistry registry, Lifecycle.Event event) {
            mRegistry = registry;
            mEvent = event;
        }

        @Override
        public void run() {
            if (!mWasExecuted) {
                mRegistry.handleLifecycleEvent(mEvent);
                mWasExecuted = true;
            }
        }
    }

小结通过继承LifecycleService来获取生命感知能力，通过service实例的getLifecycle方法来获取生命监听管理

6 Activity、Fragment生命周期感知

其实现又有不同；

继承androidx 包中ComponentActivity以及子类，其已经实现了LifecycleOwner接口，通过其getLifecycle方法即可管理监听，通过ReportFragment注入的方式实现分发
继承androidx 包中Fragment以及子类，其已经实现了LifecycleOwner接口，通过其getLifecycle方法即可管理监听，通过Fragment内部自己实现了分发
对于继承普通包的Activity类，其通过registerActivityLifecycleCallbacks方法进行注入生命周期；通过ReportFragment注入的方式实现分发
非androidx包下fragment生命周期暂不支持

7 小结

整体来说生命周期的感知，都是通过具有生命周期类实现LifecycleOwner、LifecycleRegistryOwner接口，通过实例getLifecycle方法来进行监听管理；而进程的生命管理，由于其特殊性，提供了单例类ProcessLifecycleOwner进行管理

技术变化都很快，但基础技术、理论知识永远都是那些；作者希望在余后的生活中，对常用技术点进行基础知识分享；如果你觉得文章写的不错，请给与关注和点赞；如果文章存在错误，也请多多指教！