标签:防止 传递 为我 ted 提高 strong roi exe base
在 Android 开发中,我们都很熟悉 Activity 的 Lifecycle,并且会在特定的 Lifecycle 下执行特定的操作。当然,我们清楚 Lifecycle 本身是带有 Android 特质的,那尝试设想下,如果 普通的 Java Class 也能自动感知 Lifecycle 呢
?咋一听这个想法似乎背后意义不大,但在实际探索中,我们发现这个特性能为我们达成一些之前未考虑到或者不易实现的优化。java学习群669823128
本文分享下我们基于这个思想所开发的框架: AutoLifecycle
及其带来的一些有意思的实践。
注:下文提到的 Lifecycle-Aware
就是这里指代的 让普通 Java Class 自动获取 Lifecycle
。
在网络请求时,相信大家都有一个经验:在每个网络结果回来时,我们做的第一件事不是显示数据,而是写个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
,不仅仅是网络请求。
先说下这项优化的原理。
通常,我们会在 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优化效果
现在有了 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%
的优化,效果是非常不错的,而且代码也更加简洁清晰。
通过简单的注册 AutoLifecycle
, Presenter
能够自动感知到所有 Lifecycle
,甚至包括自定义的特殊 Lifecycle
,如下图:
LifecycleAwarePresenter
第一项优化比较直接,可以先让大家形成一个直观印象。
我们项目是采用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
里写一遍,提高类的内聚性。
(TL;DR)
下面介绍下 AutoLifecycle
的关键实现部分,感兴趣的读者可以参考。
使用过 RxJava
的同学知道里面有一个 PublishSubject
,基于观察者模式,主动发送并接受消息。这里我们用 PublishSubject
来发送Lifecycle事件。见如下:
上面提了, PublishSubject
不仅能发送消息,还能接受自己的消息。基于这个特点,我们便可以监听每一个LifecycleEvent。如下图:
这里的参数Observable是我们希望被回调的函数,IContextLifecycle是指定的Lifecycle。即当指定的Lifecycle Event发生时,会自动subscribe提供的Observable。
基于这个功能,便可以实现上面场景一和场景二里的 @AutoLifecycleEvent
注解了,即把 @AutoLifecycleEvent
标注的函数包装成一个Observable,通过这个 executeOn
来注册函数的执行生命周期即可。
在场景三里,我们为网络请求的 Observable
提供了一个 Transformer
,它能在监听到某个Lifecycle发生时,停止数据流的向下流动。该 Transformer
的核心实现是:
可以看出,当指定的Lifecycle一旦发生,我们网络请求Observable就会停止向下传递数据。
可以看出, AutoLifecycle
除了支持常规的生命周期,还能支持自定义的特殊生命周期,比如View Inflate前。
另外,上面都是以Activity为例,不过显然这套框架可以灵活扩展,不局限于Activity,还能适用于Fragment、DialogFrament等。
Lifecycle-Aware
思想是Google官方提出来的概念:赋予普通类自动感知生命周期的能力。而本文也是基于这个思想,提供了一些具体实践和优化的思路,读者同学可以根据自己的情况做更多的改进和尝试。java学习群669823128
让普通 Java 类自动感知 Activity Lifecycle
标签:防止 传递 为我 ted 提高 strong roi exe base
原文地址:http://www.cnblogs.com/-reset/p/7806852.html