‘壹’ Android后台进程保活方案
思想： 使用 Linux 中的 fork 机制创建 Native 进程，在 Native 进程中监控主进程的存活，当主进程挂掉后，在 Native 进程中立即对主进程进行拉活。
原理： 在 Android 中所有进程和系统组件的生命周期受 ActivityManagerService 的统一管理。Android5.0以下通过 Linux 的 fork 机制创建的进程为纯 Linux 进程，其生命周期不受 Android 的管理。
该方案主要适用于 Android5.0 以下版本手机。
该方案不受 forceclose 影响，被强制停止的应用依然可以被拉活，在 Android5.0 以下版本拉活效果非常好。
详情
对于 Android5.0 以上手机，系统虽然会将native进程内的所有进程都杀死，这里其实就是系统“依次”杀死进程时间与拉活逻辑执行时间赛跑的问题，如果可以跑的比系统逻辑快，依然可以有效拉起。在 某些 Android 5.0 以上机型有效。
详情
https://github.com/Marswin/MarsDaemon
作者5.0以下系统用一个java进程和一个fork出来的纯native进程双管道互锁监听对方的状态，无论哪个被杀后都拉起第三个进程，第三个进程来拉活常驻进程，实现拉活。
5.0以上同一进程组的进程会被同时杀死，所以5.0以上使用双java进程在native层互锁文件实现监听，但任务管理器会在短时间内杀死所有进程，只能用反射提前初始化pacel，在进程被杀的时候和系统抢那几十毫秒的时间发送一个拉活的广播。用4个文件来让两个进程实现互锁来做监听，但实际效果很一般，测试了几个5.0以上的国产机型都不行，效果是根本监听不到进程被杀，目测原因是当任务管理器查杀进程的时候将所有的进程都挂起了，随后全部杀掉，并在一段时间内禁止进程启动。
PersistedJobService.java
BootReceiver.java静态注册BroadcastReceiver
注册，开机，网络切换、拍照、拍视频时候，利用系统产生的广播也能唤醒app，不过Android N已经将这三种广播取消了
常用的拉活权限
BackgroundService.java
WakeLock
作为前台应用运行，提高应用存活几率
service被关掉后自动启动
START_STICKY
如果系统在onStartCommand返回后被销毁，系统将会重新创建服务并依次调用onCreate和onStartCommand（注意：根据测试Android2.3.3以下版本只会调用onCreate根本不会调用onStartCommand，Android4.0可以办到），这种相当于服务又重新启动恢复到之前的状态了）。
START_NOT_STICKY
如果系统在onStartCommand返回后被销毁，如果返回该值，则在执行完onStartCommand方法后如果Service被杀掉系统将不会重启该服务。
START_REDELIVER_INTENT
START_STICKY的兼容版本，不同的是其不保证服务被杀后一定能重启。
service注册，权限设置为高优先级
KeepAliveService.java
注册，在新的独立进程内启动，适用5.0以下的原生系统，5.0以上同样会被杀死
他的局限性在于：
第一，用户会在系统设置的账户列表里面看到一个不认识的账户；
第二，同步的事件间隔是有限制的，最短1分钟，见源码，如果小雨60秒，置为60秒。而且各种国产机怎么改的源码我们未可知，是不是都能用仍然未可知；
第三，很致命，某些手机比如note3需要手动设置账户，你如何骗你的用户给你手动设置账户完了之后不卸载你；
第四，也很致命，必须联网！google提供这个组件是让你同步账户信息，不联网你同步个鬼，我们要保活，可以不联网不做事，但是不能不联网就死
集成三方推送平台sdk，友盟极光等