应用性能分析：指标、测试和监控

信息技术数字 » 资源 » 应用性能分析：指标、测试和监控

要达到那种质量水平，仅仅“发布前稍作测试”是不够的，它需要多种因素的综合作用。 连续监测（APM 和 RUM）精心设计的性能测试、清晰的指标以及能够模拟从日常使用到极端流量高峰等各种情况的工具至关重要。此外，还必须采取策略性措施：衡量对业务真正重要的指标，并尽可能实现自动化，以避免不断被动应对问题。

应用性能：它的定义、重要性以及我们的衡量标准

当我们谈论应用程序性能时，我们指的是 应用程序的响应速度、稳定性和可扩展性。 当用户数量或数据量增加时，无需担心资源消耗激增或影响用户体验。这适用于 移动应用、网页应用和桌面应用API、微服务或复杂的企业系统。

关键在于系统地测量一系列…… 应用程序性能指标（KPI） 这使我们能够了解应用程序是否达到了技术和业务目标，并在最终用户注意到问题或生产环境中发出警报之前及时检测到问题开始出现的情况。

评估应用程序性能最常用的指标包括：

• CPU使用率：应用程序消耗多少处理器资源，以及是否存在峰值，表明存在过多的计算、设计不良的循环或阻塞响应的进程。
• 内存使用情况内存占用量、内存泄漏、页面错误或超页面现象表明系统花费在移动数据上的时间比执行业务逻辑的时间更多。
• 每分钟请求数和每次请求字节数这显示了应用程序或 API 处理的请求数量以及每个请求处理的数据量。这有助于了解后端扩展能力以及每次调用的数据量是否合理。
• 延迟和响应时间：应用程序响应所需的时间，从用户执行操作或客户端发送请求到收到有效响应为止。
• 正常运行时间和可用性：服务正常运行的时间百分比，通常通过定期 ping 或合成检查进行监控。
• 错误率：以错误（HTTP 4xx/5xx 代码、未处理的异常、功能故障）结束的请求比例。
• Apdex评分和用户满意度：该指数以单个值概括了根据响应时间计算出的满意、容忍或不满用户的百分比。
• 垃圾回收性能（GC）在具有自动内存管理的平台（Java、.NET、Android）上，GC 花费了多少时间，引入了多少暂停，以及这会对 CPU 使用率和流畅性产生怎样的影响。
• 吞吐量或性能：单位时间内处理的交易或请求数量，在高并发系统中至关重要。

追踪这些指标的目的不是为了收集图表：而是为了…… 了解应用程序的实际状态预测瓶颈，优先改进，并用数据证明优化对用户体验和业务成果都有影响。

APM、RUM 和实时性能监控

在现代环境中，随着分布式架构、容器、混合云和微服务的普及，如果没有良好的性能控制，几乎不可能有效控制性能。 应用程序性能监控 (APM) 工具 结合真实用户监控 (RUM) 技术，以及日益先进的可观测性组件。

APM/RUM解决方案（例如Elastic、Instana、Applications Manager、Turbonomic等与APM集成的解决方案）提供 端到端可见性 了解您的应用程序中发生的情况：响应时间、分布式跟踪、数据库查询、外部调用、错误和异常，并与基础设施指标集成。

El 真实用户监控 (RUM) 它捕捉了真实用户所看到的：屏幕加载时间、界面卡顿、浏览器或移动应用错误，以及不同地区和设备上的感知延迟。这与合成基准测试和实验室测试相辅相成，后者固然重要，但无法取代真实世界的数据。

另一方面，现代APM平台提供以下功能：

• 实时监控 关键KPI：可用性、Apdex、错误率、传输速度 资源消耗.
• 分布式追踪 跟踪跨多个微服务、队列、数据库和外部服务的事务，找出最慢的环节。
• 依赖关系图 自动化工具可以显示服务、数据库、队列和前端之间的关系，从而更容易检测出故障的根本原因。
• 代码和线程分析 查找消耗过多 CPU 或阻塞接口线程的方法、SQL 查询或代码段。
• 智能警报和AIOps 结合机器学习和时间序列分析来检测异常情况、减少误报并确定关键事件的优先级。

结合APM、RUM和合成监测结果 360°全方位性能可视性这有助于深入了解用户看到的内容、应用程序内部的运行机制以及底层基础设施的响应方式。这使得 DevOps 和 ITOps 团队能够快速应对突发事件，甚至更好地预防它们的发生。

移动和 Web 应用的关键性能指标

在移动和网页应用中，某些性能指标尤为重要，因为它们直接影响用户感知和产品成功与否。密切监控这些指标，决定着一款应用是能吸引用户，还是在第二次使用后就被卸载。

移动领域的关键点之一是 应用程序启动延迟也就是说，从用户点击图标（或通知）到屏幕上显示有用数据所经过的时间。时间可分为以下几种类型：

• 冷启动该应用程序不在内存中；系统必须创建一个进程，加载代码，初始化库，并显示第一个屏幕。
• 半热启动该过程仍然存在，但该活动被重新创建或恢复到某种状态。
• 热启动您只需重新调整视图或恢复活动，无需额外付出太多努力。

作为参考，强烈建议以……为目标。 冷启动时间低于 500 毫秒 由于 p95 和 p99 延迟（最高百分位数）接近中位数，如果一些用户等待几秒钟，而另一些用户在半秒钟内打开应用程序，则说明某些方面不平衡。

另一个关键方面是 滚动和界面锁定在动态画面（例如信息流、列表、图库）上，用户期望获得流畅的体验。当系统无法以设备的刷新率（60Hz、90Hz 甚至 120Hz）生成帧时，就会出现卡顿和延迟。这种“卡顿”发生在应用程序渲染内容的时间超过一帧的持续时间（例如，在 60 FPS 下超过 16,7 毫秒）时。

除了流利度之外，还需要监测…… 屏幕之间的转换切换标签页、从列表中打开详细信息或显示对话框等操作应几乎是瞬间完成的，动画流畅，不会出现闪烁或长时间的黑屏。

在幕后，电池消耗和能源效率同样重要。 不必要的任务、大量的内存分配和高强度的 CPU 使用 它们会缩短电池续航时间并导致设备过热。Android Runtime (ART) 提高了效率，但如果您的应用内部循环每秒创建数千个新对象，则内存分配和垃圾回收的成本将非常明显。

识别和纠正性能问题的工作流程

为了避免依赖运气，建立一套完善的机制非常有用。 系统化绩效分析工作流程这种方法结合了实验室中详细的手动测试和生产环境中汇总指标的收集。典型的方法包括以下步骤：

首先，我们需要确定 关键用户旅程也就是说，对用户体验和业务影响最大的流程：

• 频繁启动应用程序（图标、通知、深度链接）。
• 屏幕上会持续滚动显示大量数据。
• 视图和活动之间的关键转换。
• 长时间操作流程，例如浏览、音频/视频播放、结账等。

一旦定义完成，它们就会被实施和分析。 分析和追踪工具 例如，可以使用 Perfetto 或 Systrace 来查看设备在微秒级精度下正在做什么，可以使用内存配置文件生成器来检测泄漏和分配热点，或者可以使用 Simpleperf 等工具来找出哪些函数消耗的 CPU 最多。

需要强调的是，对绩效进行详细分析需要 调试单个执行过程 这些路径以受控方式进行复制，从而重现问题。汇总数据分析对于发现模式和回归现象很有价值，但它不能取代对特定轨迹的深入分析。

同时，建议进行配置 持续收集指标 在自动化测试和生产环境中：启动时间、阻塞率、帧指标（例如，通过 Android 上的 FrameMetricsAggregator）、Play 控制台字段指标、滚动宏基准测试等。这些指标使您能够看到设备、操作系统版本和网络条件之间的真实差异。

用于精确测量的应用程序和系统设置

最常见的误区之一是在不切实际的条件下衡量绩效。为了使结果有用，必须…… 配置 APK 和系统 仔细地确保测试环境类似于生产环境，但要控制噪声。

在应用程序方面，这至关重要。 不要对调试版本进行测量。调试版本会添加检查、日志和标志，这些都会显著改变执行时间。在 Android 10 及更高版本中，可以使用该属性。 可分析的 android:shell="true" 在清单中启用发布版本的性能分析，以保持与真实版本接近的行为。

建议也使用 代码缩减 生产环境（例如 ProGuard、R8 等）至关重要，因为代码大小和组织结构会导致明显的性能差异。然而，仔细审查规则至关重要：某些配置可能会忽略重要的监控点，因此需要在测试环境中进行相应的调整。

关于编译，值得将应用程序置于一个已知状态，通常且明确地处于模式。 速度 o 速度曲线两者都能减少从 DeX 解释执行的代码量以及后台 JIT 编译的需求，从而提高结果的稳定性。速度模式力求更接近真实生产环境的行为，但需要预热应用程序并管理配置文件（例如，基线配置文件）。

从系统角度来看，当需要非常高精度的测量（微基准测试）时，通常的做法是…… 校准设备在同一终端和操作系统版本上运行 A/B 基准测试，设置 CPU/GPU 频率，禁用小核心或使用 lockClocks 等脚本进行温度限制等等。这并不能代表真实世界的情况，但它可以减少特定场景下的干扰因素。

对于更贴近用户体验的测量（启动时间、电池消耗、UI崩溃），建议使用 诸如 Macrobenchmark 之类的测试框架它能自动执行许多步骤，避免出现细微但关键的配置错误。

典型的性能问题模式

几乎所有经过深入分析的应用程序中，都会出现某些现象。 反复出现的问题模式 了解这一点很有意义，因为如果及时发现问题，通常会有比较明确的解决方案。

最常见的之一是 由于蹦床活动，开局缓慢当启动意图（图标、通知、深度链接）触发后，会先启动一个不绘制任何帧的中间 Activity，然后再启动“真正的”Activity，此时就会出现这种情况。跟踪信息显示，两次连续的 `activityStart` 事件之间没有任何视觉效果。这种“跳转”会增加启动延迟，却没有任何实际意义。通常的解决方案是将初始化代码重构为一个可重用的组件，或者将其直接集成到主 Activity 中。

另一部经典作品是…… 不必要的内存分配会触发垃圾回收如果 Systrace 或内存分析显示，在长时间运行的操作期间，垃圾回收周期每隔几秒就执行一次，则很可能是代码在密集型循环中反复且持续地分配对象。解决方案并非删除所有新语句，而是解决内存热点问题，在适当的地方重用结构体或应用对象池模式。

它们也经常被发现 图形管线出现卡顿的帧在正常的跟踪中，对 Choreographer.doFrame() 的调用会以固定的频率发生（例如，每 16,7 毫秒一次）。放大这些调用以该频率发生的区域，可以发现开销较大的视图、过于复杂的布局、在 UI 线程上运行的 I/O 操作或配置错误的 RecyclerView。

具体来说，RecyclerView 是诸多问题的根源：例如，当只有少数元素实际发生变化时，却通过 notifyDataSetChanged() 使整个数据集失效；嵌套 RecyclerView 中未正确配置回收视图池；或者执行失败。 数据预取 当列表到达末尾时，这样做就足够了。但所有这些都会导致渲染开销大、滚动时出现跳动，以及用户明显的等待时间。

性能测试：类型、步骤和最佳实践

除了生产监控之外，任何严肃的战略都需要一个完善的计划。 应用程序性能测试 在受控环境下进行。这些测试使我们能够在向用户开放变更或新版本之前，验证容量、稳定性和可扩展性。

测试有好几种类型，每种类型都有其特定的目的：

• 负载测试他们会在预测的用户或交易负载下评估应用程序的行为，测量响应时间、吞吐量和资源消耗，以便在部署前发现瓶颈。
• 压力测试他们将系统推向极限，以测试其承受能力、故障表现和恢复能力。他们对于产能规划和应对类似“黑色星期五”的购物高峰至关重要。
• 耐久性/浸泡测试他们会持续负载数小时或数天，以发现缓慢退化、内存泄漏或资源耗尽等问题。
• 峰值测试他们模拟负载的突然和反复增加（例如，活动、功能发布、直播），以验证应用程序和基础设施能否应对突发变化。
• 容量测试他们分析当用户数量显著增加时应用程序的运行情况。 数据量 （数据库大小、文件、消息），验证响应时间、存储可靠性和数据丢失情况。
• 可扩展性测试他们会检查应用程序在负载逐渐增加时的响应情况，以及水平或垂直扩展是否能带来预期的性能提升。

典型的性能测试过程包括几个不同的阶段。首先， 需求分析了解业务可接受的响应时间、吞吐量比率、可用性水平或错误限制。然后，进入一个阶段…… 规划和策略 它定义了测试的范围、环境、工具以及将要监控的指标。

以下是设计内容 案例分析 测试环境涵盖不同的负载场景、网络条件和数据量，已配置好测试环境（硬件、软件、网络、负载注入和监控工具），并运行测试，仔细收集性能数据。

关键阶段是 监测与分析这包括将响应时间与 CPU 使用率、网络延迟与错误率、流量高峰与数据库过载等进行关联分析。在将调查结果以清晰的报告形式记录下来并提交给利益相关者后，流程将进入下一阶段…… 优化和重新测试调整代码、配置或资源，并重复测试，直到验证改进措施生效为止。

性能测试的工具和框架

要将以上所有内容付诸实践，就必须依靠…… 性能测试工具 具体而言，涵盖开源和商业软件，涉及自动化、负载生成、监控和分析。一些相关类别包括：

• 开源工具诸如 Apache JMeter、Gatling、k6、Locust、Taurus、nGrinder 等项目，以及扩展了性能场景的单元和功能测试框架（JUnit、XCTest、Appium），可以构建功能强大的测试套件，且许可成本低廉。
• 商业负载测试和APM工具WebLOAD、LoadNinja、NeoLoad、LoadView、BlazeMeter、Rational Performance Tester、Silk Performer、Eggplant、CloudTest 或 Parasoft 等解决方案提供集成环境，具有基于云的负载生成、高级报告和专业支持。
• 专业化且可观察的解决方案Applications Manager、Instana、Dynatrace、IBM Turbonomic 等产品，以及 SolarWinds 等网络监控平台，都专注于持续监控、异常检测以及应用程序性能、基础设施和用户体验之间的关联。
• 平台特定工具例如，对于 Android 系统，Perfetto、系统跟踪、Android Studio 内存分析器、Simpleperf、Systrace 或 Play Console 帧指标等工具可以对系统级行为进行非常精细的分析。

在选择其中一种时，建议考虑以下因素： 易用性、对协议和技术的支持、可扩展性、与 CI/CD 的集成许可模式、可扩展性和支持质量（社区支持或商业支持）也是重要的考虑因素。同时使用多种工具也很常见：一种用于负载生成，一种用于应用性能管理 (APM)，另一种用于基础设施可观测性。

简而言之，分析和监控应用程序性能需要结合精心选择的指标、合适的工具和严谨的测试流程，但结果绝对物超所值： 更快、更稳定、更高效的应用程序用户满意度更高，生产事故更少，当然，这对品牌声誉和收入也会产生直接的积极影响。