Android如何讓Service不被輕易殺死

引言

随着Android系統的更新，讓服務長期運作在背景越來越困難，使我們可以免受流氓軟體的困擾，真是可喜可賀。然而作為一個開發者，有時候也會面臨這樣一個問題，我們希望我們的服務可以盡可能長時間的在背景存活，然而我們的軟體如果不是在ROM廠商的白名單中的話，一旦記憶體吃緊，被殺死幾乎是必然的事情，接下來我們就來談談如何盡可能讓我們的服務存活的時間長一些。

1、提升service程序優先級

Android将程序分為6個等級,它們按優先級順序由高到低依次是:

1.前台程序( FOREGROUND_APP)
2.可視程序(VISIBLE_APP )
3.次要服務程序(SECONDARY_SERVER )
4.背景程序 (HIDDEN_APP)
5.内容供應節點(CONTENT_PROVIDER)
6.空程序(EMPTY_APP) 
           

當service運作在低記憶體的環境時，将會kill掉一些存在的程序。是以程序的優先級将會很重要，可以使用startForeground 将service放到前台狀态。這樣在低記憶體時被kill的幾率會低一些。

這種方法可以明顯的提升服務的存活時間，但是這個方法存在一個問題就是會在通知欄顯示一個通知，如果我們不想要這個通知怎麼辦，在網上搜尋時發現可以再寫一個空的前台service，而notification則使用同一個id，這樣通知欄顯示的就是後面的這個service的notification，将這個service銷毀，notification也會随之銷毀，親測有效，下面附上連結：

Android的startForeground前台Service如何去掉通知顯示

2、onStartCommand方法

如果記憶體吃緊，服務被幹掉了，有沒有辦法挽救一下呢，答案是确實還可以搶救一下。

StartCommond幾個常量參數簡介：

1、START_STICKY

在運作onStartCommand後service程序被kill後，那将保留在開始狀态，但是不保留那些傳入的intent。不久後service就會再次嘗試重新建立，因為保留在開始狀态，在建立 service後将保證調用onstartCommand。如果沒有傳遞任何開始指令給service，那将擷取到null的intent。

2、START_NOT_STICKY

在運作onStartCommand後service程序被kill後，并且沒有新的intent傳遞給它。Service将移出開始狀态，并且直到新的明顯的方法（startService）調用才重新建立。因為如果沒有傳遞任何未決定的intent那麼service是不會啟動，也就是期間onstartCommand不會接收到任何null的intent。

3、START_REDELIVER_INTENT

在運作onStartCommand後service程序被kill後，系統将會再次啟動service，并傳入最後一個intent給onstartCommand。直到調用stopSelf(int)才停止傳遞intent。如果在被kill後還有未處理好的intent，那被kill後服務還是會自動啟動。是以onstartCommand不會接收到任何null的intent。

使用方法很簡單，設定一下flags就可以了：

@Override  
public int onStartCommand(Intent intent, int flags, int startId) {  
    flags = START_STICKY;  
    return super.onStartCommand(intent, flags, startId);  
}  
           

3、onDestroy（）方法中重新開機服務

可以寫一個服務啟動自己，也可以寫兩個服務，互相啟動，就是startService(),這裡就不再贅述。

4、監聽廣播

可以靜态或動态注冊一些廣播接收器，比如開機廣播，解鎖手機的廣播等，需要注意的是，有一部分廣播是必須要動态注冊才能接收的，比如開關螢幕，還有系統的alarm manager的定時廣播等。

總結

以前的建立兩個程序守護的方式在android5.0以後就不能用了，想讓服務永遠存活也不現實，我們隻是盡量讓它多存活一段時間。網上這方面的東西很多，内容也基本是一樣的，這裡我挑選了幾個個人感覺比較有用的方法，做下記錄。

如果不是在ROM廠商的白名單中的話，我感覺能做的其實也不算太多，想讓服務不被殺死，很難，想要殺死一個應用，很簡單，直接到設定-應用程式中，強制關閉就好，不走生命周期，package級别直接關閉，不管QQ,微信還是什麼全家桶，都可以一下帶走 (～￣▽￣)～。