【AAC 系列二】深入理解架构组件的基石：Lifecycle

0. 前言

在前文，我就提到 Android Architecture Components （后简称为 AAC），是一个帮助开发者设计 健壮 、 可测试 且 可维护 的一系列库的集合。

Lifecycle 就是 AAC 中的一员，它能够帮助我们方便的管理 Activity 以及 Fragment 的生命周期。

本文带大家深入了解 Lifecycle 。

注意：本文基于 Lifecycle 1.1.1 版本，Android API 26 ，依赖如下图。  

image.png

   并假设读者对 Lifecycle 有基本的了解，我绘制了一个基本的类图，如果对于下面类图所涉及到的类都还算了解则可以继续阅读下去，如果完全不知道，建议阅读一些教程先。  
image.png

1. Lifecycle 使用基础

在 AppCompatActivity 里我们可以通过 getLifecycle() 方法拿到 Lifecycle ,并添加 Observer 来实现对 Activity 生命周期的监听。

一个简单的使用例子如下：

public class MainActivity extends AppCompatActivity {

    private static final String TAG = "MainActivity";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        testLifecycle();
    }

    private void testLifecycle() {
        getLifecycle().addObserver(new LifecycleObserver() {

            @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
            void onResume(){
                Log.d(TAG, "LifecycleObserver onResume() called");
            }
        });
    }

    @Override
    protected void onResume() {
        super.onResume();
        Log.d(TAG, "onResume: ");
    }
}

启动 MainActivity 就可以看到如下日志：

D/MainActivity: onResume: 
D/MainActivity: LifecycleObserver onResume() called

日志说明我们通过上述代码确实实现了监听生命周期的功能。

那么问题来了，这是怎么做到的？

我把这个问题拆分成了两块：

生命周期的感知问题： 是什么感知了Activity的生命周期 ？
注解方法的调用问题： 是什么调用了我们使用注解修饰的方法 ？

2. 感知生命周期的原理

2.1 初现端倪 ReportFragment

我通过调试堆栈发现了一个叫做 ReportFragment 的类，非常可疑，遂跟踪之。

注意：Debug 查看堆栈是阅读源码手段中最常用最简单最好用最亲民的方法，没有之一，每个人都应该熟练掌握。

来看看这个类都写了什么：

public class ReportFragment extends Fragment {

    private static final String REPORT_FRAGMENT_TAG = "android.arch.lifecycle"
            + ".LifecycleDispatcher.report_fragment_tag";
        //注入 Fragment 的方法
    public static void injectIfNeededIn(Activity activity) {
        // ProcessLifecycleOwner should always correctly work and some activities may not extend
        // FragmentActivity from support lib, so we use framework fragments for activities
        android.app.FragmentManager manager = activity.getFragmentManager();
        if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
            manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
            // Hopefully, we are the first to make a transaction.
            manager.executePendingTransactions();
        }
    }
    //...
    @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);
    }

    @Override
    public void onPause() {
        super.onPause();
        dispatch(Lifecycle.Event.ON_PAUSE);
    }

    @Override
    public void onStop() {
        super.onStop();
        dispatch(Lifecycle.Event.ON_STOP);
    }

    @Override
    public void onDestroy() {
        super.onDestroy();
        dispatch(Lifecycle.Event.ON_DESTROY);
        // just want to be sure that we won't leak reference to an activity
        mProcessListener = null;
    }
        //分发生命周期事件给 LifecycleRegistryOwner 的 Lifecycle 或者 LifecycleRegistry
    private void dispatch(Lifecycle.Event event) {
        Activity activity = getActivity();
        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);
            }
        }
    }
   //...
}

一看代码我们就知道了，它重写了生命周期回调的方法，确实是这个 ReportFragment 在发挥作用，Lifecycle 利用了 Fragment 来实现监听生命周期，并在生命周期回调里调用了内部 dispatch 的方法来分发生命周期事件。(怎么分发后面讲)

2.2 幕后“黑手” SupportActivity

从方法来看注入 Fragment 的方法应该是调用 injectIfNeededIn(Activity) 的地方了。

在通过搜索发现 SupportActivity 调用了该方法。（API 28 的版本是 ComponentActivity ，代码实现没什么差别）

public class SupportActivity extends Activity implements LifecycleOwner, Component {

    //拥有一个 LifecycleRegistry
    private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        //在 onCreate 里注入了 ReportFragment
        ReportFragment.injectIfNeededIn(this);
    }

    @CallSuper
    protected void onSaveInstanceState(Bundle outState) {
        this.mLifecycleRegistry.markState(State.CREATED);
        super.onSaveInstanceState(outState);
    }

    public Lifecycle getLifecycle() {
        return this.mLifecycleRegistry;
    }
}

可以看到 SupportActivity 内部包含了一个 LifecycleRegistry ，并实现了 LifecycleOwner ，并且在 onCreate 方法里调用了 ReportFragment.injectIfNeededIn(this); 注入了 ReportFragment 。

LifecycleRegistry 是 Lifecycle 的实现，并负责管理 Observer ，在上面【2】章节的 dispatch 方法中已经看到了该类的出现，它的 handleLifecycEvent 接受了生命周期的回调。

2.3 Lifecycle 的生命周期事件与状态的定义

这小节补充一下 Lifecycle 的回调与 Activity 、Fragment 的生命周期对标相关知识，后面分析会出现。

Lifecycle 中定义了 Event : 表示生命周期事件， State : 表示当前状态。

2.3.1 Lifecycle.Event

Lifecycle 定义的生命周期事件，与 Activity 生命周期类似。

    public enum Event {
        ON_CREATE,
        ON_START,
        ON_RESUME,
        ON_PAUSE,
        ON_STOP,
        ON_DESTROY,
        ON_ANY
    }

2.3.2 Lifecycle.State

State 表示当前组件的生命周期状态。

    /**
        * Lifecycle states. You can consider the states as the nodes in a graph and
        * {@link Event}s as the edges between these nodes.
        */
        public enum State {
        DESTROYED,
        INITIALIZED,
        CREATED,
        STARTED,
        RESUMED;
        public boolean isAtLeast(@NonNull State state) {
            return compareTo(state) >= 0;
        }
    }

2.3.3 Event 与 State 的关系：

image.png

(图1.图来源见【8.2】)

2.4 小结

通过研究我们发现，SupportActivity 在 onCreate 方法里注入了 ReportFragment ，通过 Fragment 的机制来实现生命周期的监听。

实际上利用 Fragment 监听 Activity 生命周期的功能在开源社区由来已久， Lifecycle 并非原创，Lifecycle 的出现算是把这个实现官方化了。

相比于第三方的实现，嵌入到 Android 源码中的实现对开发者来说是非常有好处的，即屏蔽了细节，又降低了使用难度。 **
<a name="731a721b"></a>

3. 注解方法被调用的原理

OnLifecycleEvent 注解：

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface OnLifecycleEvent {
    Lifecycle.Event value();
}

看到有 RetentionPolicy.RUNTIME 修饰，我就猜测它是靠反射来实现了，不过还是看下具体实现验证下吧。

之前在了解完生命周期监听的原理的同时，我们也看到了生命周期事件的接收者 LifecycleRegistry ，是它的 handleLifecycleEvent() 接收了事件，我们继续追踪。

    /**
     * Sets the current state and notifies the observers.
     * Note that if the {@code currentState} is the same state as the last call to this method,
     * calling this method has no effect.
     */
    public void handleLifecycleEvent(Lifecycle.Event event) {
        mState = getStateAfter(event);
        if (mHandlingEvent || mAddingObserverCounter != 0) {
            mNewEventOccurred = true;
            // we will figure out what to do on upper level.
            return;
        }
        mHandlingEvent = true;
        sync();
        mHandlingEvent = false;
    }

其实从方法注释就能看出来了，就是它处理了状态并通知了 observer 。

看下 getStateAfter() 方法：

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

getStateAfter() 这个方法根据当前 Event 获取对应的 State ，细看其实就是【2.3.3】中那个图的代码实现。

接下去看 sync() 方法：

    private void sync() {
        while (!isSynced()) {
            mNewEventOccurred = false;
            // no need to check eldest for nullability, because isSynced does it for us.
            if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
                backwardPass();
            }
            Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
            if (!mNewEventOccurred && newest != null
                    && mState.compareTo(newest.getValue().mState) > 0) {
                forwardPass();
            }
        }
        mNewEventOccurred = false;
    }

sync 方法里对比了当前 mState 以及上一个 State ，看是应该前移还是后退，这个对应了生命周期的前进跟后退，打个比方就是从 onResume -> onPause (forwardPass)，onPause -> onResume (backwardPass)，拿 backwardPass() 举例吧。（forwardPass方法处理类似）

    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();
            while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
                    && mObserverMap.contains(entry.getKey()))) {
                //调用 downEvent 获取更前面的 Event
                Event event = downEvent(observer.mState);
                pushParentState(getStateAfter(event));
                //分发 Event 
                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);
    }

通过源码可以看到， backwardPass() 方法调用 downEvent 获取往回退的目标 Event。

可能比较抽象，举个例子，在 onResume 的状态，我们按了 home，这个时候就是 RESUMED 的状态变到 STARTED 的状态，对应的要发送的 Event 是 ON_PAUSE，这个就是 backwardPass() 的逻辑了。

如果前面的代码都是引子的话，我们最终看到了一丝分发的痕迹了—— observer.dispatchEvent(lifecycleOwner, event) 。

    static class ObserverWithState {
        State mState;
        GenericLifecycleObserver mLifecycleObserver;

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

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

可以看到最后调用了 GenericLifecycleObserver.onStateChanged() 方法，再跟。

class ReflectiveGenericLifecycleObserver implements GenericLifecycleObserver {
    //mWrapped 是 我们的 Observer
    private final Object mWrapped;
    //反射 mWrapped 获取被注解了的方法
    private final CallbackInfo mInfo;
    @SuppressWarnings("WeakerAccess")
    static final Map<Class, CallbackInfo> sInfoCache = new HashMap<>();

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

    @Override
    public void onStateChanged(LifecycleOwner source, Event event) {
        invokeCallbacks(mInfo, source, event);
    }
    
    private void invokeCallbacks(CallbackInfo info, LifecycleOwner source, Event event) {
        invokeMethodsForEvent(info.mEventToHandlers.get(event), source, event);
        invokeMethodsForEvent(info.mEventToHandlers.get(Event.ON_ANY), source, event);
    }
  
    private void invokeMethodsForEvent(List<MethodReference> handlers, LifecycleOwner source,
            Event event) {
        if (handlers != null) {
            for (int i = handlers.size() - 1; i >= 0; i--) {
                MethodReference reference = handlers.get(i);
                invokeCallback(reference, source, event);
            }
        }
    }
    //最后走到 invokeCallback 这里
    private void invokeCallback(MethodReference reference, LifecycleOwner source, Event event) {
        //noinspection TryWithIdenticalCatches
        try {
            switch (reference.mCallType) {
                case CALL_TYPE_NO_ARG:
                    reference.mMethod.invoke(mWrapped);
                    break;
                case CALL_TYPE_PROVIDER:
                    reference.mMethod.invoke(mWrapped, source);
                    break;
                case CALL_TYPE_PROVIDER_WITH_EVENT:
                    reference.mMethod.invoke(mWrapped, source, event);
                    break;
            }
        } catch (InvocationTargetException e) {
            throw new RuntimeException("Failed to call observer method", e.getCause());
        } catch (IllegalAccessException e) {
            throw new RuntimeException(e);
        }
    }
    
    private static CallbackInfo getInfo(Class klass) {
        CallbackInfo existing = sInfoCache.get(klass);
        if (existing != null) {
            return existing;
        }
        existing = createInfo(klass);
        return existing;
    }
    
    //通过反射获取 method 信息
    private static CallbackInfo createInfo(Class klass) {
        //...
        Method[] methods = klass.getDeclaredMethods();

        Class[] interfaces = klass.getInterfaces();
        for (Class intrfc : interfaces) {
            for (Entry<MethodReference, Event> entry : getInfo(intrfc).mHandlerToEvent.entrySet()) {
                verifyAndPutHandler(handlerToEvent, entry.getKey(), entry.getValue(), klass);
            }
        }

        for (Method method : methods) {
            OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
            if (annotation == null) {
                continue;
            }
            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");
                }
            }
            Event event = annotation.value();
            //...
            MethodReference methodReference = new MethodReference(callType, method);
            verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
        }
        CallbackInfo info = new CallbackInfo(handlerToEvent);
        sInfoCache.put(klass, info);
        return info;
    }

    @SuppressWarnings("WeakerAccess")
    static class CallbackInfo {
        final Map<Event, List<MethodReference>> mEventToHandlers;
        final Map<MethodReference, Event> mHandlerToEvent;

        CallbackInfo(Map<MethodReference, Event> handlerToEvent) {
            //...
        }
    }

    static class MethodReference {
        final int mCallType;
        final Method mMethod;

        MethodReference(int callType, Method method) {
            mCallType = callType;
            mMethod = method;
            mMethod.setAccessible(true);
        }
    }

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

这个类的代码比较多，不过也不复杂。可以看到最后代码走到了invokeCallback() ，通过反射调用了方法。

而这个方法是 createInfo() 方法中反射遍历我们注册的 Observer 的方法找到的被 OnLifecycleEvent 注解修饰的方法，并且按 Event 类型存储到了 info.mEventToHandlers 里。

到这里整个链路就清晰了，我们在 Observer 用注解修饰的方法，会被通过反射的方式获取，并保存下来，然后在生命周期发生改变的时候再找到对应 Event 的方法，通过反射来调用方法。

注意：源码中还有一些细节比较繁琐，比如怎么获取的方法，怎么包装的 Observer ，State 的管理以及存储等，就不在这里展开了，有兴趣的自行了解。

4. 图解 Lifecycle

如果被代码绕晕了，也没关系，我画了类图以及时序图，帮助大家理解，配合着类图跟时序图看代码，会容易理解很多。

4.1 Lifecycle 相关原理类的 UML 图

核心类 UML 图整理如下：

Lifecycle-UML.jpg

(图2. Lifecycle-UML图)

4.1 Lifecycle 原理时序图

图中起始于 onCreate ，顺便利用 onCreate 描绘整个流程。（其他生命周期原理一样，不重复画了）

image.png

(图3. Lifecycle 时序图)

4.3 Lifecycle State 与 Event 的关系图

图展示了 State 与 Event 的关系，以及随着生命周期走向它们发生的变化。

Lifecycle-Seq2.png

(图4. State 与 Event 的关系图)

5. Lifecycle 的实战应用

好了，重点的原理我们分析完毕了，如果看一遍没有理解，就多看几遍。

这个小节来讲讲 Lifecycle 的实战应用。

Lifecycle 的应用场景非常广泛，我们可以利用 Lifecycle 的机制来帮助我们将一切跟生命周期有关的业务逻辑全都剥离出去，进行完全解耦，比如视频的暂停与播放，Handler 的消息移除，网络请求的取消操作，Presenter 的 attach&detach View 等等，并且可以以一个更加优雅的方式实现，还我们一个更加干净可读的 Activity & Fragment。

下面举个简单的例子：

5.1 自动移除 Handler 的消息：LifecycleHandler

我们担心 Handler 会导致内存泄露，通常会在 onDestroy 里移除消息，写多了烦，但是结合 Lifecyc le ，我们可以写出一个 lifecycle-aware 的 Handler，自动在 onDestroy 里移除消息，不再需要写那行样板代码。

代码实现如下：

image.png

该代码已经包含在我的开源库 Pandora 里了，可以访问：https://github.com/AlanCheen/Pandora ，直接依赖使用，欢迎 star。

5.2 给 ViewHolder 添加 Lifecycle 的能力

有些 App 会有长列表的页面，里面塞了各种不用样式的 Item，通常会用 RecyclerView 来实现，有时候部分 Item 需要获知生命周期事件，比如包含播放器的 Item 需要感知生命周期来实现暂停/重播的功能，借助 Lifecycle 我们可以实现。

具体实现可以参考我的开源库 Flap：https://github.com/AlanCheen/Flap 。

6. 知识点梳理汇总

**Lifecycle** 库通过在 SupportActivity 的 onCreate 中注入 ReportFragment 来感知发生命周期；
**Lifecycle** 抽象类，是 Lifecycle 库的核心类之一，它是对生命周期的抽象，定义了生命周期事件以及状态，通过它我们可以获取当前的生命周期状态，同时它也奠定了观察者模式的基调；（我是党员你看出来了吗:-D）
**LifecycleOwner** ，描述了一个拥有生命周期的组件，可以自己定义，不过通常我们不需要，直接使用 AppCompatActivity 等即可；
**LifecycleRegistry** 是 Lifecycle 的实现类，它负责接管生命周期事件，同时也负责 Observer 的注册以及通知；
**ObserverWithState** ，是 Observer 的一个封装类，是它最终通过 ReflectiveGenericLifecycleObserve 调用了我们用注解修饰的方法；
**LifecycleObserver** ，Lifecycle 的观察者，利用它我们可以享受 Lifecycle 带来的能力；
**ReflectiveGenericLifecycleObserver**，它存储了我们在 Observer 里注解的方法，并在生命周期发生改变的时候最终通过反射的方式调用对应的方法。

7. 总结

Lifecycle 是一个专门用来处理生命周期的库，它能够帮助我们将 Acitivity、Framgent 的生命周期处理与业务逻辑处理进行完全解耦，让我们能够更加专注于业务；通过解耦让 Activity、Fragment 的代码更加可读可维护。

可以这么说 Lifecycle 的出现彻底解决了 Android 开发遇到的生命周期处理难题，并且还给开发者带来了新的架构姿势，让我们可以设计出更加合理的架构。

妈妈再也不用担心我遇到生命周期难题了！

同时 Lifecycle 作为 AAC 的基石，为 LiveData、ViewModel 的登场打下坚实的基础。

那么，LiveData、ViewModel 的背后又是什么原理呢？

尽请期待下一篇！

8. 参考与推荐

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 203,547评论 6赞 477
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 85,399评论 2赞 381
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 150,428评论 0赞 337
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 54,599评论 1赞 274
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 63,612评论 5赞 365
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 48,577评论 1赞 281
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 37,941评论 3赞 395
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 36,603评论 0赞 258
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 40,852评论 1赞 297
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 35,605评论 2赞 321
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 37,693评论 1赞 329
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 33,375评论 4赞 318
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 38,955评论 3赞 307
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 29,936评论 0赞 19
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 31,172评论 1赞 259
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 43,970评论 2赞 349
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 42,414评论 2赞 342

【AAC 系列二】深入理解架构组件的基石：Lifecycle

0. 前言

1. Lifecycle 使用基础

2. 感知生命周期的原理

2.1 初现端倪 ReportFragment

2.2 幕后“黑手” SupportActivity

2.3 Lifecycle 的生命周期事件与状态的定义

2.3.1 Lifecycle.Event

2.3.2 Lifecycle.State

2.3.3 Event 与 State 的关系：

2.4 小结

3. 注解方法被调用的原理

4. 图解 Lifecycle

4.1 Lifecycle 相关原理类的 UML 图

4.1 Lifecycle 原理时序图

4.3 Lifecycle State 与 Event 的关系图

5. Lifecycle 的实战应用

5.1 自动移除 Handler 的消息：LifecycleHandler

5.2 给 ViewHolder 添加 Lifecycle 的能力

6. 知识点梳理汇总

7. 总结

8. 参考与推荐

推荐阅读更多精彩内容