Lifecycle

[图片]Vue 在导出过程中，通过不同平台进行平台特定指令和组件导出，该图针对于Vue-Web。在执行过程中，分别进行了通用Vue的初始化，和平台特定的初始化，在new Vue中，vue执行了_init 方法分别进行了右上角的初始化方法整个过程从 Vue 实例化， 生命周期从 beforeCreate -> mounted

在上篇文章：Android 生命周期组件 Lifecycle 使用详解 中，我们讲了 Lifecycle 的简单使用，本篇我们来研究下它的源码。基础环境搭建首先，按照上篇文章所讲，快速搭建环境。添加 Lifecycle 轻量级依赖库： implementation “android.arch.lifecycle:runtime:1.1.1"添加support library 28.0.0的支持库（希望大家能先保持一致，因为不同版本的源码是有区别的，后面会将到）：implementation ‘com.android.support:appcompat-v7:28.0.0’再添加个注解处理器相关的依赖，至于用处，后面会讲：annotationProcessor “android.arch.lifecycle:compiler:1.1.1"接下来创建实现了 LifecycleObserver 接口的 MyObserver 类：让我们的 Activity 继承自 AppCompatActivity，并在 onCreate() 方法中通过 getLifecycle().addObserver(new MyObserver())绑定 MyObserver ：核心代码就一句， getLifecycle().addObserver(new MyObserver())，就能让我们创建的 MyObserver 类，拥有生命周期感知能力。我们知道，这里主要的对象就两个。一个是 getLifecycle() 方法返回来的 LifecycleRegistry 对象(继承自抽象类 Lifecycle)，一个是我们创建的需要监听生命周期的类 MyObserver。那我们不禁要问：LifecycleRegistry 是如何感知到生命周期的？它又是如何把生命周期事件分发给 LifecycleObserver 的？我们先来解决第一个问题，LifecycleRegistry 是如何感知到生命周期的。LifecycleRegistry 是如何感知到生命周期的首先，我们Command/Ctrl + 鼠标左键跟踪 getLifecycle() 代码，发现它的具体实现是在 AppCompatActivity 的祖先类 SupportActivity 中，该类实现了 LifecycleOwner 接口。在 onSaveInstanceState() 方法中将 mLifecycleRegistry 的状态置为了 Lifecycle.State.CREATED，这点我们在前篇也讲到过。但从这我们还是看不到跟生命周期有关的东西。此时，我们发现在 onCreate() 方法中有这一行代码：ReportFragment.injectIfNeededIn(this);ReportFragment 是做什么的？点进去看:可以看到， ReportFragment 的 injectIfNeededIn(Activity activity)方法向 Activity 中添加了一个未设置布局的 Fragment ：然后又在重写的生命周期事件中调用dispatch(Lifecycle.Event event)方法，来分发生命周期事件，这就是“生命周期感知能力”的来源。这种通过一个空的 Activity 或者 Fragment 来实现特定功能的技巧还是挺常见的，比如权限请求库 RxPermission ，以及 airbnb 开源的用于URL跳转的 DeepLinkDispatch（前者是使用空的 Fragment，后者使用的是空的 Activity）ReportFragment#dispatch(Lifecycle.Event event) 这里面，又调用了 LifecycleRegistry 的handleLifecycleEvent(event)方法。至此，就引入了第二个问题，事件是如何分发到 LifecycleObserver 的。事件是如何分发到 LifecycleObserver 的进入 LifecycleRegistry#handleLifecycleEvent(Lifecycle.Event event)方法，发现它又调用了 moveToState(State next) 方法：而在 sync() 方法中，根据 state 的状态，最终会调用到backwardPass(…)或者forwardPass(…)：以 forwardPass(…) 为例：上图可以看到，通过 mObserverMap 最终获取到一个 ObserverWithState 类型的 observer 对象，并调用它的dispatchEvent进行事件分发： observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));ObserverWithState 又是个什么鬼？我们继续追踪，发现 ObserverWithState 是 LifecycleRegistry 的一个静态内部类。从名称上就能看出，该类封装了 Observer 对象和 State 对象（具体就是 State 和 GenericLifecycleObserver，GenericLifecycleObserver 是个接口，继承自 LifecycleObserver），在其 dispatchEvent 方法中，最终会回调 mLifecycleObserver 的 onStateChanged(…) 方法。追踪到这里，我们知道了，Lifecycle在监听到生命周期变化之后，最终会回调 GenericLifecycleObserver 的 onStateChanged() 方法。我们不由得疑惑，我们定义的 MyObserver 哪去了？没看到有调用我们定义的回调方法啊。它和 GenericLifecycleObserver 又有什么关系？我们看到，ObserverWithState 的构造函数里传进来了一个 LifecycleObserver 类型的 observer 对象，这个参数是从哪传进来的？继续追踪，发现追到了LifecycleRegistry#addObserver(LifecycleObserver observer)方法。而这个方法，就是我们在MainActivity#onCreate(…)方法中调用的： getLifecycle().addObserver(new MyObserver());到这里，总算跟我们的 MyObserver 关联上了。查看LifecycleRegistry#addObserver(LifecycleObserver observer)方法源码：这里面的核心代码就两行，一行是： ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);这行代码，通过传进来的Observer对象，创建出 ObserverWithState 对象。还有一行是： ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);这行代码是将 LifecycleObserver 对象放入一个FastSafeIterableMap 中,以便进行迭代。接下来我们就进入 ObserverWithState 的构造方法中看看：在构造方法中，通过 Lifecycling.getCallback(observer)根据传进来的 observer ，构造了一个 GenericLifecycleObserver 类型的 mLifecycleObserver ，那秘密应该也就在这个方法里，继续跟进。这个方法的本质，其实就是根据传进来的一个LifecycleObserver 对象，构造出来一个 GenericLifecycleObserver 对象(目前有四个子类:FullLifecycleObserverAdapter、SingleGeneratedAdapterObserver、CompositeGeneratedAdaptersObserver、ReflectiveGenericLifecycleObserver)，而最终构造出来的对象，就包含了我们创建的 LifecycleObserver 的所有信息，包括各种回调方法等。看到这里，就要提到文章开头要大家添加的一个注解处理器的依赖：annotationProcessor “android.arch.lifecycle:compiler:1.1.1"当我们通过注解的方式来自定义LifecycleObserver 的时候，按照传统方式，必定要通过反射来对注解进行解析，这样就会对性能造成影响。一方面，我们通过缓存，来避免每次都通过反射获取构造器。另一方面，又通过注解处理器，在编译时对那些被@OnLifecycleEvent注解标注的普通方法，进行预处理，生成以“类名_LifecycleAdapter”命名的类，将各种回调方法直接进行逻辑转换，避免反射，进而来提高性能。明白了这点，再看Lifecycling.getCallback(observer)方法就比较容易理解了。如果传进来的的参数 object 是 FullLifecycleObserver 类型，就把它构造成FullLifecycleObserverAdapter 对象，并返回如果传进来的的参数 object 是GenericLifecycleObserver类型，直接返回该对象如果1，2都不满足，就解析该类的的构造器的Type（该类是反射获取的，还是通过注解处理器生成的）。如果是通过注解处理器生成的类来调用回调函数，就返回一个SingleGeneratedAdapterObserver/CompositeGeneratedAdaptersObserver 对象如果以上条件都不满足，就通过反射来调用各回调函数。返回一个 ReflectiveGenericLifecycleObserver 对象现在我们在 app 目录下的 bulid.gradle 中添加上上面的注解处理器依赖，然后编译下项目，会发现在build目录下生成了对应的类：MyObserver_LifecycleAdapter.java点进去，看看生成的这个类的源码：可以看到，我们在 MyObserver 中通过@OnLifecycleEvent注解标注的那些方法，在这里都根据条件进行判断了，而非通过注解。这时候我们就能理清这个这个流程了，当添加了注解处理器之后，我们这里的Lifecycling.getCallback(observer)方法将会把我们的MyObserver对象构建成一个 SingleGeneratedAdapterObserver对象返回（因为这里只有一个构造器），之后的 mLifecycleObserver.onStateChanged(owner, event);其实调用的就是SingleGeneratedAdapterObserver的onStateChanged(owner, event)方法：这里面就可以看到，它调用了内部包裹的类的callMethods(…)方法，也就是我们上面提到的MyObserver_LifecycleAdapter的callMethonds(…)方法。到这里，就完成了 Lifecycle 源码的解析。通过反射获取注解信息这顺便提下通过注解的方式调用各回调方法的过程。主要相关类就是 ReflectiveGenericLifecycleObserver.java这里我们主要关注回调信息 CallbackInfo 的获取方式的代码： mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());因为反射的代价是比较大的，所以又通过 ClassesInfoCache.java这个单例类，为 ReflectiveGenericLifecycleObserver 类要调用的各种方法的相关信息进行了缓存。点进去看下它的 getInfo(…) 方法内部，是如何获取方法信息的。里面又调用了createInfo()方法：这里，就能看到对注解进行处理的代码了。到这，我们就算完成了继承自 AppCompactActivity 的情况下的源码解析，而继承自普通 Activity 这种情况下，原理是什么呢？鉴于篇幅，将放在下篇文章。欢迎关注我的公众号获取。 ...

前言2018 年的 Google I/O 大会上，Google 发布了 Android Jetpack，并称其为下一代的 Android 组件，旨在帮助开发者加快应用开发速度。准确来讲，Jetpack 是一系列 Android 软件组件的集合，它包括基础组件、架构组件、行为组件、界面组件。其中的 Android Architecture Components 指的就是这里的 “架构组件”。Android Architecture Components 是 Google 推荐的一个构建 APP 的应用架构，它包含了一些列架构相关组件。而本篇文章我们要介绍的 Lifecycle 就是其中的一个与生命周期相关的库，同时，Lifecycle 也跟 LiveData 和 ViewModel 两个库紧密联系，想要搞懂后两者，就必须先搞懂它。具体各组件之间的关系，以及各自在 Jetpack 中的地位，可以参见下面两幅来源于官网的图片。Lifecycle 的作用Lifecycle 是具有生命周期感知能力的组件，也就是说，我们能在 Activity 或者 Fragment 的生命周期发生变化的时候得到通知。我们往往会在 Activity 的各种生命中周期方法里执行特定的方法，比如，进行广播的注册和解绑、Eventbus 的注册和解绑等:public class TestActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_test); } @Override protected void onStart() { super.onStart(); EventBus.getDefault().register(this); } @Override protected void onDestroy() { EventBus.getDefault().unregister(this); super.onDestroy(); }}如果我们把很多这种需要跟生命周期相关的逻辑代码都直接放在 Activity 的生命周期方法中，Activity 将会变得难以维护。通过 Lifecycle，我们就能通过把这些逻辑抽离出来，进而避免这种问题。因为本质上我们需要的只是 Activity 或者 Fragment 的生命周期发生改变的时候能通知到我们，以便我们在对应生命周期中执行对应的方法。Lifecycle 的基本使用2.0、 导入 Lifecycle 依赖Lifecycle 被包含在 support library 26.1.0 及之后的依赖包中，如果我们的项目依赖的支持库版本在 26.1.0及以上，那么不需要额外导入 Lifecycle 库，本篇例子中使用的支持库是 28.0.0 ： implementation ‘com.android.support:appcompat-v7:28.0.0’如果支持库版本小于 26.1.0 ，就需要单独导入 Lifecycle 库 ： implementation “android.arch.lifecycle:runtime:1.1.1"当然，如果项目已经迁移到了 AndroidX，可以使用下面的方式引入 ： implementation “androidx.lifecycle:lifecycle-runtime:2.0.0"还是建议大家尝试尽快把项目迁移为 AndroidX，因为很多更新，会最先在 AndroidX 中发布，逐渐摆脱传统的support包。比如这里要讲的 Lifecycle 在 AndroidX 中已经升级到了 2.x 版本，而支持库中还是 1.x 版本。鉴于支持库一般都在 26.1.0 以上，并且尚有大部分用户未迁移到AndroidX，在本篇文章中，我们使用 support library 28.0.0 中默认包含的 Lifecycle 库。我们在项目的 app 目录下的 build.gradle 文件中添加以下依赖： implementation ‘com.android.support:appcompat-v7:28.0.0’以 support library 版本在 26.1.0 及以上为前提，这里我们分两种情况来讲。一种是我们创建的Activity 继承自 AppCompatActivity(以Activity 为例，Fragment类似)，另一种是创建的 Activity 继承自普通的 Activity，而非 AppCompatActivity。这里要先说一点， Lifecycle 的实现机制是观察者模式，意识到这点，再讲它的使用过程及原理就比较容易理解了。 整体流程：构建一个 Lifecycle 对象（通过一个实现了 LifecycleOwner 接口的对象的 getLifecycle()方法返回），这个对象就是一个被观察者，具有生命周期感知能力构建一个 LifecycleObserver 对象，它对指定的 Lifecycle 对象进行监听通过将 Lifecycle 对象的 addObserver(…) 方法，将 Lifecycle 对象和 LifecycleObserver 对象进行绑定2.1、 方式一：继承自 AppCompatActivity首先，我们创建一个 MyObserver.java 类，让它实现 LifecycleObserver 接口( LifecycleObserver 接口是一个空接口，主要是给注解处理器使用)，如下：public class MyObserver implements LifecycleObserver { private static final String TAG = “MyObserver”; // 使用注解 @OnLifecycleEvent 来表明该方法需要监听指定的生命周期事件 @OnLifecycleEvent(Lifecycle.Event.ON_RESUME) public void connectListener() {// … Log.d(TAG, “connectListener: ——– onResume” ); } @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE) public void disconnectListener() {// … Log.d(TAG, “disconnectListener: ——- onPause”); }}可以看到，我们通过在方法上使用@OnLifecycleEvent 注解使得该方法具有了生命周期感知能力。括号里面的参数，表明需要监听的是什么生命周期事件。Lifecycle 主要就是通过 Event 和 State 这两个枚举类来跟踪所关联组件的生命周期状态。具体的 Event 和 State 之间的转换关系，可以参照下图：接下来，让我们的 Activity 继承自 AppCompatActivity，然后在 onCreate(…) 方法中通过getLifecycle().addObserver(new MyObserver())完成 Lifecycle 和LifecycleObserver 的绑定。public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); // 就只需要这一行代码，简洁吧 getLifecycle().addObserver(new MyObserver()); }}然后我们就可以运行下程序，跑起来之后按 Home 键或者按返回键进行操作。能看到，随着生命周期的变化，MyObserver() 中定义的方法在控制台中也被正确地打印了出来。是不是觉得特别简单。但之所以毫不费力，是因为有人替你“负重前行”。在 support library 26.1.0 及以后的支持库中，AppCompatActivity 的祖先类 SupportActivity已经默认实现了 LifecycleOwner 接口，通过其 getLifecycle() 方法可以直接返回一个 Lifecycle 对象。之后我们就可以通过该对象的 addObserver(…) 方法将 Lifecycle 跟指定的 LifecycleObserver 进行绑定。2.2、 方式二：继承自普通的 Activity首先，我们仍然需要像上面的方式，来创建一个MyObserver 对象。这次我们创建一个继承自普通的 Activity 的 Activity ，那自然无法直接使用 getLifecycle() 方法来获取 Lifecycle 。无法直接使用，那我们能否模仿 AppCompatActivity的实现，来自己创建 Lifecycle 对象呢？当然可以。这时候，我们就需要自己实现LifecycleOwner接口，并在具体的生命周期下通过 LifecycleRegistry 的 markState(…)方法来主动进行事件的分发。请看下面改造过的 MainActivity.java 代码 ：public class MainActivity extends Activity implements LifecycleOwner { private LifecycleRegistry mLifecycleRegistry; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mLifecycleRegistry = new LifecycleRegistry(this); getLifecycle().addObserver(new MyObserver()); mLifecycleRegistry.markState(Lifecycle.State.CREATED); } @Override protected void onResume() { super.onResume(); mLifecycleRegistry.markState(Lifecycle.State.RESUMED); } @Override protected void onPause() { super.onPause(); mLifecycleRegistry.markState(Lifecycle.State.STARTED); } @NonNull @Override public Lifecycle getLifecycle() { return mLifecycleRegistry; }}然后运行代码，发现结果和上面的完全一样。可以看到，MainActivity实现了LifecycleOwner接口（实现该接口的对象，即是 Lifecycle 的持有者），并在其 getLifecycle( ) 方法中返回了一个 LifecycleRegistry对象，而 LifecycleRegistry 是 Lifecycle 的实现类，能处理多个 Observer，我们自定义 LifecycleOwner的时候就可以直接使用它。其他使用方式，则完全相同。为了让使用更加方便灵活，Lifecycle 还提供了查询当前组件所处的生命周期状态的方法：lifecycle.getCurrentState().isAtLeast(STARTED)总结实现了 LifecycleObserver 接口的类可以和实现了 LifecycleOwner 接口的类无缝工作，因为 LifecycleOwner 可以提供一个 Lifecycle 对象，而 LifecycleObserver 就正需要对这个 Lifecycle 对象进行监听呢。LifecycleOwner 是从特定的类（比如 Activity 或者 Fragment 等）中抽象出来的Lifecycle 的持有者。LifecycleRegistry 是 Lifecycle 的实现类，用于注册和反注册那些需要监听当前组件生命周期的 LifecycleObserver注意从 1.0.0-rc1 版本的 Lifecycle 包开始，当 Activity 的 onSaveInstanceState() 方法调用结束之后，Lifecycle 将立刻被标记为 CREATED 和 ON_STOP ，而不是等 onStop() 方法调用结束。这点和 API level 26 或者更低版本上 Activity 的生命周期的调用顺序并不匹配，需要稍加注意。有具体需求的可以进一步查阅相关文档。更多最新消息，欢迎关注我的公众号获取： ...