Android服务开发经验——优雅地活着 by个推推送

具体来说，就是要做到两点：
1. 尽可能运行
2. 尽可能省电

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

尽可能运行
Android系统会根据当前资源状况（主要是内存空闲的情况）对后台服务进行不定期的清理，尤其是当内存高度紧张时，会出现大堆服务交替处于“正在重启服务”的状态。前台服务可以避免这个问题的发生，但是前提条件是你需要在通知栏显示一个置顶的无法清除的硕大的通知栏。如果你的应用恰巧是类似墨迹天气或者360这样正好需要一直给用户展示这样的一个通知栏，那么恭喜你，你可以忽略这个头痛的进程回收问题；但是对大多数后台服务来说，显示这样的通知并不合适。你可以尝试修改服务优先级，但是在大多数手机上并不会有什么本质上的变化。
另外一个需要考虑的问题是用户越来越频繁的“一键清理”操作，无论是系统内置的一键清理功能，还是通过360、猎豹等提供的一键清理，都会增加服务杀死或重启的几率。当然，如果你的应用有正当理由请求用户授予root权限，那么太好了，同样也可以通过各种你懂的方式确保你的Service正常运行。

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

为了更好地在耗电方面进行优化，首先需要了解到每唤醒一次AP核，都会带来一段时间的固定开销（可能是几百ms），然后再重新休眠，即使你什么也不做。其次，唤醒后的耗电，一般只与工作时长有关，与工作强度关系不大，就我目前所知大多数ARM芯片还没有类似Intel芯片那种调频功能。
此外，负责网络处理的CP核的开启需要非常小心，因为CP核是耗电大户，而且为了提高网络通讯效率，CP核开启后会保持比AP核更长的工作时间，根据手机和网络类型的不同，可能是1到5s甚至是更长时间。最后，也是最好理解的，每开启一个外设，都会额外增加耗电。
所以，优化的措施主要就是尽可能减少唤醒的频率，以及进行任务合并，尤其是网络相关的操作，尽量合并到同一时间内处理。在文件IO（尤其是网络IO）期间，AP核如果无所事事，就尽量不要占用Wakelock，释放出来。当有网络事件需要处理时，CP负责唤醒AP，进行后续操作。要实现这点很不容易，根据业务需求，程序结构上需要做很细致的规划。最后就是，尽量别碰其他的外设。

下面来看一下国内专业推送服务商 “个推”是怎么做的，作为专注推送三周年领先者，个推的做法是：1，开启流量合并通道。目前，大多第三方信息推送采用的方式是，为应用开发者提供SDK包嵌入应用程序来实现信息的推送。于是，每个用户的手机里可能会有多个应用都包含了个推的SDK，也就是服务通道。这样，每个SDK在信息推送过程中，都会消耗一小部分的流量。个推可以自动将这样的多个推送服务通道合并，只开启一个通道即可。2，增量更新下载,，一般当应用有新版本时，我们都需要下载一个全新的安装包，个推推送的应用版本更新通知时，只要升级差量部分即可，也起到很好的省电省流量的效果。

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