Android發(fā)熱監(jiān)控實踐
一、背景
相信移動端高度普及的現在，大家或多或少都會存在電量焦慮，擁有過手機發(fā)熱發(fā)燙的糟糕體驗。而發(fā)熱問題是一個長時間、多場景的指標存在，且涉及到端側應用層、手機 ROM 廠商系統(tǒng)、外界環(huán)境等多方面的影響。如何有效衡量發(fā)熱場景、定位發(fā)熱現場、以及歸因發(fā)熱問題成為了端側應用層發(fā)熱監(jiān)控的面前的三座大山。本文通過得物 Android 端側現有的一些監(jiān)控實踐，不深入功耗計算場景無法自拔，優(yōu)先聚焦于發(fā)熱場景本身，希望能給大家一些參考。
二、發(fā)熱定義
溫度是最直觀能反映發(fā)熱問題的指標，當前 Android 側，我們以體感溫度 37° 以上作為分界線，向上每 3° 作為一個發(fā)熱溫度區(qū)間，區(qū)間細分上限溫度 49° ，即劃分出 37-40，40-43，43-46，46-49，49+ 五個等級。
以手機溫度、CPU 使用率作為第一、第二要素來判斷用戶是否發(fā)熱的同時，獲取其他參數來支撐發(fā)熱現場情況。
具體指標如下:
手機溫度 CPU 使用率、GPU 使用率；
線程堆棧；
系統(tǒng)服務使用頻次；
設備前后臺、亮滅屏時長；
電量、充電情況；
熱緩解發(fā)熱等級；
系統(tǒng)機型、版本；
....
三、指標獲取
溫度
- 電池溫度系統(tǒng) 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 除支持電池溫度的系統(tǒng)廣播外，也包含電量、充電狀態(tài)等額外信息的讀取，均定義在其源碼中。
以下羅列幾個值得關注的:
//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 進入充電狀態(tài)
// ACTION_DISCHARGING 進入放電狀態(tài)- 傳感器溫度Android是基于Linux 基礎上修改的開源操作系統(tǒng)，同樣的在手機系統(tǒng)sys/class/thermal/ 目錄下存在以 thermal_zoneX 為代表各傳感器的溫度分區(qū)，以及 cooling_deviceX 為代表風扇或散熱器等冷卻設備。以一加 9 為例，共存在 105 個溫度傳感器 or 溫度分區(qū)，以及 48 個冷卻設備。
每個溫度分區(qū)下記錄下具體的參數類型，我們重點關注的是 type 文件和 temp 文件，分別記錄了該傳感器設備的名稱，以及當前的傳感器溫度。以 thermal_zone29 為例，代表了 CPU 第一核心的 第五處理單元的溫度值為 33.2 攝氏度。而對單一設備來說分區(qū)對應的名稱是固定的，從而我們可以通過讀取 thermal_zone 文件的方式來記錄當前第一個 type 文件名稱包含 CPU 的傳感器作為 CPU 溫度。
圖片
- 殼溫Android 10 Google 官方推出了熱緩解框架，通過 HAL2.0 框架監(jiān)聽底層硬件傳感器（主要為 USB 傳感器、Skin 傳感器）提供 USB、殼溫的熱信號等級變更監(jiān)聽， 系統(tǒng) PowerManager 源碼提供了對應發(fā)熱等級變更的回調和發(fā)熱等級的獲取，共 7 個等級，提供給開發(fā)者主動或被動獲取。
圖片
final PowerManager powerManager = (PowerManager) mContext.getSystemService(Context.POWER_SERVICE);
powerManager.addThermalStatusListener(new PowerManager.OnThermalStatusChangedListener() {
@Override
public void onThermalStatusChanged(int status) {
//返回對應的熱狀態(tài)
}
});但對于發(fā)熱等級來說，殼溫無疑是最為能夠反應手機的發(fā)熱情況的。可以看到 Android 系統(tǒng)的 API 實際上是提供了 AIDL 接口，可以直接注冊 Thermal 變更事件的監(jiān)聽，獲取到 Temperature 對象。但由于標識了 Hide API 。常規(guī)應用層是無法獲取到的，在考慮好 Android 版本兼容性前提下，通過反射代理 ThermalManagerService 方式進行讀取。
圖片
但事與愿違，國內廠商并沒有完全適配官方熱緩解框架，熱狀態(tài)回調時常不夠準確，而是需要單獨接入每個廠商的熱緩解 SDK 去直接獲取到殼溫，具體 API 則以各應用廠商的內部接入文檔為準。
CPU使用率
在系統(tǒng) proc/[pid]/stat 和 /proc/[pid]/task/[tid]/stat 分別記錄了對應進程 ID、進程 ID 下的線程 ID 的 CPU 信息。具體的字段描述在此不進行贅述，詳見：https://man7.org/linux/man-pages/man5/procfs.5.html。
圖片
我們重點關注 14.15 位的信息，分別代表進程/線程的用戶態(tài)運行的時間和內核態(tài)運行的時間。
圖片
通過解析當前進程的 Stat 文件，以及 Task 目錄下所有線程的 Stat 文件，在兩次采樣周期內(當前設置為 1s)的 utime+stime 之和的差值/采樣間隔，即可認為是進線程的 CPU 的使用率。即 進線程 CPU 使用率 = ((utime+stime)-(lastutime+laststime)) / period
GPU使用率
GPU 的使用率 = (下圖)數值 1 / 數值 2 * 100，經過驗證與 SnapDragonProfiler 信息采集獲取的數值基本一致。
聯發(fā)科芯片的設備，我們可以直接通過讀取 /d/ged/hal/gpu_utilization 下的使用率數值。
同樣的通過指定周期(每秒 1 次)的采樣間隔，即可獲取到每秒的當前 GPU 使用率。
系統(tǒng)服務使用
與市面上常規(guī)的監(jiān)控手段差異不大，都是通過系統(tǒng) Hook ServiceManager 的方式，監(jiān)聽系統(tǒng)服務的 Binder 通信，匹配對應的調用方法名，做對應中間層監(jiān)控的回調記錄處理。
熟悉 Android 開發(fā)的同學知道 Android 的 Zygote 進程是 Android 系統(tǒng)啟動時的第一個進程。在 Zygote Fork 進程中會孵化出系統(tǒng)服務相關的進程 SystemServer，在其核心的 RUN 方法中，會注冊啟動大量的系統(tǒng)服務，并通過 ServiceManager 進行管理。
故我們可以通過反射代理 ServiceManager 的方式，以 LocationManager 為例進行監(jiān)聽，攔截對應 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");
// 創(chuàng)建一個代理對象 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());
// 執(zhí)行原始的方法
return method.invoke(originalLocationManager, args);
}
});
// 替換原始的 IBinder 對象
getServiceMethod.invoke(null, "location", proxyLocationManager);同理 我們獲取在固定采樣周期內 各系統(tǒng)服務對應 申請次數、計算間隔時長等進行記錄。
源碼 Power_profile 文件中定義了每個系統(tǒng)服務狀態(tài)下的電流量定義。
我們在需要記錄每個元器件在不同狀態(tài)的工作時間之后，通過以下計算方式，可以得出元器件的發(fā)熱貢獻排行，即：
元器件 電量消耗（發(fā)熱貢獻） ~~ 電流量 * 運行時長 * 電壓（一般為固定值，可忽略）
圖片
線程堆棧
上文說到 在計算 CPU 使用率的時讀取進程下所有線程的 Stat 文件，我們可以獲取到子線程的 CPU 使用率，對其使用率進行倒排，篩選超過閾值（當前定義 50% ) 或 占用 Top N 的線程進行存儲。由于堆棧頻繁采集時機上是有性能折損的，故犧牲了部分的堆棧采樣精度和準確性，在溫度、CPU 使用率等指標超過閾值定義后，才開始采集 指定下發(fā)時間的堆棧信息。
我們還要明確一個概念，線程 Stat 文件的文件名即為線程標識名，Thread.id 是指線程ID。
其兩者并不等價，但 Native 方法中給我們提供了對應的方式去建立兩者的映射關系。
在 Art Thread.cc 方法中，將 Java 中的 Thread 對象轉換成 C++ 中的 Thread 對象，調用 ShortDump 打印線程的相關信息，我們通過字符串匹配到核心的 Tid= 的信息，即可獲取到線程的 Tid。
核心代碼邏輯如下:
//獲取隊列中最近一次cpu采樣的數據
val threadCpuUsageData = cpuProfileStoreQueue.last().threadUsageDataList
val hotStacks = mutableListOf<HotStack>()
if (threadCpuUsageData != null) {
val dataCount = if (threadCpuUsageData.size <= TOP_THREAD_COUNT) {
threadCpuUsageData.size
} else {
TOP_THREAD_COUNT
}
val traces: MutableMap<Thread, Array<StackTraceElement>> = Thread.getAllStackTraces()
//定義tid 和 thread的映射關系map
val tidMap: MutableMap<String, Thread> = 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的發(fā)熱堆棧
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)
}
}
}
}
}四、監(jiān)控方案
了解核心指標數據是如何獲取的前提下，其實監(jiān)控方案的核心思路無非就是通過遠端 APM 配置中心下發(fā)的采樣閾值、采樣周期、各模塊數據開關等限定采樣配置，子線程 Handler 定時發(fā)消息，采集各個模塊的數據進行組裝，在合適的時機進行數據上報即可，具體的數據拆解、分析工作則由發(fā)熱平臺進一步處理。
模塊整體架構
圖片
上報時機
圖片
核心采集流程
圖片
線上線下區(qū)分
由于所有子線程的 CPU 采集、堆棧采集實際上是會對性能有折損的，200+ 的線程的讀取耗時整體在 200ms 左右，采樣子線程的 CPU 使用率在 10%，考慮到線上用戶體驗問題，并不能全量開啟高頻率采樣。
圖片
圖片
故整體方案來說: 線下場景以重點側重發(fā)現、排查、治理全量問題，上報全量日志，以 CPU、GPU 使用率為第一衡量指標；
線上場景以重點側重觀察整體發(fā)熱大盤趨勢、分析潛在問題場景，上報核心日志，以電池溫度為第一衡量指標。
發(fā)熱平臺
在平臺側同學的支持下，發(fā)熱現場數據經過平臺側進行消費，將核心的發(fā)熱堆棧經過 Android 堆棧反混淆服務進行聚合，補齊充電狀態(tài)、主線程 CPU 使用率、問題類型、電池溫度等基礎字段，平臺側就具備發(fā)現、分析、解決的流程化監(jiān)控推進的能力。
具體的堆棧信息 & 發(fā)熱信息平臺展示如下:
圖片
圖片
由于電池溫度、CPU 使用率是針對運行時發(fā)熱場景最直觀的指標，且我們一期重點關注發(fā)熱場景的治理，不針對元器件 Hook 等耗電場景進行持續(xù)深入分析，故當前得物側是以電池溫度、CPU 使用率為第一第二指標 建立核心的發(fā)熱問題四象限，優(yōu)先關注高溫、高 CPU 的問題場景。
圖片
在數據分析過程中，我們遇到了數據上的效率排查效率不夠高、問題精度不夠準的情況。
- 如何定位是高溫場景是發(fā)生在 App 內部，且在使用過程中明顯上升的？ 通過過濾從啟動開始即高溫、后臺切換回來即高溫的場景，重點關注在 App 內部溫度上升的場景。
- 線上的采樣后仍舊單日有 6w+ 數據的上報，我們如何篩選出更為核心的數據？當前的做法是定義了溫度跨度的概念，優(yōu)先看在 App 內部溫度跨度較大的 Case。
- 線程存在調用 Wait 等方法阻塞的堆棧，消耗內核態(tài)的時間分配，但實際不消耗整體 CPU 的誤報數據。補充了線程的運行狀態(tài)和 Proc 文件中記錄的 State，方便優(yōu)先處理 RUNNABLE線程的 CPU 高溫高占用問題。
- 手機溫度上升作為漸進式的場景，如何實現溫度上升場景下的頁面精確歸因？增加溫度采樣頻率的同時，匯總 CPU 使用率和實時堆棧等瞬時數據作為數據支撐，但考慮到數據體量的情況，數據上報聚合裁剪方式仍在逐步探索更為合理的方式，力求在兩者之間找到一個平衡點。
圖片
圖片
五、收益
Android 端側發(fā)熱監(jiān)控自上線以來，背靠平臺側的支撐，陸續(xù)發(fā)現了一些問題并聯合開發(fā)同學做了對應場景的治理優(yōu)化工作，如：
耗時獨立線程任務 接入統(tǒng)一線程池調度管理；
動畫執(zhí)行死循環(huán)監(jiān)測修復；
高 IO 場景的文件讀寫策略優(yōu)化；
高并發(fā)任務鎖粒度優(yōu)化；
日志庫等 Json 解析頻繁場景 采用效率更高的序列化方；
系統(tǒng)相機等系統(tǒng)功率過高的采集參數設備分級嘗試；
基于 Webgl 的游戲場景 幀率降低和資源及時回收優(yōu)化運行時內存；
....
這無疑給未來體驗工作的場景技術選型、技術實現沉淀了一些有價值的經驗，符合對 App 體驗追求極致的高標準、高要求。
六、未來展望
手機發(fā)熱作為漸進式的體驗場景，涉及手機硬件、系統(tǒng)服務、軟件使用、外界環(huán)境多方位因素。對于端側的排查上來說，當前優(yōu)先級聚焦于應用層的不合理使用上，對于排查工具鏈路增強、問題業(yè)務歸因、低電量、低功耗模式下的動態(tài)策略降低、自動化診斷報告等環(huán)節(jié)仍舊有很多值得深入挖掘的點，例如：
監(jiān)控/工具增強
- App 浮層分析工具 (CPU\GPU/頻率/溫度/功耗等信息)
- 借鑒 BatteryHistorian、SnapdragonProfiler、Systrace 等工具，實現自研TeslaLab 能力增強。
業(yè)務歸因
- 發(fā)熱堆棧自動分配
- 調用溯源歸因精細化
場景策略、降級
- CPU 調頻、動態(tài)幀率、分辨率降級
- 端內低功耗模式探索
自動化診斷報告
- 單用戶定向自動化分析輸出診斷報告
七、總結
在此也只是粗略介紹當前已經做的針對發(fā)熱治理的一些初步工作，以及對未來發(fā)熱功耗相關開展的思路，希望能讓 App 帶來更好的體驗，給用戶帶來更對美好事物的向往的感受。
