React Native Firebase 在 Android 上并发获取文档的性能问题解析与优化

在 React Native 应用开发中，使用 React Native Firebase 进行 Firestore 数据操作是常见场景。然而，许多开发者在 Android 平台上会遇到一个特殊的性能问题：当并发获取多个文档时，每个请求的执行时间会呈现递增趋势。本文将深入分析这一现象的原因，并提供有效的解决方案。

问题现象

开发者通常会使用 Promise.all 来并发获取多个文档：

await Promise.all(
  documentIds.map(id => getDoc(doc(myCollection, id)))

在 iOS 平台上，这种写法能够实现真正的并发请求，所有文档几乎同时获取完成。但在 Android 平台上，我们会观察到每个 getDoc 请求的执行时间逐渐增加，整体耗时远高于预期。

底层机制分析

这个问题的根源在于 React Native Firebase 在 Android 平台的线程管理机制。默认情况下，所有 Firestore 请求共享一个工作线程，导致并发请求实际上被序列化执行：

1. 虽然 JavaScript 层面是并发调用 getDoc
2. 但在 Native 层，这些请求被分配到同一个工作线程队列
3. 每个请求必须等待前一个请求完成后才能开始执行
4. 因此形成了请求时间的累积效应

这种设计在简单场景下没有问题，但在需要高并发操作的场景下就会成为性能瓶颈。

解决方案

React Native Firebase 提供了配置项来调整线程池大小。我们需要在项目根目录下创建 firebase.json 文件，并设置 android_task_executor_maximum_pool_size 参数：

{
  "react-native": {
    "android_task_executor_maximum_pool_size": 30
  }
}

这个配置的作用是：

1. 设置线程池的最大线程数
2. 当并发请求数不超过设定值时，所有请求都能获得独立线程
3. 超过设定值的请求才会进入队列等待
4. 30 是一个经验值，可根据实际需求调整

实现原理

这个配置改变了 React Native Firebase 在 Android 平台的任务执行方式：

1. 默认情况下使用单线程执行器（SingleThreadExecutor）
2. 配置后改为使用线程池执行器（ThreadPoolExecutor）
3. 每个 getDoc 请求可以分配到不同的线程
4. 真正实现了请求的并行处理

最佳实践建议

1. 根据应用实际并发需求设置合理的线程池大小
2. 避免设置过大值导致线程资源浪费
3. 在性能关键路径上考虑分批处理大量请求
4. 修改配置后需要重新构建应用才能生效
5. 建议在开发阶段进行性能测试以确定最优参数

总结

React Native Firebase 在 Android 平台的这一默认行为是为了平衡资源消耗和一般使用场景。通过理解其底层机制并合理配置线程池，开发者可以显著提升 Firestore 并发操作的性能，特别是在需要批量获取数据的场景下。这种优化对于数据密集型应用的用户体验改善尤为重要。