1簡介

APP保活系列(最高支援到Android 7.0)：

• (1) 探討一種新型的雙程序守護應用保活方法

  http://blog.csdn.net/andrexpert/article/details/53485360

• (2) 探討Android6.0及以上系統APP常駐記憶體(保活)實現-爭寵篇（本文）

• (3) 探討Android6.0及以上系統APP常駐記憶體(保活)實現-復活篇

  http://blog.csdn.net/andrexpert/article/details/75174586

APP常駐記憶體(保活)，舊事重提，距離上一次的研究亦有半年有餘。最近，使用者反饋說多程序守護方案在華為Mate8(7.0)保活效果不是很好，有時候還是不能及時收到訊息，於是，又帶著懷疑的眼光，重新找回原來的程式碼進行測試，順便分析了市場上主流運動類APP保活方法(微信、手Q就算了，富人家的孩子，不具代表性)，同時也對系統對記憶體中APP的管理規則進行了進一步探索。

本文便是對最近一週的探索、學習、測試的總結之一，以備將來不時之需。

2APP保活核心思想歸納

對於Android6.0及其以上系統APP保活，我覺得主要還是通過這兩個方面進行，即：降低omm_adj值，儘量保證程序不被系統殺死；程序被殺死後，通過其他方式將程序復活。

但需要明白的是，面對各手機廠商的深度定製和谷歌越來越嚴格的資源管理機制，這兩種方式結合的保活不是永久的，只能是相對存在，不同的機型結果也是不一樣的。

由於篇幅限制，本文主要剖析下通過何種方式降低oom_adj的值來降低APP被殺的機率，以及oom_adj值是怎樣做到的？

接下來，我們需要了解下Android系統回收記憶體中的程序所依據的規則：程序在記憶體中時活動主要有五種狀態，即前臺程序、可見程序、服務程序、後臺程序、空程序，這幾種狀態的程序優先順序由高到低，oom_adj值由低到高(在ProcessList定義)。

然後Android系統會根據當前系統資源和程序oom_adj值來回收相應的程序，前臺程序一般不會被回收，空程序最容易被回收，這種管理規則就是"傳說中"的Low Memory Killer。

為了更直觀的瞭解這套規則，我畫了個表：

注：優先順序1表示最高階，普通程序的oom_adj>=0，系統程序oom_adj<0，系統會根據相應的記憶體閥值對符合某段oom_adj值的程序進行回收。另外，oom_adj值也會隨著佔用實體記憶體越大而增大，系統程序絕對不會被系統殺死。

3市場主流運動類APP分析

1. 咕咚(v 7.17.0)

(1) 一鍵清理/滑動清理

a. 當"咕咚"處於停止狀態，其程序被殺死，通知欄圖示被清理，等待幾分鐘沒有 自動重啟，當重新進入“咕咚”時，會從歡迎介面重新進入；

b. 當"咕咚"處於運動進行狀態，程序死亡，通知欄圖示被清除，等待幾分鐘沒有自動重啟，但當重新進入“咕咚”時，其直接顯示運動介面，而沒有從歡迎介面進入，運動時間等狀態與被清理時一樣；

c. 當"咕咚"處於運動暫停狀態，其程序正常存活，通知欄圖示正常顯示。如果是單獨清理，程序死亡，通知欄圖示被清除；但當重新進入“咕咚”時，其直接顯示運動介面，而沒有從歡迎介面進入，運動時間等狀態與被清理時一樣；

(2) 黑屏/鎖屏

a. 當"咕咚"處於停止狀態，退到後臺，鎖屏進入黑屏狀態，等待5分鐘，程序死亡，通知欄被清除；

b. 當"咕咚"處於運動進行狀態，退到後臺，鎖屏進入黑屏狀態，然後再進入系統，“咕咚”跑步介面自動彈出。再次鎖屏，等待20分鐘，程序沒有被殺死，"咕咚"跑步介面自動彈出，運動狀態保持不變；

c. 當"咕咚"處於運動暫停狀態，退到後臺，鎖屏進入黑屏狀態，然後再進入系統，"咕咚"跑步介面自動彈出。再次鎖屏。等待20分鐘，程序沒有被殺死，"咕咚"跑步介面自動彈出，運動狀態保持不變；

 前提：

手機管家->鎖屏清理應用"關閉；
手機管家->自啟管理"關閉；
運動狀態，禁用返回鍵，使用者只能從Home鍵退到後臺；
運動介面文字閃爍或運動計時；
斷網；

分析：

當"咕咚"處於停止狀態時，一鍵清理和黑屏狀態會被殺死，說明在沒有進入運動介面之前，其保活機制沒有被啟動(即沒有使運動介面切換到後臺等)。

當“咕咚”處於運動狀態時，一鍵清理和黑屏狀態沒有被殺死(滑動清理除外)，說明已經啟動保活機制：

①"咕咚"禁止了返回鍵，以保證運動Activity不被銷燬；

②不斷更新通知欄計時，以保證APP始終在前臺，防止被系統回收；

③"咕咚"被清理後能夠自動重啟，通知被刪除後自動彈出，說明可能有另外一個東西(程序或Service)監聽器運動Service(或程序)存活狀態，當Service被銷燬時，立馬將其拉起來；④“咕咚”被強制停止或清理殺死後，再次進入會直接顯示運動介面且能夠保持殺死之前的運動狀態，說明其可能利用配置檔案記錄了相關狀態；

⑤鎖屏/解鎖後，"咕咚"運動介面會自動彈出，說明其利用了廣播機制對鎖屏廣播進行監聽，彈出Activity以保證程序始終在前臺；

結論：常駐通知欄，雙程序守護，廣播鎖屏，自定義鎖屏。

備註：以上為華為Mate8(7.0)測試結果；其他如三星C9(6.0)保活較好，特別是當一鍵清理時，"咕咚會自動啟動，估計是使用了程序守護策略，而三星使用的是原生系統，因此結果你懂得；360F4(6.0)保活很差，以更厲害的方式幹掉流氓APP；

2. 樂動力(v7.3.2)

(1) 一鍵清理 / 滑動清理
     

 三星C9(6.0)：無論何種狀態，"樂動力" 程序被殺死，等待幾分鐘，沒有自動啟動；
 360F4(6.0)：無論何種狀態，"樂動力" 程序被殺死，等待幾分鐘，沒有自動啟動；
 華為Mate8(7.0)：無論何種狀態，"樂動力" 程序被殺死，等待幾分鐘，沒有自動啟動；

(2) 鎖屏/黑屏

 a. 當"樂動力"處於停止狀態，退到後臺，鎖屏，等待5分鐘，程序死亡，通知欄被清除；
 b. 當"樂動力"處於運動暫停狀態，退到後臺，鎖屏再開啟，運動介面被切換到前臺，並強制彈出自定義鎖屏介面(覆蓋在系統鎖屏介面之上)；再次鎖屏，等待20分鐘，應用程序存活；
 c. 當"樂動力"處於運動進行狀態，退到後臺，鎖屏再開啟，運動介面被切換到前臺，並強制彈出自定義鎖屏介面(覆蓋在系統鎖屏介面之上)；再次鎖屏，等待20分鐘，應用程序存活；

前提：

手機管家->鎖屏清理應用"關閉；
手機管家->自啟管理"關閉；
運動狀態，禁用返回鍵，使用者只能從Home鍵退到後臺
斷網

分析：

當"樂動力"處於停止狀態時，黑屏狀態下，其在短時間內被系統殺死，說明保活機制沒有啟用；

但當處於運動暫停或進行狀態時，"樂動力"在一段時間內沒有被殺死，且當鎖屏時，"樂動力"會自動將運動介面切換到前臺，此外，還會強制彈出自定鎖屏介面，這就說明"樂動力"的保活機制很可能是利用監聽鎖屏廣播強制將相關介面切換到前臺，以提高"樂動力"在黑屏狀態下的存活率。

結論：

常駐通知欄，廣播鎖屏，自定義鎖屏

3. 悅動圈(v3.1.2.9)

(1) 一鍵清理 / 滑動清理

三星C9(6.0)：效果與樂動力一致；
360F4(6.0)：效果與樂動力一致；
華為Mate8(7.0)：效果與樂動力一致；

(2) 鎖屏/黑屏

a. 當"悅動圈"處於停止狀態，退到後臺，鎖屏，等待3分鐘，程序死亡，通知欄被清除；
b. 當"悅動圈"處於運動暫停狀態時，自定義鎖屏、切換介面到前臺與咕咚、樂動力一樣，效果一致；
c. 當"悅動圈"處於運動進行狀態時，自定義鎖屏、切換介面到前臺與咕咚、樂動力一樣，效果一致；

結論：常駐通知欄，廣播鎖屏，自定義鎖屏

4APP保活方案探討

經過上面的討論分析，"咕咚"、"樂動力"等這類APP主要是通過監聽鎖屏、網路等系統廣播，將程序置於前臺以提高程序的級別，從而防止程序不那麼輕易被系統幹掉。

另外，"咕咚"可能還使用了相關的程序被清理復活策略。當然，對於復活策略，我們下一篇文章再探討，本文主要討論以上APP是通過哪些方式降低程序omm_adj值，防止其被系統殺死的。

為了達到與"咕咚"等APP類似效果，我們模擬這麼一種場景：當用戶登入測試APP後，先不開啟保活功能；當用戶開始跑步時，開啟保活功能，然後再在這基礎上做黑屏執行、一鍵清理、強制停止等功能測試。

也就是說，Android專案中SplashActivity、LoginActivity只是配合我們"演戲"的，真正啟動APP保活邏輯的是在SportsActivity，它將上演"後宮爭寵"戲碼。

好吧，小夥子，開始你的表演！

1. 開啟前臺Service，“逼君上位”

 將Service置為前臺，目的時提高程序Service的oom_adj值，以降低其被系統回收的機率。該方案的原理是，通過使用 startForeground()方法將當前Service置於前臺來提高Service的優先順序。

需要注意的是，對API大於18而言 startForeground()方法需要彈出一個可見通知，如果你覺得不爽，可以開啟另一個Service將通知欄移除，其oom_adj值還是沒變的。實現程式碼如下：

a) DaemonService.java

/**前臺Service，使用startForeground 
 * 這個Service儘量要輕，不要佔用過多的系統資源，否則 
 * 系統在資源緊張時，照樣會將其殺死 
 * 
 * Created by jianddongguo on 2017/7/7. 
 * http://blog.csdn.net/andrexpert 
 */  
public class DaemonService extends Service {  
    private static final String TAG = "DaemonService";  
    public static final int NOTICE_ID = 100;  
    @Nullable  
    @Override  
    public IBinder onBind(Intent intent) {  
        return null;  
    }  
    @Override  
    public void onCreate() {  
        super.onCreate();  
        if(Contants.DEBUG)  
            Log.d(TAG,"DaemonService---->onCreate被呼叫，啟動前臺service");  
        //如果API大於18，需要彈出一個可見通知  
        if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR2){  
            Notification.Builder builder = new Notification.Builder(this);  
            builder.setSmallIcon(R.mipmap.ic_launcher);  
            builder.setContentTitle("KeepAppAlive");  
            builder.setContentText("DaemonService is runing...");  
            startForeground(NOTICE_ID,builder.build());  
            // 如果覺得常駐通知欄體驗不好  
            // 可以通過啟動CancelNoticeService，將通知移除，oom_adj值不變  
            Intent intent = new Intent(this,CancelNoticeService.class);  
            startService(intent);  
        }else{  
            startForeground(NOTICE_ID,new Notification());  
        }  
    }  
    @Override  
    public int onStartCommand(Intent intent, int flags, int startId) {  
        // 如果Service被終止  
        // 當資源允許情況下，重啟service  
        return START_STICKY;  
    }  
    @Override  
    public void onDestroy() {  
        super.onDestroy();  
        // 如果Service被殺死，幹掉通知  
        if(Build.VERSION.SDK_INT 
                >= Build.VERSION_CODES.JELLY_BEAN_MR2){  
            NotificationManager mManager = 
                (NotificationManager)getSystemService(NOTIFICATION_SERVICE);  
            mManager.cancel(NOTICE_ID);  
        }  
        if(Contants.DEBUG)  
            Log.d(TAG,"DaemonService---->onDestroy，前臺service被殺死");  
        // 重啟自己  
        Intent intent = new Intent(getApplicationContext(),DaemonService.class);  
        startService(intent);  
    }  
}  

講解一下：

這裡還用到了兩個技巧：一是在onStartCommand方法中返回START_STICKY，其作用是當Service程序被kill後，系統會嘗試重新建立這個Service，且會保留Service的狀態為開始狀態，但不保留傳遞的Intent物件，onStartCommand方法一定會被重新呼叫。

其二在onDestory方法中重新啟動自己，也就是說，只要Service在被銷燬時走到了onDestory這裡我們就重新啟動它。

相關推薦