运用实例

Activity中的注册句子：getLifecycle().addObserver(LifecycleObserver)

getLifecycle().addObserver(new LifecycleObserver() {
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    void aa() {
        Log.i("kobe", "LifecycleObserver ");
    }
});

在办法上增加注解，这里以ON_RESUME为例，当Activity的onResume被调用时，aa()会履行，日志被打印。

注册进程

getLifecycle().addObserver()，getLifecycle部分

getLifecycle是LifecycleOwner的接口办法，在Activity中调用，存在承继联系。
androidx.appcompat.app.AppCompatActivity
androidx.fragment.app.FragmentActivity
androidx.core.app.ComponentActivity implements LifecycleOwner

• androidx.activity.ComponentActivity.java

private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
public Lifecycle getLifecycle() {
    return mLifecycleRegistry;
}

LifecycleRegistry的引用在ComponentActivity中声明，且什么时即完结初始化。
LifecycleRegistry的入参就是Activity本身，lifecycle运用观察者形式，activity是内容提供者，是被观察者。
LifecycleRegistry与Activity是一一对应的联系，LifecycleRegistry用于办理当时Activity和这个Activity的观察者。
LifecycleRegistry的成员：
mState：是LifeCycleRegistry的状况。

getLifecycle().addObserver()，addObserver部分

• androidx.lifecycle.LifecycleRegistry.java

int mAddingObserverCounter; // 记载有多少个观察者
public void addObserver(@NonNull LifecycleObserver observer) {
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
    ... // 后边貌似是做一个相似粘性事情的东西
}

ObserverWithState把mState与Observer封装起来；
mObserverMap是一个map，key是Observer，而value是前面封装后的ObserverWithState。

Activity的生命周期办法履行，怎样告诉到观察者

告诉的建议

Activity生命周期改变时，即生命周期办法履行时，会告诉Lifecycle。但其实这个告诉进程的建议不是Activity，而是借助于其内部的一个不行见的Fragment完结的。我猜由于Fragment与Activity的生命周期高度耦合，而下降Activity的职责，所以告诉的建议就由ReportFragment代庖了。
Activity内增加了一个不行见的Fragment，如下：

• androidx.core.app.ComponentActivity

onCreate() {
    ReportFragment.injectIfNeededIn(this); // 将这个ReportFragment增加到Activity，进程略
}

当Activity生命周期改变时，Fragment的生命周期也会改变，不管Fragment是否可见。举例就是，A、B两个Fragment，当时显示的是A，当Activity履行onResume，或许其他生命周期办法，B的也会履行。
当ReportFragment的生命周期办法履行时，会调用dispatch把生命周期改变发送出去。也只有生命周期办法会调用dispatch()，所以Lifecycle无法监听到Fragment的show、hide。

• ReportFragment.java

@Override
public void onActivityCreated(Bundle savedInstanceState) {
    ...
    dispatch(Lifecycle.Event.ON_CREATE);
}
@Override
public void onStart() {
    ...
    dispatch(Lifecycle.Event.ON_START);
}
@Override
public void onResume() {
    ...
    dispatch(Lifecycle.Event.ON_RESUME);
}
private void dispatch(Lifecycle.Event event) {
    Activity activity = getActivity();
    if (activity instanceof LifecycleOwner) { // ComponentActivity完成LifecycleOwner，所以进入这个分支
        Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
        if (lifecycle instanceof LifecycleRegistry) {
            ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
        }
    }
}

告诉的进程

dispatch 》 LifecycleRegistry.handleLifecycleEvent 》 moveToState 》 sync 》 forwardPass|backwardPass 》 observer.dispatchEvent（LifecycleRegistry$ObserverWithState） 》 mLifecycleObserver.onStateChanged【
mLifecycleObserver是LifecycleEventObserver，详细应该是ReflectiveGenericLifecycleObserver，这个挖一个坑（为什么mLifecycleObserver是ReflectiveGenericLifecycleObserver）】
》 ReflectiveGenericLifecycleObserver.onStateChanged 》 mInfo.invokeCallbacks 》 invokeMethodsForEvent 》 mInfo.invokeCallbacks，invokeCallbacks中通过反射调用被@LifecycleEvent符号的办法。

为什么mLifecycleObserver是ReflectiveGenericLifecycleObserver

mLifecycleObserver.onStateChanged这一句，mLifecycleObserver的声明类型是GenericLifecycleObserver（GenericLifecycleObserver extends LifecycleObserver），而GenericLifecycleObserver的子类很多，为什么是ReflectiveGenericLifecycleObserver呢？
在LifecycleRegistry.addObserver()办法中，LifecycleObserver将会被封装为ObserverWithState，如下：

• LifecycleRegistry$ObserverWithState.java

static class ObserverWithState {
    LifecycleEventObserver mLifecycleObserver;
    ObserverWithState(LifecycleObserver observer, State initialState) {
        mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
    }
    void dispatchEvent(LifecycleOwner owner, Event event) {
    ...
    mLifecycleObserver.onStateChanged(owner, event);
    }
}

详细的封装进程由Lifecycling.lifecycleEventObserver()完结。

• Lifecycling.java

static LifecycleEventObserver lifecycleEventObserver(Object object) {
    ...
    final Class klass = object.getClass();
    int type = getObserverConstructorType(klass);
    if (type == GENERATED_CALLBACK) { // 此分支不满意
        ...
        return new CompositeGeneratedAdaptersObserver(adapters);
    }
    return new ReflectiveGenericLifecycleObserver(object);
}

如上，条件不满意，所以走最终的ReflectiveGenericLifecycleObserver。这个决议条件是type = getObserverConstructorType()的值，其存在如下调用联系：
getObserverConstructorType 》 resolveObserverCallbackType。

• Lifecycling.java

private static int resolveObserverCallbackType(Class klass) {
    Constructor constructor = generatedConstructor(klass); // 返回null，懒得贴源码和剖析了
    if (constructor != null) {
        return GENERATED_CALLBACK;
    }
    boolean hasLifecycleMethods = ClassesInfoCache.sInstance.hasLifecycleMethods(klass);
    if (hasLifecycleMethods) {
        return REFLECTIVE_CALLBACK;
    }
    ...
    }

这里应该返回REFLECTIVE_CALLBACK，所以上面的LifecycleObserver mLifecycleObserver应该为ReflectiveGenericLifecycleObserver类型，这是用了装饰者形式。
上面ClassesInfoCache.sInstance.hasLifecycleMethods()是个很重要的办法，后边会剖析到。

mInfo.invokeCallbacks，mInfo的来历。

mInfo的类型是ClassesInfoCache.CallbackInfo，这是一个内部类。
上面的调用流程到了mInfo.invokeCallbacks，mInfo的类型是CallbackInfo，怎样来的。
LifecycleObserver是会被封装成ReflectiveGenericLifecycleObserver，看封装进程，也就是ReflectiveGenericLifecycleObserver的结构办法。

• ReflectiveGenericLifecycleObserver.java

ReflectiveGenericLifecycleObserver(Object wrapped) { // 这个wrapped就是Lifecycle的目标
    mWrapped = wrapped;
    mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
}

• ClassesInfoCache.java

CallbackInfo getInfo(Class klass) { // klass是Lifecycle，或许其子类
    CallbackInfo existing;
    existing = createInfo(klass, null);
}
private CallbackInfo createInfo(Class klass, @Nullable Method[] declaredMethods) {
    /* Method到event的映射，虽然是个局部变量，但仍是很重要的 */
    Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
    // declaredMethods作为入参，传入的实参是null，这里走后边的getDeclaredMethods(klass)，获取办法
    Method[] methods = declaredMethods != null ? declaredMethods : getDeclaredMethods(klass);
    boolean hasLifecycleMethods = false;
    /*
    * 1、找到被@OnLifecycleEvent注解的办法
    * 2、把这个办法增加到handlerToEvent中。——handlerToEvent是个map，是Method到Event的映射。
    */
    for (Method method : methods) {
        OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
        if (annotation == null) {
            continue;
        }
        MethodReference methodReference = new MethodReference(callType, method); // 对Method封装
        verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
    }
    /*
    * 把LifecycleObserver中的办法（@LifecycleEvent）找到，用handlerToEvent办理；
    * ClassInfoCache内还有两个map，mCallbackMap和mHasLifecycleMethods，他们把handlerToEvent办理起来，key都是LifecycleObserver这个class
    */
    CallbackInfo info = new CallbackInfo(handlerToEvent);
    mCallbackMap.put(klass, info);
    mHasLifecycleMethods.put(klass, hasLifecycleMethods);
    return info;
}

看一下CallbackInfo的结构办法

在这个结构办法中，把前面的局部变量————Method到Event的映射，用类变量保存起来；遍历Method到Event的映射，然后树立一个Event到Method的映射。为什么呢？由于观察者形式，是观察provider（被观察者）的事情的，树立了Event到Method的映射，当Event产生时，很便利就找到Method就履行了。然后Method为什么用List呢，由于LifecycleObserver中是可以写多个办法，然后监听同一个事情的，即这些办法都是用@Lifecycle.Event.ON_RESUME注解。

• CallbackInfo.java ———— ClassesInfoCache$CallbackInfo

final Map<Lifecycle.Event, List<MethodReference>> mEventToHandlers;
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());
    }
}

mInfo.invokeCallbacks，invokeCallbacks调用流程

invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target);
invokeMethodsForEvent(List handlers, LifecycleOwner source, Lifecycle.Event event, Object mWrapped);
handlers.get(i).invokeCallback(LifecycleOwner source, Lifecycle.Event event, Object target);
mMethod.invoke(...);

看invokeMethodsForEvent的入参，invokeMethodsForEvent(mEventToHandlers.get(event), source, event, target)，mEventToHandlers是Event到Method（准确说是Method的List）的映射，用get得到这个List，所以后边handlers.get(i)就得到了Method目标，invoke就履行了。

State的效果

LifecycleRegistry$ObserverWithState.mState

这个State跟Observer一一对应的，且略拖延。当一个Event过来并处理完毕后，ObServer（所有的Observer）记载这个State，下一个Event过来时，比较（min），然后满意条件的才会继续处理，详见forwardPass|backwardPass。

Fragment的生命周期办法履行，怎样告诉到

注册时必须调用getLifecycle().addObserver()，Fragment自己完成了LiftcycleOwner。

• androidx.fragment.app.Fragment.java

class Fragment implements LifecycleOwner {
    LifecycleRegistry mLifecycleRegistry;
    public Fragment() {
        initLifecycle();
    }
    private void initLifecycle() {
        mLifecycleRegistry = new LifecycleRegistry(this);
    }
    @Override
    public Lifecycle getLifecycle() {
        return mLifecycleRegistry;
    }
}

流程：Fragment.perforStart 》 mLifecycleRegistry.handleLifecycleEvent，剩下的和Activity的一样。

小结

当数据改变时，更新UI。但是处于隐藏状况的Activity，需求咱们判别；然后还有现已产生内存溢出的Activity，更新UI可能导致崩溃。Lifecycle有效帮咱们从这些杂乱的判别摆脱出来，也一定程度避免了崩溃的产生。
Lifecycle应该是和Eventbus互补，我看有的在线教育讲师说Lifecycle取代Eventbus，我不认可。Lifecycle只会在生命周期改变时才会驱动告诉，Eventbus不管何时都行；Lifecycle的驱动建议者只能是Activity和Fragment，Eventbus不管什么都行。
在数据改变后告诉刷新UI，Lifecycle更好用，但除此之外，Eventbus仍有无可比拟的优势。
另外，对应Fragment的show、hide，Lifecycle无法感知。

然后看了一些结构的源码，感觉说到底，仍是规划形式、数据结构、反射、注解这些最基本的java常识。尤其是反射和注解，像Eventbus、Retrofit、Butterknife等都是如此。了解这些，便利便于咱们了解结构。我在阅读源码进程中，也是需求不断百度、或许检查api才知道某一句话意思，知道为什么走这个分支。

最终，我想到达2级，这样可以给文章增加两个标签，所以请觉得文章有用的同学，帮点一个赞，谢谢。