Android系统开发之唤醒与功耗

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

一级代理的依据是：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个。谷歌的一个检测网络联通情况的服务，能和他们比吗，能导致待机功耗翻倍吗？
本文原作者 长鸣鸟 ，转载不带名的严重鄙视。