此处延伸：进程的优先级是什么
当前业界的Android 进程保活手段主要分为** 黑、白、灰**三种，其大致的实现思路如下：
黑色保活：不同的app 进程，用广播相互唤醒（包括利用系统提供的广播进行唤醒）
白色保活：启动前台Service
灰色保活：利用系统的漏洞启动前台Service
------------------------------------------------------------------------
黑色保活
所谓黑色保活，就是利用不同的app 进程使用广播来进行相互唤醒。举个3 个比较常见的场
景：
场景1：开机，网络切换、拍照、拍视频时候，利用系统产生的广播唤醒app
场景2：接入第三方SDK 也会唤醒相应的app 进程，如微信sdk 会唤醒微信，支付宝sdk 会
唤醒支付宝。由此发散开去，就会直接触发了下面的场景3
场景3：假如你手机里装了支付宝、淘宝、天猫、UC 等阿里系的app，那么你打开任意一个
阿里系的app 后，有可能就顺便把其他阿里系的app 给唤醒了。（只是拿阿里打个比方，其
实BAT 系都差不多）
------------------------------------------------------------------------
白色保活
白色保活手段非常简单，就是调用系统api 启动一个前台的Service 进程，这样会在系统的
通知栏生成一个Notification，用来让用户知道有这样一个app 在运行着，哪怕当前的app
退到了后台。如下方的LBE 和QQ 音乐这样：
------------------------------------------------------------------------
灰色保活
灰色保活，这种保活手段是应用范围最广泛。它是利用系统的漏洞来启动一个前台的Service
进程，与普通的启动方式区别在于，它不会在系统通知栏处出现一个Notification，看起来就
如同运行着一个后台Service 进程一样。这样做带来的好处就是，用户无法察觉到你运行着
一个前台进程（因为看不到Notification）,但你的进程优先级又是高于普通后台进程的。那
么如何利用系统的漏洞呢，大致的实现思路和代码如下：
思路一：API < 18，启动前台Service 时直接传入new Notification()；
思路二：API >= 18，同时启动两个id 相同的前台Service，然后再将后启动的Service 做stop
处理
熟悉Android 系统的童鞋都知道，系统出于体验和性能上的考虑，app 在退到后台时系统并
不会真正的kill 掉这个进程，而是将其缓存起来。打开的应用越多，后台缓存的进程也越多。
在系统内存不足的情况下，系统开始依据自身的一套进程回收机制来判断要kill 掉哪些进程，
以腾出内存来供给需要的app。这套杀进程回收内存的机制就叫Low Memory Killer ，它是
基于Linux 内核的OOM Killer（Out-Of-Memory killer）机制诞生。
进程的重要性，划分5 级：
前台进程(Foreground process)
可见进程(Visible process)
服务进程(Service process)
后台进程(Background process)
空进程(Empty process)
了解完Low Memory Killer，再科普一下oom_adj。什么是oom_adj？它是linux 内核分配给
每个系统进程的一个值，代表进程的优先级，进程回收机制就是根据这个优先级来决定是否
进行回收。
对于oom_adj 的作用，你只需要记住以下几点即可：
进程的oom_adj 越大，表示此进程优先级越低，越容易被杀回收；越小，表示进程优先级
越高，越不容易被杀回收
普通app 进程的oom_adj>=0,系统进程的oom_adj 才可能<0
有些手机厂商把这些知名的app 放入了自己的白名单中，保证了进程不死来提高用户体验
（如微信、QQ、陌陌都在小米的白名单中）。如果从白名单中移除，他们终究还是和普通
app 一样躲避不了被杀的命运，为了尽量避免被杀，还是老老实实去做好优化工作吧。
所以，进程保活的根本方案终究还是回到了性能优化上，进程永生不死终究是个彻头彻尾的
伪命题！