应用耗电怎么办？

作者: _qisen | 来源:发表于2017-06-03 18:11 被阅读114次

应用耗电怎么办？
史上最全！Android程序性能优化之耗电优化（一）
APP性能优化
Android应用耗电优化
Android应用耗电优化
应用耗电的统计
iOS耗电量检测与优化
iOS耗电量检测与优化
Android高手笔记 - 耗电优化
Android O 后台startService限制简析

前些时候，收到短信提示，域名又将要过去，一晃又是一年过去了。我在购置 woaitqs.cc 这个域名的时候，没有想过自己会坚持这么久（最近太忙，有些懈怠，逃：））。算上从开始统计博文访问量，到今天截止，共计 102803 人次，虽然这个人数还是很少很少，不过也算一个小的里程碑了。今晚吃饭，加个🥚 鸡蛋，不两个🥚 鸡蛋。

厂商在预装你的 APP 之前，通常会进行功耗测试。这种功耗测试，与研发进行的测试不同，可不是通过 ADB 或者 Android Studio Monitor 进行验证的，而是通过特定的 功耗仪 来进行的。以前，厂商在进行测试的时候，会扣取手机的电池，并换上对应的仪器，通过这个仪器上的电流消耗，可以较准确地判断该应用是否有功耗问题。

那么，如果我们的应用被厂商告知，有性能问题时，又不提供相应的仪器(测量方式一般为机密)情况下，如何快速定位功耗问题了？

定性分析

Android 开发就免不了与系统服务打交道，功耗相关的服务也是属于其中的一种。

adb shell dumpsys [system service name]

用法如上所示，非常简单，举几个例子。adb shell dumpsys activity 显示 ActivityManager 相关的信息，adb shell dumpsys alarm 显示的是 Alarm 服务相关的信息。power 则是系统的电源管理服务，我们能否通过 dumpsys power 获取到需要的信息吗？

不过很遗憾，这里面提供的信息并不是很足够。这个 power 列举了电源相关的很多东西，大多都用不上。不过有个地方，还是能帮助到我们的。

WakeLock Summary。wakelock 是告知系统还有服务需要进行，只有有一个 wakelock 存在，系统就不能进入睡眠中。通过这个可以判断是否有程序调用了这个，而并没有释放，这可能是导致功耗问题的原因之一。

在后续的调研中，发现了另一个很好用的系统服务batterystats，这个服务提供的信息远多于power, 而用法也并不难。

adb shell dumpsys batterystats --enable full-wake-history；容许开启完整的 wake 历史。
adb shell dumpsys batterystats --reset；清空以前的信息
在应用上进行一段时间的操作
adb shell dumpsys batterystats [your package name]> sample.txt；这样所有的信息就在这个 sample 文件中了。

是不是很棒啊？23333

我们来分析下，得到的结果。结果主要分为 Daily stats,
Statistics since last charge, Device battery use since last full charge 以及 UID info。这里只用关心，UID 相关的信息即可。

u0a151:
  Wake lock *alarm* realtime
  Wake lock AudioMix realtime
  Wake lock *launch* realtime
  Wake lock WindowManager realtime
  Sensor GPS: (not used)

在这个信息块中，将记录应用进行了哪些消耗电量的操作。在上面的例子中，可以看到 AlarmService、AudioMix 等都消耗了电量，而没有使用传感器。

对这个管兴趣的同学，可以继续看这个链接。https://commonsware.com/Android/previews/power-measurement-options

定量解决

前面提供了一些定量分析的方法，但这些信息还是太泛，我们要的是具体的解决方案，需要从代码上解决功耗问题。那么我们就细细地思考下，如何来分拆这些问题。

CPU 消耗过多
网络请求
传感器与屏幕唤醒

耗电通常是由上诉三个方面引起的，我们一个一个地突破它们。

首先是 传感器与屏幕唤醒, 这个可以通过前面提到的方法，找到应用是否在该时间段内调用过传感器，或者 wakelock。如果确实存在这样的问题，就直接在项目中查找，关于 GPS、wakelock、Sensor 等等的调用，在找到源头之后，进行合适的处理即可。

然后是 网络请求, 我们得借助于 Android Monitor，找到其中的 Network 区域，在这区域中，如果发现确实还有网络波动，说明在此时进行了不应该发生的网络请求，从而导致在厂商这里没有通过测试。如果项目，都是使用统一的网络模块，那就在源头处加上日志、或者断点调试等方式，来帮助我们定位问题。

monitor network

最后才是 CPU 消耗过多, 这次厂商提及的问题就是放生在这一块。告知我们在保持屏幕不动、未进行操作时，仍有电量消耗。通过 Monitor 中的 CPU 区域，确实发现有相应的活动。此时，一个伟大的神器就帮助了我，那就是 TraceView。这个工具实在太好用，关于这个工具的用法，也有很多教程，就不再赘述了。

总之，是想告诉大家分析问题的方法，遇事不慌，冷静下来，总有解决的方法。