前 90 篇里，性能话题出现过很多次：第 8 篇讲启动、列表、内存三大战役，第 31 篇讲 Profiler 工具链，第 51 篇讲启动框架编排，第 57 篇讲内存治理，第 73 篇讲性能治理系统。这些单点方案各有价值，但零散的经验很难复用到下一个项目。
这一篇把它们串成一条完整的线：性能优化不是一个技巧的集合，而是一条从「定义指标」到「建立基线」再到「持续治理」的闭环。
一、先定义指标：说不清数字，就谈不上优化
很多团队的性能优化是从"感觉卡"开始的。感觉是最不可靠的输入，因为同样一帧，开发者觉得流畅，用户可能已经投诉了三次。
指标体系通常分两层：
用户可感知指标（面向体验）
技术指标（面向定位）
启动阶段：各 Task 耗时、首帧前主线程执行时长
列表：复用命中率、可见区外组件创建数
内存：PSS 峰值、GC 次数、泄漏对象数
渲染：build/layout/render 各阶段耗时、无效刷新次数
定义指标时有一个容易忽略的点：指标要可采集、可对比。用手工掐表得到的启动时间，和用工具采集的相比，可重复性差很多。推荐的做法是建立自动化性能测试用例，每次发版前跑一遍，拿到可对比的数值。
二、优化地图：不同阶段找不同抓手
按用户访问路径，性能优化可以拆成四个阶段，每个阶段有不同的优先项：
一个常见的误区是跳过前两个阶段直接调内存。实际上，大多数用户可感知的问题出在启动和渲染。内存问题往往在应用长时间运行后才暴露，优先级反而要靠后。
启动优化的一线实践
// app_startup 配置：把初始化拆成有向无环图
{
"app_startup": [
{
"name": "InitCoreKit",
"dependency": []
},
{
"name": "InitDatabase",
"dependency": ["InitCoreKit"]
},
{
"name": "InitTracker",
"dependency": [],
"parallel": true
},
{
"name": "LoadUserConfig",
"dependency": ["InitDatabase"]
}
]
}
编排启动任务的关键是按依赖关系组织，而不是按书写顺序执行。无依赖的任务并行跑，主线程只做最必要的事。
渲染优化的两个核心思路
让状态变窄：
@State越接近使用它的组件越好。页面级状态一改，整棵组件树都要参与 diff。让列表变懒：
LazyForEach只创建可视区组件，配合cachedCount做前后缓冲。再进一步，@Reusable组件复用能减少列表快速滑动时的对象创建。
// 列表组件复用示例
@Component
@Reusable
export struct NewsCard {
@State title: string = '';
@State source: string = '';
aboutToReuse(params: Record<string, Object>): void {
this.title = params.title as string;
this.source = params.source as string;
}
build() {
Column() {
Text(this.title).fontSize(16).fontWeight(FontWeight.Medium)
Text(this.source).fontSize(12).fontColor('#999999')
}
.alignItems(HorizontalAlign.Start)
.padding(12)
}
}
@Reusable 要求组件实现 aboutToReuse 方法，把新数据灌进缓存的组件实例。列表滑动时，离屏的卡片不销毁，而是直接复用，创建开销大幅下降。
三、工具链：DevEco Profiler 全家桶怎么搭配用
工具选对了，定位能快一半。DevEco Studio 的性能工具按场景分工：
工具链的正确打开方式不是逐个试，而是按「先帧率、后 CPU、再内存」的顺序排查：先确认卡顿发生在哪个阶段，再顺着火焰图往下钻。
四、治理闭环：性能不是一次性的
单个版本的性能优化做得再彻底，三个月后可能因为一个新功能退回原点。所以性能要治理，不是修。
治理闭环分五步：
立基线：每个发布版本固化一组性能基线数据。
设阈值：核心指标设红线，比如「冷启动超 2 秒不得发布」。
进流水线：CI 里跑自动化性能用例，不达标直接拦截。
分级响应：线上指标异常自动告警，按影响面分级处理。
复盘沉淀：每个优化案例沉淀成团队知识库，避免重复踩坑。
第 73 篇讲过的性能治理系统，落地时最实用的抓手其实是 CI 拦截。让性能问题在合入前暴露，比上线后靠监控发现再紧急修复，成本低一个量级。
五、实战建议：从这套闭环里挑两件先做
如果你所在的团队性能工作还是"出了问题再查"，不用一口气把整套治理体系建起来。先做两件事：
给核心路径立指标：挑启动耗时和首页帧率两个指标，用工具跑出基线。
把优化手段模板化：把 LazyForEach + @Reusable、AppStartup 编排这些方案沉淀成项目模板，新页面默认继承。
这两件事做完，你就已经比大多数团队前进了一步：不再是"出了问题才想起性能"，而是"每个版本都知道自己处在什么水平"。
小结
性能优化这条线，从指标定义、工具定位、单点优化到持续治理，是一个完整闭环。单点技巧是零件，闭环才是机器。零件再多，没有装配成机器，就发挥不了作用。
下篇进入安全与隐私工程化，把第 63、79 篇的安全话题升级为体系化实践。
参考阅读
DevEco Studio 官方文档：性能优化工具
HarmonyOS 开发者文档：应用性能优化概览
本系列第 51、52、57、73 篇