Android发热监控实践

日期：2023-10-24 10:23:27 来源：龙城安卓网

一

背景

相信移动端高度普及的现在，大家或多或少都会存在电量焦虑，拥有过手机发热发烫的糟糕体验。而发热问题是一个长时间、多场景的指标存在，且涉及到端侧应用层、手机 ROM 厂商系统、外界环境等多方面的影响。如何有效衡量发热场景、定位发热现场、以及归因发热问题成为了端侧应用层发热监控的面前的三座大山。本文通过得物 Android 端侧现有的一些监控实践，不深入功耗计算场景无法自拔，优先聚焦于发热场景本身，希望能给大家一些参考。

二

发热定义

温度是最直观能反映发热问题的指标，当前 Android 侧，我们以体感温度 37° 以上作为分界线，向上每 3° 作为一个发热温度区间，区间细分上限温度 49° ，即划分出 37-40，40-43，43-46，46-49，49+ 五个等级。

以手机温度、CPU 使用率作为第一、第二要素来判断用户是否发热的同时，获取其他参数来支撑发热现场情况。

具体指标如下:

手机温度 CPU 使用率、GPU 使用率；

线程堆栈；

系统服务使用频次；

设备前后台、亮灭屏时长；

电量、充电情况；

热缓解发热等级；

系统机型、版本；

....

三

指标获取

温度

电池温度系统 BatteryManger 已经提供了一系列自带的接口和粘性广播获取电池信息。BatteryManager.EXTRA_TEMPERATURE 广播，获取的温度值是摄氏度为单位的 10 倍数值。//获取电池温度BatteryManager.EXTRA_TEMPERATURE，华氏温度需要除以10

fun getBatteryTempImmediately(context: Context): Float {

return try {

val batIntent = getBatteryStickyIntent(context) ?: return 0f

batIntent.getIntExtra(BatteryManager.EXTRA_TEMPERATURE, 0) / 10F

} catch (e: Exception) {

0f

}

}

private fun getBatteryStickyIntent(context: Context): Intent? {

return try {

context.registerReceiver(null, IntentFilter(Intent.ACTION_BATTERY_CHANGED))

} catch (e: Exception) {

null

}

}

BatteryManager 除支持电池温度的系统广播外，也包含电量、充电状态等额外信息的读取，均定义在其源码中。

四

监控方案

了解核心指标数据是如何获取的前提下，其实监控方案的核心思路无非就是通过远端 APM 配置中心下发的采样阈值、采样周期、各模块数据开关等限定采样配置，子线程 Handler 定时发消息，采集各个模块的数据进行组装，在合适的时机进行数据上报即可，具体的数据拆解、分析工作则由发热平台进一步处理。

模块整体架构

上报时机

核心采集流程

线上线下区分

由于所有子线程的 CPU 采集、堆栈采集实际上是会对性能有折损的，200+ 的线程的读取耗时整体在 200ms 左右，采样子线程的 CPU 使用率在 10%，考虑到线上用户体验问题，并不能全量开启高频率采样。

故整体方案来说: 线下场景以重点侧重发现、排查、治理全量问题，上报全量日志，以 CPU、GPU 使用率为第一衡量指标；

线上场景以重点侧重观察整体发热大盘趋势、分析潜在问题场景，上报核心日志，以电池温度为第一衡量指标。

发热平台

在平台侧同学的支持下，发热现场数据经过平台侧进行消费，将核心的发热堆栈经过 Android 堆栈反混淆服务进行聚合，补齐充电状态、主线程 CPU 使用率、问题类型、电池温度等基础字段，平台侧就具备发现、分析、解决的流程化监控推进的能力。

具体的堆栈信息 & 发热信息平台展示如下:

由于电池温度、CPU 使用率是针对运行时发热场景最直观的指标，且我们一期重点关注发热场景的治理，不针对元器件 Hook 等耗电场景进行持续深入分析，故当前得物侧是以电池温度、CPU 使用率为第一第二指标建立核心的发热问题四象限，优先关注高温、高 CPU 的问题场景。

在数据分析过程中，我们遇到了数据上的效率排查效率不够高、问题精度不够准的情况。

如何定位是高温场景是发生在 App 内部，且在使用过程中明显上升的？通过过滤从启动开始即高温、后台切换回来即高温的场景，重点关注在 App 内部温度上升的场景。线上的采样后仍旧单日有 6w+ 数据的上报，我们如何筛选出更为核心的数据？当前的做法是定义了温度跨度的概念，优先看在 App 内部温度跨度较大的 Case。线程存在调用 Wait 等方法阻塞的堆栈，消耗内核态的时间分配，但实际不消耗整体 CPU 的误报数据。补充了线程的运行状态和 Proc 文件中记录的 State，方便优先处理 RUNNABLE线程的 CPU 高温高占用问题。手机温度上升作为渐进式的场景，如何实现温度上升场景下的页面精确归因？增加温度采样频率的同时，汇总 CPU 使用率和实时堆栈等瞬时数据作为数据支撑，但考虑到数据体量的情况，数据上报聚合裁剪方式仍在逐步探索更为合理的方式，力求在两者之间找到一个平衡点。 Android发热监控实践