Android應對進程被殺死--Service(二)

Service組件在android開發中經常遇到,其經常作爲後臺服務,需要始終保持運行,負責處理一些必要(見不得人)的任務。而一些安全軟件,如360等,會有結束進程的功能,如果不做Service的保持,就會被其殺掉。

在早些時候,我們可以通過以下方法:
1.service中重寫onStartCommand方法,這個方法有三個返回值, START_STICKY是service被kill掉後自動重啓

 

  1. public int onStartCommand(Intent intent, int flags, int startId) {          
  2.    return START_STICKY;      
  3. }  
public int onStartCommand(Intent intent, int flags, int startId) {        
   return START_STICKY;    
}

2. 配置Android:persistent=”true”
3. setForeground(true);
4. android:process=”com.xxx.xxxservice”配置到單獨的進程中

以上的方法要麼只是提升service優先級或者存活率, 並不能解決被安全軟件強行殺死的問題.
要麼像第四種單獨的進程運行service在360老的版本是可以的,但是在360的比較新的版本中仍然會被殺死.

如何保持Service的運行狀態是現在要說明的,核心就是利用ANDROID的系統廣播,觸發自己的程序檢查Service的運行狀態,如果被殺掉,就再起來。常用的有開機廣播,解鎖屏幕的廣播,電量變化等等, 其中解屏的廣播算比較頻繁的了,但是也並不能保證一定的頻率,尤其是在特定的時間裏(比如用戶睡覺的時候,用戶並不進行解鎖操作).而我們仍要做一些操作的時候,就沒有辦法了.

因此,我採用了一種別的方案. 另外再加上兩個類似一守護進程的Service, 分別檢查Service的運行狀態,註冊響應的廣播,對其進行守護,一旦發現沒有運行就將其啓動.我利用的系統廣播是Intent.ACTION_TIME_TICK,這個廣播每分鐘發送一次,我們可以每分鐘檢查一次Service的運行狀態,如果已經被結束了,就重新啓動Service。

它的優點就是間隔時間短而且非常穩定, 而其他的廣播並不能保證這一點,當然,在具體的應用中還是要根據需求使用, 結合其他廣播來保證自己的service一定會被重啓.

畢竟現在安全軟件是越來越厲害了,更新得也是非常頻繁. 有時間還是要看下還有沒有其他的方法,綜合幾種來使用.


下邊就是具體的代碼和注意事項了:
1、 Intent.ACTION_TIME_TICK的使用
我們知道廣播的註冊有靜態註冊和動態註冊,但此係統廣播只能通過動態註冊的方式使用。即你不能通過在manifest.xml裏註冊的方式接收到這個廣播,只能在代碼裏通過
registerReceiver()方法註冊。
在This App extends Application 或者在service裏註冊廣播:  
  1. IntentFilter filter = newIntentFilter(Intent.ACTION_TIME_TICK);  
  2.      
  3.     MyBroadcastReceiver receiver = new MyBroadcastReceiver();  
  4.     registerReceiver(receiver, filter);  
在廣播接收器MyBroadcastReceiver extends BroadcastReceiver的onReceive裏  
  1. boolean isServiceRunning = false;  
  2.  
  3.  
  4.     if (intent.getAction().equals(Intent.ACTION_TIME_TICK)) {  
  5.        
  6.     //檢查Service狀態  
  7.        
  8.     ActivityManager manager = (ActivityManager)AppApplication.getContext().getSystemService(Context.ACTIVITY_SERVICE);  
  9.     for (RunningServiceInfo service :manager.getRunningServices(Integer.MAX_VALUE)) {  
  10.     if(“so.xxxx.xxxxService”.equals(service.service.getClassName()))  
  11.            
  12.      {  
  13.      isServiceRunning = true;  
  14.     }  
  15.        
  16.      }  
  17.     if (!isServiceRunning) {  
  18.     Intent i = new Intent(context, xxxService.class);  
  19.            context.startService(i);  
  20.     }  
  21.  
  22.  
  23. }  


終極解決方案:


使用Jni,在 c端 fork進程,檢測Service是否存活,若Service已被殺死,則進行重啓Service. 

至於檢測方式,可以輪詢獲取子進程Pid,若爲1, 則說明子進程被Init進程所領養,已經成爲了孤兒進程.   

但是這種方式比較消耗電量,並且由於不同手機系統定製的改變,當應用被強制停止時,父進程並不一定被真正殺死,因此在一些特定機型上是無法通過此方式進行判斷. 這裏推薦使用liunx socket的方式進行類似心跳包的檢測,並且當觸發檢測Service是否被殺死之前,需要判斷應用是否已經被卸載,如果應用已經被卸載,則不再進行檢測Service行爲,直接調用exit(0)退出子進程,避免浪費系統資源和消耗電量.


注意: 目前在Android 5.0系統上會把fork出來的進程放到一個進程組裏, 當程序主進程掛掉後,也會把整個進程組殺掉,因此用fork的方式也無法在Android5.0及以上系統實現守護進程. 這個是系統層面的限制,當然也是爲了優化整個的系統環境,守護進程給手機帶來的體驗並不好

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章