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

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

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

一.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)先級(jí)，降低在內(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é)了以上被殺死的場(chǎng)景分析销斟，我們得出兩種技術(shù)方案：

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

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

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

Android 系統(tǒng)將盡量長(zhǎ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í)的進(jìn)程迈勋，依此類推，以回收系統(tǒng)資源醋粟。

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

前臺(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)、但仍對(duì)用戶可見的Activity（已調(diào)用其onPause()方法）烤礁。例如讼积，如果前臺(tái) Activity 啟動(dòng)了一個(gè)對(duì)話框，允許在其后顯示上一 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)程

包含目前對(duì)用戶不可見的 Activity 的進(jìn)程（已調(diào)用 Activity 的onStop()方法）甸鸟。這些進(jìn)程對(duì)用戶體驗(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ì)對(duì)用戶體驗(yàn)產(chǎn)生明顯影響剔交，因?yàn)楫?dāng)用戶導(dǎo)航回該 Activity 時(shí)，Activity 會(huì)恢復(fù)其所有可見狀態(tài)改衩。 有關(guān)保存和恢復(fù)狀態(tài)的信息岖常，請(qǐng)參閱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)程評(píng)定為它可能達(dá)到的最高級(jí)別洽胶。例如晒夹，如果某進(jìn)程托管著服務(wù)和可見 Activity，則會(huì)將此進(jìn)程評(píng)定為可見進(jìn)程姊氓，而不是服務(wù)進(jìn)程丐怯。

前臺(tái)進(jìn)程的重要性最高，依次遞減翔横，空進(jìn)程的重要性最低读跷，下面分別來闡述每種級(jí)別的進(jìn)程，進(jìn)程的回收策略如上禾唁，進(jìn)程的介紹可詳見http://www.reibang.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)先級(jí)在屏幕鎖屏?xí)r間由4提升為最高優(yōu)先級(jí)1，主要解決第三方應(yīng)用及系統(tǒng)管理工具在檢測(cè)到鎖屏事件后一段時(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)先級(jí)為4，通過 setForeground 接口可以將后臺(tái) Service 設(shè)置為前臺(tái) Service抽兆，使進(jìn)程的優(yōu)先級(jí)由4提升為2识补，從而使進(jìn)程的優(yōu)先級(jí)僅僅低于用戶當(dāng)前正在交互的進(jìn)程，與可見進(jìn)程優(yōu)先級(jí)一致辫红，使進(jìn)程被殺死的概率大大降低凭涂。

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

對(duì)于不需要常駐通知欄的應(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)先級(jí)依然保持為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對(duì)象那槽，這適用于不執(zhí)行命令的媒體播放器（或類似的服務(wù)），它只是無限期的運(yùn)行著并等待工作的到來等舔。

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

4. START_REDELIVER_INTENT：系統(tǒng)就會(huì)重新創(chuàng)建了這個(gè)服務(wù)，并且用最后的Intent對(duì)象調(diào)蝶柿。等待中的Intent對(duì)象會(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)先級(jí)磷蜀。將被設(shè)置為CORE_SERVER_ADJ，此值為-12褐隆，而核心進(jìn)程init的值為-16污它。當(dāng)前正在前臺(tái)運(yùn)行的進(jìn)程的值為0妓灌。如果應(yīng)用能設(shè)置這個(gè)屬性，那就真的可以做到背婀。活祥山，因?yàn)樗娴目梢詺⒉凰溃裣到y(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)方法恭取，你在這里可以把自己?jiǎn)?dòng)起來蜈垮。注意是正常關(guān)閉的時(shí)候是會(huì)自己?jiǎn)?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)”注冊(cè)對(duì)應(yīng)的廣播監(jiān)聽器愤诱，即可在發(fā)生響應(yīng)事件時(shí)拉活淫半。

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

但是有如下問題：

a. 廣播接收器被管理軟件撮慨、系統(tǒng)軟件通過“自啟管理”等功能禁用的場(chǎ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)定期喚醒賬號(hào)更新服務(wù)絮识，同步的事件間隔是有限制的嗽上，最短1分鐘兽愤，利用同步機(jī)制進(jìn)行進(jìn)程的拉活

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

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

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

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

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

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

這個(gè)是android里面一個(gè)特性瘤旨，跨進(jìn)程bind一個(gè)service之后裆站，如果被bind的service掛掉，bind他的service會(huì)把他拉起來羽嫡！可以考慮使用遠(yuǎn)程服務(wù)來實(shí)現(xiàn)杭棵，可是還是不能被曜Γ活進(jìn)程艰管，可以被殺掉牲芋！

9) 多 APP 間互相拉起

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

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)對(duì) 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ì)被殺死