Android 运行后台服务的生命周期与使用技巧

核心提示：Running Norm Proc # 4: oom_adj= 8 ProcessRecord{4367e838 12761:android.process.acore/10016}Running Norm Proc # 3: oom_adj= 8 ProcessRecord{43691cd8 12754:com.go

Running Norm Proc # 4: oom_adj= 8 ProcessRecord{4367e838 12761:android.process.acore/10016}

Running Norm Proc # 3: oom_adj= 8 ProcessRecord{43691cd8 12754:com.google.process.gapps/10000}

Running PERS Proc # 1: oom_adj=-12 ProcessRecord{43506750 5941:com.android.phone/1001}

Running PERS Proc # 0: oom_adj=-100 ProcessRecord{4348fde0 5908:system/1000}

返回的一大堆东西，观察 oom_adj 的值，如果是大于 8 一般就是属于 backgroud 随时可能被干掉，数值越小证明优先级越高，被干掉的时间越晚。你看phone的程序是 -12 说明电话就是电话，其他什么都干了了，也的能接电话对吧。另外还有一个 -100 的，更邪乎因为是 system 如果他也完蛋了，你得系统也就挂了，嘿嘿。

用其他方式启动 Service

其实不光能从 Activity 中启动 Service ，还有一个很有用的方法是接收系统的广播，这就要用到 Receiver 。在 Mainfest 文件中配置你得 Receiver 能接收什么样的广播消息，那么即使你得程序没有显示给用户，你的 Service 也能启动。你要做的就是继承 android.content.BroadcastReceiver ，然后实现 onReceive(Context context, Intent intent) 方法，就可以启动你得 Service 了。这里不能 bindService 因为一个 Receiver 是一个短暂存在的对象，所以 bind 是没有什么意义的。

资源消耗

大家都说 G1 的电池太不抗用，这个问题其实我看来跟多是软件的问题。1150毫安的电池不算大，但也不算小了，考虑到 500mhz 的 CPU 还是非常耗电的。因为一个 Service 要长时间后台运行，所以如果你得 Service 太过于消耗资源那电池更用不了多久了。

对于这个问题我有一点点考虑，和大家分享一下。因为一般 Service 都会启动另外的线程不断循环作一些操作，循环频率不易太高。也不要做太过于耗费资源的操作，特别是CPU资源，因为后台 Service 用户看不到，会比较莫名奇妙。具体可以结合 top 以及 logcat 监测使用情况。LOG中如果虚拟机频繁的 GC 应该也说明程序还有很大改进的余地。因为GC 也是很耗费CPU的。可能这些不光 Service 应该注意，只要是移动设备都应该考虑，才能给你的用户最佳的体验。