Android Service使用關鍵點

Service的2種類型：
1. 經過調用startService()來啓動服務，就能在後臺一直運行下去，即便啓動它的組件已經被銷燬了。 一般，started的服務執行單一的操做而且不會向調用者返回結果。因此，必須用stopSelf()或stopService()進行終止。不論調用了多少次startService()，只須要調用一次stopService()來中止服務。

2. 經過調用bindService()綁定到服務上，容許組件與服務進行交互、發送請求、獲取結果，甚至能夠利用進程間通訊（IPC）跨進程執行這些操做。綁定服務的生存期和被綁定的應用程序組件一致。多個組件能夠同時與一個服務綁定，不過全部的組件調用unbindService()解除綁定後，服務也就會被銷燬。
注意:經過startService()來啓動的服務也能夠經過調用bindService()被綁定，此時stopService()或stopSelf()不會真的終止服務，除非全部的客戶端都解除了綁定。

manifest中定義的屬性：
android:exported
是否容許任何應用程序組件都使用此服務
默認值取決於<service>是否包含<intent-filter>，若是不包含，則默認值爲false，反之則爲true。也可使用permission權限控制來達到相同的目的。
android:permission
標識此Service的調用權限，若是沒有設置，則默認使用<application>的權限設置。
android:process
標識該Service將運行在哪一個進程中。若是以「：」開頭，Service是Applicaiton的私有進程；以包名形式，Sevice是全局進程。

請注意onStartCommand()方法必須返回一個整數,描述系統在殺死服務以後應該如何繼續運行:
START_NOT_STICKY  
殺死服務後，不會重建，除非還存在未發送的intent。 當服務再也不是必需的，而且應用程序可以簡單地重啓那些未完成的工做時，這是避免服務運行的最安全的選項。
START_STICKY  
殺死服務後，將重建服務並調用onStartCommand()，但不會再次送入上一個intent，而是用null intent來調用onStartCommand() 。除非還有啓動服務的intent未發送完，那麼這些剩下的intent會繼續發送。 這適用於媒體播放器（或相似服務），它們不執行命令，但須要一直運行並隨時待命。
START_REDELIVER_INTENT  
殺死服務後，將重建服務並用上一個已送過的intent調用onStartCommand()。任何未發送完的intent也都會依次送入。這適用於那些須要當即恢復工做的活躍服務，好比下載文件。

IntentService是Service類的子類，用來處理異步請求。客戶端能夠經過startService(Intent)方法傳遞請求給IntentService，IntentService經過worker thread處理每一個Intent對象，執行完全部的工做以後自動中止Service。不須要主動調用stopSelft()來結束服務。

具體參考：
http://android-doc.com/guide/components/services.html
http://android-doc.com/guide/components/bound-services.html