最近了解到一个开源库,uber的 AutoDispose,由于不经常使用RxJava,竟然不知道还有这么个东西。。它的主要作用就是在Activity或View销毁不可用的时候自动取消RxJava的订阅,也就是常用的Disposable切断管道流, 取消订阅,避免内存泄漏。AutoDispose将之前的Disposable.dispose()操作做了封装,可以自动处理。
它的使用就不去详细探索了,搜索一下就有一堆,这里主要探究一下AutoDispose的实现原理的关键技术点,既然它能在AC销毁的时候自动取消,那么它是如何自动感知AC的生命周期的呢?
AutoDispose的简单用法示例:
Observable.interval(1, TimeUnit.SECONDS)
.doOnDispose(new Action() {
@Override public void run() throws Exception {
Log.i(TAG, "Disposing subscription from onResume() with untilEvent ON_DESTROY");
}
})
.as(AutoDispose.<Long>autoDisposable(
AndroidLifecycleScopeProvider.from(this, Lifecycle.Event.ON_DESTROY)))//OnDestory时自动解绑
.subscribe(new Consumer<Long>() {
@Override public void accept(Long num) throws Exception {
Log.i(TAG, "Started in onResume(), running until in onDestroy(): " + num);
}
});
其中as返回的还是一个Observable对象,关键是这一行:
AutoDispose.autoDisposable(
AndroidLifecycleScopeProvider.from(this, Lifecycle.Event.ON_DESTROY))
AndroidLifecycleScopeProvider.from(this, Lifecycle.Event.ON_DESTROY) 中的this是什么:
这个this实际上是LifecycleOwner这个接口,LifecycleOwner又是神马?
是android提供的Lifecycle
这个组件库中的一个接口,同时还有一个LifecycleObserver
观察者接口,通过源码发现,support.v7
包中的AppCompatActivity
最终继承自SupportActivity
,SupportActivity
实现了LifecycleOwner
接口,support.v4
包中的Fragment
也实现了LifecycleOwner
接口。AndroidX的ComponentActivity
支持库同样也实现了LifecycleOwner
接口:
所以这些类当中默认都能直接使用 AutoDispose ,那具体的生命周期检测是如何做到的?
先看LifecycleObserver
这个接口的简单使用代码:
import android.arch.lifecycle.Lifecycle;
import android.arch.lifecycle.LifecycleObserver;
import android.arch.lifecycle.OnLifecycleEvent;
import android.util.Log;
public class MyObserver implements LifecycleObserver {
private final static String TAG = MyObserver.class.getSimpleName();
@OnLifecycleEvent(Lifecycle.Event.ON_START)
public void ready(){
Log.e(TAG,"ON_START");
}
@OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
public void connectListener() {
Log.e(TAG,"ON_RESUME");
}
@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
public void disconnectListener() {
Log.e(TAG,"ON_PAUSE");
}
@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
public void destroyListener() {
Log.e(TAG,"ON_DESTROY");
}
}
然后在Activity当中调用:getLifecycle().addObserver(new MyObserver());
运行,启动AC,home返回桌面,再返回,再back关闭AC,打印输出:
我们发现LifecycleOwner
这个接口可以帮助我们摆脱Activity之外独立监听Activity的生命周期,
点击 getLifecycle() 方法,发现:
没错,就是在SupportActivity类当中的 LifecycleRegistry这个类的对象
LifecycleRegistry 又是神马?
预览一下它的几个方法:
LifecycleRegistry就像状态机一样,来管理和切换Ac的各个生命周期状态的,每个生命周期都有状态常量与之一一对应,那AC又是如何调用LifecycleRegistry的呢?
在 SupportActivity 的onCreate方法当中:
public class SupportActivity extends Activity implements LifecycleOwner, Component {
private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ReportFragment.injectIfNeededIn(this);
}
@CallSuper
protected void onSaveInstanceState(Bundle outState) {
this.mLifecycleRegistry.markState(State.CREATED);
super.onSaveInstanceState(outState);
}
关键是这一行:ReportFragment.injectIfNeededIn(this);,那这个 ReportFragment又是神马?
就是一个Fragment类,而且不是v4包的,是原生包里的。
它的每个生命周期方法中都会调用 dispatch(Lifecycle.Event event) 方法:
这里调用了 LifecycleRegistry 的 handleLifecycleEvent 方法,而handleLifecycleEvent 方法当中其实就是进行对应生命周期状态的切换了。我们知道Activity 会自动调用 Fragment 的生命周期,这样就完成了生命周期的无感知监听,利用了一个隐式的无UI界面的Fragment对象来巧妙的实现的。
上面是 SupportActivity 的,那普通 Activity 呢?怎么调用 LifecycleRegistry 的?
对于 26.1.0 以后的版本,你会发现,对于普通的 Activity,如果你想要使用 lifecycle,你只需要实现LifecycleOwner 接口即可。
其实是在 LifecycleDispatcher 类当中调用的:
class LifecycleDispatcher {
private static final String REPORT_FRAGMENT_TAG = "android.arch.lifecycle"
+ ".LifecycleDispatcher.report_fragment_tag";
private static AtomicBoolean sInitialized = new AtomicBoolean(false);
static void init(Context context) {
if (sInitialized.getAndSet(true)) {
return;
}
// 在 init 方法中,监听全局 activity 的创建,从而来添加 fragment
((Application) context.getApplicationContext())
.registerActivityLifecycleCallbacks(new DispatcherActivityCallback());
}
@SuppressWarnings("WeakerAccess")
@VisibleForTesting
static class DispatcherActivityCallback extends EmptyActivityLifecycleCallbacks {
private final FragmentCallback mFragmentCallback;
DispatcherActivityCallback() {
mFragmentCallback = new FragmentCallback();
}
@Override
public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
if (activity instanceof FragmentActivity) {
((FragmentActivity) activity).getSupportFragmentManager()
.registerFragmentLifecycleCallbacks(mFragmentCallback, true);
}
ReportFragment.injectIfNeededIn(activity);
}
@Override
public void onActivityStopped(Activity activity) {
if (activity instanceof FragmentActivity) {
markState((FragmentActivity) activity, CREATED);
}
}
@Override
public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
if (activity instanceof FragmentActivity) {
markState((FragmentActivity) activity, CREATED);
}
}
//....
}
}
可以看到,它 在 init 方法中,通过 context.getApplicationContext() .registerActivityLifecycleCallbacks 监听全局 activity 的创建,在 activity oncreate 的时候,调用 ReportFragment.injectIfNeededIn(activity) ,从而来添加 fragment,进而分发相应的事件。
那 LifecycleDispatcher.init 方法又是在哪里调用的呢?
public class ProcessLifecycleOwnerInitializer extends ContentProvider {
@Override
public boolean onCreate() {
LifecycleDispatcher.init(getContext());
ProcessLifecycleOwner.init(getContext());
return true;
}
它是在 ProcessLifecycleOwnerInitializer 的 onCreate 方法中调用的。而 ProcessLifecycleOwnerInitializer 是一个 ContentProvider。
而 ContentProvider 的 onCreate 方法优先于 Application 的 onCreate 执行,所以在 Application 之前我们就调用了 ProcessLifecycleOwnerInitializer init 方法,监听了 Activity 的创建,当 Actiivty 创建的时候,会尝试为 Activity 添加 ReportFragment。而 ReportFragment 会在 Activity 生命周期变化的时候帮助我们分发生命周期。
关于ContentProvider 的 onCreate 方法优先于 Application 的 onCreate 执行,可以参考这里。
大致过程,借用道友的一张图:
另外,Application层级也能监听app的状态,使用 ProcessLifecycleOwner:
public class App extends Application {
@Override
public void onCreate() {
super.onCreate();
ProcessLifecycleOwner.get().getLifecycle().addObserver(new ApplicationObserver());
}
}
也就是说如果自己设计一个框架想监听AC或App生命周期, 只需要接受一个 LifecycleOwner
参数即可,因为android系统多数组件类都实现了这个接口。
参考链接:
https://www.jianshu.com/p/bd800c5dae30
https://blog.csdn.net/gdutxiaoxu/article/details/86660766
https://blog.csdn.net/yuzhangzhen/article/details/110409667