前言

Android進(jìn)程和Service的保活，是困擾Android開發(fā)人員的一大頑疾。因涉及到省電和內(nèi)存管理策略，各廠商基于自家的理解，在自已ROOM發(fā)布于都對標(biāo)準(zhǔn)Android發(fā)行版作為或多或少的改動(dòng)，使得應(yīng)用層程序在處理進(jìn)程和Service保活問題上變的異常復(fù)雜，且很難兼容，因?yàn)檎f不定哪款手機(jī)或者哪個(gè)版本的省電策略發(fā)生改變，那么隨之而來的就是進(jìn)程和Service保活的差異。

在應(yīng)用場景上，由于即時(shí)通訊應(yīng)用(包括IM聊天應(yīng)用、消息推送服務(wù)等)為了保證消息的全時(shí)、實(shí)時(shí)送達(dá)能力，必須要實(shí)現(xiàn)進(jìn)程或Service的保活。而就這一看似不起眼的問題，實(shí)際處理起來，因?yàn)楸姸郃ndroid手機(jī)和Android系統(tǒng)版本的差異，讓問題的處理充滿了不確定性。

本文基于作者的實(shí)踐以及相關(guān)資料的整理，總結(jié)了自已對Android進(jìn)程和Service保活的理解，希望能為你的應(yīng)用開發(fā)帶來啟發(fā)。

概述

近期做了一個(gè)Android項(xiàng)目，涉及到了后臺(tái)進(jìn)程和Service保活的問題，網(wǎng)上找了很多資料，基本的保活方法都測試了。結(jié)果是：不同的手機(jī)，不同的Android版本保活效果各有差異。最難繞過的是個(gè)廠商對“后臺(tái)程序保活”管理。

本文主要把相應(yīng)的實(shí)踐結(jié)果和保活方法進(jìn)行總結(jié)。然而，因筆者可用的測試真機(jī)有限，可能存有不完整的地方，還請及時(shí)提出指正并補(bǔ)充，大家共同進(jìn)步。

手機(jī)QQ、微信這樣的大型IM是如何解決保活問題的?

以小米手機(jī)為例，MIUI的神隱模式讓很多IM和推送開發(fā)同行糾結(jié)不已：在MIUI深度休眠之后,默認(rèn)會(huì)徹底斷開后臺(tái)應(yīng)用的socket。但微信、QQ這樣的應(yīng)用，MIUI官方的帖子說了:給這2個(gè)應(yīng)用特殊照顧。好吧，特殊照顧，普通的APP只能繼續(xù)折騰了。

(關(guān)于MIUI的神隱模式的討論，見此貼的回復(fù)：http://www.52im.net/thread-354-1-1.html)

本文實(shí)踐涉及到的真機(jī)型號和版本

手機(jī)：三星9100-4.1.2，三星9300-4.3，華為G730-4.1.2，華為TL00H-EMUI3.1(android 5.1.1)，魅族MX4-Flyme4.2.8.2c(android 4.4.2)。

手頭能用的測試機(jī)就這些了。主要測試的service是一個(gè)最基本的service，在相應(yīng)的生命周期的觸發(fā)函數(shù)上做了輸出。測試時(shí)都沒有添加到后臺(tái)保護(hù)中，注：三星的機(jī)子沒找到有后臺(tái)保護(hù)設(shè)置的地方。

為什么我們的后臺(tái)進(jìn)程/Service會(huì)被結(jié)束掉?

我想到的是有三個(gè)方面：

• Android系統(tǒng)內(nèi)存回收機(jī)制;
• 各廠商對后臺(tái)程序的一個(gè)管理制度(就是允許程序后臺(tái)運(yùn)行那個(gè));
• 第三方軟件的清理(360什么的)。

其中有的后臺(tái)程序保護(hù)把程序結(jié)束的同時(shí)會(huì)把程序弄成停止?fàn)顟B(tài)，導(dǎo)致無法接收廣播!

我們的保活方案有哪些?

1)控制onStartCommand函數(shù)的返回值：

我對這個(gè)函數(shù)的理解是：當(dāng)服務(wù)被異常終止時(shí)，是否重啟服務(wù)?有些文章里面在用這個(gè)做保活時(shí)，修改的是flag，在我實(shí)際測試中是無效。有效的做法是直接返回參數(shù)。另外默認(rèn)的flags值為0，是START_STICKY_COMPATIBILITY。

具體代碼如下：

@Override 
publicintonStartCommand(Intent intent,intflags,intstartId) { 
    // TODO Auto-generated method stub 
    returnSTART_STICKY; 
    //return super.onStartCommand(intent, flags, startId); 
} 

測試結(jié)果：

魅族的機(jī)子無效，不管默認(rèn)還是修改參數(shù)，在DDMS里面直接結(jié)束進(jìn)程后都不會(huì)重啟服務(wù)。其它三臺(tái)機(jī)子(9100沒測)：默認(rèn)參數(shù)的情況下就會(huì)重啟服務(wù)，return START_STICKY 會(huì)重啟，return START_NOT_STICKY 不會(huì)重啟。

另外：用360一鍵清理，或者360超級ROOT的手機(jī)優(yōu)化，會(huì)殺死進(jìn)程，過會(huì)兒還是會(huì)重啟，只是會(huì)慢很多，大概是在排隊(duì)重啟服務(wù)。

2)在service 的onDestory里面重啟服務(wù)：

這個(gè)在所有能觸發(fā)onDestory的情況下都是有效的。4臺(tái)測試機(jī)都測試過。直接startService 或者發(fā)送廣播重啟都可以 。

但能觸發(fā)onDestory的情況，我不知道內(nèi)存回收會(huì)不會(huì)觸發(fā)。另外兩種情況(2，3)是不觸發(fā)的。我的測試方法是在“設(shè)置”-> 應(yīng)用管理-> 正在運(yùn)行-> 停止服務(wù)。(這個(gè)是正常停止服務(wù)，會(huì)觸發(fā)onDestory，所以上面的onStartCommand效果不會(huì)觸發(fā)。)

3)提高服務(wù)的優(yōu)先級：

這個(gè)主要是針對***種kill服務(wù)的情況，內(nèi)存回收機(jī)制。由于這個(gè)測試比較難搭建。360清理什么把后臺(tái)的進(jìn)程都?xì)⒌模w現(xiàn)不出優(yōu)先級這樣的概念。我的建議是能提高就提高，下面幾個(gè)實(shí)驗(yàn)。

[1] 前臺(tái)service：

創(chuàng)建一個(gè)通知使自己成為前臺(tái)service

測試結(jié)果：

360一鍵清理和手機(jī)優(yōu)化，不會(huì)把該service結(jié)束掉。

[2] 對于后臺(tái)保護(hù)：

華為G730不結(jié)束service，魅族和華為TL00H都會(huì)結(jié)束service。通知欄的保活效果還是可以的，一般的應(yīng)用要求基本能滿足了。

[3] 若有root權(quán)限：

android:persistent="true",并放入system/app中

測試結(jié)果：

效果一般，三星9100上用360等清理工具殺不掉進(jìn)程，在華為G730上沒什么效果.(這個(gè)測試跟onStartCommand有點(diǎn)干擾)。

4)守護(hù)進(jìn)程：

雙服務(wù)：360會(huì)同時(shí)殺掉兩個(gè)服務(wù)，分兩個(gè)apk也一樣。

native守護(hù)進(jìn)程：360不會(huì)殺掉native的守護(hù)進(jìn)程，但在魅族和華為TL00H中待機(jī)一段時(shí)間后還是會(huì)被殺掉。

結(jié)論和待續(xù)：

1. 一般的應(yīng)用添加到后臺(tái)保護(hù)進(jìn)程后，改個(gè)onStartCommand返回值，再加個(gè)通知。基本上大部分都能保活了。

2. 雙服務(wù)我覺得沒有native守護(hù)進(jìn)程來的好，雖然360，微信什么的都有幾個(gè)進(jìn)程服務(wù)，但如果不添加到后臺(tái)保活的話，效果一樣不能保活，也會(huì)進(jìn)入停止?fàn)顟B(tài)。

3. 但是.360手機(jī)助手會(huì)創(chuàng)建雙natice守護(hù)進(jìn)程做相互的看守。存活的效果會(huì)高一點(diǎn)點(diǎn)。“沒添加到后臺(tái)保活”一般只會(huì)殺一次，(魅族是屏幕關(guān)閉后5分鐘，華為TL00H是屏幕關(guān)閉時(shí))。

附個(gè)native守護(hù)進(jìn)程：利用socket來判斷服務(wù)是否存在，需要在被保活的服務(wù)里創(chuàng)建一個(gè)監(jiān)聽socket。調(diào)試信息會(huì)在SD卡目錄下創(chuàng)建一個(gè)daemon.log。使用方法：NDKFork port包名/.服務(wù)名。具體下載鏈接：http://download.csdn.net/detail/pvlking/9412815

Android應(yīng)用實(shí)現(xiàn)保活的基本原理總結(jié)

都是通過雙進(jìn)程互拉以及設(shè)置進(jìn)程的重要性，除非你root后，把自己的進(jìn)程設(shè)置成系統(tǒng)進(jìn)程。

互拉的方式有很多種：

• 可以通過監(jiān)聽系統(tǒng)廣播來把自己拉起來
• 可以多個(gè)app相互拉
• 可以把自己的服務(wù)搞成前臺(tái)服務(wù)
• 在service的onstart方法里返回 STATR_STICK
• 添加Manifest文件屬性值為android:persistent=“true”
• 覆寫Service的onDestroy方法
• 服務(wù)互相綁定
• 設(shè)置鬧鐘，定時(shí)喚醒
• 自己的app在native層fork一個(gè)子進(jìn)程來與主進(jìn)程互拉。

綜上所述，總結(jié)下來就是，目前實(shí)現(xiàn)Android后臺(tái)保活沒有***實(shí)現(xiàn)，只能針對不同的機(jī)型綜合使用上面列舉的方法，同時(shí)祈禱自已APP的用戶不要遇到奇葩機(jī)型的保活問題。

推薦一個(gè)開源的解決方案

1)源碼托管地址

源碼托管地址是：https://github.com/52im/MarsDaemon。

2)實(shí)現(xiàn)原理

原理：使用Jni,在 c端 fork進(jìn)程，檢測Service是否存活，若Service已被殺死，則進(jìn)行重啟Service. 至于檢測方式，可以輪詢獲取子進(jìn)程Pid,若為1, 則說明子進(jìn)程被Init進(jìn)程所領(lǐng)養(yǎng),已經(jīng)成為了孤兒進(jìn)程. 但是這種方式比較消耗電量，并且由于不同手機(jī)系統(tǒng)定制的改變，當(dāng)應(yīng)用被強(qiáng)制停止時(shí)，父進(jìn)程并不一定被真正殺死，因此在一些特定機(jī)型上是無法通過此方式進(jìn)行判斷. 這里推薦使用liunx socket的方式進(jìn)行類似心跳包的檢測，并且當(dāng)觸發(fā)檢測Service是否被殺死之前，需要判斷應(yīng)用是否已經(jīng)被卸載，如果應(yīng)用已經(jīng)被卸載，則不再進(jìn)行檢測Service行為，直接調(diào)用exit(0)退出子進(jìn)程，避免浪費(fèi)系統(tǒng)資源和消耗電量.

注意: 目前在Android 5.0系統(tǒng)上會(huì)把fork出來的進(jìn)程放到一個(gè)進(jìn)程組里， 當(dāng)程序主進(jìn)程掛掉后，也會(huì)把整個(gè)進(jìn)程組殺掉,因此用fork的方式也無法在Android5.0及以上系統(tǒng)實(shí)現(xiàn)守護(hù)進(jìn)程. 這個(gè)是系統(tǒng)層面的限制，當(dāng)然也是為了優(yōu)化整個(gè)的系統(tǒng)環(huán)境,守護(hù)進(jìn)程給手機(jī)帶來的體驗(yàn)并不好

具體見源碼：http://androidxref.com/5.0.0_r2/ ... /ProcessRecord.java

好消息：

Android5.0 以上目前已在 https://github.com/52im/MarsDaemon 中被黑科技攻克，部分機(jī)型可能無法起到作用，但思路很值得借鑒，代碼結(jié)構(gòu)也不錯(cuò), 具體方案請見源碼哦。