记录一下分析Google
出品的AAC
库(ps:不是音频),下面是官方地址
https://developer.android.com/topic/libraries/architecture/index.html?hl=zh-cn
Lifecycles
使用
这是一个用于管理UI
组件生命周期和处理数据持久化的库,要使用这个库,需要手动拉下依赖
运行发现这三句都要添加
首先说下Lifecycles
这块,这一模块旨在帮助没有生命周期的类能够方便的监听生命周期的变化,从而减少内存泄露的出现,使用的方法非常简单,官方提供了LifecycleRegistryOwner
接口可以让你的Activity
或者Fragment
实现,其后实例化LifecycleRegistry
即可
之后则新建一个Observer
(没有生命周期的类)去继承LifecycleObserver
,并使用@OnLifecycleEvent
注解方法指定需要监听的生命周期
最后调用LifecycleRegistry.addObserver()
进行绑定即可让Observer
也获取相应的生命周期回调
分析
使用起来的确很简单,接下来就是开始分析,首先第一个问题是为什么Observer
能够得到跟Activity
一样的生命周期回调,先从addObserver
读起
这里将Observer
传进来之后会实例化一个ObserverWithState
,然后放进一个Map
保存起来,最后调用sync
,先看看这个ObserverWithState
这个GenericLifecycleObserver
是什么鬼,进去Lifecycling
看下
可以看出这里用了反射以Observer
新建了个类GenericLifecycleObserver
,这个类可以在build/source
下找到
看到onStateChanged
方法下是实现就反应过来YourObserver
的方法会响应生命周期的变化就是这里被调用的,所以继续看哪里调用了onStateChanged
额,这不就是刚才的ObserverWithState
吗,原来在这里被调用,通过判断mObserverCurrentState != mState
是否成立一直循环执行,所以可以指向mState
,这个状态变化从而影响sync()
从而调用mCallback.onStateChanged
从而执行YourObserver
的方法实现生命周期检测,那么继续看哪里改变了mState
啊哈,markState()
只是单纯的改变mState
,handleLifecycleEvent()
不仅改变了mState
,还遍历之前的Map
再次执行sync()
从而通知Observer
生命周期的变化,继续往下看
这部分代码在LifecycleDispatcher
这个类找到,dispatchIfLifecycleOwner
被调用的地方有四个,指向到FragmentCallback
看到FragmentCallback
继承的是FragmentManager.FragmentLifecycleCallbacks
就明白了,继续看
FragmentCallback
在DispatcherActivityCallback
构造方法中被实例化,继续
哈哈,之所以Observer
能够响应生命周期的回调,一切源头就在这里,通过对Application
注册Application.ActivityLifecycleCallbacks
监听所有Activity
的生命周期回调,从而调用sync()
、调用mCallback.onStateChanged()
通知Observer
生命周期的变化。那么这个init
是在哪里调用的呢
哇,原来官方利用了ContentProvider
的特性,在创建的时候就注册了Application.ActivityLifecycleCallbacks
,才有后面的可能。至于ContentProvider
的注册,实际利用Gradle
的合并manifest
特性,相关资料看这里https://developer.android.com/studio/build/manifest-merge.html?hl=zh-cn#_2,合并后的manifest
可以在build/intermediates/manifests
下找到
ProcessLifecycleOwner
看向LifecycleRuntimeTrojanProvider.onCreate
,实现了两个init
其中LifecycleDispatcher.init
则是我们逆推来的,其原理是利用Application
的registerActivityLifecycleCallbacks()
注册Activity
生命周期监听,再根据判断if (activity instanceof FragmentActivity)
继续调用FragmentManager.registerFragmentLifecycleCallbacks
注册Fragment
生命周期监听,最后都是调用LifecycleRegistryOwner.handleLifecycleEvent
去通知各个Observer
的方法从而管理生命周期。
还有一个ProcessLifecycleOwner
是干嘛的呢,Let’s go
竟然是一个sInstance
静态实例,最终同样是向Application
注册生命周期监听,道理是一样的,但是与LifecycleDispatcher
不同的是这里维护了一个自己的Registry
并且activityPaused
时调用handleLifecycleEvent
的时机也是通过一个Handler
并延时700ms执行,为什么这样做呢,看到了ProcessLifecycleOwner
的注释
该类同样拥有Activity
的生命周期的监听,但是会忽略掉ON_DESTROY
,其中比较特殊的是ON_PAUSE
会延迟700ms再执行handleLifecycleEvent
,官方解释是这个延时足够确保当Activity
销毁或者重建(比如旋转屏幕)时不会发生ON_PAUSE
事件,这也可以非常简单的判断应用是否进入后台等情景。