程序被系统kill——Service进程滥用

• 问题描述

程序在后台常驻运行过程中被某厂商手机系统kill，发现kill进程的是系统的电量管理相关进程。但是手机已经赋予我们APP所有权限，依然会被kill。

我们通过开启手机工程模式，得到以下日志：

• 分析

通过日志分析，发现download进程短时间内启动了124次，现在问题可以初步定为到:download进程。通过查找源码发现，该进程是一个Service进程，使用完毕后会自己kill掉进程。

日志：

相应代码：

• 原因

现在原因就比较清晰了，Service服务进程在执行完任务后，进行了自杀（强杀System.exit(0)）从而被系统认为是crash，紧接着就会被系统拉起，然后服务定期自杀检测，进行自杀，接着又被拉起……。这样系统就会认为该进程在不断的crash，从而认为该应用有问题，然后把应用添加到“禁止启动列表”，应用被拉黑，然后杀死整个进程组（我们是多进程应用）。

• 解决

使用Service的stopself方法或者onDestroy方法，服务结束后，所在进程的回收交给安卓的垃圾回收机制来做，这样问题得到了解决。

• 建议&规范

Service销毁方式

Service进程在处理完任务后，要使用安卓Service的stopself方法或者onDestroy方法结束Service，所在进程的回收交给安卓的垃圾回收机制来做。因为不同的rom的表现可能不同，有些rom会出现异常退出现象、有些rom会出现高耗电提醒、有些rom没有表现出来。如非必要，建议不要手动去杀死进程（注：stopSelf()之后调用System.exit(0)并没有在示例问题rom上发现问题，但不代表所有rom都没问题）。

另外，android.os.Process.killProcess(android.os.Process.myPid())和使用System.exit(0)会有同样的问题。

onStartCommand返回值

建议不要修改onStartCommand方法的返回值，都交由系统处理比较好。（例如，返回START_NOT_STICKY如果真是意外崩溃，进程就不会

重启，这不是我们想要的结果）。

• 扩展

onStartCommand()方法返回值是一个整数，可选范围有：

START_STICKY

START_NOT_STICKY

START_REDELIVER_INTENT

START_STICKY_COMPATIBILITY

返回值为START_STICKY时，Service被异常kill掉，会被系统拉起，但Intent内容丢失。

返回值为START_NOT_STICKY时，Service被异常kill掉时，不会被系统拉起。

返回值为START_REDELIVER_INTENT时，Service被异常kill掉时，会被系统拉起，并且Intent内容保留。

返回值为START_STICKY_COMPATIBILITY时，START_STICKY的兼容版本，但不保证服务被终止后一定能重启。