Firebase Performance Monitoring 是 Google 提供的免费应用性能监控服务，它默认会自动收集应用启动时间、页面渲染、网络请求等指标，但对于数据库操作这种局部代码行为，默认监控是覆盖不到的。很多团队在遇到列表加载缓慢、数据保存卡顿时，往往只能靠打日志来猜测耗时，既不系统也难以长期追踪。通过 Firebase Performance Monitoring 的自定义 Trace 能力，我们可以把每一次数据库读写的耗时作为指标上报到云端，在控制台查看耗时分布、百分位统计和趋势变化，从而真正建立起数据库层面的性能监控体系。
一、监控原理：Trace 和 Metric 的工作机制
Firebase Performance Monitoring 的核心概念是 Trace（跟踪），一个 Trace 代表一段你想测量的代码执行过程，它有明确的开始和结束时间点。在开始和结束之间，你还可以记录自定义指标（Metric），比如本次数据库操作影响的行数、查询返回的记录条数等。Trace 结束后，数据会被暂存在本地，SDK 会在合适的时机批量上传到 Firebase 服务器。
对于数据库监控来说，通常的做法是在每次执行数据库操作前创建一个命名的 Trace，操作完成后调用 stop 方法结束它。Trace 的名称就是控制台里聚合维度的名称，建议用有业务语义的命名方式，比如 db_query_user_list、db_insert_order，这样在控制台上一眼就能分辨出是哪个操作出现了性能劣化。
需要注意一点，Trace 内部的时间统计是毫秒级的，且每个应用同时活跃的 Trace 数量有限制（官方建议不超过一定数量的并发 Trace），所以不要在循环里为每一行数据都创建 Trace，而应该把整批操作放在一个 Trace 里，用 Metric 记录批次大小。
二、在 Android 项目中接入 SDK 并实现数据库耗时监控
接入过程比较简单，首先在项目级 build.gradle 中添加 Google 服务插件，再在应用级 build.gradle 中引入性能监控依赖，并在 app 模块中启用插件：
// 项目级 build.gradle
plugins {
id 'com.google.gms.google-services' version '4.4.0' apply false
}
// 应用级 build.gradle
plugins {
id 'com.google.gms.google-services'
id 'com.google.firebase.firebase-perf'
}
dependencies {
implementation 'com.google.firebase:firebase-perf:20.5.1'
}
SDK 配置好之后，就可以编写一个通用的数据库操作监控工具类。下面这段代码封装了一个 traceDbOperation 方法，接收操作名称和要执行的 lambda 表达式，自动完成 Trace 的创建、指标记录和异常处理：
object DbPerfMonitor {
inline fun <T> traceDbOperation(
name: String,
rowsMetric: Int = 0,
block: () -> T
): T {
val trace = FirebasePerformance.getInstance().newTrace(name)
trace.start()
try {
val result = block()
if (rowsMetric > 0) {
trace.putMetric("affected_rows", rowsMetric.toLong())
}
return result
} catch (e: Exception) {
trace.putMetric("error_count", 1)
throw e
} finally {
trace.stop()
}
}
}
在 Room 数据库的调用处使用这个工具类，就能把查询耗时完整记录下来：
suspend fun loadUsers(): List<User> = withContext(Dispatchers.IO) {
DbPerfMonitor.traceDbOperation("db_query_user_list") {
userDao.getAllUsers()
}
}
如果使用的是 Cloud Firestore，做法类似，把 get 或 addSnapshotListener 的首次回调时间作为 Trace 的结束点即可。对于自动收集的网络请求监控，Firebase 已经覆盖了 OkHttp 层，但 Firestore 的请求走的是自己的通道，默认不在自动监控范围内，所以手动 Trace 是必要的。
三、不同数据库框架的埋点位置选择
埋点位置的选择直接影响数据的准确性。对于 SQLite 原生 API，应该在 SQLiteDatabase.rawQuery 或 execSQL 的外层包裹 Trace；对于 Room，最佳位置是 Repository 层的 suspend 方法中，而不是 DAO 接口内部，因为 Room 的 DAO 是编译期生成的代码，直接改起来不方便，放在调用方更灵活。
如果使用 GreenDAO 或其他 ORM 框架，可以考虑在统一的会话管理类里做 AOP 式的拦截，这样所有数据库操作自动被监控覆盖，避免遗漏。还有一种思路是利用 Kotlin 委托或动态代理，对 DAO 对象做一层包装，所有方法调用前后自动打点，代码侵入性更低。
另外建议为不同类型的操作建立统一的命名规范，例如查询类用 db_query_ 前缀，写入类用 db_write_ 前缀，事务类用 db_txn_ 前缀。控制台支持按名称筛选，规范命名后可以快速对比同类操作的耗时差异，判断是普遍性问题还是个别查询的问题。
四、分析控制台数据并优化慢查询
数据上报后，在 Firebase 控制台的 Performance 面板中找到「自定义跟踪记录」分类，就能看到每个 Trace 的统计信息。控制台提供的是近似百分位分布，重点关注 P50 和 P95 两个数值：P50 反映典型用户的体验，P95 则暴露长尾问题。如果 db_query_user_list 的 P50 是 30ms 而 P95 达到 800ms，说明大部分情况正常，但存在特定条件下的慢查询，比如数据量增长后没有命中索引。
拿到慢查询的数据后，常见的优化方向包括：检查查询字段是否建立了索引；确认是否在主线程执行了数据库操作（这是 Android 上最常见的问题，StrictMode 可以辅助发现）；对大列表查询改用分页加载，Room 的 PagingSource 配合 Paging 3 库是标准方案；写入密集场景下把多次单条插入合并为事务批量提交，SQLite 中批量事务的写入速度可以比逐条写入快一个数量级。
最后提醒两点：一是 Performance Monitoring 免费额度足以支撑绝大多数应用的监控需求，不必担心成本；二是 Trace 数据不是实时的，从上报到控制台可见通常有十几秒到几分钟的延迟，做实时排查时还是要结合本地日志。把 Firebase Performance Monitoring 的数据库埋点纳入日常开发流程后，每次发版都能对比历史趋势，性能劣化在用户大规模反馈之前就能被及时发现。
Firebase Performance Monitoring数据库性能监控Android性能优化修改时间：2026-09-14 13:40:56