文章目录前言性能问题有哪些Profiler 工具介绍案例 1列表滚动卡顿案例 2页面切换白屏案例 3内存泄漏性能优化清单写在最后前言HarmonyOS7 的 DevEco Studio 内置了Profiler性能分析工具能帮你抓 CPU、内存、渲染等维度的数据。说实话以前我调性能全靠猜——觉得哪里慢就改哪里经常改了半天没效果。有了 Profiler终于不用瞎猜了。性能问题的本质就是代码在干不该干的事或者该干的事干得太慢。Profiler 帮你找到到底是谁在浪费时间。性能问题有哪些移动端性能问题翻来覆去就那几类问题类型表现用户感知渲染卡顿滑动掉帧、动画不流畅“这 App 好卡”启动慢冷启动超过 2 秒“怎么还在转圈”页面白屏切换页面长时间空白“是不是崩了”内存泄漏越用越卡最终闪退“用着用着就崩了”耗电快后台持续占用 CPU“手机烫死了”这篇文章重点聊前三个每个都有完整案例。Profiler 工具介绍先认识一下 Profiler。在 DevEco Studio 底部工具栏点击Profiler图标或者菜单 View → Tool Windows → Profiler选择设备后就能开始采集数据。Profiler 的核心面板面板功能用途CPU记录函数调用耗时找到最耗时的函数Memory监控内存分配和回收发现内存泄漏FPS实时帧率监控定位掉帧时刻Graphics渲染流水线分析看布局和绘制哪个慢使用流程选择设备和进程选择要监控的维度CPU / Memory / FPS点击 Record 开始采集操作 App 复现问题点击 Stop 停止采集分析数据定位问题划重点采集数据时一定要复现问题场景。无目的的采集只会给你一堆看不懂的数据。案例 1列表滚动卡顿现象商品列表往下滑的时候明显一顿一顿的FPS 从 60 掉到 30。定位过程用 Profiler 的 FPS 面板我发现每次掉帧都伴随着一个buildItem函数的调用高峰。切换到 CPU 面板一看罪魁祸首找到了——ForEach 在每次滑动时都在重新创建所有 item 组件。问题代码Componentstruct ProductList{Stateproducts:Product[][]build(){List(){ForEach(this.products,(item:Product){ListItem(){ProductCard({product:item})// 每次都重新创建}})}}}ForEach 没有指定键值生成器导致框架无法判断哪些 item 是新增的、哪些是已有的。结果一有变化所有 item 全部重建。修复方案——加上键值生成器ForEach(this.products,(item:Product){ListItem(){ProductCard({product:item})}},(item:Product)item.id.toString()// 用唯一 id 作为 key)加上第三个参数后ForEach 就能通过 key 识别哪些 item 没变只创建和更新真正变化的部分。FPS 稳稳回到 60。这个坑太经典了。ForEach 不加 key性能直接拉胯。养成习惯ForEach 必须写第三个参数。案例 2页面切换白屏现象从列表页进入详情页时白屏持续将近 1 秒用户以为 App 挂了。定位过程用 Profiler 的 CPU 面板抓了一次页面跳转过程。发现aboutToAppear里的网络请求是同步等待的——页面要等请求回来才开始渲染。问题代码Componentstruct DetailPage{StatedetailData:DetailData|nullnullasyncaboutToAppear(){// 页面要等这个请求完成才开始渲染this.detailDataawaitrequestDetailData(this.id)}build(){if(this.detailData){// 详情内容}else{// 空白加载中...}}}aboutToAppear里 await 网络请求页面就一直停在空白状态等数据。网络慢的时候白屏时间就更长。修复方案——先渲染骨架数据到了再更新Componentstruct DetailPage{StatedetailData:DetailData|nullnullaboutToAppear(){// 不 await让页面先渲染出来requestDetailData(this.id).then(data{this.detailDatadata})}build(){Column(){if(this.detailData){DetailContent({data:this.detailData})}else{SkeletonScreen()// 骨架屏用户至少看到东西了}}}}把 await 去掉改成.then()让页面先渲染骨架屏数据回来后自动更新。白屏时间从 1 秒降到几乎无感知。案例 3内存泄漏现象App 用了十几分钟后越来越卡最终直接闪退。定位过程用 Profiler 的 Memory 面板我发现一个PageRouter对象的引用数一直在增长每次切换页面都多一个但从没减少。切了 20 次页面内存涨了 80MBGC 根本回收不掉。翻代码一查是一个全局的事件监听器持有页面的引用问题代码Componentstruct ChatPage{aboutToAppear(){// 注册了监听但从不取消eventEmitter.on(newMessage,this.onNewMessage)}onNewMessage(msg:Message){this.messages.push(msg)}}页面退出后eventEmitter还持有this.onNewMessage的引用而onNewMessage又通过闭包持有整个组件的this。GC 看到还有引用在就不回收。页面切来切去泄漏就越积越多。修复方案——页面销毁时取消监听Componentstruct ChatPage{aboutToAppear(){eventEmitter.on(newMessage,this.onNewMessage)}aboutToDisappear(){// 页面销毁时必须取消监听eventEmitter.off(newMessage,this.onNewMessage)}onNewMessage(msg:Message){this.messages.push(msg)}}加上aboutToDisappear里取消监听泄漏问题解决。内存使用恢复正常连续使用 30 分钟也没再闪退。内存泄漏是温水煮青蛙型的问题短时间看不出来长时间必崩。养成习惯有 on 就有 off有 add 就有 remove。性能优化清单根据这三个案例我整理了一份日常优化清单ForEach 必须指定 key 生成器aboutToAppear里不要 await 长耗时操作页面切换用骨架屏替代白屏aboutToDisappear里必须清理监听器和定时器列表 item 布局尽量扁平减少嵌套层级大图用异步加载不要阻塞主线程用 Profiler 定期做性能巡检不要等问题大了再查写在最后性能优化最忌讳的就是凭感觉改。你觉得慢的地方可能根本不是瓶颈真正的罪魁祸首藏在你看不到的地方。Profiler 就是你的 X 光机先看清楚再动刀。我的建议是每次做完功能顺手用 Profiler 跑一遍 FPS 和内存。发现问题当场改比积累到用户投诉再改轻松 10 倍。
