当前位置:首页 > 数码 > Android发热监控通常指南 (android是什么)

Android发热监控通常指南 (android是什么)

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

一、背景

置信移动端高度遍及的如今,大家或多或少都会存在电量焦虑,领有过手机发热发烫的蹩脚体验。而发热疑问是一个长期间、多场景的目的存在,且触及到端侧运行层、手机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体验谋求极致的高规范、高要求。

六、未来展望

手机发热作为渐进式的体验场景,触及手机配件、系统服务、软件经常使用、外界环境多方位起因。关于端侧的排查过去说,以后优先级聚焦于运行层的不正当经常使用上,关于排查工具链路增强、疑问业务归因、低电量、低功耗形式下的灵活战略降落、智能化诊断报告等环节依旧有很多值得深化开掘的点,例如:

监控/工具增强

业务归因

场景战略、升级

Android

智能化诊断报告

七、总结

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


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

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

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

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

免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。

标签: Android

“Android发热监控通常指南 (android是什么)” 的相关文章

Android-开发中经常出现的-技术-Hook (android studio)

Android-开发中经常出现的-技术-Hook (android studio)

Hook技术引见 Hook技术是一种在软件开发中经常出现的技术,它准许开发者在特定的事情出现时拔出自定义的代码逻辑。经常出现的运行场景包含在函数调用前后口头特定的操作,或许在特定的事情出现时...

Android中保持屏幕常亮的有效方法-全面指南 (android studio)

Android中保持屏幕常亮的有效方法-全面指南 (android studio)

WakeLock是Android中用于控制设备唤醒状态的类。通过获取WakeLock对象并设置屏幕常亮标志,可以保持屏幕常亮。这对于需要在设备处于休眠状态时仍然保持屏幕显示的应用程序非常有用,例如...

Android数据对象序列化原理与运行 (android是什么)

Android数据对象序列化原理与运行 (android是什么)

序列化与反序列化 「序列化」是将对象转换为可以存储或传输的格局的环节。在计算机迷信中,对象通常是指内存中的数据结构,如数组、列表、字典等。经过序列化,可以将这些对象转换为字节流或文本格局,以...

结构和应用-深入了解Android中的SELinux-了解其功能 (茶多酚的结构和应用)

结构和应用-深入了解Android中的SELinux-了解其功能 (茶多酚的结构和应用)

SELinux 简介 SELinux(Security-Enhanced Linux)是一种安全增强的 Linux 操作系统,它通过强制访问控制 (MAC) 机制来提供更高级别的系统安全保护...

Context在Android开发中的至关重要性 (contextual)

Context在Android开发中的至关重要性 (contextual)

Introduction In Android development, Context is a crucial class that represents the curr...

AIDL在Android运行程序开发中的关键性

AIDL在Android运行程序开发中的关键性

DL引见 AIDL(InterfaceDefinitionLanguage)是一种用于定义Android运行程序中的跨进程通讯接口的言语。经过经常使用AIDL,开发人员可以定义客户端和服务之...

深入了解-硬件抽象层的奥秘-揭开-HAL-Android-系统架构 (什么是硬知识)

深入了解-硬件抽象层的奥秘-揭开-HAL-Android-系统架构 (什么是硬知识)

Android系统中,硬件抽象层(HAL)扮演着至关重要的角色,它负责在不同硬件和上层应用程序之间建立一个抽象层。有了HAL,不同的硬件设备可以被统一调用,从而提高了系统的兼容性和可移植性。...

Android-系统进程优先级深入解析 (android studio)

Android-系统进程优先级深入解析 (android studio)

进程是操作系统中正在运行的程序的实例。 每个进程都有自己的内存空间和系统资源。 进程可以独立地执行指令。 进程可以包含一个或多个线程。 进程之间可以...