Android发热监控实践

一、背景

相信移动端高度普及的现在,大家或多或少都会存在电量焦虑,拥有过手机发热发烫的糟糕体验。而发热问题是一个长时间、多场景的指标存在,且涉及到端侧应用层、手机 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 除支持电池温度的系统广播外,也包含电量、充电状态等额外信息的读取,均定义在其源码中。

以下罗列几个值得关注的:
//BATTERY_PROPERTY_CHARGE_COUNTER 剩余电池容量,单位为微安时
//BATTERY_PROPERTY_CURRENT_NOW 瞬时电池电流,单位为微安
//BATTERY_PROPERTY_CURRENT_AVERAGE 平均电池电流,单位为微安
//BATTERY_PROPERTY_CAPACITY 剩余电池容量,显示为整数百分比
//BATTERY_PROPERTY_ENERGY_COUNTER 剩余能量,单位为纳瓦时
// EXTRA_BATTERY_LOW  是否认为电量低
// EXTRA_HEALTH  电量健康常量的常数
// EXTRA_LEVEL  电量值
// EXTRA_VOLTAGE 电压
// ACTION_CHARGING   进入充电状态
// ACTION_DISCHARGING  进入放电状态
  • 传感器温度

Android是基于Linux 基础上修改的开源操作系统,同样的在手机系统sys/class/thermal/ 目录下存在以 thermal_zoneX 为代表各传感器的温度分区,以及 cooling_deviceX 为代表风扇或散热器等冷却设备。

以一加 9 为例,共存在 105 个温度传感器 or 温度分区,以及 48 个冷却设备。

Android发热监控实践_第1张图片

每个温度分区下记录下具体的参数类型,我们重点关注的是 type 文件和 temp 文件,分别记录了该传感器设备的名称,以及当前的传感器温度。以 thermal_zone29 为例,代表了 CPU 第一核心的 第五处理单元的温度值为 33.2 摄氏度。而对单一设备来说分区对应的名称是固定的,从而我们可以通过读取 thermal_zone 文件的方式来记录当前第一个 type 文件名称包含 CPU 的传感器作为 CPU 温度。

Android发热监控实践_第2张图片

  • 壳温

Android 10 Google 官方推出了热缓解框架,通过 HAL2.0 框架监听底层硬件传感器(主要为 USB 传感器、Skin 传感器)提供 USB、壳温的热信号等级变更监听, 系统 PowerManager 源码提供了对应发热等级变更的回调和发热等级的获取,共 7 个等级,提供给开发者主动或被动获取。

Android发热监控实践_第3张图片

final PowerManager powerManager = (PowerManager) mContext.getSystemService(Context.POWER_SERVICE);
powerManager.addThermalStatusListener(new PowerManager.OnThermalStatusChangedListener() {
    @Override
    public void onThermalStatusChanged(int status) {
       //返回对应的热状态
    }
});

但对于发热等级来说,壳温无疑是最为能够反应手机的发热情况的。可以看到 Android 系统的 API 实际上是提供了 AIDL 接口,可以直接注册 Thermal 变更事件的监听,获取到 Temperature 对象。但由于标识了 Hide API 。常规应用层是无法获取到的,在考虑好 Android 版本兼容性前提下,通过反射代理 ThermalManagerService 方式进行读取。

Android发热监控实践_第4张图片

但事与愿违,国内厂商并没有完全适配官方热缓解框架,热状态回调时常不够准确,而是需要单独接入每个厂商的热缓解 SDK 去直接获取到壳温,具体 API 则以各应用厂商的内部接入文档为准。

CPU 使用率

CPU 使用率的采集通过读取解析 Proc stat 文件的方式进行计算。

在系统 proc/[pid]/stat  和  /proc/[pid]/task/[tid]/stat  分别记录了对应进程 ID、进程 ID 下的线程 ID 的 CPU 信息。具体的字段描述在此不进行赘述,详见:https://man7.org/linux/man-pages/man5/procfs.5.html。

Android发热监控实践_第5张图片

我们重点关注 14.15 位的信息,分别代表进程/线程的用户态运行的时间和内核态运行的时间。

Android发热监控实践_第6张图片

通过解析当前进程的 Stat 文件,以及 Task 目录下所有线程的 Stat 文件,在两次采样周期内(当前设置为 1s)的 utime+stime 之和的差值/采样间隔,即可认为是进线程的 CPU 的使用率。即 进线程 CPU 使用率 = ((utime+stime)-(lastutime+laststime)) / period

GPU使用率

高通芯片的设备,我们可以参考 /sys/class/kgsl/kgsl-3d0/gpubusy 下文件内容,参考高通官网的说明。

GPU 的使用率 = (下图)数值 1 / 数值 2 * 100,经过验证与 SnapDragonProfiler 信息采集获取的数值基本一致。

Android发热监控实践_第7张图片

Android发热监控实践_第8张图片

联发科芯片的设备,我们可以直接通过读取 /d/ged/hal/gpu_utilization 下的使用率数值。

同样的通过指定周期(每秒 1 次)的采样间隔,即可获取到每秒的当前 GPU 使用率。

系统服务使用

Android 系统服务包括 Warelock、Alarm、Sensor、Wifi、Net、Location、Bluetooth、Camera等。

与市面上常规的监控手段差异不大,都是通过系统 Hook ServiceManager 的方式,监听系统服务的 Binder 通信,匹配对应的调用方法名,做对应中间层监控的回调记录处理。

熟悉 Android 开发的同学知道 Android 的 Zygote 进程是 Android 系统启动时的第一个进程。在 Zygote Fork 进程中会孵化出系统服务相关的进程 SystemServer,在其核心的 RUN 方法中,会注册启动大量的系统服务,并通过 ServiceManager 进行管理。

Android发热监控实践_第9张图片

故我们可以通过反射代理 ServiceManager 的方式,以 LocationManager 为例进行监听,拦截对应 LocationManager 内对应的方法,记录我们期望获取的数据。

// 获取 ServiceManager 的 Class 对象
Class serviceManagerClass = Class.forName("android.os.ServiceManager");
// 获取 getService 方法
Method getServiceMethod = serviceManagerClass.getDeclaredMethod("getService", String.class);
// 通过反射调用 getService 方法获取原始的 IBinder 对象
IBinder originalBinder = (IBinder) getServiceMethod.invoke(null, "location");
// 创建一个代理对象 Proxy
Class iLocationManagerStubClass = Class.forName("android.location.ILocationManager$Stub");
Method asInterfaceMethod = iLocationManagerStubClass.getDeclaredMethod("asInterface", IBinder.class);
final Object originalLocationManager = asInterfaceMethod.invoke(null, originalBinder);
Object proxyLocationManager = Proxy.newProxyInstance(context.getClassLoader(),
        new Class[]{Class.forName("android.location.ILocationManager")},
        new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                // 在这里进行方法的拦截和处理
                Log.d("LocationManagerProxy", "Intercepted method: " + method.getName());
                // 执行原始的方法
                return method.invoke(originalLocationManager, args);
            }
        });
// 替换原始的 IBinder 对象
getServiceMethod.invoke(null, "location", proxyLocationManager);

同理 我们获取在固定采样周期内 各系统服务对应 申请次数、计算间隔时长等进行记录。

源码 Power_profile 文件中定义了每个系统服务状态下的电流量定义。

我们在需要记录每个元器件在不同状态的工作时间之后,通过以下计算方式,可以得出元器件的发热贡献排行,即:

元器件 电量消耗(发热贡献)  ~~  电流量 * 运行时长 * 电压(一般为固定值,可忽略)

Android发热监控实践_第10张图片

线程堆栈

由于发热问题是一个综合性的问题,并不像 Crash 问题一样,在发生现场我们就可以知道是哪个线程触发的。如果将所有线程的堆栈都进行 Dump 记录的话,得物当前运行时的子线程数量在 200+,全部进行存储的话无疑是不合理的。问题就转变为 如何较为准确的找到发热代码的线程堆栈?

上文说到 在计算 CPU 使用率的时读取进程下所有线程的 Stat 文件,我们可以获取到子线程的 CPU 使用率,对其使用率进行倒排,筛选超过阈值(当前定义 50% ) 或 占用 Top N 的线程进行存储。由于堆栈频繁采集时机上是有性能折损的,故牺牲了部分的堆栈采样精度和准确性,在温度、CPU 使用率等指标超过阈值定义后,才开始采集 指定下发时间的堆栈信息。

我们还要明确一个概念,线程 Stat 文件的文件名即为线程标识名,Thread.id 是指线程ID。

其两者并不等价,但 Native 方法中给我们提供了对应的方式去建立两者的映射关系。

在 Art  Thread.cc 方法中,将 Java 中的 Thread 对象转换成 C++ 中的 Thread 对象,调用 ShortDump 打印线程的相关信息,我们通过字符串匹配到核心的 Tid= 的信息,即可获取到线程的 Tid。

Android发热监控实践_第11张图片

核心代码逻辑如下:

//获取队列中最近一次cpu采样的数据
 val threadCpuUsageData = cpuProfileStoreQueue.last().threadUsageDataList
       val hotStacks = mutableListOf()
        if (threadCpuUsageData != null) {
            val dataCount = if (threadCpuUsageData.size <= TOP_THREAD_COUNT) {
                threadCpuUsageData.size
            } else {
                TOP_THREAD_COUNT
            }
            val traces: MutableMap> = Thread.getAllStackTraces()
            //定义tid 和 thread的映射关系map
            val tidMap: MutableMap = mutableMapOf()
            traces.keys.forEach { thread ->
                //调用native方法获取到tid信息
                val tidInfo = hotMonitorListener?.findTidInfoByThread(thread)
                tidInfo?.let {
                    findTidByTidInfo(tidInfo).let { tid ->
                        if (tid.isNotEmpty()) {
                            tidMap[tid] = thread
                        }
                    }
                }
            }
            //采集topN的发热堆栈
            for (index in 1..dataCount) {
                val singleThreadData = threadCpuUsageData[index - 1]
                val isMainThread = singleThreadData.pid == singleThreadData.tid
                val thread = tidMap[singleThreadData.tid.toString()]
                thread?.let { findThread ->
                    traces[findThread]?.let { findStackTrace ->
                        //获取当前的线程堆栈
                        val sb = StringBuilder()
                        for (element in findStackTrace) {
                            sb.append(element.toString()).append("\n")
                        }
                        sb.append("\n")
                        if (findStackTrace.isNotEmpty()) {
                            //是否为主线程
                            //组装hotStack
                            val hotStack = HotStack(
                                //进程id
                                singleThreadData.pid,
                                singleThreadData.tid,
                                singleThreadData.name,
                                singleThreadData.cpuUseRate,
                                sb.toString(),
                                thread.state
                                isMainThread
                            )
//                        Log.d("HotMonitor", sb.toString())
                            hotStacks.add(hotStack)
                        }
                    }
                }

            }
        }

四、监控方案

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

模块整体架构

Android发热监控实践_第12张图片

上报时机

Android发热监控实践_第13张图片

核心采集流程

Android发热监控实践_第14张图片

线上线下区分

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

Android发热监控实践_第15张图片

Android发热监控实践_第16张图片

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

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

发热平台

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

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

Android发热监控实践_第17张图片

Android发热监控实践_第18张图片

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

Android发热监控实践_第19张图片

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

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

Android发热监控实践_第20张图片

Android发热监控实践_第21张图片

五、收益

Android 端侧发热监控自上线以来,背靠平台侧的支撑,陆续发现了一些问题并联合开发同学做了对应场景的治理优化工作,如:

耗时独立线程任务 接入统一线程池调度管理;

动画执行死循环监测修复;

高 IO 场景的文件读写策略优化;

高并发任务锁粒度优化;

日志库等 Json 解析频繁场景 采用效率更高的序列化方;

系统相机等系统功率过高的采集参数设备分级尝试;

基于 Webgl 的游戏场景 帧率降低和资源及时回收优化运行时内存;

....

这无疑给未来体验工作的场景技术选型、技术实现沉淀了一些有价值的经验,符合对 App 体验追求极致的高标准、高要求。

六、未来展望

手机发热作为渐进式的体验场景,涉及手机硬件、系统服务、软件使用、外界环境多方位因素。对于端侧的排查上来说,当前优先级聚焦于应用层的不合理使用上,对于排查工具链路增强、问题业务归因、低电量、低功耗模式下的动态策略降低、自动化诊断报告等环节仍旧有很多值得深入挖掘的点,例如:

监控/工具增强

  • App 浮层分析工具 (CPU\GPU/频率/温度/功耗等信息)
  • 借鉴 BatteryHistorian、SnapdragonProfiler、Systrace 等工具,实现自研TeslaLab 能力增强。

业务归因

  • 发热堆栈自动分配
  • 调用溯源归因精细化

场景策略、降级

  • CPU 调频、动态帧率、分辨率降级
  • 端内低功耗模式探索

自动化诊断报告

  • 单用户定向自动化分析输出诊断报告

七、总结

在此也只是粗略介绍当前已经做的针对发热治理的一些初步工作,以及对未来发热功耗相关开展的思路,希望能让 App 带来更好的体验,给用户带来更对美好事物的向往的感受。

*文 / GavinX

本文属得物技术原创,更多精彩文章请看:得物技术官网

未经得物技术许可严禁转载,否则依法追究法律责任!

你可能感兴趣的:(发热功耗,性能优化,App体验,端侧监控)