OPPO 是怎么让 Android 流畅的？流畅性优化三阶段实施方案

这里可以调整气泡内文字大小！滑动试试吧！ ×

12 px

26 px

整个工作将分为用户调研、开发、测试三个阶段推进，每个阶段聚焦核心目标，层层递进保障流畅性体验。

用户调研的核心，是明确用户对流畅性的核心关注点，以及这些关注点对体验的影响程度。首先会开展一轮用户调研，筛选出用户实际关注的流畅性相关场景。

针对这些场景设计评分量表，通过用户评分挖掘场景的实际意义。比如返回桌面场景的 7 分制评分中，1-3 分为满意、4 分为一般、5-7 分为不满意，数据显示超过 500 毫秒用户就会不满意，这类阈值会作为后续工作的核心输入标准，每个调研场景都会对应产出专属阈值。

进入开发阶段后，核心原则是保留已有优化成果，同时严防性能劣化。这一阶段会用到三个核心工具，且工具触发均有明确条件 —— 用户指标方面包括掉帧、持锁大于 8ms、binder 调用耗时等，性能指标则聚焦动画期间的 io 操作、广播注册、find service 等潜在性能问题。

O-StrictMode 工具检测到问题后，会将 backtrace 以蓝屏形式打印；Trace Analyzer 能自动分析 trace 文件，过滤无效 trace 和未抓到时间点的问题，对有效 trace 直接定位根因，减少手动分析成本、提升效率；MTrace 作为轻量型 Trace 增强工具，思路类似 measure instrumention，并非采样方案。

它会在打开后直接读取寄存器上的函数地址和时间戳，通过 TLS 无锁的 RingBuffer 存储，结束后再落盘保存。之所以需要 MTrace，是因为现有工具存在局限：perfetto 功能全面但需预先埋点，cpu profiling 能满足大部分需求但要求 app 有 debug 或 profile 权限，且会强制转换为解释执行导致性能下降，BTrace 虽对 app 友好，但对 Framework 过重、缺少动态性且性能损耗大。

MTrace 与 perfetto 结合后，能补充更详细的调用链信息，比如明确 doFrame 大于 200ms 时的具体运行内容、定位大量布局 layout 导致的耗时，或是像三方输入法周期性卡顿这样的问题 —— 此前仅通过 trace 无法定位根因，结合 MTrace 后发现，每一帧的字符串操作导致内存持续增长，进而触发 GC 造成卡顿，最终锁定系统层 bug。

测试阶段以整机测试为核心，重点强化监控能力，同样依赖三个关键工具。第一个是 Touch Go，这是基于图形框架的 AI 自动化工具，替代了高成本的机械臂点击方案。

下发测试 case 时，手机端会录屏并抓取每一帧数据，传输到 PC 端通过 OpenCV 做图形解析，进而得出帧率变化、流畅性曲线等数据，通过判断帧的开始和结束阈值计算帧时延，能精准获取单场景下的动画时延，但无法覆盖复合场景。

复合场景的长链路性能问题，需依靠 Perf Test 工具解决。它是基于 Trace 的自动化测试工具，通过 SQL 自动分析，能拆解亮屏 - 全搜 - 输入法弹出 - 启动应用这类长链路操作。

工具会先根据 tag 提取对应的 trace 文件并分割，拆解出解锁进桌面、启动应用、返回桌面等子场景，再提取各子场景的用户面指标（如时延）和技术面指标（如 CPU、RAM、IO 使用状况）。

同时会给 trace 标注标签，包括场景信息、抬手位置、点击事件、每一帧的第一帧绘制时间点等，结合进程线程名、深度等 SQL 信息计算耗时，最终将结果以 json 格式保存，还能整合多轮测试数据形成表格，部署在流水线上监控每个版本的指标变化。

最后是 Perf Metric 工具，它基于前两个工具做整体负载分析。在长时间运行测试模型后，会全面拆解过程中的所有用户面和技术面指标，清晰呈现不同版本间的性能整体变化情况，方便及时发现问题并协同研发解决。