进程保活

一、应用自身保活：

1、多进程相互唤醒：当系统内存不足时系统会杀掉部分进程，这个过程是以进程（pid）为单位来进行的（我测试的时候是通过一个应用里面fork出20个进程，每个进程再申请内存，ps发现系统不会把应用关掉，而是杀死其中的某一个进程），因此，我们可以通过多进程Binder绑定的方式来实现相互唤醒，这种方式无法解决强制关闭的情况，因为强制关闭是以应用（uid）为单位进行的

2、提高进程优先级：这种方式可以有效降低应用被杀死的概率，下面简单说一下系统杀进程的规则，Android进程回收内存的机制叫Low Memory Killer ，它是基于Linux内核的 OOM Killer（Out-Of-Memory killer）机制诞生。再科普一下oom_adj，它代表Linux进程的优先级，进程回收机制就是根据这个优先级来决定是否进行回收，进程的oom_adj越小，表示进程优先级越高，越不容易被杀回收，普通app进程的oom_adj>=0，系统进程的oom_adj才可能<0，其中，核心进程init的值为-16，前台Activity为0，前台Service为2，后台Activity为7等等。查看进程优先级的方法：cat /proc/进程ID/oom_adj，另外，设置presisitent也可以提高优先级

3、让service.onStartCommand返回START_STICKY：如果service进程被kill掉（内存不足时），保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，通过实验发现，当应用被意外杀死时，如果onStartCommand返回START_STICKY，过一会Service进程又会出现在任务管理器中

4、Service执行onDestory时，发送广播启动Service

5、监听系统广播：注册静态的BroadcastReceiver，来接收（开机广播、网络切换等），但是大部分情况是无效的

二、多应用相互保活：

1、多应用广播唤醒：同一个厂商之间的app约定唤醒的Action

在Android3.1之后，系统的PMS增加了对处于stopped状态应用的管理，这个stopped和Activity生命周期中的stop状态是完全两码事，指的是安装后从来没有启动过的应用，与此同时系统增加了2个Flag：FLAG_INCLUDE_STOPPED_PACKAGES和FLAG_EXCLUDE_STOPPED_PACKAGES ，来标识一个intent是否激活处于stopped状态的应用。不过google还是留了点余地，允许应用通过给广播intent设置FLAG_INCLUDE_STOPPED_PACKAGES来唤醒处于“stopped state”的程序，也就是用户自己写的广播intent可以控制这个机制，但是我们无法修改系统广播的intent

通过上面的介绍，手机注册静态广播来接收系统事件，原则上来说是可以自启动的，为什么在有些手机上，应用被杀死之后就接收不到系统事件了呢。我在实验的时候，先是通过adb kill掉进程，然后应用能通过系统广播启动，android原生系统强制关闭应用后也能通过系统广播启动，中兴A2手机强制关闭应用后就接收不到系统广播，后来查了一下资料，国产ROM会在强制停止应用时会将应用重置为stopped状态，这样就应用就接收不到系统广播了

三、Root手机应用保活

1、首先将应用变为系统应用来保活：我们自己安装的应用默认是安装在在/data/app目录下，系统应用是安装在/system/app目录下，我们可以将/data/app目录下的内容剪切到/system/app下面，重启手机即可

2、设置android:persistent="true"，在apk的AndroidManifest.xml文件中设置android:persistent=true，此apk需要放入到system/app目录下，成为一个systemapp，同时oom_adj（进程优先级）被设置为CORE_SERVER_ADJ，此值为-12，我自己做了一个demo，对一个设置了persistent属性的系统应用，用任何办法杀掉都会立刻重启

保活终极（永生）大法：安装系统应用并设置android:persistent属性，用户不可卸载，不会被杀死，且开机自启动，通过这个系统应用来发送自定义广播，激活微销机器人

刚开始我是想直接把机器人变为系统应用，后来发现这样软件升级的时候会有问题，最终的方案是偷偷安装一个没有入口（MainActivity）的程序，把它变为系统应用，该应用只用来发送自定义广播，进而拉活机器人，由于有root权限，我们可以在投顾无感知的情况下完成这一过程，这样对于投顾来说，只有一个应用可见，且没有升级问题