这是我在项目使用RxAndroid、RxJava和Retrofit时的一些记录和分析。
在使用RxAndroid和Retrofit进行网络操作时,有如下这些代码
getMyFollowingBoard(mTokenType, mTokenAccess, mIndex, mLimit)
.doOnUnsubscribe(new Action0() {
@Override
public void call() {
Logger.d("Unsubscribe");
}
})
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(只有响应操作的打印...)
(正确联网返回)
[ModuleFragment:onStart:230]:
[ModuleFragment:onNext:251]:
[ModuleFragment:onCompleted:236]:
[ModuleFragment:call:221]: Unsubscribe
分析:
- 网络的调用在Fragment中,没有做相关Fragment生命周期绑定处理。
- 打印结果的前四行,没有问题,是正确的调用。
但是我没有在任何地方调用取消订阅的操作,为什么会能够响应doOnUnsubscribe方法?
有必要贴一下doOnUnsubscribe的说明图
方法说明:Observables被取消订阅时候调用。
在RxJavaCallAdapterFactory类里面层层调用最后能看到这样的代码
// Attempt to cancel the call if it is still in-flight on unsubscription.
subscriber.add(Subscriptions.create(new Action0() {
@Override public void call() {
call.cancel();//这是Retrofit网络取消方法
}
}));
这段代码是给 subscribe 增加一个 unsubscribe 的事件。 也就是请求完成的时候,会自动对 call 进行一个终止,也就是 http 的 close 行为。
资料来自于:
https://segmentfault.com/a/1190000004077117?utm_source=tuicool&utm_medium=referral
修改上面的代码,添加线程休眠2秒,网络操作在onActivityCreated生命周期中调用
getMyFollowingBoard(mTokenType, mTokenAccess, mIndex, mLimit)
.filter(new Func1() {
@Override
public Boolean call(FollowingBoardListBean followingBoardListBean) {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return true;
}
})
.doOnUnsubscribe(new Action0() {
@Override
public void call() {
Logger.d("Unsubscribe");
}
})
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(只有响应操作的打印...)
(进入Fragment,再马上退出)
[BaseFragment:onCreateView:95]: MyAttentionBoardFragment
[BaseFragment:onActivityCreated:106]: MyAttentionBoardFragment
—>按下返回键,退出这个Fragment
[BaseFragment:onPause:124]: MyAttentionBoardFragment
[BaseFragment:onDestroyView:136]: MyAttentionBoardFragment
[BaseFragment:onDestroy:143]: MyAttentionBoardFragment
[MyAttentionBoardFragment:onNext:90]:
[MyAttentionBoardFragment:onCompleted:79]:
[MyAttentionBoardFragment:call:70]: Unsubscribe
分析:
在负责显示网络内容的Fragment都销毁的情况还接收联网结果调用是没有意义的。没有用的对象占用内存。
在RxJava中存在这个类
rx.subscriptions.CompositeSubscription
类说明:Subscription that represents a group of Subscriptions that are unsubscribed together.
All methods of this class are thread-safe.
翻译:有关于Subscriptions的集合类,用于取消订阅操作。
所以我们可以使用它保存我们的Subscription联网操作,在合适的地方取消
集成在BaseFragment用于统一管理。
public abstract class BaseFragment extends Fragment {
private CompositeSubscription mCompositeSubscription;
public CompositeSubscription getCompositeSubscription() {
if (this.mCompositeSubscription == null) {
this.mCompositeSubscription = new CompositeSubscription();
}
return this.mCompositeSubscription;
}
public void addSubscription(Subscription s) {
if (this.mCompositeSubscription == null) {
this.mCompositeSubscription = new CompositeSubscription();
}
this.mCompositeSubscription.add(s);
}
@Override
public void onDestroy() {
super.onDestroy();
//在销毁时统一取消
if (this.mCompositeSubscription != null) {
this.mCompositeSubscription.unsubscribe();
}
}
}
添加上面代码到BaseFragment后,再次实验
[BaseFragment:onCreateView:95]: MyAttentionBoardFragment
[BaseFragment:onActivityCreated:106]: MyAttentionBoardFragment
[BaseFragment:onResume:118]: MyAttentionBoardFragment
[BaseFragment:onPause:124]: MyAttentionBoardFragment
[BaseFragment:onDestroy:143]: MyAttentionBoardFragment
[MyAttentionBoardFragment:call:72]: Unsubscribe //看到取消了
[BaseFragment:onDetach:155]: MyAttentionBoardFragment
这样就实现了RxAndroid和Retrofit在Fragment的优化(Activity同理)
这在Goog官方MVP架构中,同样采用这样的方式处理生命周期同步。
在这篇博客http://blog.danlew.net/2014/10/08/grokking-rxjava-part-4/
也就是深入浅出RxJava(四:响应式安卓开发)的原文中又提到
这样的代码实现
AndroidObservable.bindActivity(this, retrofitService.getImage(url))
.subscribeOn(Schedulers.io())
.subscribe(bitmap -> myImageView.setImageBitmap(bitmap);
实现:当你的Activity或Fragment完成,同样也会发出停止网络操作信号
这里有AndroidObservable源码
但是相信大家在compile 'io.reactivex:rxandroid:1.1.0'
AppObservable and its bind methods have been completely eradicated. There were a number of problems with it:
说明:AppObservable(也就是进化版的AndroidObservable),存在很多问题,已经从RxAndroid中移除
问题如下:
1. It tried to auto-unsubscribe, but it would only do so if the sequence emitted an item after the Activity or Fragment paused. As a consequence, sequences that never end might never unsubscribe.
2. It was designed to defend against notifications after pause, but it appears that bug only occurred due to a subtle logic issue in the HandlerScheduler.
3. It automatically called observeOn(AndroidSchedulers.mainThread()), whether you wanted it or not.
extends RxAppCompatActivity
,会影响我们的代码层级。