转载请注明出处：
Lifecycle-aware Components google官方生命周期组件

地址：http://www.jianshu.com/p/aa6275ad5664

目录

很多情况下，业务模块需要activity的生命周期，由此会产生很多级联耦合。google官方提供了Lifecycle-aware 组件可以帮助我们去掉这种耦合。

1 场景

比如你需要在a模块中调用activty的ondestroy（）方法，你肯定会写一个接口，在业务模块中实现，然后activity中set进来这个实现，在ondestroy（）方法中调用这个实现。这时候你的activity肯定需要耦合a模块，使用delegate类，和这个是一个道理。通过delegate层可以稍微减少这种关系，但如果一个模块层级较深，我们又想获取activity 的生命周期，比如onDestroy（）中取消订阅，我们还是不得不进行硬性耦合。

2 更深入的好处

这个功能太棒了，在框架中，我们知道我们把view和model绑定后，我们需要一个触发时机来启动model进行加载数据，触发时机肯定就是activity的onStart()或onCreate（）生命周期，因此，我们不得不建立activity和业务模块的硬性耦合，但这个组件做到了不耦合，这样我们就不需要传递实现/接口，也不需要delegate。

3 用法

• 你需要你的有业务模块实现LifecycleObserver接口，实现的方法可以按需增减（因为使用的是注解的形式，所以你可以只写你需要的方法）：

     @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
     public void onCreate() {
     Log.e("lifecycle","WishScoreRelativeLayout.onCreate()" );
     }

     @OnLifecycleEvent(Lifecycle.Event.ON_START)
     public void onStart() {
     Log.e("lifecycle","WishScoreRelativeLayout.onStart()");
     }

     @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
      public void onResume() {
      Log.e("lifecycle","WishScoreRelativeLayout.onResume()");
      }

      @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
      public void onStop() {
      Log.e("lifecycle","WishScoreRelativeLayout.onStop()");
      }

      @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
      public void onDestroy() {
       Log.e("lifecycle","WishScoreRelativeLayout.onDestroy()" );
       }

• 在这个组件初始化的地方进行：

     if (context instanceof LifecycleRegistryOwner){
        ((LifecycleRegistryOwner) context).getLifecycle().addObserver(this);
     }    

即使addObserver（）的时候activity已经进行到了onResume,你在组件中又写了onCreate（），onStart（）的回调，那么在addObserver的时候，就会执行之前的onCreate（），onStart（）。因为addObserver（）的时候会判断activty的生命周期状态，然后把之前的生命周期回调执行了。
比如我们让WishScoreRelativeLayout实现LifecycleObserver中各个生命周期回调，然后在WishScoreRelativeLayout初始化时期addObserver（），初始化时期的时机是MovieDetailBlockActivity的onResume。那么我们看下：

• 我们还需要activity实现LifecycleRegistryOwner：

   public class MyFragment extends Fragment implements LifecycleRegistryOwner {
   
   LifecycleRegistry lifecycleRegistry = new LifecycleRegistry(this);
  
   @Override
   public LifecycleRegistry getLifecycle() {
   return lifecycleRegistry;
   }
   }
  

4 实现原理

你可能会问为什么，实现的机制是什么？我撸了一遍源码，有很多小细节，设计的很不错。但是没有做笔记。也不是很难，自己可以直接看源码，也可以参考

• https://developer.android.com/topic/libraries/architecture/lifecycle.html
• http://chaosleong.github.io/2017/05/27/How-Lifecycle-aware-Components-actually-works/

当然，我也可以粗略的讲述一下：

核心就是借助lifecycleRegistry做为中介层，来实现对生命周期事件的发送和订阅。对生命周期的订阅，可以很清楚的看到是刚才写的LifecycleObserver。那么lifecycleRegistry怎么获取的activty的生命周期的呢？因为这里借助了

   ((Application) context.getApplicationContext())
       .registerActivityLifecycleCallbacks(activityLifecycleCallback)

在activityLifecycleCallback 中的各个生命周期回调中进行了LifecycleRegistry.handleLifecycleEvent(特定生命周期event)。这就是大体的过程，当然实际上比这复杂的多。比如，并不是使用的activityLifecycleCallback中的生命周期回调，因为这个不准确。那怎么获取的activity或者是fragment的生命周期的回调呢？看过glide源码的同学肯定知道，glide使用新创建一个fragment来监听宿主activity的生命周期，这里类似，也使用新建了一个ReportFragment，我们监听的是ReportFragment的生命周期回调（当然这个也不准确，还监听了其他的）。对于activityLifecycleCallback，内部还赋予一个生命周期状态参数，LifecycleRegistry在add这个callback和发送生命周期event的时候，根据这个参数和lifecycleRegistry的状态参数对比，进行状态的升降来同步他们的状态。我们前面看到了LifecycleObserver里面都是注解的方法，这里还用到了注解处理的一些逻辑，然后反射生成GenericLifecycleObserver实例，便于以后调用它的onStateChanged（）方法。还是挺复杂的，能学到不少东西，可以看看。

5 效率和方法数引入

查看了包大小，这个只会引入25个左右的类，还算是比较轻量级了。并且是官方的library，所以也不存在第三方包的一些问题。至于效率上，通过上面的原理介绍，其实就是在activity周期回调的时候，会查看注册这个activity的所有observer，然后通知他们进行回调。按理说代码不会多执行太多的代码。在addobserver（）上，需要反射实例化GenericLifecycleObserver，可能这点上有些效率的牺牲。