Android Room内部Flow类型、底层实现及代码执行逻辑问询

1. Android Room内部使用的Flow属于冷流还是热流？ #

Room返回的Flow属于冷流。核心特征是：只有当存在订阅者（调用collect）时才会触发数据库查询，且每个新订阅都会重新执行一次完整的查询流程。

2. 使用Room查询返回Flow，无收集器时不发起请求，订阅后插入新数据会更新Flow，它属于冷流还是热流？底层实现是怎样的？ #

这依然是冷流，只是它是带有可观察查询能力的特殊冷流。
底层实现逻辑：

• Room在编译阶段会为DAO中的Flow查询生成对应实现代码。当订阅者开始收集时，Room会立即执行SQL查询并发射结果，同时为目标数据库表注册一个ContentObserver。
• 当表中发生插入、更新或删除操作时，ContentObserver会收到通知，Room会重新执行查询，将最新结果发射给当前订阅者。
• 一旦订阅者取消收集，Room会移除ContentObserver监听，后续的数据变化不会再触发查询更新。
  每个订阅者都会独立拥有一套监听和查询流程，完全符合冷流“每个订阅对应一个新的流实例”的核心定义。

3. 以下Kotlin代码的逻辑是顺序执行还是并发执行？ #

query().buffer().filter {
    api.makeLongFilteringRequest(it)
}.collect {
    ui.show(it)
}

这段代码是顺序执行的，和冷热流的并发特性无关，关键在于操作符的行为：

• query()返回的Room冷流，每次收集触发一次查询并发射数据项。
• buffer()会缓存上游发射的数据，但filter中的api.makeLongFilteringRequest(it)是同步执行的——这个耗时请求会阻塞当前流的执行，必须等请求完成后才会判断是否通过过滤，再把数据传给下游的collect。
• 整体流程是：上游发射一个数据 → 执行耗时请求 → 过滤判断 → 下游UI展示 → 再处理下一个数据，全程顺序执行。如果需要并发处理，得配合flowOn(Dispatchers.IO)将耗时操作切到IO线程，再结合flatMapMerge这类并发操作符实现。

内容的提问来源于stack exchange，提问作者Leha Bodunov