關於 Android 平臺的程序保活這一塊，想必是所有 Android 開發者矚目的內容之一。你到網上搜 Android 程序保活，可以搜出各種各樣神乎其技的做法，絕大多數都是極其不靠譜。前段時間，Github還出現了一個很火的“黑科技”程序保活庫，聲稱可以做到程序永生不死。
CSDN上也出現過一篇使用C程序守護的方式，Android程序常駐：

，也能很好的解決5.0及以下的機器。
接下來本文講的內容是來至：

主要講灰色保活。
灰色保活，這種保活手段是應用範圍最廣泛。它是利用系統的漏洞來啟動一個前臺的Service程序，與普通的啟動方式區別在於，它不會在系統通知欄處出現一個Notification，看起來就如同執行著一個後臺Service程序一樣。這樣做帶來的好處就是，使用者無法察覺到你執行著一個前臺程序（因為看不到Notification）,但你的程序優先順序又是高於普通後臺程序的。那麼如何利用系統的漏洞呢，大致的實現思路和程式碼如下：
 

思路一：API < 18，啟動前臺Service時直接傳入new Notification()；
思路二：API >= 18，同時啟動兩個id相同的前臺Service，然後再將後啟動的Service做stop處理；

public class GrayService extends Service {

    private final static int GRAY_SERVICE_ID = 1001;

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        if
 
 (Build.VERSION.SDK_INT < 18) {
            startForeground(GRAY_SERVICE_ID, new Notification());//API < 18 ，此方法能有效隱藏Notification上的圖示
        } else {
            Intent innerIntent = new Intent(this, GrayInnerService.class);
            startService(innerIntent);
            startForeground(GRAY_SERVICE_ID, new
 
 Notification());
        }

        return super.onStartCommand(intent, flags, startId);
    }

    ...
    ...

    /**
     * 給 API >= 18 的平臺上用的灰色保活手段
     */
    public static class GrayInnerService extends Service {

        @Override
        public int onStartCommand(Intent intent, int flags, int startId) {
            startForeground(GRAY_SERVICE_ID, new Notification());
            stopForeground(true);
            stopSelf();
            return super.onStartCommand(intent, flags, startId);
        }

    }
}

這樣能讓你神不知鬼不覺的啟動著一個前臺Service。我們可以使用adb命令列程式，在然後輸入下面的shell命令

打印出指定包名的所有程序中的Service資訊，看下有沒有 isForeground=true 的關鍵資訊。如果通知欄沒有看到屬於app的 Notification 且又看到 isForeground=true 則說明了，此app利用了這種灰色保活的手段。當然這也只是目前一種可行的方式，哪天google封了也是有可能的。

下面就給自己做個記錄，記錄下系統的程序回收機制
熟悉Android系統的童鞋都知道，系統出於體驗和效能上的考慮，app在退到後臺時系統並不會真正的kill掉這個程序，而是將其快取起來。開啟的應用越多，後臺快取的程序也越多。在系統記憶體不足的情況下，系統開始依據自身的一套程序回收機制來判斷要kill掉哪些程序，以騰出記憶體來供給需要的app。這套殺程序回收記憶體的機制就叫 Low Memory Killer ，它是基於Linux核心的 OOM Killer（Out-Of-Memory killer）機制誕生。

瞭解完 Low Memory Killer，再科普一下oom_adj。什麼是oom_adj？它是linux核心分配給每個系統程序的一個值，代表程序的優先順序，程序回收機制就是根據這個優先順序來決定是否進行回收。對於oom_adj的作用，你只需要記住以下幾點即可：

程序的oom_adj越大，表示此程序優先順序越低，越容易被殺回收；越小，表示程序優先順序越高，越不容易被殺回收
普通app程序的oom_adj>=0,系統程序的oom_adj才可能<0
那麼我們如何檢視程序的oom_adj值呢，需要用到下面的兩個shell命令

ps | grep PackageName //獲取你指定的程序資訊

關於 Android 程序保活，你所需要知道的一切

這裡是以我寫的demo程式碼為例子，紅色圈中部分別為下面三個程序的ID

UI程序：com.clock.daemon
普通後臺程序：com.clock.daemon:bg
灰色保活程序：com.clock.daemon:gray

當然，這些程序的id也可以通過AndroidStudio獲得

接著我們來再來獲取三個程序的oom_adj

cat /proc/程序ID/oom_adj

從上圖可以看到UI程序和灰色保活Service程序的oom_adj=0，而普通後臺程序oom_adj=15。到這裡估計你也能明白，為什麼普通的後臺程序容易被回收，而前臺程序則不容易被回收了吧。但明白這個還不夠，接著看下圖

上面是我把app切換到後臺，再進行一次oom_adj的檢驗，你會發現UI程序的值從0變成了6,而灰色保活的Service程序則從0變成了1。這裡可以觀察到，app退到後臺時，其所有的程序優先順序都會降低。但是UI程序是降低最為明顯的，因為它佔用的記憶體資源最多，系統記憶體不足的時候肯定優先殺這些佔用記憶體高的程序來騰出資源。所以，為了儘量避免後臺UI程序被殺，需要儘可能的釋放一些不用的資源，尤其是圖片、音視訊之類的。

從Android官方文件中，我們也能看到優先順序從高到低列出了這些不同型別的程序：Foreground process、Visible process、Service process、Background process、Empty process。而這些程序的oom_adj分別是多少，又是如何掛鉤起來的呢？推薦大家閱讀下面這篇文章：

總結（文末有福利）
絮絮叨叨寫完了這麼多，最後來做個小小的總結。迴歸到開篇提到QQ程序不死的問題，我也曾認為存在這樣一種技術。可惜我把手機root後，殺掉QQ程序之後就再也起不來了。有些手機廠商把這些知名的app放入了自己的白名單中，保證了程序不死來提高使用者體驗（如微信、QQ、陌陌都在小米的白名單中）。如果從白名單中移除，他們終究還是和普通app一樣躲避不了被殺的命運，為了儘量避免被殺，還是老老實實去做好優化工作吧。

所以，程序保活的根本方案終究還是回到了效能優化上，程序永生不死終究是個徹頭徹尾的偽命題！