如何进行进程保活，首先我们应该先分析一下进程被杀死的原因开始

Android进程被杀死的场景分析：

从 Android 的进程被杀死的场景分析，查看被杀死的原因

一.Android手机的进程回收策略

Android 的内存回收主要靠 LowMemoryKiller 完成，Low Memorry Killer的机制主要是通过进程的oom_adj和oom_score来进行内存的处理的，关于 OOM_ADJ的说明如下：

  1. 每一个进程都有一个oom_adj值，取值范围[-17,15]。

  2. 每一个进程都有一个oom_score值，它是根据oom_adj计算出一个值，分数越大越容易被杀死。

  3. 内存紧张时，LMK基于oom_adj和oom_score值来决定是否要回收一个进程。

  4. oom_adj值越小，越不容易被杀死。当 oom_adj 的值大于等于4时是比较容易被杀死的 Android进程，0-3表示不容易被杀死的Android进程，小于0的为  非Android 进程（纯 Linux 进程）尤其是-17的 native 进程不受系统管理不会被系统杀死

  5. 查看oom_adj和oom_score方法：

        cat proc/pid/oom_adj

        cat proc/pid/oom_score

所以结合Android 的进程回收机制，若是想要不被杀死或者减少被杀死的可能性，就需要提升进程优先级，降低在内存不足被系统回收的可能性

二.killBackgroundProcesses杀死进程

ActivityManager的killBackgroundProcesses方法，可以立即杀死与指定包相关联的所有后台进程，这与内核杀死那些进程回收内存是一样的，但这些进程如果在将来某一时刻需要使用，会重新启动。该方法需要权限Android.permission.KILL_BACKGROUND_PROCESSES。源码解释如下：

三.force-stop、kill杀死进程

5.0以下源码

    通过 pid 杀死进程，因此通过主进程 fork 出来的 c 进程是不会被杀死的，但是在5.0及以上源码发现，通过主进程 fork 出来的子进程也会被杀死了，话不多说直接上源码，

5.0以上源码

通过源码可以看到通过 uid 杀死进程，因此 fork 出来的子进程也同样会被杀死

总结了以上被杀死的场景分析，我们得出两种技术方案：

Ⅰ. 提升进程优先级（降低被杀死的概率）

Ⅱ.进程杀死后，拉活进程

（一）提升进程优先级的技术手段：

Android 系统将尽量长时间地保持应用进程，但为了新建进程或运行更重要的进程，最终需要清除旧进程来回收内存。 为了确定保留或终止哪些进程，系统会根据进程中正在运行的组件以及这些组件的状态，将每个进程放入“重要性层次结构”中。 必要时，系统会首先消除重要性最低的进程，然后是清除重要性稍低一级的进程，依此类推，以回收系统资源。

进程的重要性，划分5级：

前台进程(Foreground process)

可见进程(Visible process)

服务进程(Service process)

后台进程(Background process)

空进程(Empty process)

前台进程

用户当前操作所必需的进程。如果一个进程满足以下任一条件，即视为前台进程：

托管用户正在交互的Activity（已调用Activity的onResume()方法）

托管某个Service，后者绑定到用户正在交互的 Activity

托管正在“前台”运行的Service（服务已调用startForeground()）

托管正执行一个生命周期回调的Service（onCreate()、onStart()或onDestroy()）

托管正执行其onReceive()方法的BroadcastReceiver

通常，在任意给定时间前台进程都为数不多。只有在内存不足以支持它们同时继续运行这一万不得已的情况下，系统才会终止它们。 此时，设备往往已达到内存分页状态，因此需要终止一些前台进程来确保用户界面正常响应。

可见进程

没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。 如果一个进程满足以下任一条件，即视为可见进程：

托管不在前台、但仍对用户可见的Activity（已调用其onPause()方法）。例如，如果前台 Activity 启动了一个对话框，允许在其后显示上一 Activity，则有可能会发生这种情况。

托管绑定到可见（或前台）Activity 的Service。

可见进程被视为是极其重要的进程，除非为了维持所有前台进程同时运行而必须终止，否则系统不会终止这些进程。

服务进程

正在运行已使用startService()方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联，但是它们通常在执行一些用户关心的操作（例如，在后台播放音乐或从网络下载数据）。因此，除非内存不足以维持所有前台进程和可见进程同时运行，否则系统会让服务进程保持运行状态。

后台进程

包含目前对用户不可见的 Activity 的进程（已调用 Activity 的onStop()方法）。这些进程对用户体验没有直接影响，系统可能随时终止它们，以回收内存供前台进程、可见进程或服务进程使用。 通常会有很多后台进程在运行，因此它们会保存在 LRU （最近最少使用）列表中，以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法，并保存了其当前状态，则终止其进程不会对用户体验产生明显影响，因为当用户导航回该 Activity 时，Activity 会恢复其所有可见状态。 有关保存和恢复状态的信息，请参阅Activity文档。

空进程

不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存，以缩短下次在其中运行组件所需的启动时间。 为使总体系统资源在进程缓存和底层内核缓存之间保持平衡，系统往往会终止这些进程。

根据进程中当前活动组件的重要程度，Android 会将进程评定为它可能达到的最高级别。例如，如果某进程托管着服务和可见 Activity，则会将此进程评定为可见进程，而不是服务进程。

前台进程的重要性最高，依次递减，空进程的重要性最低，下面分别来阐述每种级别的进程，进程的回收策略如上，进程的介绍可详见http://www.jianshu.com/p/8a95f1f82ede?utm_source=desktop&utm_medium=timeline中介绍

目前常见的技术手段如下：

1) 1像素悬浮层

监控手机锁屏解锁事件，在屏幕锁屏时启动1个像素的 Activity，在用户解锁时将 Activity 销毁掉。注意该 Activity 需设计成用户无感知。

通过该方案，可以使进程的优先级在屏幕锁屏时间由4提升为最高优先级1，主要解决第三方应用及系统管理工具在检测到锁屏事件后一段时间（一般为5分钟以内）内会杀死后台进程，已达到省电的目的问题

实现方案：

首先定义 Activity，并设置 Activity 的大小为1像素：

其次，从 AndroidManifest 中通过如下属性，排除 Activity 在 RecentTask 中的显示：

最后，控制 Activity 为透明：

Activity 启动与销毁时机的控制：

2) 将Service设置为前台服务

Android 中 Service 的优先级为4，通过 setForeground 接口可以将后台 Service 设置为前台 Service，使进程的优先级由4提升为2，从而使进程的优先级仅仅低于用户当前正在交互的进程，与可见进程优先级一致，使进程被杀死的概率大大降低。

从 Android2.3 开始调用 setForeground 将后台 Service 设置为前台 Service 时，必须在系统的通知栏发送一条通知，也就是前台 Service 与一条可见的通知时绑定在一起的。

对于不需要常驻通知栏的应用来说，该方案虽好，但却是用户感知的，无法直接使用。

通过实现一个内部 Service，在  KeepLiveService 和其内部 Service 中同时发送具有相同 ID 的 Notification，然后将内部 Service 结束掉。随着内部 Service 的结束，Notification 将会消失，但系统优先级依然保持为2。

具体实现方案：

（二）进程死后，拉活进程

1) 在service的onstart方法里返回 START_STICK

 主要的几个返回值：

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

   2. START_STICKY：系统就会重新创建这个服务并且调用onStartCommand()方法，但是它不会重新传递最后的Intent对象，这适用于不执行命令的媒体播放器（或类似的服务），它只是无限期的运行着并等待工作的到来。

   3. START_NOT_STICKY：直到接受到新的Intent对象，才会被重新创建。这是最安全的，用来避免在不需要的时候运行你的服务。

   4. START_REDELIVER_INTENT：系统就会重新创建了这个服务，并且用最后的Intent对象调。等待中的Intent对象会依次被发送。这适用于如下载文件。

  具体实现方案：

  将 Service 设置为 START_STICKY，利用系统机制在 Service 挂掉后自动拉活：

 如下两种情况无法拉活：

   Service 第一次被异常杀死后会在5秒内重启，第二次被杀死会在10秒内重启，第三次会在20秒内重启，一旦在短时间内 Service 被杀死达到5次，则系统不再拉起。

   进程被取得 Root 权限的管理工具或系统工具通过 forestop 停止掉，无法重启。

   force close和一些清理软件很容易就清理掉!

2) 添加Manifest文件属性值为android:persistent=“true”

   app.persistent = true不仅仅标志着此apk不能轻易的被kill掉，亦或在被kill掉后能够自动restart，并且还涉及到了进程的优先级。将被设置为CORE_SERVER_ADJ，此值为-12，而核心进程init的值为-16。当前正在前台运行的进程的值为0。如果应用能设置这个属性，那就真的可以做到保活，因为他真的可以杀不死，像系统的keyguard进程，media进程，且这些进程的adj都是负数，代表了前台activity黑屏了他们也不会死。但是这个属性需要系统shareuid，然后编译不过，因为需要系统签名！

  因此，要弄这个属性需获取两个关键的信息：

     (1).在apk的AndroidManifest.xml文件中设置android:persistent=true

     (2).此apk需要放入到system/app目录下，成为一个systemapp

   最主要的是让程序成为系统程序，这个可以做到吗？如果你技术过硬是可以尝试下的！首先弄个自动root的apk，加壳放到程序中，然后程序运行的时候，自动运行自动root的apk，获取root权限，然后在native层中，使用命令的方式把程序移到system/app目录下，成为系统程序！

3) 覆写Service的onDestroy方法

   在设置里面的正在运行，注意是正在运行里面，点击关闭，会走onDestroy回调方法，你在这里可以把自己启动起来。注意是正常关闭的时候是会自己启动起来，可是使用第三方的清理软件360，root过的360，force close这些来搞，压根不会走到onDestory的方法

4) 监听一堆系统静态广播

  在发生特定系统事件时，系统会发出响应的广播，通过在 AndroidManifest 中“静态”注册对应的广播监听器，即可在发生响应事件时拉活。

  常用的用于拉活的广播事件包括：

  但是有如下问题：

   a. 广播接收器被管理软件、系统软件通过“自启管理”等功能禁用的场景无法接收到广播，从而无法自启。

   b. 系统广播事件不可控，只能保证发生事件时拉活进程，但无法保证进程挂掉后立即拉活。

5) 监听第三方应用的静态广播

  与接收系统广播类似，不同的是该方案为接收第三方应用广播。

通过反编译第三方应用，如：手机QQ、微信、支付宝、UC浏览器等找出它们外发的广播，在应用中进行监听，这样当这些应用发出广播时，就会将我们的应用拉活。

有效程度除与系统广播一样的因素外， 第三方应用的广播属于应用私有，当前版本中有效的广播，在后续版本随时就可能被移除或被改为不外发。

6) AlarmManager唤醒

  主要是实现也一个监听开机的广播，和一个周期性的闹钟，不过比较致命的是耗电量是很高的

7) 账户同步，定时唤醒

  android系统里有一个账户系统，系统定期唤醒账号更新服务，同步的事件间隔是有限制的，最短1分钟，利用同步机制进行进程的拉活

   难点：需要手动设置账户，你如何骗你的用户给你手动设置账户完了之后不卸载你，必须联网

   添加账号和设置同步周期的代码如下：

   该方案需要在 AndroidManifest 中定义账号授权与同步服务。

   理论上使用与所有 Android 系统，也能解决 force-stop 的拉活，但是前提是需要联网状态下

   注：最新 Android 版本（Android N）中系统好像对账户同步这里做了变动，该方法不再有效。

8) 双服务守护

   这个是android里面一个特性，跨进程bind一个service之后，如果被bind的service挂掉，bind他的service会把他拉起来！可以考虑使用远程服务来实现，可是还是不能保活进程，可以被杀掉！

9) 多 APP 间互相拉起

   比较常见的就是家族 app 之间互相调起，你监听到我死了，我把你拉起，之间互相拉活对方

10) Native进程拉起

    原理就是通过 JNI fork出一个 c 进程，c 进程监控主进程是否存活，主要通过管道和文件监控的方式实现监控，发现主进程死后，通过调起一个 service 将主进程拉活

   具体的实现方案：

  此方案存在两个问题：

   1.如果直接使用 JNI fork 出一个子进程，这样会存在一个内存较大问题，也就是主版占用多大内存，native 进程也占用多大内存，因此需要去写一个独立的 c 进程来降低内存大小

   2.上面讲到5.0以上的系统会将根据 uid 杀进程，因此 native 进程也会被杀死，因此在5.0以上此方案失效的，

11) 双进程守护

    顾名思义开启两个 native 进程进行保活，当一个 native 进程被杀死后，另一个 native 进行拉起，具体实现方案可参考：http://blog.csdn.net/marswin89/article/details/50916631

12）JobSchedule机制拉活

   Android5.0 以后系统对 Native 进程等加强了管理，Native 拉活方式失效。系统在 Android5.0 以上版本提供了 JobScheduler 接口，系统会定时调用该进程以使应用进行一些逻辑操作。

   具体实现方案：

   通过创建一个系统任务JobInfo，添加到 JobSchedule 中，通过系统调度任务来实现拉活，force-stop 也能实现拉活

    但是存在很多兼容性问题，目前在华为6.0以上不生效，以及在7.0系统上不能实现，根据官方文档说是在 Doze 安全模式下，系统调度也会被杀死