在Android客户端开发里，界面响应、网络请求和本地存储往往是并行的，线程切换一旦处理不当，就会引发ANR或者内存泄漏。RxJava并不是为了替代协程或者Handler，而是提供一种统一的响应式编程模型，把原本分散在多个回调里的逻辑串成一条可组合的数据流。它的核心在于Observable、Flowable、Single等可观察类型，以及map、flatMap、filter、debounce等操作符。理解这些基础构造后，就能在合适的场景中快速落地。
网络请求与线程切换
网络请求是移动端最常见的异步场景。传统写法里，发起请求后在回调里判断返回结果，再手动切换到主线程更新UI，代码容易在多个回调之间跳跃。RxJava的做法是先用Single或者Observable封装网络接口，再通过subscribeOn指定子线程，通过observeOn切回Android主线程。
真正让代码简洁的是链式操作。例如可以先在子线程拿到网络数据，再用map把原始响应转换成界面需要的模型，然后observeOn(AndroidSchedulers.mainThread())，最后在subscribe里刷新视图。这样线程切换的时机写在链路上，不依赖Handler或者runOnUiThread。
// 模拟网络接口
public interface ApiService {
Single<List<User>> fetchUsers();
}
apiService.fetchUsers()
.subscribeOn(Schedulers.io())
.map(users -> {
List<UserUI> uiList = new ArrayList<>();
for (User user : users) {
uiList.add(new UserUI(user.getName(), user.getAvatar()));
}
return uiList;
})
.observeOn(AndroidSchedulers.mainThread())
.subscribe(
uiList -> {
adapter.submitList(uiList);
},
throwable -> {
Toast.makeText(context, "加载失败", Toast.LENGTH_SHORT).show();
}
);
上例中，subscribeOn只决定数据源开始执行的线程，observeOn决定下游观察者收到事件的线程。注意不要误以为subscribeOn可以多次调用随意切换，实际上只有第一个subscribeOn对订阅流程的启动线程生效。需要在网络请求结束后更新UI时，只要在subscribe之前调用一次observeOn，后面的操作符都会运行在主线程。
如果请求依赖上一个请求的结果，可以继续用flatMap。例如先获取用户列表，再根据第一个用户ID查询详情。这样两个异步任务被拍平成一条顺序执行的链，不需要嵌套回调。异常处理也集中在subscribe的第二个参数里，不必在每个回调里单独判断。
输入防抖与搜索联想
搜索框输入时，如果每次文本变化都立即请求接口，会产生大量无效请求，服务器压力也会增加。RxJava的debounce操作符可以在指定时间窗口内没有新事件时，才把最后一个事件发射给下游。Android开发中常用RxBinding或自定义TextWatcher来把EditText的文本变化转成Observable。
基本流程是：TextWatcher回调里把字符串交给BehaviorSubject或者PublishSubject，再对可观察序列做debounce 300毫秒，过滤掉空白内容，跳过连续相同的关键词，然后调用网络接口。如果用户在300毫秒内继续输入，计时器会被重置，只有停止输入后才会发起搜索请求。
subject
.debounce(300, TimeUnit.MILLISECONDS)
.map(String::trim)
.filter(keyword -> !keyword.isEmpty())
.distinctUntilChanged()
.subscribeOn(Schedulers.io())
.switchMap(keyword -> searchApi.search(keyword))
.observeOn(AndroidSchedulers.mainThread())
.subscribe(result -> {
searchAdapter.update(result);
});
这里使用了switchMap而不是flatMap。区别在于，当新关键词到来时，switchMap会退订上一个尚未完成的搜索请求，只保留最新一次请求，避免旧请求晚返回导致界面显示错误的搜索结果。这个细节在搜索场景非常关键，因为网络响应顺序不一定等于请求顺序。
此外，debounce的时间需要根据业务调整。过短则防抖效果不明显，过长则用户体感延迟大。300毫秒是常见选择，也可以结合本地测试数据调整。输入防抖不仅适用于搜索联想，还适合表单实时校验、筛选条件联动等场景。
多数据源合并与缓存读取
一个页面可能需要同时从内存缓存、本地数据库和远程接口读取数据，并且希望优先展示缓存，静默更新远程数据。RxJava的concat、merge、concatArrayEager等操作符可以组合多个数据源。对于先缓存后网络的场景，通常使用concat，因为concat会按顺序订阅，前一个数据源结束后才订阅下一个。
例如页面启动时先读取数据库缓存，如果缓存存在就直接渲染，再继续请求网络拿到最新数据后更新数据库和界面。代码上可以把两个数据源拼成一条Observable，下游只用订阅一次。这样可以减少Activity或Fragment中的状态判断。
Observable<List<Goods>> cache = goodsDao.queryGoods().toObservable();
Observable<List<Goods>> remote = goodsApi.fetchGoods()
.doOnNext(list -> goodsDao.insertAll(list));
Observable.concat(cache, remote)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(list -> {
goodsAdapter.show(list);
});
上述代码中，concat会先订阅数据库，数据库查询完成后发射缓存列表，再订阅远程接口。如果远程接口较慢，用户至少可以在缓存返回时看到内容。doOnNext用来在远程数据到达时写入数据库，不改变主数据流。这样缓存逻辑就被拆分成可复用的数据源。
如果希望缓存和网络同时请求，谁先返回谁先展示，可以换成merge，但要注意线程切换和重复数据。合并多个接口也可以使用zip，它会把多个数据源最后一次发射的数据按函数组合，适合同时请求首页多个模块的情况。
定时轮询与生命周期管理
部分业务需要定时刷新，例如消息通知、行情数据或者订单状态轮询。RxJava的interval操作符可以每隔固定时间发射一个递增数字，配合switchMap或者flatMap触发远程请求。相比Handler的postDelayed或者Timer，interval生成的流可以更容易地和生命周期绑定，统一取消。
Observable.interval(0, 5, TimeUnit.SECONDS)
.flatMap(tick -> orderApi.queryOrderStatus(orderId))
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(status -> {
if (status.isFinished()) {
compositeDisposable.clear();
} else {
statusView.update(status);
}
});
生命周期管理是Android中使用RxJava必须面对的问题。如果Activity销毁后订阅仍然存在，订阅者可能持有Activity引用，造成内存泄漏。通常用CompositeDisposable管理多个Disposable，在onDestroy中调用clear或dispose方法，把所有订阅一次性解除。
对于需要观察生命周期状态的场景，可以使用RxLifecycle或者AutoDispose。这些库能自动在合适的生命周期节点结束订阅。自研封装也可以监听LifecycleOwner状态，在ON_DESTROY时调用dispose。但核心原则不变：不要忘记取消订阅，尤其是网络、数据库这类可能长时间执行的流。
RxJava在Android中的使用场景远不止这些，例如权限请求、广播事件、事件总线替代、防连点等。掌握网络线程切换、输入防抖、数据流组合和生命周期管理这几个基本姿势后，再逐步引入背压、Flowable和更复杂的操作符，会让代码更具可维护性。