应用发热问题排查指南
问题背景
在应用使用过程中,出现设备发热的情况。
排查思路
发热问题主要是排查整机的功耗情况,对于应用侧来说,主要是排查的方向有:
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使用参考:布局分析。
关于低功耗可以参考官网的最佳实践。