背景
在 Android 开发中，我们都很熟悉 Activity 的 Lifecycle，并且会在特定的 Lifecycle 下执行特定的操作。当然，我们清楚 Lifecycle 本身是带有 Android 特质的，那尝试设想下，如果普通的 Java Class 也能自动感知 Lifecycle 呢？咋一听这个想法似乎背后意义不大，但在实际探索中，我们发现这个特性能为我们达成一些之前未考虑到或者不易实现的优化。
本文分享下我们基于这个思想所开发的框架：AutoLifecycle 及其带来的一些有意思的实践。
- 优化一：当Activity进入onDestroy时，自动取消网络请求返回
- 优化二：自动将网络请求时机提前到View渲染之前，提高页面打开速度
- 优化三：MVP改进，让Presenter和View自动bind/unBind
注：下文提到的Lifecycle-Aware就是这里指代的让普通 Java Class 自动获取 Lifecycle。
实践及优化
优化一：当Activity进入onDestroy时，自动取消网络请求返回
在网络请求时，相信大家都有一个经验：在每个网络结果回来时，我们做的第一件事不是显示数据，而是写个if-else判断Activity还在不在。
mTopApiObservable
...
.subscribe(new Subscriber<Object>() {
@Override
public void onNext(Object data) {
if(activity == null) {
return; // 判断Activity是否还在，不在就不去显示数据
}
display(data); // 显示数据
}
...
});
由于网络请求都是异步的，所以不得不做这样的判断，来防止不可预测的空指针问题或内存泄漏问题。
既然你总是担心Activity还在不在，那么如果我们通过Lifecycle-Aware让每个网络请求能自动感知Activity的onDestroy事件，
并在onDestroy时，自动把网络请求结果取消掉不再返回，那就能够消除这个担忧了。
mTopApiObservable
...
.compose(bindUntilEvent(ActivityLifecycle.DESTROY)) // 绑定Activity的onDestroy事件
.subscribe(new Subscriber<Object>() {
@Override
public void onNext(Object data) {
display(data); // 直接去显示数据
}
...
});
其中最关键的就是compose(bindUntilEvent(ActivityLifecycle.DESTROY))这句，它能达到的效果是：一旦Activity发生onDestroy时，Observer的数据就会停止向Subscriber里流动。从而保证onNext无需担心Activity已Destroy这种情况。
在上面网络请求的实践里，你还可以根据自己的情况把Destroy换成Stop/Pause等，而且可以看出，这种自动取消机制可适用于任何Observable，不仅仅是网络请求。
优化二：自动将网络请求提前到View Inflate之前，加速页面渲染
先说下这项优化的原理。
通常，我们会在Activity的onCreate里依次执行下面的代码：
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.XXX); // Inflate View
findViewByIds(); // 初始化View
presenter.loadDataFromServer(); // 发起网络请求
}
即在Inflate View和初始化View之后，才发起网络请求去加载数据。
而实际上，网络请求是不占用主线程的，如果能在Inflate View之前就在其他线程发起网络请求，可以把整个页面显示耗时缩短100ms-200ms。
LoadBeforeInflate优化效果 (1).png
现在有了AutoLifecycle框架，我们就可以很轻松实现：让Presenter自动监听Inflate View这个生命周期，在那时发起网络请求即可。
public class NewPresenter {
public NewPresenter(IView iView) {
...
// 向AutoLifecycle注册
AutoLifecycle.getInstance().init(this);
}
// 当Activity Inflate View前自动回调
@AutoLifecycleEvent(activity = ActivityLifecycle.PRE_INFLATE)
private void onHostPreInflate() {
loadDataFromServer(); // 发起网络请求
}
...
}
此时，我们的Activity也不用手动调用presenter.loadDataFromServer();了，因为Presenter内会在感知到Inflate View事件时自动发起网络请求。
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.XXX);
findViewByIds();
// 无需手动启动网络请求
}
经过测试，在保证单个网络请求耗时相同的情况下，页面从onCreate到显示数据的渲染耗时可以从550ms缩短到367ms，也就是30%-40%的优化，效果是非常不错的，而且代码也更加简洁清晰。
优化前
优化后
[图片上传失败...(image-889271-1510146010290)]
通过简单的注册AutoLifecycle，Presenter能够自动感知到所有Lifecycle，甚至包括自定义的特殊Lifecycle，如下图：
[图片上传失败...(image-8c0f0b-1510146010290)]
B2.png
优化三：MVP改进，让Presenter和View自动bind/unBind
第一项优化比较直接，可以先让大家形成一个直观印象。
我们项目是采用MVP项目，对于Presenter的使用存在一段固定代码，即在onCreate时调用bindView()，在onDestroy时调用unBindView()。如下图：
public class OldActivity extends BaseActivity {
BasePresenter mPresenter = new BasePresenter();
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mPresenter.bindView(this); // onCreate时手动bind Presenter 和 IView
}
@Override
protected void onDestroy() {
mPresenter.unbindView(); // onDestroy时手动unBindView
super.onDestroy();
}
}
那么，既然我们现在能让一个普通类自动感知Lifecycle，那其实也就能让Presenter在感知到onCreate时自动bindView，在感知到onDestroy时自动unBindView。
改进后的代码如下：
public class NewActivity extends BaseActivity {
NewPresenter mPresenter;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mPresenter = new NewPresenter(this); // 只需要创建即可
}
}
public class NewPresenter {
private IView mIView;
public NewPresenter(IView iView) {
this.mIView = iView;
// 向AutoLifecycle注册即可获得Lifecycle回调
AutoLifecycle.getInstance().init(this);
}
// 当Activity进入onCreate后自动调用
@AutoLifecycleEvent(activity = ActivityLifecycle.CREATE)
private void onHostCreate() {
bindView(mIView);
}
// 当Activity进入onDestroy后自动调用
@AutoLifecycleEvent(activity = ActivityLifecycle.DESTROY)
private void onHostDestroy() {
unBindView();
}
}
其实，在大家的平常开发中，还会存在许多类似Presenter的类：需要在某个特定的Lifecycle下执行一些动作。这时就可以基于Lifecycle-Aware来让这个普通类自动去执行，而不是去每个Activity/Fragment里写一遍，提高类的内聚性。
AutoLifecycle的核心原理
(TL;DR)
下面介绍下AutoLifecycle的关键实现部分，感兴趣的读者可以参考。
1. 让Activity对外发送Lifecycle事件
使用过RxJava的同学知道里面有一个PublishSubject，基于观察者模式，主动发送并接受消息。这里我们用PublishSubject来发送Lifecycle事件。见如下：
D1.png
这里的Lifecycle事件可以自己定义，比如前面提到的PRE_INFLATE事件，是在setContentView之前发送，类似：
D2.png
2. 感知某个Lifecycle的发生并自动执行回调
上面提了，PublishSubject不仅能发送消息，还能接受自己的消息。基于这个特点，我们便可以监听每一个LifecycleEvent。如下图：
D3.png
这里的参数Observable是我们希望被回调的函数，IContextLifecycle是指定的Lifecycle。即当指定的Lifecycle Event发生时，会自动subscribe提供的Observable。
基于这个功能，便可以实现上面场景一和场景二里的@AutoLifecycleEvent注解了，即把@AutoLifecycleEvent标注的函数包装成一个Observable，通过这个executeOn来注册函数的执行生命周期即可。
3. 监听Lifecycle并取消网络请求结果
在场景三里，我们为网络请求的Observable提供了一个Transformer，它能在监听到某个Lifecycle发生时，停止数据流的向下流动。该Transformer的核心实现是：
D4.png
可以看出，当指定的Lifecycle一旦发生，我们网络请求Observable就会停止向下传递数据。
4. 支持自定义Lifecycle，支持Activity/Fragment/DialogFrament等
可以看出，AutoLifecycle除了支持常规的生命周期，还能支持自定义的特殊生命周期，比如View Inflate前。
另外，上面都是以Activity为例，不过显然这套框架可以灵活扩展，不局限于Activity，还能适用于Fragment、DialogFrament等。
总结
Lifecycle-Aware思想是Google官方提出来的概念：赋予普通类自动感知生命周期的能力。而本文也是基于这个思想，提供了一些具体实践和优化的思路，读者同学可以根据自己的情况做更多的改进和尝试。
——————
wingjay
谢谢。
参考
https://developer.android.com/topic/libraries/architecture/lifecycle.html
https://www.atatech.org/articles/63098
https://github.com/trello/RxLifecycle
http://reactivex.io/RxJava/javadoc/rx/subjects/PublishSubject.html
http://reactivex.io/RxJava/javadoc/rx/Observable.Transformer.html
网友评论