HarmonyOS 鸿蒙Next应用发热问题排查指南

问题背景

在应用使用过程中，出现设备发热的情况

排查思路

发热问题主要是排查整机的功耗情况，对于应用侧来说，主要是排查的方向有：

1、CPU上的负载是否符合预期；

2、内存是否合理使用导致频繁GC；

3、页面是否存在冗余绘制的情况。

排查步骤如下：

1、关闭USB充电模式，通过DevEco Profiler实时监控温度和功耗，明确发热问题的具体场景以及功耗来源。

2、通过Frame Profiler录制对应场景，分析CPU频点及负载情况：

a. 如果是CPU核上存在GC线程负载较高，需要通过Allocation和Snapshot模板来分析内存使用情况。

b. 如果是CPU核上存在应用侧子线程负载较高，借助Callstack泳道分析函数栈，排查业务逻辑是否存在异常。一般频繁执行了长耗时任务，或者进入异常业务逻辑导致无限循环。

c. 如果是CPU核上UI主线程负载较高，通过Trace泳道分析是否存冗余绘制及组件未复用等情况。

排查流程图如下：

1、确认功耗来源

避免充电对观察功耗的影响，在分析问题期间，可以通过设置 -> 系统 -> 开发者选项 -> 关闭充电设置关闭USB充电选项。使用Profiler实时监控能力观察设备温度变化，以及各器件的功耗数据，确定发热场景和功耗来源。具体使用可以参考：实时监控

Temperature：显示了当前设备温度信息，3秒一个采集周期，如果温度持续上升，说明已确认发热场景。

Device Current：当前设备最大电流、平均电流以及最新的电流值（如果出现负数，说明是在充电）。

Energy泳道：展示各项部件（主要关注CPU、Display、GPU）的周期内平均功耗占比。

2、使用Frame Profiler分析CPU负载

开启Frame Profiler采集后，复现问题场景，在CPU Core泳道中观察运行时长占比比较高的线程。具体使用可以参考：CPU活动分析

如果是应用侧线程负载较高，使用Callstack分析对应线程在执行的任务，结合函数栈分析业务逻辑是否存在异常，一般频繁执行了长耗时任务，或者业务逻辑导致无限循环。具体使用可以参考：基础耗时分析

案例一：应用侧某线程负载高

采集完Trace后，观察CPU核的频点很高，CPU调度很频繁，框选CPU Core泳道后，查看CPU负载来源。

通过详情区，可以看到CPU的负载主要来源应用侧子线程，通过排查，该线程和页面绑定，在页面切换时未释放。

案例二：应用侧业务线程负载高

采集完Trace后，观察CPU部分核上频点很高，基本在最高频运行，框选对应泳道后，查看CPU负载来源。

通过详情区，可以看到CPU的负载来源，应用侧业务线程负载很高，通过排查，发现是在弱网环境下，在该线程中频繁请求网络。

案例三：GC线程负载高

采集完Trace后，观察CPU部分核上频点很高，基本在最高频运行，框选对应泳道后，查看CPU负载来源。

通过详情区，可以看到CPU的负载来源，应用进程下的OS_GC_Thread线程负载很高，需要借助Allocation和Snapshot模板分析内存使用情况。GC策略可以参考：GC垃圾回收，Allocation使用可以参考：内存分析及优化

案例四：UI主线程负载高

采集完Trace后，观察CPU部分核上频点很高，基本在最高频运行，框选对应泳道后，查看CPU负载来源。

通过详情区，可以看到CPU的负载来源是UI主线程

找到对应线程的Trace泳道，里面也包含了线程运行状态，可以在详情区看到Running占比非常高

发现有个Image组件一直再执行绘制任务，后续借助ArkUI Inspector排查到是不可见的区域有个图片一直绘制。ArkUI Inspector使用参考：布局分析

关于低功耗可以参考官网的最佳实践