灰色?；?，這種?；钍侄问菓?yīng)用范圍最廣泛。它是利用系統(tǒng)的漏洞來啟動一個前臺的Service進程，與普通的啟動方式區(qū)別在于，它不會在系統(tǒng)通知欄處出現(xiàn)一個Notification，看起來就如同運行著一個后臺Service進程一樣。這樣做帶來的好處就是，用戶無法察覺到你運行著一個前臺進程（因為看不到Notification）,但你的進程優(yōu)先級又是高于普通后臺進程的。那么如何利用系統(tǒng)的漏洞呢，大致的實現(xiàn)思路和代碼如下：

思路一：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上的圖標(biāo)
    } 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。其實市面上很多app都用著這種灰色?；畹氖侄?，什么？你不信？好吧，我們來驗證一下。流程很簡單，打開一個app，看下系統(tǒng)通知欄有沒有一個 Notification，如果沒有，我們就進入手機的adb shell模式，然后輸入下面的shell命令

dumpsys activity services PackageName

打印出指定包名的所有進程中的Service信息，看下有沒有 isForeground=true 的關(guān)鍵信息。如果通知欄沒有看到屬于app的 Notification 且又看到 isForeground=true 則說明了，此app利用了這種灰色?；畹氖侄?。

下面分別是我手機上微信、qq、支付寶、陌陌的測試結(jié)果，大家有興趣也可以自己驗證一下。

微信

手Q

支付寶

陌陌

其實Google察覺到了此漏洞的存在，并逐步進行封堵。這就是為什么這種保活方式分 API >= 18 和 API < 18 兩種情況，從Android5.0的ServiceRecord類的postNotification函數(shù)源代碼中可以看到這樣的一行注釋

當(dāng)某一天 API >= 18 的方案也失效的時候，我們就又要另謀出路了。需要注意的是，使用灰色?；畈⒉淮碇愕腟ervice就永生不死了，只能說是提高了進程的優(yōu)先級。如果你的app進程占用了大量的內(nèi)存，按照回收進程的策略，同樣會干掉你的app。感興趣于灰色?；钍侨绾卫孟到y(tǒng)漏洞不顯示 Notification 的童鞋，可以研究一下系統(tǒng)的 ServiceRecord、NotificationManagerService 等相關(guān)源代碼，因為不是本文的重點，所以不做詳述。

嘮叨的分割線

到這里基本就介紹完了 黑、白、灰 三種實現(xiàn)方式，僅僅從代碼層面去講?；钍遣粔虻?，我希望能夠通過系統(tǒng)的進程回收機制來理解保活，這樣能夠讓我們更好的避免踩到進程被殺的坑。

進程回收機制

熟悉Android系統(tǒng)的童鞋都知道，系統(tǒng)出于體驗和性能上的考慮，app在退到后臺時系統(tǒng)并不會真正的kill掉這個進程，而是將其緩存起來。打開的應(yīng)用越多，后臺緩存的進程也越多。在系統(tǒng)內(nèi)存不足的情況下，系統(tǒng)開始依據(jù)自身的一套進程回收機制來判斷要kill掉哪些進程，以騰出內(nèi)存來供給需要的app。這套殺進程回收內(nèi)存的機制就叫 Low Memory Killer ，它是基于Linux內(nèi)核的 OOM Killer（Out-Of-Memory killer）機制誕生。

了解完 Low Memory Killer，再科普一下oom_adj。什么是oom_adj？它是linux內(nèi)核分配給每個系統(tǒng)進程的一個值，代表進程的優(yōu)先級，進程回收機制就是根據(jù)這個優(yōu)先級來決定是否進行回收。對于oom_adj的作用，你只需要記住以下幾點即可：

• 進程的oom_adj越大，表示此進程優(yōu)先級越低，越容易被殺回收；越小，表示進程優(yōu)先級越高，越不容易被殺回收
• 普通app進程的oom_adj>=0,系統(tǒng)進程的oom_adj才可能<0

那么我們?nèi)绾尾榭催M程的oom_adj值呢，需要用到下面的兩個shell命令

ps | grep PackageName //獲取你指定的進程信息

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

• UI進程：com.clock.daemon
• 普通后臺進程：com.clock.daemon:bg
• 灰色?；钸M程：com.clock.daemon:gray

當(dāng)然，這些進程的id也可以通過AndroidStudio獲得

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

cat /proc/進程ID/oom_adj

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

上面是我把app切換到后臺，再進行一次oom_adj的檢驗，你會發(fā)現(xiàn)UI進程的值從0變成了6,而灰色?；畹腟ervice進程則從0變成了1。這里可以觀察到，app退到后臺時，其所有的進程優(yōu)先級都會降低。但是UI進程是降低最為明顯的，因為它占用的內(nèi)存資源最多，系統(tǒng)內(nèi)存不足的時候肯定優(yōu)先殺這些占用內(nèi)存高的進程來騰出資源。所以，為了盡量避免后臺UI進程被殺，需要盡可能的釋放一些不用的資源，尤其是圖片、音視頻之類的。

從Android官方文檔中，我們也能看到優(yōu)先級從高到低列出了這些不同類型的進程：Foreground process、Visible process、Service process、Background process、Empty process。

總結(jié)（文末有福利）

絮絮叨叨寫完了這么多，最后來做個小小的總結(jié)?；貧w到開篇提到QQ進程不死的問題，我也曾認為存在這樣一種技術(shù)?？上野咽謾Croot后，殺掉QQ進程之后就再也起不來了。有些手機廠商把這些知名的app放入了自己的白名單中，保證了進程不死來提高用戶體驗（如微信、QQ、陌陌都在小米的白名單中）。如果從白名單中移除，他們終究還是和普通app一樣躲避不了被殺的命運，為了盡量避免被殺，還是老老實實去做好優(yōu)化工作吧。

所以，進程?；畹母痉桨附K究還是回到了性能優(yōu)化上，進程永生不死終究是個徹頭徹尾的偽命題！

補充更新

有童鞋問，在華為的機子上發(fā)現(xiàn)微信和手Q的UI進程退到后臺，oom_adj的值一點都沒有變，是不是有什么黑科技在其中。為此，我稍稍驗證了一下，驗證方式就是把demo工程的包名改成手機QQ的，編譯運行在華為的機子上，發(fā)現(xiàn)我的進程怎么殺也都是不死的，退到后臺oom_adj的值同樣不發(fā)生變化，而恢復(fù)原來的包名就不行了。所以，你懂的，手Q就在華為機子的白名單中。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。