性能监控 — 概念、指标与数据采集

什么是性能监控

性能监控是通过收集执行时间、内存使用、帧率和能耗指标来定量评估应用程序行为的实践。与仅记录致命故障的崩溃报告不同，性能监控跟踪渐进式退化：应用程序在运行，但比应有速度慢。

根据Google（2024）的数据，53%的用户会在应用加载超过3秒时关闭它。每增加一秒的延迟，各品类的转化率平均下降20%。这使得性能监控不仅仅是技术实践，更是移动产品的业务必要性。

现代性能监控涵盖四个层面：客户端（iOS、Android）、网络（API请求、WebSocket）、后端服务和基础设施。在移动开发中，重点放在客户端指标上，因为大多数性能问题恰恰出现在用户设备上。

移动应用的关键指标

为了全面监控，需要跟踪五组指标，每组指标负责用户体验的一个方面。FPS（每秒帧数）显示动画和滚动的流畅度——低于30帧每秒的值会被感知为卡顿。

时间指标

应用冷启动时间——从点击图标到界面完全就绪的时间。热启动时间——从后台返回的时间。用户操作的响应时间（点击到响应）。Android的启动时间通过ActivityManager测量，iOS则通过dyld和premain时间测量。根据Firebase Performance的数据，前100名应用的冷启动中位时间为1.8秒。

内存和CPU指标

内存消耗不应超过设备可用容量的80%，否则系统会开始从后台卸载应用。内存占用通过Xcode Instruments（iOS）和Android Profiler跟踪。内存泄漏通过重复操作（例如在屏幕之间切换）时消耗的增加来检测。

网络指标

HTTP请求的执行时间、响应大小、超时和错误频率。网络延迟对于在不稳定连接条件下运行的移动应用尤其关键（3G、地铁、电梯、漫游）。建议跟踪p95响应时间——它恰恰显示了网络条件最差的“最重”用户的体验。

Real User Monitoring与Synthetic Monitoring

Real User Monitoring（RUM）在生产环境中从真实用户设备收集数据。该方法显示用户根据其设备、操作系统版本、网络和地理位置实际经历的延迟。RUM提供最准确的性能画像，但取决于哪些用户进入了样本。

Synthetic Monitoring则在受控条件下的测试设备上执行预定义的场景。它可以在问题到达用户之前检测回归，并在相同环境中重现问题。Firebase Test Lab和BrowserStack在真实设备上提供无需手动启动的合成测试。

最佳策略是两种方法的组合：合成测试在CI阶段捕获回归，RUM则提供生产中的真实情况。根据Datadog（2024）的数据，使用两种方法的团队在性能问题变成事件之前多检测到35%的问题。

配置Firebase Performance Monitoring

Firebase Performance Monitoring是Google提供的免费工具，用于在iOS和Android上收集性能指标。它自动测量应用启动时间、HTTP请求和屏幕渲染，无需编写代码。安装只需将SDK添加到项目并在Firebase控制台中激活Performance模块。

自动指标收集

连接SDK后，Firebase Performance会自动为每个HTTP请求通过URLSession（iOS）或OkHttp（Android）创建trace。屏幕渲染针对UIViewController和Activity进行测量，记录从onCreate/viewDidLoad到首次渲染完成的时间。所有指标在Firebase控制台中按应用版本、设备和国家进行汇总。

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // 执行支付
        trace.stop()
    }
}

代码为支付场景创建了一个带有金额属性的自定义trace。通过Firebase控制台中的这个trace，可以查看支付执行时间的中位数和p95，按应用版本和设备分组。

HTTP监控

Firebase自动拦截网络请求，记录URL、响应代码、payload大小和执行时间。对于Android上的OkHttp，自动检测无需额外配置。网络请求在控制台中按端点分组显示，可以快速发现特定API的减慢。

用于业务逻辑的自定义trace

标准指标涵盖总体性能，但诊断业务流程需要对特定场景进行检测。自定义trace允许测量身份验证、新闻源加载、图像处理或数据同步的执行时间。

每个自定义trace应具有“场景-动作”格式的有意义名称，并包含用于过滤的属性。例如，带有“file_size”和“compression_quality”属性的“image-upload” trace将能够发现加载时间对图像大小的依赖关系。建议每个屏幕不要创建超过20个自定义trace——过度的检测会产生噪音并使分析复杂化。

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // 加载图像
    trace?.stop()
}

Swift中的示例为图像加载创建了一个带有文件大小和压缩级别属性的trace。在Firebase控制台中，这些属性成为分组和过滤指标的字段。

触发阈值和告警

没有通知系统的指标收集是无用的。告警应通知团队指标超出允许范围，触发阈值分为三个级别：警告（warning）、临界（critical）和故障（outage）。每个级别决定通知渠道：warning——发送到团队Slack频道，critical——发送到值班工程师的PagerDuty，outage——群发给所有利益相关者。

对于移动指标，建议使用基于百分位数的动态阈值：冷启动p95时间超过4秒——临界告警。静态阈值（例如CPU > 90%）效果较差，因为它们不考虑按时间段和星期几的正常负载波动。Firebase Performance支持通过Firebase Console配置告警，发送到Slack、PagerDuty和电子邮件，并在未确认时进行升级。

根据Incident Management Survey（2024）的数据，基于百分位数而非平均值配置告警的团队会少漏掉45%的事件。平均值（average）平滑了峰值——p95保证显示用户的最差场景，不受时间段和季节性负载波动的影响。