Firebase Performance中_app_start测量逻辑及相关日志、埋点疑问
Firebase性能监控_app_start追踪相关疑问解答
问题背景
根据Firebase官方文档,_app_start的测量规则为:
- 在应用的FirebasePerfProvider ContentProvider的onCreate方法执行完成时开始;
- 在第一个Activity的onResume()方法被调用时结束。
我的应用包含两个Activity:
- LoginActivity(启动页)
- MainActivity
在LoginActivity的onCreate方法中,我会检查用户是否已登录,若已登录则打开MainActivity。原本预期_app_start的测量会在LoginActivity的onResume调用时结束(因为它是第一个Activity),但在已登录用户启动应用的场景下,日志内容存在困惑:

第一条日志显示LoginActivity的渲染耗时为620ms,但_experiment_app_start_ttid记录的耗时为1988ms。
补充信息:我在MainActivity中手动记录了Firebase Analytics的app_start事件。
疑问
- 为何Displayed日志的620ms与
_experiment_app_start_ttid的1988ms数值不同?该追踪是否与_app_start完全不同? - 如何记录
_app_start追踪的数值? - 在MainActivity中手动记录app_start分析事件是否会影响
_app_start追踪的测量(比如是否会在MainActivity的onResume后才结束测量)?
解答
1. 数值差异与追踪的区别
- Displayed日志的620ms:这是Android系统记录的Activity首次绘制完成的耗时,计算起点是进程创建,终点是Activity第一帧渲染完成,仅聚焦LoginActivity的UI渲染环节,不包含后续页面跳转的耗时。
_experiment_app_start_ttid的1988ms:这是Firebase内部的实验性追踪指标,和官方定义的_app_start不是同一概念。在已登录场景下,LoginActivity启动后立即跳转MainActivity,这个指标可能覆盖了从进程启动到MainActivity完成初始化的全流程,包含页面跳转、MainActivity启动和初始化的耗时,因此数值远大于Displayed日志的耗时。
2. 记录_app_start追踪数值的方法
有两种方式可以获取_app_start的数值:
- Firebase控制台查看:打开Firebase性能监控面板,在「应用启动」模块可直接查看
_app_start的统计数据,包括分位数、平均耗时等。 - 本地日志或代码监听:
- 开启Firebase性能监控调试日志,通过Logcat过滤
FirebasePerformance标签,可找到_app_start的耗时记录。 - 实现
PerformanceMetricsListener接口监听指标,在回调中捕获_app_start数据。示例代码:FirebasePerformance.getInstance().addPerformanceMetricsListener { metric -> if (metric.name == "_app_start") { val duration = metric.getDouble(FirebasePerformance.Metric.DURATION) Log.d("AppStartTrace", "_app_start耗时:${duration}ms") // 可将数据存入本地或上报自定义服务 } }
- 开启Firebase性能监控调试日志,通过Logcat过滤
3. 手动记录Analytics的app_start事件对_app_start追踪的影响
不会影响。Firebase性能监控的_app_start追踪与Firebase Analytics的app_start事件是完全独立的模块:
_app_start的测量严格遵循官方规则,终点是第一个启动的Activity(即LoginActivity)的onResume调用完成,即使LoginActivity启动后立即跳转MainActivity,也不会改变计时终点。- 在MainActivity手动记录的Analytics app_start事件,仅属于Analytics模块的事件上报逻辑,与性能监控的
_app_start追踪计时无关联,不会干扰其测量过程。
内容的提问来源于stack exchange,提问作者positron
相关产品推荐
相关产品推荐

