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個。谷歌的一個檢測網絡聯通狀況的服務，能和他們比嗎，能致使待機功耗翻倍嗎？
本文原做者 長鳴鳥 ，轉載不帶名的嚴重鄙視。