您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

qq飞车刷喇叭技巧(抖音 Android 性能优化系列：抖音功耗优化实践)

功耗,电流,器件qq飞车刷喇叭技巧(抖音 Android 性能优化系列：抖音功耗优化实践)

发布时间：2016-12-08加入收藏来源：互联网点击：

电压型电量计：简单讲就是检测当前电压，然后查询电压-电池容量对应表，获得电量估算电流型电量计：也叫库仑计，原理是在电池的充电/放电路径上的连接一个检测电阻。ADC 量测在检测电阻上的电压，转换成电池正在充电或放电的电流值。实时计数器（RTC）则提供把该电流值对时间作积分，从而得知流过多少库伦。

Android 提供了 BMS 的接口，通过属性提供了电池电量计的统计结果

BATTERY_PROPERTY_CHARGE_COUNTER 剩余电池容量，单位为微安时BATTERY_PROPERTY_CURRENT_NOW 瞬时电池电流，单位为微安BATTERY_PROPERTY_CURRENT_AVERAGE 平均电池电流，单位为微安BATTERY_PROPERTY_CAPACITY 剩余电池容量，显示为整数百分比BATTERY_PROPERTY_ENERGY_COUNTER 剩余能量，单位为纳瓦时

import android.os.BatteryManager;import android.content.Context;BatteryManager mBatteryManager = (BatteryManager)Context.getSystemService(Context.BATTERY_SERVICE);Long energy = mBatteryManager.getLongProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER);Slog.i(TAG, "Remaining energy = " energy "nWh");

以下面的 Nexus9 为例，该机型使用了 MAX17050 电流型电量计，解析度 156.25uA，更新周期 175.8ms。

从实践结果上看，由于不同的手机使用的电量计不同，导致直接读取出来的电流值单位也不同，需要做数据转化。为了简化电池数据的获取，我们开发了 Thor SDK，只保留电流、电压、电量等指标的采集过程，针对不同机型做了数据归一处理，用户可以不用关心内部实现，只需要提供需要采样的数据类型、采样周期就可以定时返回所需要的功耗相关的数据，我们用 Thor 对比 PowerMonitor 进行了数据一致性的校验，误差<5mA，满足线上监控需求。

此外我们做了 Thor 采集功能本身的功耗影响，可以看到 1s 采集 1 次的情况下，平均电流上涨了 0.59mA，所以说这种方案的功耗影响非常低，适合线上采集电流值。

厂商自带耗电排行耗电排行

厂商提供的耗电排行也可以用来查看一段时间内的应用耗电情况。如下面华为的耗电排行里，对硬件和软件耗电进行了分拆，并给出了应用的具体耗电量。其他厂商 OV 也是支持具体的耗电量，小米则是提供耗电占比，并不会提供具体耗电量。

入口：设置->电池->耗电排行

功耗归因

从功耗评估我们可以判断应用的整体耗电情况，但具体到某个 case 高耗电的原因是什么，就要具体问题选择不同的工具来进行分析了。目前可以直接归因到业务代码的主要是 CPU 相关的工具，这也是我们目前分析问题的主要方向，后续我们也会建设流量归因等能力，下面我列举了常用的分析工具。

Battery Historian

谷歌官方提供的分析工具，需要先进行功耗测试，再通过 adb 抓取 bugreport.zip，再通过网页工具打开，可提供粗粒度的功耗归因。

本质上是对 systemserver 里的各种服务统计信息 手机状态 内核统计信息(kernel 唤醒)的展示，应用耗电的估算依赖厂商配置的 power_profile.xml。比较适合对整机耗电问题做耗电归因，如归因到某应用耗电较高。

对于单个应用，由于对 wakelock，alarm，gps，job，syncservice，后台服务运行时长等统计的比较详细，比较适合做后台耗电的归因。对于网络异常，CPU 异常，只能看到消耗较多，无法归因到具体业务。https://developer.android.com/topic/performance/power/setup-battery-historian?hl=zh-cn

AS Profiler

相比于 BatteryHistorian 需要先手动测试，再 adb 抓取的操作繁琐，AS 自带的 Profiler 提供了 Energy 的可视化展示。使用 debug 版本的应用，可以直观的看到功耗的消耗情况，方便了线下测试。需要注意的是这里展示的功耗值是通过 GPS 网络 CPU 计算的拟合值，并不是真实功耗值，只表征功耗水平。

Profiler 同步展示了 CPU 使用率，网络耗电，内存信息。支持 CPU 和线程级别的跟踪。通过主动录制 Trace，可以分析各线程的 CPU 使用情况，以及耗时函数。对于容易复现的 CPU 高负载问题或者固定场景的耗时问题，这种方式可以很容易看到根因。但 trace 的展示方式并不适合偶现的 CPU 高负载，信息量特别多反而让人难以抓住重点。

网络耗电可以很方便抓取到上行下行的网络请求，可以展示网络请求的 api 细节，并且划分到线程上。对于频繁的网络访问，很容易找到问题点。但目前只支持通过 HttpURLConnection 和 OkHttp 的网络请求，使用其他的网络库，Profiler 追踪不到。

可以看到官方出品的工具，功能比较完善，但只支持 debug 版本的 app 分析，如果要分析 release 版本的 app，需要使用 root 手机。总体而言，Profiler 比较适合于线下固定某个业务场景的分析。https://developer.android.com/studio/profile/energy-profiler

线程池监控

使用上面的工具监控单个线程的 CPU 异常是可以的。但是对于线程池，Handler，AsyncTask 等异步任务不太容易归因具体的业务，尤其是网络库的线程池，由于执行的网络请求逻辑是一样的，只靠抓线程堆栈是不能归因到具体业务的。需要统计提交任务的源头代码才能抓到真正问题点。

我们可以通过多种机制，如改造线程池，java hook 等，对提交任务方进行了详细记录和聚合，可以帮忙我们分析线程池里的耗时任务。

线上 CPU 异常精准监控

除了线下的 CPU 分析，我们在进行线上 CPU 异常监控的建设时，我们考虑到单纯使用 CPU 使用率阈值不能精准的判断进程是否处于 CPU 异常。比如不同的 CPU 型号本身的性能不同，在某些低端 CPU 上的使用率就是比较高。又比如系统有不同的温控策略，省电策略，会对手机进行限频，对任务进行 CPU 核心迁移。在这种情况下，应用也会有更高的 CPU 使用率。

因此我们基于不同的变量因素（如 CPU 型号，进程/线程的 CPU 时长在不同核，不同频点的分布，充电，电量，内存，网络状态等），将 CPU 的使用阈值进行精细判定，针对不同场景、不同设备、不同业务制定精细化的 CPU 异常阈值，从而实现了高精度的 CPU 异常抓取。

此外还有业界的一些归因框架，在这里不展开介绍了。

Facebook BatteryMetrics：从 CPU/IO/Location 等多种归因点采集数据，和系统 BatteryStatsService 的统计行为类似，偏重于线下做 App 的耗电评估和器件分解。WeChat BatteryCanary：提供了线程和线程池归因能力，相对于其他工具，增加前后台，亮灭屏，充放电，前台服务统计的统计。功耗优化实践

上面介绍了功耗的组成，以及如何分析我们应用的耗电。这里我们对功耗优化做一个整体性介绍。我们把优化思路从器件角度展开，列举我们有哪些优化的思路和措施，可以减少器件的使用情况，进而降低功耗。此外对于一些用户可感知的有损业务的降级，我们通过低功耗模式来做，在低电量时通过更激进的降级手段，缓解用户的电量焦虑，带来用户的使用时长的提升。

下图列举了各器件上的优化思路，有一些优化思路会对多个器件都有收益，在这里没有特别详细的区分，就划分在主要影响的器件上，如减少刷新区域，对 GPU，CPU，DDR 都有收益，主要收益在 GPU 绘制上，在下图里就列举在 GPU 上了。

同时我们列举了厂商侧的一些优化方案，应用通常无需关注，比如降低屏幕刷新率，TP 扫描频率，整机低分辨率等，这种可以通过厂商合作的方式进行更细致的调优，如分场景动态调整屏幕刷新率，在搜索列表场景使用 90HZ 高刷，在短视频场景结合帧率对齐进行刷新率降低为 30HZ，以获得更平衡的功耗和性能体验。

 2/6   首页 上一页 1 2 3 4 5 6 下一页 尾页