今天來學習如何用intent來啟動service，一樣參考官網。

Service物件

• Service class
• onCreate() - Service實作部分。需特別注意，因為service是執行在APP process的main thread，所以要有非同步處理，例如在onCreate()裡建立新的thread，或使用AsyncTask。

啟動service

• Context.startService()
  當有人呼叫Context.startService()啟動service之後，系統會試情況呼叫該service的onCreate()來建立service，然後呼叫onStartCommand(Intent, int, int)，接著開始執行service，直到Context.stopService()或有人呼叫service的stopSelf()，service才結束運作。

• Context.bindService()
  當有人呼叫Context.bindService()啟動service之後，系統會試情況呼叫該service的onCreate()來建立service，但不呼叫onStartCommand()。使用者會收到onBind(Intent)所回傳的IBinder物件，可讓使用者與service互動。當service從connection狀態變成真正開始或者，有一個以上的connection有Context.BIND_AUTO_CREATE flag，該service就會停止。

onStartCommand() return值

• START_STICKY
  如果service process在啟動service之後被砍了，保留在開始狀態，但不保留intent。之後系統自己會試著重新建立service。因為service保留在開始狀態，service建立完之後會再呼叫一次onStartCommand()。如果這時沒有pending的start command可傳給service，就會使用一個NULL的intent來啟動service，需特別注意。

• START_NOT_STICKY
  如果service process在啟動service之後被砍了，且沒有intent再來啟動該service，就不要保留在開始狀態，系統也不會自己重建service。除非之後有explicit call明確地想重啟此service，service才會被再次建立，所以不須擔心使用NULL intent建立service的問題。

• START_REDELIVER_INTENT
  如果service process在啟動service之後被砍了，系統會安排之後重啟，並且使用上一次使用的相同intent，所以一樣不會有NULL intent建立service的問題。

  這沒有一個實例還真是難以想像，不過就先讀過有個記憶點吧。
  

JobScheduler

Android 5.0(API level 21)之後，可透過JobScheduler來啟動service。所以來了解一下JobServicer是什麼。

• JobService
  非同步job service物件的class，實作寫在onStartJob(JobParameters)，是JobScheduler callback的主要入口點。
• JobScheduler
  一個用來管理各種job的class，這些job會被自己APP的process執行。
• JobInfo
  傳給JobScheduler的info，可使用JobInfo.Builder來建立，如下：

JobInfo.Builder(int jobId, ComponentName jobService)
// 初始化一個Builder，用來建立JobInfo

建立好JobInfo物件之後，可透過schedule(JobInfo)傳給JobScheduler。
JobService會執行JobScheduler所安排好的眾多Job，且一定要實作平行(非同步)運作，否則會被未來呼叫的callback給block住，詳細參考官網-JobService。

今天學習的都是官網上對這些class的基本介紹，未來需要有實例才能融會貫通，今天就先這樣。