Android service保活方案

网上有很多介绍保活的文章，还有一些极客利用Native保活service，确实很有想法~
我这个方案不算新鲜，不过确实解决了我的问题，达到了我想要的效果，我的业务是：APP启动之后，在用户无感知的情况下， 拉取用户所有照片上传到服务器(没有恶意，仅仅是为了锻炼技术)

ok,现在步入正题，首先我想要保活的是Service，但是普通的service是依赖于APP的，所以我将service设置了

android:process=":uploadImage"

你懂得，将service设为进程级别。

虽然我们的service目前不依赖APP，但是却不能顽强的存活，经不起手机卫士来搞事情，所以我们需要在service中重写onStartCommand方法，这个方法有四种返回值：

START_STICKY：如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到service，那么参数Intent将为null。

START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务。

START_REDELIVER_INTENT：重传Intent。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。

START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。

ok,这里我使用的是START_STICKY，经测试START_REDELIVER_INTENT的效果和START_STICKY，而且START_STICKY属性使service的重启速度更快。

现在的service算是比较顽强了，但是为了保险起见，我又注册一个广播，然后在service的onDestroy中发送广播，在广播中实现拉起：

class KeepAliveReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        context.startService(Intent(context, ImageHandleService::class.java))
    }
}

到此结束，现在的service还不算很安全，还可以做更安全的方案优化，比如再开启一个守护进程，实时监听。

要使自己的Service能够一直运行,最简单的方法就是重写onStartCommand方法就好了.但是千万不要做坏事,不要做被用户鄙视的恶意程序

进程保活方案：AlarmManager + JobScheduler + service原生方法onStartCommand + 广播保活 + 双进程守护。

笔者能力有限，不足之处欢迎指出。