Android系统开发之唤醒与功耗

Richard_Gao 发布于2019-06-25 10:37 / 3416人阅读

摘要：一级代理的依据是我集成的代码开启了谷歌的一个服务，这个服务肯定造成了电量大量消耗。然而功耗并没有降低。谷歌的一个检测网络联通情况的服务，能和他们比吗，能导致待机功耗翻倍吗本文原作者长鸣鸟，转载不带名的严重鄙视。

本文原作者长鸣鸟，转载不带名的严重鄙视。
鄙人目前所在的项目为外包项目，而且属于二级代理。
客户要求整机降低功耗，一级代理就喷说是我们提交的代码造成的功耗过大，甚至指名道姓说是我干的。
内心火大只差掀桌。但掀桌也要先回喷完再掀。

一级代理的依据是：1.我集成的代码开启了谷歌的一个服务，这个服务肯定造成了电量大量消耗。
2.不知道我集成的代码还干了什么，但机器不停被唤醒，肯定是我的代码造成的，频繁唤醒肯定造成功耗过大，所以都是我的错。
第一条，拿掉了我的代码，功耗没有降低。为了喷他喷的更有力量，我继续探查第二条。
因为休眠状态下不能使用adb，所以我root后，拿到了/data/logs下面的日志文件，看到了如下内容：

08-09 16:26:18.430     0     0 I KERNEL  : [   57.893828] PM: noirq suspend of devices complete after 14.767 msecs
08-09 16:26:18.430     0     0 D KERNEL  : [   57.893837] Disabling non-boot CPUs ...
08-09 16:26:18.433     0     0 I KERNEL  : [   57.897084] smpboot: CPU 1 is now offline
08-09 16:26:18.436     0     0 I KERNEL  : [   57.900456] Platform supports Module Level DVFS
08-09 16:26:18.440     0     0 I KERNEL  : [   57.903735] smpboot: CPU 2 is now offline
08-09 16:26:18.444     0     0 I KERNEL  : [   57.908429] smpboot: CPU 3 is now offline
08-09 16:26:18.447     0     0 I KERNEL  : [   57.910825] pmc_atom: 16 - GBE in SC is in D0 prior to sleep
08-09 16:26:18.447     0     0 I KERNEL  : [   57.910832] pmc_atom: 17 - SATA in SC is in D0 prior to sleep
08-09 16:26:18.447     0     0 I KERNEL  : [   57.910837] pmc_atom: 32 - SMB in SC is in D0 prior to sleep
08-09 16:26:18.447     0     0 I KERNEL  : [   57.910841] pmc_atom: 34 - ISH in SC is in D0 prior to sleep
08-09 16:26:18.447     0     0 I KERNEL  : [   57.910880] ACPI: suspend to mwait
08-09 16:26:39.451     0     0 I KERNEL  : [   78.915223] ACPI: resume from mwait
08-09 16:26:39.452     0     0 I KERNEL  : [   78.915835] pmc_atom: pmc: wakeup status[4400]
08-09 16:26:39.452     0     0 I KERNEL  : [   78.915839] pmc_atom: pmc: rtc might wake up system!
08-09 16:26:39.452     0     0 I KERNEL  : [   78.915888] Suspended for 21.000 seconds
08-09 16:26:39.452     0     0 I KERNEL  : [   78.916368] Enabling non-boot CPUs ...
08-09 16:26:39.452     0     0 I KERNEL  : [   78.916586] x86: Booting SMP configuration:
08-09 16:26:39.452     0     0 I KERNEL  : [   78.916595] smpboot: Booting Node 0 Processor 1 APIC 0x2
08-09 16:26:39.470     0     0 I KERNEL  : [   78.934239] Skipped synchronization checks as TSC is reliable.
08-09 16:26:39.472     0     0 I KERNEL  : [   78.935848] CPU1 is up
08-09 16:26:39.472     0     0 I KERNEL  : [   78.936069] smpboot: Booting Node 0 Processor 2 APIC 0x4
08-09 16:26:39.489     0     0 I KERNEL  : [   78.953647] Skipped synchronization checks as TSC is reliable.
08-09 16:26:39.491     0     0 I KERNEL  : [   78.955680] Platform supports Module Level DVFS
08-09 16:26:39.491     0     0 I KERNEL  : [   78.955717] CPU2 is up
08-09 16:26:39.492     0     0 I KERNEL  : [   78.955756] smpboot: Booting Node 0 Processor 3 APIC 0x6
08-09 16:26:39.509     0     0 I KERNEL  : [   78.973296] Skipped synchronization checks as TSC is reliable.
08-09 16:26:39.509     0     0 I KERNEL  : [   78.973696] CPU3 is up
08-09 16:26:39.515     0     0 I KERNEL  : [   78.979035] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
08-09 16:26:39.515     0     0 I KERNEL  :  SUBSYSTEM=pci
08-09 16:26:39.515     0     0 I KERNEL  :  DEVICE=+pci:0000:00:14.0
08-09 16:26:39.521     0     0 I KERNEL  : [   78.985310] PM: noirq resume of devices complete after 10.832 msecs
08-09 16:26:39.542     0     0 I KERNEL  : [   79.006029] PM: early resume of devices complete after 20.506 msecs
08-09 16:26:39.543     0     0 D KERNEL  : [   79.007057] mei_txe 0000:00:1a.0: irq 138 for MSI/MSI-X
08-09 16:26:39.543     0     0 D KERNEL  :  SUBSYSTEM=pci
08-09 16:26:39.543     0     0 D KERNEL  :  DEVICE=+pci:0000:00:1a.0
08-09 16:26:39.547     0     0 D KERNEL  : [   79.011106] bq27x00_battery_resume num=0,C1=91

根据08-09 16:26:39.452 0 0 I KERNEL : [ 78.915839] pmc_atom: pmc: rtc might wake up system!看来设备是频繁被rtc定时器唤醒的。那我们就来研究定时器的问题。
终端输入：

adb shell dumpsys alarm

本文原作者长鸣鸟，转载不带名的严重鄙视。
可以看到：

Past-due non-wakeup alarms: (none)
    Number of delayed alarms: 4, total delay time: +1m1s294ms
    Max delay time: +48s261ms, max non-interactive time: +11m37s993ms

  Broadcast ref count: 0

  mAllowWhileIdleMinTime=+5s0ms
  Last allow while idle dispatch times:
  UID u0a12: -7m16s759ms

  Top Alarms:
    +1s201ms running, 0 wakeups, 10 alarms: 1000:android
      *alarm*:android.intent.action.TIME_TICK
    +1s66ms running, 0 wakeups, 5 alarms: u0a18:com.len.new.service
      *alarm*:com.len.new.service/com.len.ue.biz.v1.app.AppRunningStateReceiver
    +976ms running, 0 wakeups, 1 alarms: 1000:android
      *alarm*:android.content.jobscheduler.JOB_DELAY_EXPIRED
    +877ms running, 0 wakeups, 5 alarms: u0a18:com.len.newue.service
      *alarm*:com.len.new.service/com.len.ue.biz.v2.device.DeviceUsageReceiver
    +659ms running, 0 wakeups, 1 alarms: 1000:android
      *alarm*:com.android.server.action.NETWORK_STATS_POLL
    +654ms running, 0 wakeups, 1 alarms: u0a18:com.len.new.service
      *alarm*:com.len.new.service/com.len.ue.biz.v2.app.usage.AppUsageReaperReceiverV2
    +72ms running, 6 wakeups, 6 alarms: u0a12:com.google.android.gms
      *walarm*:com.google.android.intent.action.GCM_RECONNECT
    +42ms running, 0 wakeups, 2 alarms: u0a118:com.emoji.keyboard.touchpal
      *alarm*:com.cootek.presentation.action.CONFIG_UPDATE
    +41ms running, 0 wakeups, 2 alarms: u0a118:com.emoji.keyboard.touchpal
      *alarm*:com.cootek.usage.alarm_operation
    +31ms running, 3 wakeups, 3 alarms: u0a12:com.google.android.gms
      *walarm*:com.google.android.gms.gcm.ACTION_CHECK_QUEUE

可以看到设备息屏期间是被com.google.android.gms.gcm唤醒的。
于是干掉谷歌的服务再测试：

08-09 09:11:38.039     0     0 I KERNEL  : [  177.417637] PM: noirq suspend of devices complete after 13.452 msecs
08-09 09:11:38.039     0     0 D KERNEL  : [  177.417645] Disabling non-boot CPUs ...
08-09 09:11:38.042     0     0 I KERNEL  : [  177.420574] smpboot: CPU 1 is now offline
08-09 09:11:38.045     0     0 I KERNEL  : [  177.423234] Platform supports Module Level DVFS
08-09 09:11:38.048     0     0 I KERNEL  : [  177.426292] smpboot: CPU 2 is now offline
08-09 09:11:38.052     0     0 I KERNEL  : [  177.430330] smpboot: CPU 3 is now offline
08-09 09:11:38.054     0     0 I KERNEL  : [  177.432385] pmc_atom: 16 - GBE in SC is in D0 prior to sleep
08-09 09:11:38.054     0     0 I KERNEL  : [  177.432391] pmc_atom: 17 - SATA in SC is in D0 prior to sleep
08-09 09:11:38.054     0     0 I KERNEL  : [  177.432394] pmc_atom: 32 - SMB in SC is in D0 prior to sleep
08-09 09:11:38.054     0     0 I KERNEL  : [  177.432397] pmc_atom: 34 - ISH in SC is in D0 prior to sleep
08-09 09:11:38.054     0     0 I KERNEL  : [  177.432422] DSP in NC is in D0 prior to suspend
08-09 09:11:38.054     0     0 I KERNEL  : [  177.432434] ACPI: suspend to mwait
08-09 09:50:52.736     0     0 I KERNEL  : [ 2532.114465] ACPI: resume from mwait
08-09 09:50:52.737     0     0 I KERNEL  : [ 2532.115110] pmc_atom: pmc: wakeup status[4001]
08-09 09:50:52.737     0     0 I KERNEL  : [ 2532.115159] Suspended for 2355.000 seconds
08-09 09:50:52.737     0     0 I KERNEL  : [ 2532.115360] chv_gpio: irq[131] might wake up system!
08-09 09:50:52.737     0     0 I KERNEL  : [ 2532.115480] Enabling non-boot CPUs ...

测试的40分钟内，正常休眠2355s无唤醒。
然而功耗并没有降低。
所以说总有一些一知半解的人，觉得谷歌的代码这也要改，那也可以优化，谷歌的服务都是耗电大户，避之唯恐不及。都是在那坐井观天，想当然。你们要是真有优化的水平怎么不上天呢？
另外应用唤醒cpu本身并不会消耗很多电量，关键是要看它唤醒了干嘛，雷军之前曾说你手机装了Top100，肯定没续航。那也是第三方应用不规范，后台传数据导致的，而且是装了100个。谷歌的一个检测网络联通情况的服务，能和他们比吗，能导致待机功耗翻倍吗？
本文原作者长鸣鸟，转载不带名的严重鄙视。

专线服务私有云 android与开发 android开发与实战 android开发与应用 html5与android开发

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/13063.html

Android我还可以相信你多少系列文章一之推送

摘要：于是演变出了很多变种，每个厂家自研一套，比如小米，华为都是对外公开。根据我们的经验同时接入小米和华为，在华为手机上面走华为推送，在其他手机上面走小米推送。还要警惕的是，接入推送之后有可能存在消息延迟，这完全依赖于推送服务提供商的后台服务。我即将在2017.7.8号开一个直播讲堂，感兴趣的同学点击快来参加吧：https://segmentfault.com/l/15...内容包括： ...

seanlook 2019-06-25 11:15 评论0 收藏0
ACPI Specification 第三章 ACPI概念

摘要：兼容的电池设备需要智能电池子系统接口由操作系统直接通过嵌入式控制器接口控制或接口。这允许任何操作系统提供一个标准的总线枚举器，它可以直接与系统中的嵌入式控制器通信，从而允许系统中的其他驱动程序与系统中的嵌入式控制器通信并使用它们的资源。目录第三章 ACPI 概念... 2 3.1系统电源...

roadtogeek 2021-09-09 09:33 评论0 收藏0
性能优化6--电量优化

摘要：数据压缩通过数据压缩等方式缩减传输时间，降低电量消耗，此章节可以参考性能优化八之网络优化。性能问题不仅仅在于发现之后的优化更改，更在平时的防微杜渐。1、电量测试Android4.1版本之后在系统增加了battery info模块，记录一定时间周期内整机及单个App的电量消耗。2.1 注册广播ACTION_BATTERY_CHANGED IntentFilter filter = new ...

miqt 2019-04-23 17:16 评论0 收藏0
玩转Android- 收藏集 - 掘金

摘要：附各种权限详细处理掘金前言对于运行时权限的处理方式网上有很多，包括注解，等等。进阶篇显示网页详解掘金概述是用于显示网页的控件。经过调查复杂列表的实现掘金控件从发布以来，目前已经普遍用于项目中，来承载各种列表内容。美团点评前端无痕埋点实践 - 前端 - 掘金构建一个数据平台，大体上包括数据采集、数据上报、数据存储、数据计算以及数据可视化展示等几个重要的环节。其中，数据采集与上报是整个流...

Jonathan Shieber 2019-06-25 11:28 评论0 收藏0
（超简单）ESP8266深度睡眠模式下远程采集温湿度信息

摘要：超简单深度睡眠模式下远程采集温湿度信息项目背景相关技术深度睡眠模式温湿度采集数据收发前后端实现后端前端项目背景自己用收纳箱做了一个用于存放打印耗材的干燥箱，想用闲置的开发板和温湿度传感器做一个远程温湿度监测的小项目。 ...

pkhope 2021-11-18 10:02 评论0 收藏0