在此也只是粗略引见以后曾经做的针对发热控制的一些初步上班，以及对未来发热功耗相关展开的思绪，宿愿能让带来更好的体验，给用户带来更对美妙事物的向往的感触。​

一、背景

置信移动端高度遍及的如今，大家或多或少都会存在电量焦虑，领有过手机发热发烫的蹩脚体验。而发热疑问是一个长期间、多场景的目的存在，且触及到端侧运行层、手机ROM厂商系统、外界环境等多方面的影响。如何有效权衡发热场景、定位发热现场、以及归因发热疑问成为了端侧运行层发热监控的背地的三座大山。本文经过得物端侧现有的一些监控通常，不深化功耗计算场景无法自拔，优先聚焦于发热场景自身，宿愿能给大家一些参考。

二、发热定义

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

以手机温度、CPU经常使用率作为第一、第二要历来判别用户能否发热的同时，失掉其余参数来撑持发热现场状况。

详细目的如下:

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

线程堆栈；

系统服务经常使用频次；

设施前后盾、亮灭屏时长；

电量、充电状况；

热缓解发热等级；

系统机型、版本；

三、目的失掉

温度

//失掉电池温度BatteryManager.EXTRA_TEMPERATURE，华氏温度须要除以10fungetBatteryTempImmediately(context:Context):Float{returntry{valbatIntent=getBatteryStickyIntent(context)?:return0fbatIntent.getIntExtra(BatteryManager.EXTRA_TEMPERATURE,0)/10F}catch(e:Exception){0f}}privatefungetBatteryStickyIntent(context:Context):Intent?{returntry{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进入放电形态

每个温度分区下记载下详细的参数类型，咱们重点关注的是type文件和temp文件，区分记载了该传感器设施的称号，以及以后的传感器温度。以thermal_zone29为例，代表了CPU第一外围的第五处置单元的温度值为33.2摄氏度。而对繁多设施来说分区对应的称号是固定的，从而咱们可以经过读取thermal_zone文件的形式来记载以后第一个type文件称号蕴含CPU的传感器作为CPU温度。

图片

图片

finalPowerManagerpowerManager=(PowerManager)mContext.getSystemService(Context.POWER_SERVICE);powerManager.addThermalStatusListener(newPowerManager.OnThermalStatusChangedListener(){@OverridepublicvoidonThermalStatusChanged(intstatus){//前往对应的热形态}});

但关于发热等级来说，壳温无疑是最为能够反响手机的发热状况的。可以看到Android系统的API实践上是提供了DL接口，可以间接注册Thermal变卦事情的监听，失掉到Temperature对象。但由于标识了HideAPI。惯例运行层是无法失掉到的，在思考好Android版本兼容性前提下，经过反射代理ThermalManagerService形式启动读取。

图片

但适得其反，国际厂商并没有齐全适配官方热缓解框架，热形态回调时常不够准确，而是须要独自接入每个厂商的热缓解SDK去间接失掉到壳温，详细API则以各运行厂商的外部接入文档为准。

CPU经常使用率

CPU经常使用率的采集经过读取解析Procstat文件的形式启动计算。

在系统proc/[pid]/stat和/proc/[pid]/task/[tid]/stat区分记载了对应进程ID、进程ID下的线程ID的CPU信息。详细的字段形容在此不启动赘述，详见：。

图片

咱们重点关注14.15位的信息，区分代表进程/线程的用户态运转的期间和内核态运转的期间。

图片

经过解析以后进程的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信息采集失掉的数值基本分歧。

联发科芯片的设施，咱们可以间接经过读取/d/ged/hal/gpu_utilization下的经常使用率数值。

雷同的经过指定周期(每秒1次)的采样距离，即可失掉到每秒的以后GPU经常使用率。

系统服务经常使用

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

与市面上惯例的监控手腕差异不大，都是经过系统HookServiceManager的形式，监听系统服务的Binder通讯，婚配对应的调用方法名，做对应两边层监控的回调记载处置。

相熟Android开发的同窗知道Android的Zygote进程是Android系统启动时的第一个进程。在ZygoteFork进程中会孵化出系统服务相关的进程SystemServer，在其外围的RUN方法中，会注册启动少量的系统服务，并经过ServiceManager启动控制。

故咱们可以经过反射代理ServiceManager的形式，以LocationManager为例启动监听，阻拦对应LocationManager内对应的方法，记载咱们希冀失掉的数据。

//失掉ServiceManager的Class对象Class<?>serviceManagerClass=Class.forName("android.os.ServiceManager");//失掉getService方法MethodgetServiceMethod=serviceManagerClass.getDeclaredMethod("getService",String.class);//经过反射调用getService方法失掉原始的IBinder对象IBinderoriginalBinder=(IBinder)getServiceMethod.invoke(null,"location");//创立一个代理对象ProxyClass<?>iLocationManagerStubClass=Class.forName("android.location.ILocationManager$Stub");MethodasInterfaceMethod=iLocationManagerStubClass.getDeclaredMethod("asInterface",IBinder.class);finalObjectoriginalLocationManager=asInterfaceMethod.invoke(null,originalBinder);ObjectproxyLocationManager=Proxy.newProxyInstance(context.getClassLoader(),newClass[]{Class.forName("android.location.ILocationManager")},newInvocationHandler(){@OverridepublicObjectinvoke(Objectproxy,Methodmethod,Object[]args)throwsThrowable{//在这里启动方法的阻拦和处置Log.d("LocationManagerProxy","Interceptedmethod:"+method.getName());//口头原始的方法returnmethod.invoke(originalLocationManager,args);}});//交流原始的IBinder对象getServiceMethod.invoke(null,"location",proxyLocationManager);

同理咱们失掉在固定采样周期内各系统服务对应放开次数、计算距离时长等启动记载。

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

咱们在须要记载每个元器件在不同形态的上班期间之后，经过以下计算形式，可以得出元器件的发热奉献排行，即：

元器件电量消耗（发热奉献）~~电流量*运转时长*电压（普通为固定值，可疏忽）

图片

线程堆栈

由于发热疑问是一个综合性的疑问，并不像Crash疑问一样，在出现现场咱们就可以知道是哪个线程触发的。假设将一切线程的堆栈都启动Dump记载的话，得物以后运转时的子线程数量在200+，所有启动存储的话无疑是不正当的。疑问就转变为如何较为准确的找到发热代码的线程堆栈？

上文说到在计算CPU经常使用率的时读取进程下一切线程的Stat文件，咱们可以失掉到子线程的CPU经常使用率，对其经常使用率启动倒排，挑选超越阈值（以后定义50%)或占用TopN的线程启动存储。由于堆栈频繁采集机遇上是有性能折损的，故就义了局部的堆栈采样精度和准确性，在温度、CPU经常使用率等目的超越阈值定义后，才开局采集指定下发期间的堆栈信息。

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

其两者并不等价，但Native方法中给咱们提供了对应的形式去建设两者的映射相关。

在ArtThread.cc方法中，将中的Thread对象转换成C++中的Thread对象，调用ShortDump打印线程的相关信息，咱们经过字符串婚配到外围的Tid=的信息，即可失掉到线程的Tid。

外围代码逻辑如下:

//失掉队列中最近一次性cpu采样的数据valthreadCpuUsageData=cpuProfileStoreQueue.last().threadUsageDataListvalhotStacks=mutableListOf<HotStack>()if(threadCpuUsageData!=null){val/>图片
上报机遇
图片
外围采集流程
图片
线上线下区分
由于一切子线程的CPU采集、堆栈采集实践上是会对性能有折损的，200+的线程的读取耗时全体在200ms左右，采样子线程的CPU经常使用率在10%，思考到线上用户体验疑问，并不能全量开启高频率采样。
图片
图片
故全体打算来说:线下场景以重点并重发现、排查、控制全量疑问，上报全量日志，以CPU、GPU经常使用率为第一权衡目的；
线上场景以重点并重观察全体发热大盘趋向、剖析潜在疑问场景，上报外围日志，以电池温度为第一权衡目的。
发热平台
在平台侧同窗的支持下，发热现场数据经过平台侧启动生产，将外围的发热堆栈经过Android堆栈反混杂服务启动聚合，补齐充电形态、主线程CPU经常使用率、疑问类型、电池温度等基础字段，平台侧就具有发现、剖析、处置的流程化监控推动的才干。
详细的堆栈信息&发热信息平台展现如下:
图片
图片
由于电池温度、CPU经常使用率是针对运转时发热场景最直观的目的，且咱们一期重点关注发热场景的控制，不针对元器件Hook等耗电场景启动继续深化剖析，故以后得物侧是以电池温度、CPU经常使用率为第一第二目的建设外围的发热疑问四象限，优先关注高温、高CPU的疑问场景。
图片
在数据剖析环节中，咱们遇到了数据上的效率排查效率不够高、疑问精度不够准的状况。
图片
图片
五、收益
Android端侧发热监控自上线以来，背靠平台侧的撑持，陆续发现了一些疑问并联结开发同窗做了对应场景的控制优化上班，如：
耗时独立线程义务接入一致线程池调度控制；
动画口头死循环监测修复；
高IO场景的文件读写战略优化；
高并发义务锁粒度优化；
日志库等Json解析频繁场景驳回效率更高的序列化方；
系统相机等系统功率过高的采集参数设施分级尝试；
基于Webgl的游戏场景帧率降落和资源及时回收优化运转时内存；
这无疑给未来体验上班的场景技术选型、技术成功积淀了一些有价值的阅历，合乎对App体验谋求极致的高规范、高要求。
六、未来展望
手机发热作为渐进式的体验场景，触及手机配件、系统服务、软件经常使用、外界环境多方位起因。关于端侧的排查过去说，以后优先级聚焦于运行层的不正当经常使用上，关于排查工具链路增强、疑问业务归因、低电量、低功耗形式下的灵活战略降落、智能化诊断报告等环节依旧有很多值得深化开掘的点，例如：
监控/工具增强
业务归因
场景战略、升级
智能化诊断报告
七、总结
在此也只是粗略引见以后曾经做的针对发热控制的一些初步上班，以及对未来发热功耗相关展开的思绪，宿愿能让App带来更好的体验，给用户带来更对美妙事物的向往的感触。

---

红米手机发热怎么办 以下3个方法教你解决

1、经过网友测试，红米同时打开8个应用程序，并正常使用QQ、微信时候，手机并没有感到明显的发热现象。 在玩过半小时的打飞机和半小时的天天看消除游戏后，手机也没有特别严重的发热现象。 如果你长时间的玩手机不间断，红米发热严重那是在所难免的了。 2、关于红米手机发热问题，在使用时可以考虑适当减轻手机负载，有选择性的关闭目前不需要却在耗电的程序，还有不要长时间的玩手机，也让手机有个休息时间。 如果你的红米不幸出现发烫现象，建议咨询小米官方客服。 3、目前Android手机发热都属于正常现象，运行的程序多了，功耗大了，自然导致手机CPU和电池的温度较高。 只要不是特别厉害的发热问题，都可以不用太过计较。

安卓手机打开照相机，等一会摄像头就很烫，天气热了都这样吗？

若使用的是vivo手机，拍照或录像时，摄像头、CPU（处理器）、GPU（图像处理器）等元件会同时工作，摄像头采集画面到形成照片文件，整个过程手机运行功耗较高，长时间拍照或录像，机身会伴随一定的发热量。 可以尝试以下方法降低手机拍照或录像发热：1、拍照或录像前，清理不需要的后台应用，降低手机运行功耗；2、录像模式尽量不要选择4K或60帧，分辨率和帧率越高，手机整体运行功耗和发热量会增加；在夏季等温度较高的环境，将录像分辨率设置为720P，可减少手机发热；3、避免长时间连续拍照或录像，手机发热时可暂时退出相机，手机温度会随之降低。