如何進(jìn)行進(jìn)程保活，首先我們應(yīng)該先分析一下進(jìn)程被殺死的原因開始

Android進(jìn)程被殺死的場景分析：

從 Android 的進(jìn)程被殺死的場景分析，查看被殺死的原因

一.Android手機(jī)的進(jìn)程回收策略

Android 的內(nèi)存回收主要靠 LowMemoryKiller 完成，Low Memorry Killer的機(jī)制主要是通過進(jìn)程的oom_adj和oom_score來進(jìn)行內(nèi)存的處理的，關(guān)于 OOM_ADJ的說明如下：

1. 每一個(gè)進(jìn)程都有一個(gè)oom_adj值，取值范圍[-17,15]。

2. 每一個(gè)進(jìn)程都有一個(gè)oom_score值，它是根據(jù)oom_adj計(jì)算出一個(gè)值，分?jǐn)?shù)越大越容易被殺死。

3. 內(nèi)存緊張時(shí)，LMK基于oom_adj和oom_score值來決定是否要回收一個(gè)進(jìn)程。

4. oom_adj值越小，越不容易被殺死。當(dāng) oom_adj 的值大于等于4時(shí)是比較容易被殺死的 Android進(jìn)程，0-3表示不容易被殺死的Android進(jìn)程，小于0的為 ?非Android 進(jìn)程（純 Linux 進(jìn)程）尤其是-17的 native 進(jìn)程不受系統(tǒng)管理不會(huì)被系統(tǒng)殺死

5. 查看oom_adj和oom_score方法：

cat proc/pid/oom_adj

cat proc/pid/oom_score

所以結(jié)合Android 的進(jìn)程回收機(jī)制，若是想要不被殺死或者減少被殺死的可能性，就需要提升進(jìn)程優(yōu)先級，降低在內(nèi)存不足被系統(tǒng)回收的可能性

二.killBackgroundProcesses殺死進(jìn)程

ActivityManager的killBackgroundProcesses方法，可以立即殺死與指定包相關(guān)聯(lián)的所有后臺(tái)進(jìn)程，這與內(nèi)核殺死那些進(jìn)程回收內(nèi)存是一樣的，但這些進(jìn)程如果在將來某一時(shí)刻需要使用，會(huì)重新啟動(dòng)。該方法需要權(quán)限Android.permission.KILL_BACKGROUND_PROCESSES。源碼解釋如下：

三.force-stop、kill殺死進(jìn)程

5.0以下源碼

通過 pid 殺死進(jìn)程，因此通過主進(jìn)程 fork 出來的 c 進(jìn)程是不會(huì)被殺死的，但是在5.0及以上源碼發(fā)現(xiàn)，通過主進(jìn)程 fork 出來的子進(jìn)程也會(huì)被殺死了，話不多說直接上源碼，

5.0以上源碼

通過源碼可以看到通過 uid 殺死進(jìn)程，因此 fork 出來的子進(jìn)程也同樣會(huì)被殺死

總結(jié)了以上被殺死的場景分析，我們得出兩種技術(shù)方案：

Ⅰ. 提升進(jìn)程優(yōu)先級（降低被殺死的概率）

Ⅱ.進(jìn)程殺死后，拉活進(jìn)程

（一）提升進(jìn)程優(yōu)先級的技術(shù)手段：

Android 系統(tǒng)將盡量長時(shí)間地保持應(yīng)用進(jìn)程，但為了新建進(jìn)程或運(yùn)行更重要的進(jìn)程，最終需要清除舊進(jìn)程來回收內(nèi)存。 為了確定保留或終止哪些進(jìn)程，系統(tǒng)會(huì)根據(jù)進(jìn)程中正在運(yùn)行的組件以及這些組件的狀態(tài)，將每個(gè)進(jìn)程放入“重要性層次結(jié)構(gòu)”中。 必要時(shí)，系統(tǒng)會(huì)首先消除重要性最低的進(jìn)程，然后是清除重要性稍低一級的進(jìn)程，依此類推，以回收系統(tǒng)資源。

進(jìn)程的重要性，劃分5級：

前臺(tái)進(jìn)程(Foreground process)

可見進(jìn)程(Visible process)

服務(wù)進(jìn)程(Service process)

后臺(tái)進(jìn)程(Background process)

空進(jìn)程(Empty process)

前臺(tái)進(jìn)程

用戶當(dāng)前操作所必需的進(jìn)程。如果一個(gè)進(jìn)程滿足以下任一條件，即視為前臺(tái)進(jìn)程：

托管用戶正在交互的Activity（已調(diào)用Activity的onResume()方法）

托管某個(gè)Service，后者綁定到用戶正在交互的 Activity

托管正在“前臺(tái)”運(yùn)行的Service（服務(wù)已調(diào)用startForeground()）

托管正執(zhí)行一個(gè)生命周期回調(diào)的Service（onCreate()、onStart()或onDestroy()）

托管正執(zhí)行其onReceive()方法的BroadcastReceiver

通常，在任意給定時(shí)間前臺(tái)進(jìn)程都為數(shù)不多。只有在內(nèi)存不足以支持它們同時(shí)繼續(xù)運(yùn)行這一萬不得已的情況下，系統(tǒng)才會(huì)終止它們。 此時(shí)，設(shè)備往往已達(dá)到內(nèi)存分頁狀態(tài)，因此需要終止一些前臺(tái)進(jìn)程來確保用戶界面正常響應(yīng)。

可見進(jìn)程

沒有任何前臺(tái)組件、但仍會(huì)影響用戶在屏幕上所見內(nèi)容的進(jìn)程。 如果一個(gè)進(jìn)程滿足以下任一條件，即視為可見進(jìn)程：

托管不在前臺(tái)、但仍對用戶可見的Activity（已調(diào)用其onPause()方法）。例如，如果前臺(tái) Activity 啟動(dòng)了一個(gè)對話框，允許在其后顯示上一 Activity，則有可能會(huì)發(fā)生這種情況。

托管綁定到可見（或前臺(tái)）Activity 的Service。

可見進(jìn)程被視為是極其重要的進(jìn)程，除非為了維持所有前臺(tái)進(jìn)程同時(shí)運(yùn)行而必須終止，否則系統(tǒng)不會(huì)終止這些進(jìn)程。

服務(wù)進(jìn)程

正在運(yùn)行已使用startService()方法啟動(dòng)的服務(wù)且不屬于上述兩個(gè)更高類別進(jìn)程的進(jìn)程。盡管服務(wù)進(jìn)程與用戶所見內(nèi)容沒有直接關(guān)聯(lián)，但是它們通常在執(zhí)行一些用戶關(guān)心的操作（例如，在后臺(tái)播放音樂或從網(wǎng)絡(luò)下載數(shù)據(jù)）。因此，除非內(nèi)存不足以維持所有前臺(tái)進(jìn)程和可見進(jìn)程同時(shí)運(yùn)行，否則系統(tǒng)會(huì)讓服務(wù)進(jìn)程保持運(yùn)行狀態(tài)。

后臺(tái)進(jìn)程

包含目前對用戶不可見的 Activity 的進(jìn)程（已調(diào)用 Activity 的onStop()方法）。這些進(jìn)程對用戶體驗(yàn)沒有直接影響，系統(tǒng)可能隨時(shí)終止它們，以回收內(nèi)存供前臺(tái)進(jìn)程、可見進(jìn)程或服務(wù)進(jìn)程使用。 通常會(huì)有很多后臺(tái)進(jìn)程在運(yùn)行，因此它們會(huì)保存在 LRU （最近最少使用）列表中，以確保包含用戶最近查看的 Activity 的進(jìn)程最后一個(gè)被終止。如果某個(gè) Activity 正確實(shí)現(xiàn)了生命周期方法，并保存了其當(dāng)前狀態(tài)，則終止其進(jìn)程不會(huì)對用戶體驗(yàn)產(chǎn)生明顯影響，因?yàn)楫?dāng)用戶導(dǎo)航回該 Activity 時(shí)，Activity 會(huì)恢復(fù)其所有可見狀態(tài)。 有關(guān)保存和恢復(fù)狀態(tài)的信息，請參閱Activity文檔。

空進(jìn)程

不含任何活動(dòng)應(yīng)用組件的進(jìn)程。保留這種進(jìn)程的的唯一目的是用作緩存，以縮短下次在其中運(yùn)行組件所需的啟動(dòng)時(shí)間。 為使總體系統(tǒng)資源在進(jìn)程緩存和底層內(nèi)核緩存之間保持平衡，系統(tǒng)往往會(huì)終止這些進(jìn)程。

根據(jù)進(jìn)程中當(dāng)前活動(dòng)組件的重要程度，Android 會(huì)將進(jìn)程評定為它可能達(dá)到的最高級別。例如，如果某進(jìn)程托管著服務(wù)和可見 Activity，則會(huì)將此進(jìn)程評定為可見進(jìn)程，而不是服務(wù)進(jìn)程。

前臺(tái)進(jìn)程的重要性最高，依次遞減，空進(jìn)程的重要性最低，下面分別來闡述每種級別的進(jìn)程，進(jìn)程的回收策略如上，進(jìn)程的介紹可詳見http://www.lxweimin.com/p/8a95f1f82ede?utm_source=desktop&utm_medium=timeline中介紹

目前常見的技術(shù)手段如下：

1) 1像素懸浮層

監(jiān)控手機(jī)鎖屏解鎖事件，在屏幕鎖屏?xí)r啟動(dòng)1個(gè)像素的 Activity，在用戶解鎖時(shí)將 Activity 銷毀掉。注意該 Activity 需設(shè)計(jì)成用戶無感知。

通過該方案，可以使進(jìn)程的優(yōu)先級在屏幕鎖屏?xí)r間由4提升為最高優(yōu)先級1，主要解決第三方應(yīng)用及系統(tǒng)管理工具在檢測到鎖屏事件后一段時(shí)間（一般為5分鐘以內(nèi)）內(nèi)會(huì)殺死后臺(tái)進(jìn)程，已達(dá)到省電的目的問題

實(shí)現(xiàn)方案：

首先定義 Activity，并設(shè)置 Activity 的大小為1像素：

其次，從 AndroidManifest 中通過如下屬性，排除 Activity 在 RecentTask 中的顯示：

最后，控制 Activity 為透明：

Activity 啟動(dòng)與銷毀時(shí)機(jī)的控制：

2) 將Service設(shè)置為前臺(tái)服務(wù)

Android 中 Service 的優(yōu)先級為4，通過 setForeground 接口可以將后臺(tái) Service 設(shè)置為前臺(tái) Service，使進(jìn)程的優(yōu)先級由4提升為2，從而使進(jìn)程的優(yōu)先級僅僅低于用戶當(dāng)前正在交互的進(jìn)程，與可見進(jìn)程優(yōu)先級一致，使進(jìn)程被殺死的概率大大降低。

從 Android2.3 開始調(diào)用 setForeground 將后臺(tái) Service 設(shè)置為前臺(tái) Service 時(shí)，必須在系統(tǒng)的通知欄發(fā)送一條通知，也就是前臺(tái) Service 與一條可見的通知時(shí)綁定在一起的。

對于不需要常駐通知欄的應(yīng)用來說，該方案雖好，但卻是用戶感知的，無法直接使用。

通過實(shí)現(xiàn)一個(gè)內(nèi)部 Service，在 ?KeepLiveService 和其內(nèi)部 Service 中同時(shí)發(fā)送具有相同 ID 的 Notification，然后將內(nèi)部 Service 結(jié)束掉。隨著內(nèi)部 Service 的結(jié)束，Notification 將會(huì)消失，但系統(tǒng)優(yōu)先級依然保持為2。

具體實(shí)現(xiàn)方案：

（二）進(jìn)程死后，拉活進(jìn)程

1) 在service的onstart方法里返回 START_STICK

主要的幾個(gè)返回值：

1. START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保證服務(wù)被kill后一定能重啟。

2. START_STICKY：系統(tǒng)就會(huì)重新創(chuàng)建這個(gè)服務(wù)并且調(diào)用onStartCommand()方法，但是它不會(huì)重新傳遞最后的Intent對象，這適用于不執(zhí)行命令的媒體播放器（或類似的服務(wù)），它只是無限期的運(yùn)行著并等待工作的到來。

3. START_NOT_STICKY：直到接受到新的Intent對象，才會(huì)被重新創(chuàng)建。這是最安全的，用來避免在不需要的時(shí)候運(yùn)行你的服務(wù)。

4. START_REDELIVER_INTENT：系統(tǒng)就會(huì)重新創(chuàng)建了這個(gè)服務(wù)，并且用最后的Intent對象調(diào)。等待中的Intent對象會(huì)依次被發(fā)送。這適用于如下載文件。

具體實(shí)現(xiàn)方案：

將 Service 設(shè)置為 START_STICKY，利用系統(tǒng)機(jī)制在 Service 掛掉后自動(dòng)拉活：

如下兩種情況無法拉活：

Service 第一次被異常殺死后會(huì)在5秒內(nèi)重啟，第二次被殺死會(huì)在10秒內(nèi)重啟，第三次會(huì)在20秒內(nèi)重啟，一旦在短時(shí)間內(nèi) Service 被殺死達(dá)到5次，則系統(tǒng)不再拉起。

進(jìn)程被取得 Root 權(quán)限的管理工具或系統(tǒng)工具通過 forestop 停止掉，無法重啟。

force close和一些清理軟件很容易就清理掉!

2) 添加Manifest文件屬性值為android:persistent=“true”

app.persistent = true不僅僅標(biāo)志著此apk不能輕易的被kill掉，亦或在被kill掉后能夠自動(dòng)restart，并且還涉及到了進(jìn)程的優(yōu)先級。將被設(shè)置為CORE_SERVER_ADJ，此值為-12，而核心進(jìn)程init的值為-16。當(dāng)前正在前臺(tái)運(yùn)行的進(jìn)程的值為0。如果應(yīng)用能設(shè)置這個(gè)屬性，那就真的可以做到?；?，因?yàn)樗娴目梢詺⒉凰?，像系統(tǒng)的keyguard進(jìn)程，media進(jìn)程，且這些進(jìn)程的adj都是負(fù)數(shù)，代表了前臺(tái)activity黑屏了他們也不會(huì)死。但是這個(gè)屬性需要系統(tǒng)shareuid，然后編譯不過，因?yàn)樾枰到y(tǒng)簽名！

因此，要弄這個(gè)屬性需獲取兩個(gè)關(guān)鍵的信息：

(1).在apk的AndroidManifest.xml文件中設(shè)置android:persistent=true

(2).此apk需要放入到system/app目錄下，成為一個(gè)systemapp

最主要的是讓程序成為系統(tǒng)程序，這個(gè)可以做到嗎？如果你技術(shù)過硬是可以嘗試下的！首先弄個(gè)自動(dòng)root的apk，加殼放到程序中，然后程序運(yùn)行的時(shí)候，自動(dòng)運(yùn)行自動(dòng)root的apk，獲取root權(quán)限，然后在native層中，使用命令的方式把程序移到system/app目錄下，成為系統(tǒng)程序！

3) 覆寫Service的onDestroy方法

在設(shè)置里面的正在運(yùn)行，注意是正在運(yùn)行里面，點(diǎn)擊關(guān)閉，會(huì)走onDestroy回調(diào)方法，你在這里可以把自己啟動(dòng)起來。注意是正常關(guān)閉的時(shí)候是會(huì)自己啟動(dòng)起來，可是使用第三方的清理軟件360，root過的360，force close這些來搞，壓根不會(huì)走到onDestory的方法

4) 監(jiān)聽一堆系統(tǒng)靜態(tài)廣播

在發(fā)生特定系統(tǒng)事件時(shí)，系統(tǒng)會(huì)發(fā)出響應(yīng)的廣播，通過在 AndroidManifest 中“靜態(tài)”注冊對應(yīng)的廣播監(jiān)聽器，即可在發(fā)生響應(yīng)事件時(shí)拉活。

常用的用于拉活的廣播事件包括：

但是有如下問題：

a. 廣播接收器被管理軟件、系統(tǒng)軟件通過“自啟管理”等功能禁用的場景無法接收到廣播，從而無法自啟。

b. 系統(tǒng)廣播事件不可控，只能保證發(fā)生事件時(shí)拉活進(jìn)程，但無法保證進(jìn)程掛掉后立即拉活。

5) 監(jiān)聽第三方應(yīng)用的靜態(tài)廣播

與接收系統(tǒng)廣播類似，不同的是該方案為接收第三方應(yīng)用廣播。

通過反編譯第三方應(yīng)用，如：手機(jī)QQ、微信、支付寶、UC瀏覽器等找出它們外發(fā)的廣播，在應(yīng)用中進(jìn)行監(jiān)聽，這樣當(dāng)這些應(yīng)用發(fā)出廣播時(shí)，就會(huì)將我們的應(yīng)用拉活。

有效程度除與系統(tǒng)廣播一樣的因素外， 第三方應(yīng)用的廣播屬于應(yīng)用私有，當(dāng)前版本中有效的廣播，在后續(xù)版本隨時(shí)就可能被移除或被改為不外發(fā)。

6) AlarmManager喚醒

主要是實(shí)現(xiàn)也一個(gè)監(jiān)聽開機(jī)的廣播，和一個(gè)周期性的鬧鐘，不過比較致命的是耗電量是很高的

7) 賬戶同步，定時(shí)喚醒

android系統(tǒng)里有一個(gè)賬戶系統(tǒng)，系統(tǒng)定期喚醒賬號更新服務(wù)，同步的事件間隔是有限制的，最短1分鐘，利用同步機(jī)制進(jìn)行進(jìn)程的拉活

難點(diǎn)：需要手動(dòng)設(shè)置賬戶，你如何騙你的用戶給你手動(dòng)設(shè)置賬戶完了之后不卸載你，必須聯(lián)網(wǎng)

添加賬號和設(shè)置同步周期的代碼如下：

該方案需要在 AndroidManifest 中定義賬號授權(quán)與同步服務(wù)。

理論上使用與所有 Android 系統(tǒng)，也能解決 force-stop 的拉活，但是前提是需要聯(lián)網(wǎng)狀態(tài)下

注：最新 Android 版本（Android N）中系統(tǒng)好像對賬戶同步這里做了變動(dòng)，該方法不再有效。

8) 雙服務(wù)守護(hù)

這個(gè)是android里面一個(gè)特性，跨進(jìn)程bind一個(gè)service之后，如果被bind的service掛掉，bind他的service會(huì)把他拉起來！可以考慮使用遠(yuǎn)程服務(wù)來實(shí)現(xiàn)，可是還是不能?；钸M(jìn)程，可以被殺掉！

9) 多 APP 間互相拉起

比較常見的就是家族 app 之間互相調(diào)起，你監(jiān)聽到我死了，我把你拉起，之間互相拉活對方

10) Native進(jìn)程拉起

原理就是通過 JNI fork出一個(gè) c 進(jìn)程，c 進(jìn)程監(jiān)控主進(jìn)程是否存活，主要通過管道和文件監(jiān)控的方式實(shí)現(xiàn)監(jiān)控，發(fā)現(xiàn)主進(jìn)程死后，通過調(diào)起一個(gè) service 將主進(jìn)程拉活

具體的實(shí)現(xiàn)方案：

此方案存在兩個(gè)問題：

1.如果直接使用 JNI fork 出一個(gè)子進(jìn)程，這樣會(huì)存在一個(gè)內(nèi)存較大問題，也就是主版占用多大內(nèi)存，native 進(jìn)程也占用多大內(nèi)存，因此需要去寫一個(gè)獨(dú)立的 c 進(jìn)程來降低內(nèi)存大小

2.上面講到5.0以上的系統(tǒng)會(huì)將根據(jù) uid 殺進(jìn)程，因此 native 進(jìn)程也會(huì)被殺死，因此在5.0以上此方案失效的，

11) 雙進(jìn)程守護(hù)

顧名思義開啟兩個(gè) native 進(jìn)程進(jìn)行?；睿?dāng)一個(gè) native 進(jìn)程被殺死后，另一個(gè) native 進(jìn)行拉起，具體實(shí)現(xiàn)方案可參考：http://blog.csdn.net/marswin89/article/details/50916631

12）JobSchedule機(jī)制拉活

Android5.0 以后系統(tǒng)對 Native 進(jìn)程等加強(qiáng)了管理，Native 拉活方式失效。系統(tǒng)在 Android5.0 以上版本提供了 JobScheduler 接口，系統(tǒng)會(huì)定時(shí)調(diào)用該進(jìn)程以使應(yīng)用進(jìn)行一些邏輯操作。

具體實(shí)現(xiàn)方案：

通過創(chuàng)建一個(gè)系統(tǒng)任務(wù)JobInfo，添加到 JobSchedule 中，通過系統(tǒng)調(diào)度任務(wù)來實(shí)現(xiàn)拉活，force-stop 也能實(shí)現(xiàn)拉活

但是存在很多兼容性問題，目前在華為6.0以上不生效，以及在7.0系統(tǒng)上不能實(shí)現(xiàn)，根據(jù)官方文檔說是在 Dos 安全模式下，系統(tǒng)調(diào)度也會(huì)被殺死