Android service)

有了 Service 類我們如何啟動他呢，有兩種方法：

• Context.startService()
• Context.bindService()

在同一個應用任何地方調用 startService() 方法就能啟動 Service 了，然後系統會回調 Service 類的 onCreate() 以及 onStart() 方法。這樣啟動的 Service 會一直運行在後台，直到 Context.stopService() 或者 selfStop() 方法被調用。另外如果一個 Service 已經被啟動，其他代碼再試圖調用 startService() 方法，是不會執行 onCreate() 的，但會重新執行一次 onStart() 。

另外一種 bindService() 方法的意思是，把這個 Service 和調用 Service 的客戶類綁起來，如果調用這個客戶類被銷毀，Service 也會被銷毀。用這個方法的一個好處是，bindService() 方法執行後 Service 會回調上邊提到的 onBind() 方發，你可以從這裡返回一個實現了 IBind 介面的類，在用戶端操作這個類就能和這個服務通訊了，比如得到 Service 啟動並執行狀態或其他動作。如果 Service 還沒有運行，使用這個方法啟動 Service 就會 onCreate() 方法而不會調用 onStart()。

接著前一部分，我們來討論一下在具體使用服務時候會碰上一些問題，以及探討一下解決的辦法。

與 Service 通訊並且讓它持續運行

如果我們想保持和 Service 的通訊，又不想讓 Service 隨著 Activity 退出而退出呢？你可以先 startService() 然後再 bindService() 。當你不需要綁定的時候就執行 unbindService() 方法，執行這個方法只會觸發 Service 的 onUnbind() 而不會把這個 Service 銷毀。這樣就可以既保持和 Service 的通訊，也不會隨著 Activity 銷毀而銷毀了。

提高 Service 優先順序

Android 系統對於記憶體管理有自己的一套方法，為了保障系統有序穩定的運信，系統內部會自動分配，控製程序的記憶體使用量。當系統覺得當前的資源非常有限的時候，為了保 證一些優先順序高的程式能運行，就會殺掉一些他認為不重要的程式或者服務來釋放記憶體。這樣就能保證真正對使用者有用的程式仍然再運行。如果你的 Service 碰上了這種情況，多半會先被殺掉。但如果你增加 Service 的優先順序就能讓他多留一會，我們可以用 setForeground(true) 來設定 Service 的優先順序。

為什麼是 foreground ? 預設啟動的 Service 是被標記為 background，當前啟動並執行 Activity 一般被標記為 foreground，也就是說你給 Service 設定了 foreground 那麼他就和正在啟動並執行 Activity 類似優先順序得到了一定的提高。當讓這並不能保證你得 Service 永遠不被殺掉，只是提高了他的優先順序。

有一個方法可以給你更清晰的示範，進入 $SDK/tools 運行命令

返回的一大堆東西，觀察 oom_adj 的值，如果是大於 8 一般就是屬於 backgroud 隨時可能被幹掉，數值越小證明優先順序越高，被幹掉的時間越晚。你看phone的程式是 -12 說明電話就是電話，其他什麼都幹了了，也的能接電話對吧。另外還有一個 -100 的，更邪乎因為是 system 如果他也完蛋了，你得系統也就掛了，嘿嘿。

用其他方式啟動 Service

其實不光能從 Activity 中啟動 Service ，還有一個很有用的方法是接收系統的廣播，這就要用到 Receiver 。在 Mainfest 檔案中配置你得 Receiver 能接收什麼樣的廣播訊息，那麼即使你得程式沒有顯示給使用者，你的 Service 也能啟動。你要做的就是繼承 android.content.BroadcastReceiver ，然後實現 onReceive(Context context, Intent intent) 方法，就可以啟動你得 Service 了。這裡不能 bindService 因為一個 Receiver 是一個短暫存在的對象，所以 bind 是沒有什麼意義的。

資源消耗

大家都說 G1 的電池太不抗用，這個問題其實我看來跟多是軟體的問題。1150毫安的電池不算大，但也不算小了，考慮到 500mhz 的 CPU 還是非常耗電的。因為一個 Service 要長時間後台運行，所以如果你得 Service 太過於消耗資源那電池更用不了多久了。

對於這個問題我有一點點考慮，和大家分享一下。因為一般 Service 都會啟動另外的線程不斷迴圈作一些操作，迴圈頻率不易太高。也不要做太過於耗費資源的操作，特別是CPU資源，因為後台 Service 使用者看不到，會比較莫名奇妙。具體可以結合 top 以及 logcat 監測使用方式。LOG中如果虛擬機器頻繁的 GC 應該也說明程式還有很大改進的餘地。因為GC 也是很耗費CPU的。可能這些不光 Service 應該注意，只要是行動裝置都應該考慮，才能給你的使用者最佳的體驗。