RxJava结合Retrofit的四种subscribe订阅方式差异解析

嘿，这四种subscribe的实现可不是功能一致的，它们对应RxJava不同版本的API设计和不同的业务场景需求，我给你逐个拆解清楚：

1. 基于Subscriber的实现（过时写法） #

Observable<PostMessage> call = service.callAPI(data); 
call.subscribeOn(Schedulers.io()) 
.observeOn(AndroidSchedulers.mainThread()) 
.subscribe(new Subscriber<PostMessage>( )); 

这是RxJava 1.x时代的经典写法，在RxJava 2.x及以后的版本里已经被标记为**过时（@Deprecated）**了。Subscriber是Observer的抽象实现，它默认帮你处理了订阅时的资源管理，但RxJava 2.x重构了资源管理逻辑（引入了Disposable），所以官方已经不推荐使用这种写法了，新项目里尽量避免。

2. 基于Consumer的极简实现 #

Observable<PostMessage> call = service.callAPI(data); 
call.subscribeOn(Schedulers.io()) 
.observeOn(AndroidSchedulers.mainThread()) 
.subscribe(new Consumer<PostMessage>( ) { 
    @Override 
    public void accept(PostMessage postMessage) throws Exception { } 
}); 

这是最简化的订阅写法，只关注正常事件流的处理（也就是onNext回调）。如果你只关心API请求成功后拿到数据做业务处理，完全不需要处理错误、事件完成或者订阅回调，这种写法会很省事。

但要注意风险：如果Observable发送了onError事件（比如API请求失败），这里没有对应的错误处理逻辑，会直接抛出OnErrorNotImplementedException，大概率导致APP崩溃。所以这种写法只适合你能确保不会出现错误的场景，或者已经在上游用onErrorReturn、onErrorResumeNext这类操作符提前处理了错误的情况。

3. 基于DisposableObserver的简化完整实现 #

Observable<PostMessage> call = service.callAPI(data); 
call.subscribeOn(Schedulers.io()) 
.observeOn(AndroidSchedulers.mainThread()) 
.subscribe(new DisposableObserver<PostMessage>() { 
    @Override 
    public void onNext(PostMessage postMessage) { } 
    @Override 
    public void onError(Throwable e) { } 
    @Override 
    public void onComplete() { } 
}); 

这是RxJava 2.x专门为优化资源管理推出的Observer替代实现，是旧Subscriber的官方替代品。它内部已经帮你持有了Disposable对象，你可以通过它的dispose()方法手动取消订阅，避免内存泄漏。

它要求你实现三个核心方法：onNext（处理成功返回的数据）、onError（处理请求错误）、onComplete（事件流正常结束时回调），省去了onSubscribe的手动实现，兼顾了完整性和简洁性，是日常开发中最推荐的写法之一。

4. 基于Observer的全量自定义实现 #

Observable<PostMessage> call = service.callAPI(data); 
call.subscribeOn(Schedulers.io()) 
.observeOn(AndroidSchedulers.mainThread()) 
.subscribe(new Observer<PostMessage>( ) { 
    @Override 
    public void onSubscribe(Disposable d) { } 
    @Override 
    public void onNext(PostMessage postMessage) { } 
    @Override 
    public void onError(Throwable e) { } 
    @Override 
    public void onComplete() { } 
}); 

这是最灵活、最完整的观察者实现，要求你实现所有四个回调方法：

• onSubscribe：订阅成功时触发，在这里你可以拿到Disposable对象，手动保存到CompositeDisposable里统一管理，或者立即取消订阅（比如页面已经销毁时）
• onNext：处理正常返回的数据
• onError：处理请求错误
• onComplete：事件流正常结束时触发

这种写法适合需要精细控制订阅生命周期的场景，比如在页面销毁时统一取消所有订阅，或者在订阅时做一些初始化逻辑。

总结一下：

• 第一种是旧API的遗留写法，已过时，不推荐使用
• 第二种是极简写法，只处理成功事件，风险较高，需谨慎使用
• 第三种是平衡了简洁性和完整性的推荐写法，适合大多数日常场景
• 第四种是全量自定义写法，灵活度最高，适合需要精细控制的场景

内容的提问来源于stack exchange，提问作者R.Roshan