能否保證service不被殺死?

Service設置成START_STICKY

• kill 後會被重啟（等待5秒左右），重傳Intent，保持與重啟前一樣

提升service優先級

• 在AndroidManifest.xml文件中對於intent-filter可以通過android:priority = "1000"這個屬性設置最高優先級，1000是最高值，如果數字越小則優先級越低，同時適用於廣播。

• 【結論】目前看來，priority這個屬性貌似隻適用於broadcast，對於Service來說可能無效

提升service進程優先級

• Android中的進程是托管的，當係統進程空間緊張的時候，會依照優先級自動進行進程的回收

• 當service運行在低內存的環境時，將會kill掉一些存在的進程。因此進程的優先級將會很重要，可以在startForeground()使用startForeground()將service放到前台狀態。這樣在低內存時被kill的幾率會低一些。

• 【結論】如果在極度極度低內存的壓力下，該service還是會被kill掉，並且不一定會restart()

onDestroy方法裏重啟service

• service +broadcast 方式，就是當service走onDestory()的時候，發送一個自定義的廣播，當收到廣播的時候，重新啟動service

• 也可以直接在onDestroy()裏startService

• 【結論】當使用類似口口管家等第三方應用或是在setting裏-應用-強製停止時，APP進程可能就直接被幹掉了，onDestroy方法都進不來，所以還是無法保證

監聽係統廣播判斷Service狀態

• 通過係統的一些廣播，比如：手機重啟、界麵喚醒、應用狀態改變等等監聽並捕獲到，然後判斷我們的Service是否還存活，別忘記加權限

• 【結論】這也能算是一種措施，不過感覺監聽多了會導致Service很混亂，帶來諸多不便

在JNI層,用C代碼fork一個進程出來

• 這樣產生的進程,會被係統認為是兩個不同的進程.但是Android5.0之後可能不行

root之後放到system/app變成係統級應用

大招: 放一個像素在前台(手機QQ)