Android服务开发经验——优雅地活着

具体来说，就是要做到两点：

1. 尽可能运行

2. 尽可能省电

看似寻常的道理，实现起来还真不容易，下面一个个来看：

尽可能运行

Android系统会根据当前资源状况（主要是内存空闲的情况）对后台服务进行不定期的清理，尤其是当内存高度紧张时，会出现大堆服务交替处于“正在重启服务”的状态。前台服务可以避免这个问题的发生，但是前提条件是你需要在通知栏显示一个置顶的无法清除的硕大的通知栏。如果你的应用恰巧是类似墨迹天气或者360这样正好需要一直给用户展示这样的一个通知栏，那么恭喜你，你可以忽略这个头痛的进程回收问题；但是对大多数后台服务来说，显示这样的通知并不合适。你可以尝试修改服务优先级，但是在大多数手机上并不会有什么本质上的变化。

另外一个需要考虑的问题是用户越来越频繁的“一键清理”操作，无论是系统内置的一键清理功能，还是通过360、猎豹等提供的一键清理，都会增加服务杀死或重启的几率。当然，如果你的应用有正当理由请求用户授予root权限，那么太好了，同样也可以通过各种你懂的方式确保你的Service正常运行。

最后一个让你头疼的问题是休眠，嵌入式系统从来都会被设计成利用CPU提供的低功耗模式最大限度降低整机电流消耗，Android系统也不例外。传统上Android手机处理器被划分为AP核和CP核两部分，AP核负责系统和应用，CP核负责无线网络相关的功能，有些高端机还可能具备其他的功能核心，此外还有各式各样的外设，如GPS、传感器、LCD等。为了最小化电流消耗，当前用不到的功能模块都会通过芯片管脚直接切断电流供应或者切换成低功耗模式，其中也包括AP核。AP核一旦处于低功耗模式，通常情况下只能依靠硬件中断才能重新运行，包括CP核过来的网络事件、物理按键、或者是硬件Timer。因此，你的Service可能在任何时候突然停止运行，这个突然而来的STOP可能出现在你的任何进程中的任何线程中正在执行的任何一行代码，绝对不要假设Android系统会礼貌地等你执行完任何一个函数！

所以首先Service需要在架构上设计成可以应付随时重启，不要相信随时都能从缓存中获取到你想要的一切，定时器也经常无法按照你预想的正常工作，数据持久化方案需要花费更多的精力进行设计。另外为了隔离Service对主程序的影响，强烈建议将需要常驻后台的服务配置成独立进程，通过AIDL与主进程通讯。最后，务必配合使用电源管理Wakelock和闹铃管理AlarmManager来控制避免系统进入休眠状态。

尽可能省电

上面说到通过AlarmManager和Wakelock来确保Service的正常运行，然而频繁地唤醒系统以及用Wakelock锁定CPU就像是喝酒，适时适量有益身心健康，过度沉迷就会危及生命。一旦管理出问题，手机耗电量就会直线上升。目前多数手机厂商都是使用平均电流来评估应用的耗电量，即计算一定时间内未安装应用和安装应用情况下整机平均电流，两值相减即为应用的平均电流。通常Android手机待机状态下平均电流在8mA左右，如果你希望你的应用内置到某款手机上，对不起，手机厂商对于耗电问题绝不手软，高于5mA平均电流消耗的应用通常是无法被接受的。如下图那样如果长时间工作导致持续高电流，会成倍增加应用的平均电流值。

为了更好地在耗电方面进行优化，首先需要了解到每唤醒一次AP核，都会带来一段时间的固定开销（可能是几百ms），然后再重新休眠，即使你什么也不做。其次，唤醒后的耗电，一般只与工作时长有关，与工作强度关系不大，就我目前所知大多数ARM芯片还没有类似Intel芯片那种调频功能。

此外，负责网络处理的CP核的开启需要非常小心，因为CP核是耗电大户，而且为了提高网络通讯效率，CP核开启后会保持比AP核更长的工作时间，根据手机和网络类型的不同，可能是1到5s甚至是更长时间。最后，也是最好理解的，每开启一个外设，都会额外增加耗电。

所以，优化的措施主要就是尽可能减少唤醒的频率，以及进行任务合并，尤其是网络相关的操作，尽量合并到同一时间内处理。在文件IO（尤其是网络IO）期间，AP核如果无所事事，就尽量不要占用Wakelock，释放出来。当有网络事件需要处理时，CP负责唤醒AP，进行后续操作。要实现这点很不容易，根据业务需求，程序结构上需要做细致的规划。最后就是，尽量别碰其他的外设。

结束

没有一个应用希望自己长期占据软件耗电排行榜首，如果应用不再前台运行的时候也想做点有意义的事，就需要非常谨慎。如果每个应用都不顾他人的感受在手机上尽情撒野，那么总会有人站出来把这样的熊孩子揪出来干掉的。资源是大家的，请珍惜每1mAh的电。

下面来看一下国内专业推送服务商 “个推”是怎么做的，作为专注推送三周年领先者，个推的做法是：

1、开启流量合并通道。目前，大多第三方信息推送技术采用的方式是，为应用开发者提供SDK包嵌入应用程序来实现信息的推送。于是，每个用户的手机里可能会有多个应用都包含了个推的SDK，也就是服务通道。这样，每个SDK在信息推送过程中，都会消耗一小部分的流量。个推可以自动将这样的多个推送服务通道合并，只开启一个通道即可。

2、增量更新下载。一般当应用有新版本时，我们都需要下载一个全新的安装包，个推推送服务的应用版本更新通知时，只要升级差量部分即可，也起到很好的省电省流量的效果。