概述
转载请注明出处:
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,可能这点上有些效率的牺牲。
最后
以上就是追寻滑板为你收集整理的Lifecycle-aware Components google官方生命周期组件的全部内容,希望文章能够帮你解决Lifecycle-aware Components google官方生命周期组件所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复