应用发热问题排查指南

Excelsior_abit
发布于 2024-12-13 11:40
浏览
0收藏

问题背景

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

排查思路

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

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使用参考:​布局分析​。

应用发热问题排查指南-鸿蒙开发者社区

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

分类
收藏
回复
举报
回复
    相关推荐