鸿蒙性能调优 25 问：状态粒度、LazyForEach 与工具链

鸿蒙性能调优面试与技术文章的差异在于：面试官要的是「指标 → 工具 → 手段 → 验证」的完整闭环。这份 25 问按启动、状态与渲染、列表与滑动、内存与功耗、工具链五个板块组织，答案都控制在「面试口述 30 秒」的长度。

一、启动性能（5 问）

1. 鸿蒙应用启动流程分几段？

应用冷启动：进程创建 → AbilityStage 启动 → UIAbility onCreate → 首帧渲染 → 页面可交互。优化窗口主要在 onCreate 之前的初始化与首屏布局。

2. onCreate 里最适合做什么、最不该做什么？

只做：路由参数解析、首屏必需数据准备。不做：非首屏 SDK 初始化（挪到首帧后异步）、同步 IO、大对象解析。用启动任务编排（TaskPool + 依赖图）管理。

3. 启动耗时怎么测？

Profiler 的 Launch 模板给分段耗时；线上用 HiLog 打点（进程创建 → 首帧完成）上报 p75。两套数据对齐看，实验室定位、线上验收。

4. 首屏加载慢的通用组合拳？

首屏数据预取（AbilityStage 阶段发请求）+ 布局精简（层级浅、懒加载非首屏组件）+ 缓存快照先渲染 + 骨架屏兜底。

5. HSP/HAR 对启动有什么影响？

共享包越大加载越重，非首屏能力的 HAR 拆出去按需加载；动态 HSP 可延迟加载。答题要点：模块化本身就是启动优化的一部分。

二、状态管理与渲染（6 问）

6. 状态更新粒度怎么优化？

状态拆到最小必要粒度：列表项数据各自管理，避免大数组整体 @State；依赖该状态的组件越少越好。回答时给出「大对象 → 拆子组件」的对照例子。

7. @State、@Prop、@Link、@ObjectLink 怎么选？

@Prop 值拷贝（适合简单值，大对象开销大）；@Link 双向同步；@ObjectLink + @Observed 引用传递（大对象/嵌套对象首选）。选型错误是渲染性能问题的头号来源。

8. build 里写重逻辑为什么是反模式？

build 每次状态变更都会执行，任何重活（格式化/解析/过滤）都会被放大执行。对策：预计算、TaskPool 异步、缓存结果。

9. 什么情况用 @Watch？要注意什么？

状态变化的旁路监听（联动更新）。注意：回调里再改状态可能触发循环更新，要有终止条件；高频变化的状态不适合 @Watch 逐次响应，应节流。

10. 组件复用（@Reusable）的原理与适用场景？

滑出屏幕的组件实例回收进复用池，滑入时复用并更新数据，省创建销毁开销。适合结构同构的长列表项；结构差异大的组件复用收益低。

11. 一次性大变更怎么减少渲染压力？

批量更新合并（一次事务里改多个状态，框架自动批处理）、避免连环 @Watch 级联、用 @Computed 派生值代替手动同步多份状态。

三、列表与滑动（5 问）

12. LazyForEach 的三个必要条件？

必须配合数据源类（实现 IDataSource 通知机制）、键值生成函数稳定唯一、在 List/Grid/Swiper 容器内使用。普通 ForEach 是全量创建，列表性能的天花板就在这。

13. cachedCount 怎么设置？

屏外预加载条数：太小（滚动白屏）与太大（创建浪费）都不好，默认值基础上按 item 高度与机型调优，配合流畅度实测。

14. 长列表滚动丢帧的排查顺序？

先确认 LazyForEach + 复用生效 → 看 item 绑定逻辑（有没有 IO/解析）→ 图片解码是否异步 + 尺寸匹配 → 最后用 Profiler 帧分析看单帧耗时构成。

15. 嵌套滑动（List 里嵌 Grid）怎么优化？

避免深层嵌套（层级每深一层布局开销乘一次）；固定 item 尺寸减少测量；嵌套滚动联动用系统提供的嵌套滚动选项而不是手势自定义。

16. 图片加载的正确姿势？

尺寸匹配显示区域（源头下采样）、异步解码、列表滑动中按需取消不必要加载、合适的内存缓存策略。

四、内存与功耗（4 问）

17. 内存问题的核心指标与工具？

内存水位、GC 频率、泄漏对象增长曲线。工具：DevEco Profiler Memory 模板做时序分析，快照对比找泄漏。

18. 常见内存泄漏场景？

全局单例持有页面级对象、事件订阅未解绑、@Watch 回调闭包持有大对象、native 引用未释放（NAPI 场景）。治理手段同移动端通用：生命周期对齐 + 快照 diff。

19. 功耗优化的关注点？

减少后台活跃：定位/传感器的采集频率按需降级、网络批量合并、动画在不可见时暂停、后台任务用系统调度托管。

20. 高刷屏适配要注意什么？

帧预算从 16.7ms 变 8.3ms，原来「刚好不卡」的代码会现形；按场景申请刷新率（静态页降频省电，滑动时高刷），动画实现走系统属性动画而非定时器。

五、工具链与度量（5 问）

21. DevEco Profiler 的常用模板有哪些？

Launch（启动）、CPU（热点函数）、Memory（水位与泄漏）、Frame（丢帧分析）、Time/HiTrace（跨进程调用链）。答题时按「问题类型 → 模板」对答。

22. 怎么建立性能基线与防回退机制？

核心场景（启动/关键页滑动）定义量化指标 → 每日构建自动化跑真机采集 → 指标进看板，劣化超阈值阻断发版。有这条答案，前面所有优化才是可信的。

23. 真机与模拟器的性能差异怎么处理？

结论一律以真机为准（模拟器渲染管线不同）；用中低端真机建立「性能下限」标准，旗舰机数据只作参考。

24. 状态管理的最佳实践总结成几条？

粒度最小、单向数据流、派生用 @Computed、跨层传值避免逐层 @Link（用 Provide/Consume 或事件总线）、大对象引用传递。能背出并解释，说明有实战。

25. 「页面滑动偶尔卡顿」这种模糊反馈，怎么系统性地查？

先复现定场景（机型/操作路径），Profiler 录帧找丢帧时刻 → 定位那一帧的状态变更与组件重建范围 → 归因到状态粒度/布局层级/IO 三类之一 → 修复后同场景回归对比帧率。展示「可复现 → 可定位 → 可验证」的闭环就是满分答案。