在很多移動應用中，特別是即時通訊類專案中，保活是一個永遠無法避免的一個話題。保活，按照我的理解，主要包含兩部分：
網路連線保活：如何保證訊息接收實時性。
程序保活：儘量保證應用的程序不被Android系統回收。
在很早以前，談Android的保活都會涉及到程序常駐記憶體，如何進行效能優化等話題，今天就這些話題，做一個簡單的總結。

Android程序

在討論這個問題之前，我們首先來看一些現象級APP的程序。

搞Android的同學都知道，每一個Android應用啟動後至少對應一個程序，有的則有多個程序，大多數主流APP都會包含多個程序，因為除了主要的程序之外，還有諸如長連線、推送等程序。

檢視程序

對於任何一個程序，我們都可以通過adb shell ps|grep 的方式來檢視。具體方式如下：

上圖的具體含義如下：

程序劃分

Android系統按重要性從高到低把程序的劃為瞭如下幾種（嚴格來說是6種）。

1，前臺程序

此種程序指使用者正在使用的程式，一般系統是不會殺死前臺程序的，除非使用者強制停止應用或者系統記憶體不足等極端情況會殺死。

主要場景：

• 某個程序持有一個正在與使用者互動的Activity，並且該Activity正處於resume的狀態。
• 某個程序持有一個Service，並且該Service與使用者正在互動的Activity繫結。
• 某個程序持有一個Service，並且該Service呼叫startForeground()方法使之位於前臺執行。
• 某個程序持有一個Service，並且該Service正在執行它的某個生命週期回撥方法，比如onCreate()、onStart()或onDestroy()。
• 某個程序持有一個BroadcastReceiver，並且BroadcastReceiver正在執行其onReceive()方法。

2，可見程序

使用者正在使用，看得到，但是摸不著，沒有覆蓋到整個螢幕,只有螢幕的一部分可見程序不包含任何前臺元件，一般系統也是不會殺死可見程序的，除非要在資源吃緊的情況下，要保持某個或多個前臺程序存活。

主要場景：

• 擁有不在前臺、但仍對使用者可見的 Activity（已呼叫onPause()）。
• 擁有繫結到可見（或前臺）Activity 的 Service。

3，服務程序

在記憶體不足以維持所有前臺程序和可見程序同時執行的情況下，服務程序會被殺死。
主要場景：

• 某個程序中執行著一個Service且該Service是通過startService()啟動的，與使用者看見的介面沒有直接關聯。

4，後臺程序

後臺程序，系統可能隨時終止它們，用以回收記憶體。
主要場景：

• 在使用者按了”back”或者”home”後,程式本身看不到了,但是其實還在執行的程式，比如Activity呼叫了onPause方法。

空程序

某個程序不包含任何活躍的元件時該程序就會被置為空程序，完全沒用,殺了它只有好處沒壞處,第一個幹它。

記憶體閾值

上面主要講的是程序，那麼程序是怎麼被殺的呢？這不得不提主要的一個原因：記憶體。在移動裝置中記憶體往往是有限的，開啟的應用越多，後臺快取的程序也越多。在系統記憶體不足的情況下，系統開始依據自身的一套程序回收機制來判斷要kill掉哪些程序。在Android的記憶體回收機制中有一個重要的概念：Low Memory Killer。
我們可以使用cat /sys/module/lowmemorykiller/parameters/minfree來檢視某個手機的記憶體閾值。

注意這些數字的單位是page（1 page = 4 kb）。上面的六個數字對應的就是(MB): 72,90,108,126,144,180，這些數字也就是對應的記憶體閥值,記憶體閾值在不同的手機上不一樣，一旦低於該值,Android便開始按順序關閉程序. 因此Android開始結束優先順序最低的空程序，即當可用記憶體小於180MB(46080*4/1024)。

讀到這裡，你或許有一個疑問，假設現在記憶體不足，空程序都被殺光了，現在要殺後臺程序，但是手機中後臺程序很多，難道要一次性全部都清理掉？當然不是的，程序是有它的優先順序的，這個優先順序通過程序的adj值來反映，它是linux核心分配給每個系統程序的一個值，代表程序的優先順序，程序回收機制就是根據這個優先順序來決定是否進行回收，adj值定義在com.android.server.am.ProcessList類中，這個類路徑是${android-sdk-path}\sources\android-23\com\android\server\am\ProcessList.java。oom_adj的值越小，程序的優先順序越高，普通程序oom_adj值是大於等於0的，而系統程序oom_adj的值是小於0的，我們可以通過cat /proc/程序id/oom_adj可以看到當前程序的adj值。

看到adj值是0，0就代表這個程序是屬於前臺程序，我們再按下Back鍵，將應用至於後臺，再次檢視。

adj值變成了8，8代表這個程序是屬於不活躍的程序。關於oom_adj程序的相關內容可以參考下表：

說明：上表的數字可能在不同系統會有一定的出入。

下面按照網路保活和程序保活來給大家介紹保活的一些策略。

網路連線保活

網路保活，業界主要手段有：
a. GCM；
b. 公共的第三方push通道(信鴿等)；
c. 自身跟伺服器通過輪詢，或者長連線；

GCM即Google Cloud Messaging，主要用於訊息推送的，即使在應用沒有起來的情況下，客戶端也能通過GCM收到來自伺服器的訊息。GCM支援Android、IOS和Chrome。由於GCM需要google service支援，在國內基本不能用，經常會斷線。

push很多也是基於長連線實現的，早年的微信，直接通過Java socket 實現。所以後面我們直接談長連線。
長連線實現包括幾個要素：
a. 網路切換或者初始化時 server ip 的獲取。
b. 連線前的 ip篩選，出錯後ip 的拋棄。
c. 維護長連線的心跳。
d. 伺服器通過長連notify。
e. 選擇使用長連通道的業務。
f. 斷開後重連的策略。

今天，我們討論重點即時聊天中的心跳和 notify 機制。

1，心跳機制

通過定期的資料包，對抗NAT超時(一般會設定為5-10秒)。以下是部分地區網路NAT 超時統計。

心跳的實現過程如下：

說明：
a. 連線後主動到伺服器Sync拉取一次資料，確保連線過程的新訊息。
b. 心跳週期的Alarm 喚醒後，一般有幾秒的cpu 時間，無需wakelock。
c. 心跳後的Alarm防止傳送超時，如伺服器正常回包，該Alarm 取消。
d. 如果伺服器回包，系統通過網路喚醒，無需wakelock。

流程基於兩個系統特性：

a. Alarm喚醒後，足夠cpu時間發包。
b. 網路回包可喚醒機器。

特別是b項，假如Android封堵該特性，那就只能用GCM了。API level >= 23的doze就關閉所有的網路， alarm等。Google也最終在6.0版本加入REQUEST_IGNORE_BATTERY_OPTIMIZATIONS許可權。

2，動態心跳

4.5min心跳週期是穩定可靠的，但無法確定是最大值。通過終端的嘗試，可以獲取到特定使用者網路下，心跳的最大值。引入該特性的背景：
a. 運營商的信令風暴
b. 運營商網路換代，NAT超時趨於增大
c. Alarm耗電，心跳耗流量。

動態心跳引入下列狀態：
a. 前臺活躍態：亮屏，微信在前臺， 週期minHeart (4.5min) ，保證體驗。
b. 後臺活躍態：微信在後臺10分鐘內，週期minHeart ，保證體驗。
c. 自適應計算態：步增心跳，嘗試獲取最大心跳週期(sucHeart)。
d. 後臺穩定態：通過最大週期，保持穩定心跳。

下面是自適應計算態流程：

在自適應態：
a. curHeart初始值為minHeart ， 步增(heartStep)為1分鐘。
b. curHeart 失敗5次， 意味著整個自適應態最多隻有5分鐘無法接收訊息。
c. 結束後，如果sucHeart > minHeart，會減去10s(避開臨界)，為該網路下的穩定週期。
d. 進入穩定態時，要求連線連續三次成功minHeart心跳週期，再使用sucHeart。

3，notify機制

網路保活的意義在於訊息實時。通過長連線，即時通訊類產品有下列機制保證訊息的實時。

Sync：

通過Sync CGI直接請求後臺資料。Sync 通過後臺和終端的seq值對比，判斷該下發哪些訊息。終端正常處理訊息後，seq更新為最新值。
Sync 的主要場景：
a. 長連無法建立時，通過Sync 定期輪詢；
b. 微信切到前臺時，觸發Sync(保命機制)；
c. 長連建立完成，立即觸發Sync，防止連線過程漏訊息；
d. 接收到Notify 或者 gcm 後，終端觸發Sync 接收訊息。

Notify：

類似於GCM。通過長連線，後臺發出僅帶seq的小包，終端根據seq決定是否觸發Sync拉取訊息。

NotifyData：

在長連穩定， Notify機制正常的情況下(保證seq的同步)。後臺直接推送訊息內容，節省1個RTT (Sync) 訊息接收時間。終端收到內容後，帶上seq迴應NotifyAck，確認成功。這裡會出現Notify和NotifyData狀態互相切換的情況：

如NotifyData 後，伺服器在沒收到NotifyAck，而有新訊息的情況下，會切換回到Notify，Sync可能需要冗餘之前NotifyData的訊息。終端要保證序列處理NotifyData和Sync ，否則seq可能回退。

GCM：

只要機器上有GMS ，啟動時就嘗試註冊GCM，並通知後臺。伺服器會根據終端是否保持長連，決定是否由GCM通知。GCM主要針對國外比較複雜的網路環境。

程序保活

在Android系統裡，程序被殺的原因通常為以下幾個方面：
a. 應用Crash；
b. 系統回收記憶體；
c. 使用者觸發；
d. 第三方root許可權app。

下面分享幾個微信和qq關於程序保活的幾個方法：

1，程序拆分

俗話說，雞蛋不能放一個籃子裡面，那麼為了保活，我們也可以將程序拆分為幾個。

例如，上圖是微信應用的幾個程序：
a. push主要用於網路互動，沒有UI
b. worker就是使用者看到的主要UI
c. tools主要包含gallery和webview
這樣，程序通過拆分之後，單個程序被回收了並不影響其他的程序。拆分網路程序，確實就是為了減少程序回收帶來的網路斷開。

可以看到push的記憶體要遠遠小於worker。而且push的工作性質穩定，記憶體增長會非常少。這樣就可以保證，儘量的減少push 被殺的可能。為了提高執行緒存活的概率，這裡啟動一個純C/C++ 的程序，而不是Java run time。

2，及時拉起

系統回收不可避免，及時重新拉起的手段主要依賴系統特性。從上圖看到， push有AlarmReceiver， ConnectReceiver，BootReceiver。這些receiver 都可以在push被殺後，重新拉起。特別AlarmReceiver ，結合心跳邏輯，微信被殺後，重新拉起最多一個心跳週期。

而對於worker，除了使用者UI操作啟動。在接收訊息，或者網路切換等事件， push也會通過LocalBroadcast，重新拉起worker。這種拉起的worker ，大部分初始化已經完成，也能大大提高使用者點選微信的啟動速度。

歷史原因，我們在push和worker通訊使用Broadcast和AIDL。實際上，我一直不喜歡這裡的實現，AIDL程式碼冗餘多， broadcast效率低。歡迎大家分享更好的思路或者方法。

3，程序優先順序

前面說過Low Memory Killer機制，Low Memory Killer 機制決定是否殺程序除了記憶體大小，還有程序優先順序。這個前面也說過。從這個原理來說，我們可以通過提高程序的優先順序來保活。

值得注意的是，Android 的前臺service機制。但該機制的缺陷是通知欄保留了圖示。

對於 API level < 18 ：呼叫startForeground(ID， new Notification())，傳送空的Notification ，圖示則不會顯示。

對於 API level >= 18：在需要提優先順序的service A啟動一個InnerService，兩個服務同時startForeground，且繫結同樣的 ID。Stop 掉InnerService ，這樣通知欄圖示即被移除。