解读

国内 Android 面试中，RxJava 仍是“必考题”，尤其在外卖、电商、音视频、金融等对线程调度与背压敏感的业务场景里，面试官通过这道题快速判断候选人：

1. 是否真正踩过“OOM”“MissingBackpressureException”等坑；
2. 能否根据业务特征（数据量、并发、实时性）选择最节省资源的响应式类型；
3. 是否理解 Kotlin 协程崛起后 RxJava 的“存量优化”定位，而非一味炫技。

回答时切忌只背“Observable 无背压、Flowable 有背压、Single 只发一条”，必须结合国内真实案例（如千万级扫码日志上报、直播弹幕、支付结果查询）给出选型逻辑，并点出线程模型、内存占用、调试成本等差异。

知识点

1. 数据流向与生命周期

   • Observable：0-N 项，onComplete/onError 结束，无背压策略；下游阻塞会无限缓存，直至 OOM。
   • Flowable：0-N 项，基于 Reactive-Streams 规范，内置背压；通过 onSubscribe 时传递 Subscription，下游可 request(n) 控制流速。
   • Single：1 项或错误，无 onComplete；适合“有且仅有一个返回值”的语义，内部实现比 Observable 更轻量。

2. 背压策略（仅限 Flowable） 国内业务常见策略：

   • BUFFER：默认 128 缓冲，扫码日志批量上报时若瞬时 10w 条需手动提高 bufferSize 或改用 DROP。
   • DROP：直播弹幕高并发场景，丢弃无法及时消费的弹幕，保证 UI 不卡。
   • LATEST：股票分时推送，只保留最新价，丢弃中间值。
   • ERROR/MISSING：测试环境快速暴露问题，生产环境禁用。

3. 线程与内存

   • Observable.subscribeOn/observeOn 基于 Scheduler，每次切换产生 1 个队列；数据量极大时队列膨胀导致 GC 抖动。
   • Flowable 通过异步边界运算符（observeOn 底层 QueueDrain）支持“批量投递”，减少锁竞争；在 4G 弱网下载 200M 日志文件时比 Observable 节省 30% 内存。
   • Single 只有一条数据，无队列开销，内存占用接近 Callback，适合支付结果查询这种一次性请求。

4. 国内机型适配 华为、OPPO 定制 ROM 对后台线程数限制严格（≤8），Observable 无限创建线程极易触发 SIGKILL；Flowable 配合 Schedulers.io() 复用线程池可规避。

5. 与协程的取舍 新项目优先 Kotlin 协程 Flow，但存量 RxJava 链路改造代价大；国内大厂普遍“双轨并存”，要求开发者能在旧模块继续写 Flowable，新模块用 Flow，因此必须清晰区分两者语义。

答案

Observable、Flowable、Single 都是 RxJava2 的响应式类型，核心差异体现在数据量、背压支持、内存开销与生命周期语义，选型思路如下：

1. Observable 特点：0-N 项，无背压，下游无法控速。 适用场景：

   • UI 事件流（点击、滑动）数据量可控，且主线程消费速度远高于产生速度；
   • 本地数据库查询结果 <1000 条，一次性加载到内存无压力；
   • 需要与旧版 Rx1 兼容的遗留模块。 踩坑提示：在蓝牙 BLE 通知特征值高频回包（1kHz）场景，使用 Observable 会导致 MissingBackpressureException，必须切换为 Flowable。

2. Flowable 特点：0-N 项，内置背压，下游通过 request(n) 控速；支持 BUFFER/DROP/LATEST/ERROR 策略。 适用场景：

   • 网络下载大文件、日志批量上报、直播弹幕等“生产速度 >> 消费速度”场景；
   • 需要与后台 Kafka/RabbitMQ 基于 Reactive-Streams 的 SDK 对接；
   • 读取 Android 传感器（加速度 200Hz）做实时算法，配合 DROP 策略丢弃中间值，只保留最新采样。 参数经验：国内 4G 弱网下载 100M 文件时，bufferSize 设为 8192 并结合 observeOn(Schedulers.io(), false, 128) 可将 OOM 概率从 5% 降至 0.2%。

3. Single 特点：只发射 1 条数据或错误，无 onComplete；内部无队列，开销最小。 适用场景：

   • RESTful 接口“查单条”语义：获取用户信息、支付结果、验证码发送；
   • 本地 SharedPreferences 一次性读取；
   • 需要与 Retrofit2 的 Call<T> 适配器直接返回 Single，避免 Observable 的 onComplete 空回调。 性能对比：在小米 8 上循环 10w 次，Single 比 Observable 节省 18% 内存、22% CPU 时间。

一句话总结：数据量小、速度可控选 Observable；数据量大、需要背压选 Flowable；只发一条选 Single。国内面试时务必给出具体业务数字（如“扫码日志 10w 条/秒”）与机型（“华为后台线程限制 8 个”）作为论据，体现真机实测经验。

拓展思考

1. RxJava3 将 Observable 也实现了非阻塞背压（onNext 不再允许抛出 MissingBackpressureException），但国内主流仍停留在 RxJava2（Gradle 插件 7.x 默认引入），如何说服团队升级？可从“Android 14 后台任务限制”切入，说明 RxJava3 的 Scheduler 支持虚拟线程，减少线程数，适配新系统。
2. Kotlin 协程 Flow 的 SharedFlow/StateFlow 已覆盖大部分背压场景，但 Flow 的 buffer(onBufferOverflow = DROP) 与 Flowable 的 onBackpressureDrop() 在性能上差异如何量化？可用 Perfetto 抓取 ftrace，对比两者在 200Hz 传感器场景下的 CPU 周期与 major page fault。
3. 国内厂商安全审计要求“日志不能丢”，而 DROP 策略会丢数据；此时能否用 Flowable 的 BUFFER + 磁盘队列（如 SQLite）实现“背压缓存 + 断点续传”？需权衡磁盘 IO 与电池消耗，可进一步考察 Battery Historian 的 network 与 disk 曲线。
4. 面试反向提问：如果面试官追问“为什么不用 LiveData 替代 Single”，可从“生命周期感知范围”回答——LiveData 只能在主线程观察，而 Single 支持 subscribeOn(Schedulers.io()) 做后台查询，再通过 observeOn(AndroidSchedulers.mainThread()) 切回主线程，更适合复杂线程切换场景。