本文原作者 长鸣鸟 ，转载不带名的严重鄙视。
鄙人目前所在的项目为外包项目，而且属于二级代理。
客户要求整机降低功耗，一级代理就喷说是我们提交的代码造成的功耗过大，甚至指名道姓说是我干的。
内心火大只差掀桌。但掀桌也要先回喷完再掀。 一级代理的依据是：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个。谷歌的一个检测网络联通情况的服务，能和他们比吗，能导致待机功耗翻倍吗？
本文原作者 长鸣鸟 ，转载不带名的严重鄙视。