8.1 性能调优与质量保障
8.1 性能调优与质量保障
本节摘要：性能调优的第一原则是"先测量后修改"。本节用 DevEco Profiler 完成一次掉帧定位与修复，梳理启动优化与高频优化点清单；质量侧建立崩溃兜底、边界测试与权限隐私复核的发布前清单。
掉帧之后
从一次真实症状开始：备忘录列表快速滑动时肉眼可见掉帧。修法有两种——凭感觉改（给这个组件加个缓存、把那个图片压小）或者先测量。本节走第二条路。
打开 DevEco Profiler，选帧率与 CPU 两个探针，录制一段快速滑动。报告里两处信息定案：帧率时间线上周期性的长帧凹陷，与凹陷对齐的 CPU 热点——本例里热点集中在自定义列表项组件的 build 函数，其中有一张未做尺寸约束的头图（解码成本高）和一段每次 build 都执行的日期格式化。两个热点，两个修法：
// 修法一：图片约束 + 缓存解码 Image(item.cover) .width(48).height(48) .objectFit(ImageFit.Cover) .interpolation(ImageInterpolation.Medium) // 修法二：格式化结果随数据走，不在 build 里算 interface Note { id: number title: string updatedAt: number updatedText: string // 查询时就格式化好存进来 }
复测：长帧凹陷基本消失，滑动恢复满帧。这个案例的方法论大于结论：Profiler 的价值不是告诉你"哪里慢"，而是把"我觉得慢"变成"这两个函数的这两行贵"——猜测驱动的优化有一半概率修错地方，测量驱动的那一半浪费也省了。
高频优化点清单，按出现频率排：其一，列表项过重——把 3.2 节的懒加载纪律执行到位，列表项内部组件数控制住，图片必给尺寸；其二，build 里做昂贵计算——格式化、过滤、排序移到数据层（本例修法二），build 只做展示映射；其三，动画碰布局属性——动画应作用在透明度与变换（transform）上，改宽高会触发整段重新布局，这是"能跑但卡"的经典来源；其四，启动链路里做同步 IO——第 2 章的 onCreate 与 5.1 的 aboutToAppear 里同步读存储会拖慢首帧，重活延后或异步化；其五，状态刷新面过大——第 4.1 节的"高频状态下沉"没做，滑动计数把整个页面拉着重算。
质量保障：发布前的三张清单
性能之外，发布质量集中在三个维度，各自一张清单。
稳定性清单。核心路径异常兜底：第 6 章的请求模块每个 await 都有 catch 吗？数据库模块的事务异常都 rollBack 了吗（第 5 章的纪律）？把应用当成"随时会断网、随时会杀进程"的环境做一轮自测：编辑中途杀进程，重启后草稿在吗（5.1 的落盘时机设计在此验收）；迁移中途断联，本端状态无损吗（7.2 的兜底要求）。边界输入集中过一遍：空列表、超长标题、非法日期、纯符号搜索词——解析层（6.1 的 fromJson）与数据库层（5.2 的类型对准）是重点抽查区。
合规清单。权限逐项复核：requestPermissions 里的每一项都能对答"哪个功能用、何时申请"（第 6.2 节的如实原则，审核会问）；日志全局搜一遍敏感词（token、phone 等字段名），确认没有调试遗留；隐私声明与实际数据行为一致——收集了什么、为什么、存哪、能否删除，声明里写的要和代码里做的一一对得上，不一致是审核打回的高发项。
体验清单。三入口各过一遍（预览器、模拟器、真机，第 1 章的表）；深浅色两套主题下检查对比度；断网弱网下的错误提示是否人话（"Network 错误"不是给人看的）；多设备形态下（3.2 的断点）布局是否如预期换形态。DevEco Studio 生态里的自动化测试框架可以覆盖单元层与 UI 层，小团队至少把数据访问模块（第 5 章）与请求模块（第 6 章）的单元测试补上——这两个模块纯逻辑、无界面依赖，测试性价比最高。
⚠️ 常见坑：只在旗舰配置的真机上测性能。低端机的 CPU 与内存水位差异会把"偶尔长帧"放大成"常态卡顿"，调优验收至少覆盖一档低端设备。
💡 关键直觉：性能问题的修法多数不是"更快的代码"，而是"更少的代码被执行"——懒加载是少渲染、缓存是少计算、状态下沉是少刷新。先找"多余的执行"，再谈"高效的实现"。
本节要点回顾：
- 方法论：先测量后修改，Profiler 把感觉翻译成热点。
- 高频优化点：列表项减重、build 免计算、动画避布局属性、启动免同步 IO、刷新面收敛。
- 三张清单：稳定性（兜底与边界）、合规（权限与隐私对齐）、体验（多端多主题弱网）。
- 测试落点：数据与请求两个纯逻辑模块优先补单测。
- 设备梯度：低端机是性能验收的下限。
体检完成、问题出清，剩下的就是把应用包好送出门。下一节走完发布签名与上架的最后流程——第 1 章那个 release 构建失败的老问题，终于要正面解决了。
附：把体检变成机制而不是事件
本节的清单如果只在发布前跑一遍，它的价值只兑现了一成。更划算的做法是把它机制化：三张清单转成团队仓库里的检查单模板，每次提测前自查勾选；Profiler 录制留档，新功能合入时与上一版对比帧率曲线；低端机测试排进每个迭代，而不是想起才测。个人开发者同样适用——给自己定一条"改到列表或状态相关代码就重测滑动帧率"的规则，成本五分钟，拦截的却是发布后最难定位的那类反馈。
再给一个心态提醒：调优有边际收益，满帧之后停手。追逐"再快五毫秒"的时间，往往更该花在崩溃兜底或权限文案这些用户可感知的维度上。性能工作的目标是"不成为问题"，而不是"成为亮点"——认清这一点，你就不会在发布前夜还陷在 Profiler 里出不来。
最后留一个综合演练，作为本章的动手收口：给应用做一次完整的"发布体检"——用低端机或模拟器的性能档跑一遍启动与主流程并录制 Profiler；按三张清单逐项勾选并把发现的问题分类（当班修的、记录待办的、可接受的）；把结果写成一页体检报告存进仓库。这份报告在 8.2 提审前会被再次打开，对比两版差异还能看到自己的进步——教程的最后两节因此有了可交付的实物，而不只是读过的文字。