Lifecycle-aware Components google官方生命周期组件

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

地址：http://blog.csdn.net/qq_22744433/article/details/78019470

目录

很多情况下，业务模块需要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。那么我们看下：
  
  可以看到WishScoreRelativeLayout在addObserver（）时，会先调用onCreate(),onStart()生命周期的回调,虽然这时候activity已经进行到了onResume（）。
  我们还可以观察到：
  **Observer的onCreate()，onStart（），onResume（）是在宿主activity的onCreate()，onStart（），onResume（）之后触发的，
  Observer的onPause（），onStop（），onDestroy（）是在宿主activity的oonPause（），onStop（），onDestroy（）之前触发的**
  感兴趣的同学，可以看下源码，是怎么实现这个特点的。

• 我们还需要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，可能这点上有些效率的牺牲。