问题背景
在应用使用过程中，出现设备发热的情况
排查思路
发热问题主要是排查整机的功耗情况，对于应用侧来说，主要是排查的方向有：
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活动分析
案例一：应用侧某线程负载高
采集完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使用参考：布局分析
关于低功耗可以参考官网的最佳实践
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。