关于Android Service真正的完全详解,你需要知道的一切
轉(zhuǎn)載請(qǐng)注明出處(萬(wàn)分感謝!):?
http://blog.csdn.net/javazejian/article/details/52709857?
出自【zejian的博客】
??Service全部?jī)?nèi)容基本會(huì)在本篇涉及到,我們將圍繞以下主要知識(shí)點(diǎn)進(jìn)行分析:
- Service簡(jiǎn)單概述
- Service在清單文件中的聲明
- Service啟動(dòng)服務(wù)實(shí)現(xiàn)方式及其詳解
- Service綁定服務(wù)的三種實(shí)現(xiàn)方式
- 關(guān)于啟動(dòng)服務(wù)與綁定服務(wù)間的轉(zhuǎn)換問(wèn)題
- 前臺(tái)服務(wù)以及通知發(fā)送
- 服務(wù)Service與線程Thread的區(qū)別
- 管理服務(wù)生命周期的要點(diǎn)
- Android 5.0以上的隱式啟動(dòng)問(wèn)題及其解決方案
- 保證服務(wù)不被殺死的實(shí)現(xiàn)思路
1.Service簡(jiǎn)單概述
??Service(服務(wù))是一個(gè)一種可以在后臺(tái)執(zhí)行長(zhǎng)時(shí)間運(yùn)行操作而沒(méi)有用戶界面的應(yīng)用組件。服務(wù)可由其他應(yīng)用組件啟動(dòng)(如Activity),服務(wù)一旦被啟動(dòng)將在后臺(tái)一直運(yùn)行,即使啟動(dòng)服務(wù)的組件(Activity)已銷(xiāo)毀也不受影響。 此外,組件可以綁定到服務(wù),以與之進(jìn)行交互,甚至是執(zhí)行進(jìn)程間通信 (IPC)。 例如,服務(wù)可以處理網(wǎng)絡(luò)事務(wù)、播放音樂(lè),執(zhí)行文件 I/O 或與內(nèi)容提供程序交互,而所有這一切均可在后臺(tái)進(jìn)行,Service基本上分為兩種形式:
- 啟動(dòng)狀態(tài)
??當(dāng)應(yīng)用組件(如 Activity)通過(guò)調(diào)用 startService() 啟動(dòng)服務(wù)時(shí),服務(wù)即處于“啟動(dòng)”狀態(tài)。一旦啟動(dòng),服務(wù)即可在后臺(tái)無(wú)限期運(yùn)行,即使啟動(dòng)服務(wù)的組件已被銷(xiāo)毀也不受影響,除非手動(dòng)調(diào)用才能停止服務(wù), 已啟動(dòng)的服務(wù)通常是執(zhí)行單一操作,而且不會(huì)將結(jié)果返回給調(diào)用方。
- 綁定狀態(tài)
??當(dāng)應(yīng)用組件通過(guò)調(diào)用 bindService() 綁定到服務(wù)時(shí),服務(wù)即處于“綁定”狀態(tài)。綁定服務(wù)提供了一個(gè)客戶端-服務(wù)器接口,允許組件與服務(wù)進(jìn)行交互、發(fā)送請(qǐng)求、獲取結(jié)果,甚至是利用進(jìn)程間通信 (IPC) 跨進(jìn)程執(zhí)行這些操作。 僅當(dāng)與另一個(gè)應(yīng)用組件綁定時(shí),綁定服務(wù)才會(huì)運(yùn)行。 多個(gè)組件可以同時(shí)綁定到該服務(wù),但全部取消綁定后,該服務(wù)即會(huì)被銷(xiāo)毀。
2.Service在清單文件中的聲明
??前面說(shuō)過(guò)Service分為啟動(dòng)狀態(tài)和綁定狀態(tài)兩種,但無(wú)論哪種具體的Service啟動(dòng)類(lèi)型,都是通過(guò)繼承Service基類(lèi)自定義而來(lái),也都需要在AndroidManifest.xml中聲明,那么在分析這兩種狀態(tài)之前,我們先來(lái)了解一下Service在AndroidManifest.xml中的聲明語(yǔ)法,其格式如下:
<service android:enabled=["true" | "false"]android:exported=["true" | "false"]android:icon="drawable resource"android:isolatedProcess=["true" | "false"]android:label="string resource"android:name="string"android:permission="string"android:process="string" >. . . </service>- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
Android:exported:代表是否能被其他應(yīng)用隱式調(diào)用,其默認(rèn)值是由service中有無(wú)intent-filter決定的,如果有intent-filter,默認(rèn)值為true,否則為false。為false的情況下,即使有intent-filter匹配,也無(wú)法打開(kāi),即無(wú)法被其他應(yīng)用隱式調(diào)用。
android:name:對(duì)應(yīng)Service類(lèi)名
android:permission:是權(quán)限聲明
android:process:是否需要在單獨(dú)的進(jìn)程中運(yùn)行,當(dāng)設(shè)置為android:process=”:remote”時(shí),代表Service在單獨(dú)的進(jìn)程中運(yùn)行。注意“:”很重要,它的意思是指要在當(dāng)前進(jìn)程名稱前面附加上當(dāng)前的包名,所以“remote”和”:remote”不是同一個(gè)意思,前者的進(jìn)程名稱為:remote,而后者的進(jìn)程名稱為:App-packageName:remote。
android:isolatedProcess :設(shè)置 true 意味著,服務(wù)會(huì)在一個(gè)特殊的進(jìn)程下運(yùn)行,這個(gè)進(jìn)程與系統(tǒng)其他進(jìn)程分開(kāi)且沒(méi)有自己的權(quán)限。與其通信的唯一途徑是通過(guò)服務(wù)的API(bind and start)。
android:enabled:是否可以被系統(tǒng)實(shí)例化,默認(rèn)為 true因?yàn)楦笜?biāo)簽 也有 enable 屬性,所以必須兩個(gè)都為默認(rèn)值 true 的情況下服務(wù)才會(huì)被激活,否則不會(huì)激活。?
??ok~,關(guān)于Service在清單文件的聲明我們先了解這些就行,接下來(lái)分別針對(duì)Service啟動(dòng)服務(wù)和綁定服務(wù)進(jìn)行詳細(xì)分析
3.Service啟動(dòng)服務(wù)
??首先要?jiǎng)?chuàng)建服務(wù),必須創(chuàng)建 Service 的子類(lèi)(或使用它的一個(gè)現(xiàn)有子類(lèi)如IntentService)。在實(shí)現(xiàn)中,我們需要重寫(xiě)一些回調(diào)方法,以處理服務(wù)生命周期的某些關(guān)鍵過(guò)程,下面我們通過(guò)簡(jiǎn)單案例來(lái)分析需要重寫(xiě)的回調(diào)方法有哪些?
package com.zejian.ipctest.service;import android.app.Service; import android.content.Intent; import android.os.IBinder; import android.support.annotation.Nullable;/*** Created by zejian* Time 2016/9/29.* Description:service simple demo*/ public class SimpleService extends Service {/*** 綁定服務(wù)時(shí)才會(huì)調(diào)用* 必須要實(shí)現(xiàn)的方法 * @param intent* @return*/@Nullable@Overridepublic IBinder onBind(Intent intent) {return null;}/*** 首次創(chuàng)建服務(wù)時(shí),系統(tǒng)將調(diào)用此方法來(lái)執(zhí)行一次性設(shè)置程序(在調(diào)用 onStartCommand() 或 onBind() 之前)。* 如果服務(wù)已在運(yùn)行,則不會(huì)調(diào)用此方法。該方法只被調(diào)用一次*/@Overridepublic void onCreate() {System.out.println("onCreate invoke");super.onCreate();}/*** 每次通過(guò)startService()方法啟動(dòng)Service時(shí)都會(huì)被回調(diào)。* @param intent* @param flags* @param startId* @return*/@Overridepublic int onStartCommand(Intent intent, int flags, int startId) {System.out.println("onStartCommand invoke");return super.onStartCommand(intent, flags, startId);}/*** 服務(wù)銷(xiāo)毀時(shí)的回調(diào)*/@Overridepublic void onDestroy() {System.out.println("onDestroy invoke");super.onDestroy();} }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
??從上面的代碼我們可以看出SimpleService繼承了Service類(lèi),并重寫(xiě)了onBind方法,該方法是必須重寫(xiě)的,但是由于此時(shí)是啟動(dòng)狀態(tài)的服務(wù),則該方法無(wú)須實(shí)現(xiàn),返回null即可,只有在綁定狀態(tài)的情況下才需要實(shí)現(xiàn)該方法并返回一個(gè)IBinder的實(shí)現(xiàn)類(lèi)(這個(gè)后面會(huì)詳細(xì)說(shuō)),接著重寫(xiě)了onCreate、onStartCommand、onDestroy三個(gè)主要的生命周期方法,關(guān)于這幾個(gè)方法說(shuō)明如下:
- onBind()
??當(dāng)另一個(gè)組件想通過(guò)調(diào)用 bindService() 與服務(wù)綁定(例如執(zhí)行 RPC)時(shí),系統(tǒng)將調(diào)用此方法。在此方法的實(shí)現(xiàn)中,必須返回 一個(gè)IBinder 接口的實(shí)現(xiàn)類(lèi),供客戶端用來(lái)與服務(wù)進(jìn)行通信。無(wú)論是啟動(dòng)狀態(tài)還是綁定狀態(tài),此方法必須重寫(xiě),但在啟動(dòng)狀態(tài)的情況下直接返回 null。
- onCreate()
??首次創(chuàng)建服務(wù)時(shí),系統(tǒng)將調(diào)用此方法來(lái)執(zhí)行一次性設(shè)置程序(在調(diào)用 onStartCommand() 或onBind() 之前)。如果服務(wù)已在運(yùn)行,則不會(huì)調(diào)用此方法,該方法只調(diào)用一次
- onStartCommand()
??當(dāng)另一個(gè)組件(如 Activity)通過(guò)調(diào)用 startService() 請(qǐng)求啟動(dòng)服務(wù)時(shí),系統(tǒng)將調(diào)用此方法。一旦執(zhí)行此方法,服務(wù)即會(huì)啟動(dòng)并可在后臺(tái)無(wú)限期運(yùn)行。 如果自己實(shí)現(xiàn)此方法,則需要在服務(wù)工作完成后,通過(guò)調(diào)用 stopSelf() 或 stopService() 來(lái)停止服務(wù)。(在綁定狀態(tài)下,無(wú)需實(shí)現(xiàn)此方法。)
- onDestroy()
??當(dāng)服務(wù)不再使用且將被銷(xiāo)毀時(shí),系統(tǒng)將調(diào)用此方法。服務(wù)應(yīng)該實(shí)現(xiàn)此方法來(lái)清理所有資源,如線程、注冊(cè)的偵聽(tīng)器、接收器等,這是服務(wù)接收的最后一個(gè)調(diào)用。
??我們通過(guò)Demo測(cè)試一下Service啟動(dòng)狀態(tài)方法的調(diào)用順序,MainActivity代碼如下:
package com.zejian.ipctest;import android.content.Intent; import android.os.Bundle; import android.support.v7.app.AppCompatActivity; import android.view.View; import android.widget.Button;import com.zejian.ipctest.service.SimpleService;public class MainActivity extends AppCompatActivity implements View.OnClickListener {private Button startBtn;private Button stopBtn;@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);startBtn= (Button) findViewById(R.id.startService);stopBtn= (Button) findViewById(R.id.stopService);startBtn.setOnClickListener(this);assert stopBtn != null;stopBtn.setOnClickListener(this);}@Overridepublic void onClick(View v) {Intent it=new Intent(this, SimpleService.class);switch (v.getId()){case R.id.startService:startService(it);break;case R.id.stopService:stopService(it);break;}} }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
記得在清單配置文件中聲明Service(聲明方式跟Activity相似):
<manifest ... >...<application ... ><service android:name=".service.SimpleService" />...</application> </manifest>- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
??從代碼看出,啟動(dòng)服務(wù)使用startService(Intent intent)方法,僅需要傳遞一個(gè)Intent對(duì)象即可,在Intent對(duì)象中指定需要啟動(dòng)的服務(wù)。而使用startService()方法啟動(dòng)的服務(wù),在服務(wù)的外部,必須使用stopService()方法停止,在服務(wù)的內(nèi)部可以調(diào)用stopSelf()方法停止當(dāng)前服務(wù)。如果使用startService()或者stopSelf()方法請(qǐng)求停止服務(wù),系統(tǒng)會(huì)就會(huì)盡快銷(xiāo)毀這個(gè)服務(wù)。值得注意的是對(duì)于啟動(dòng)服務(wù),一旦啟動(dòng)將與訪問(wèn)它的組件無(wú)任何關(guān)聯(lián),即使訪問(wèn)它的組件被銷(xiāo)毀了,這個(gè)服務(wù)也一直運(yùn)行下去,直到手動(dòng)調(diào)用停止服務(wù)才被銷(xiāo)毀,至于onBind方法,只有在綁定服務(wù)時(shí)才會(huì)起作用,在啟動(dòng)狀態(tài)下,無(wú)需關(guān)注此方法,ok~,我們運(yùn)行程序并多次調(diào)用startService方法,最后調(diào)用stopService方法。Log截圖如下:?
?
??從Log可以看出,第一次調(diào)用startService方法時(shí),onCreate方法、onStartCommand方法將依次被調(diào)用,而多次調(diào)用startService時(shí),只有onStartCommand方法被調(diào)用,最后我們調(diào)用stopService方法停止服務(wù)時(shí)onDestory方法被回調(diào),這就是啟動(dòng)狀態(tài)下Service的執(zhí)行周期。接著我們重新回過(guò)頭來(lái)進(jìn)一步分析onStartCommand(Intent intent, int flags, int startId),這個(gè)方法有3個(gè)傳入?yún)?shù),它們的含義如下:
onStartCommand(Intent intent, int flags, int startId)
intent :啟動(dòng)時(shí),啟動(dòng)組件傳遞過(guò)來(lái)的Intent,如Activity可利用Intent封裝所需要的參數(shù)并傳遞給Service
flags:表示啟動(dòng)請(qǐng)求時(shí)是否有額外數(shù)據(jù),可選值有?0,START_FLAG_REDELIVERY,START_FLAG_RETRY,0代表沒(méi)有,它們具體含義如下:
START_FLAG_REDELIVERY?
這個(gè)值代表了onStartCommand方法的返回值為?
START_REDELIVER_INTENT,而且在上一次服務(wù)被殺死前會(huì)去調(diào)用stopSelf方法停止服務(wù)。其中START_REDELIVER_INTENT意味著當(dāng)Service因內(nèi)存不足而被系統(tǒng)kill后,則會(huì)重建服務(wù),并通過(guò)傳遞給服務(wù)的最后一個(gè) Intent 調(diào)用 onStartCommand(),此時(shí)Intent時(shí)有值的。START_FLAG_RETRY?
該flag代表當(dāng)onStartCommand調(diào)用后一直沒(méi)有返回值時(shí),會(huì)嘗試重新去調(diào)用onStartCommand()。
startId : 指明當(dāng)前服務(wù)的唯一ID,與stopSelfResult (int startId)配合使用,stopSelfResult 可以更安全地根據(jù)ID停止服務(wù)。
??實(shí)際上onStartCommand的返回值int類(lèi)型才是最最值得注意的,它有三種可選值,?START_STICKY,START_NOT_STICKY,START_REDELIVER_INTENT,它們具體含義如下:
START_STICKY?
??當(dāng)Service因內(nèi)存不足而被系統(tǒng)kill后,一段時(shí)間后內(nèi)存再次空閑時(shí),系統(tǒng)將會(huì)嘗試重新創(chuàng)建此Service,一旦創(chuàng)建成功后將回調(diào)onStartCommand方法,但其中的Intent將是null,除非有掛起的Intent,如pendingintent,這個(gè)狀態(tài)下比較適用于不執(zhí)行命令、但無(wú)限期運(yùn)行并等待作業(yè)的媒體播放器或類(lèi)似服務(wù)。START_NOT_STICKY?
??當(dāng)Service因內(nèi)存不足而被系統(tǒng)kill后,即使系統(tǒng)內(nèi)存再次空閑時(shí),系統(tǒng)也不會(huì)嘗試重新創(chuàng)建此Service。除非程序中再次調(diào)用startService啟動(dòng)此Service,這是最安全的選項(xiàng),可以避免在不必要時(shí)以及應(yīng)用能夠輕松重啟所有未完成的作業(yè)時(shí)運(yùn)行服務(wù)。START_REDELIVER_INTENT?
??當(dāng)Service因內(nèi)存不足而被系統(tǒng)kill后,則會(huì)重建服務(wù),并通過(guò)傳遞給服務(wù)的最后一個(gè) Intent 調(diào)用 onStartCommand(),任何掛起 Intent均依次傳遞。與START_STICKY不同的是,其中的傳遞的Intent將是非空,是最后一次調(diào)用startService中的intent。這個(gè)值適用于主動(dòng)執(zhí)行應(yīng)該立即恢復(fù)的作業(yè)(例如下載文件)的服務(wù)。
??由于每次啟動(dòng)服務(wù)(調(diào)用startService)時(shí),onStartCommand方法都會(huì)被調(diào)用,因此我們可以通過(guò)該方法使用Intent給Service傳遞所需要的參數(shù),然后在onStartCommand方法中處理的事件,最后根據(jù)需求選擇不同的Flag返回值,以達(dá)到對(duì)程序更友好的控制。好~,以上便是Service在啟動(dòng)狀態(tài)下的分析,接著我們?cè)趤?lái)看看綁定狀態(tài)的Service又是如何處理的?
4.Service綁定服務(wù)
??綁定服務(wù)是Service的另一種變形,當(dāng)Service處于綁定狀態(tài)時(shí),其代表著客戶端-服務(wù)器接口中的服務(wù)器。當(dāng)其他組件(如 Activity)綁定到服務(wù)時(shí)(有時(shí)我們可能需要從Activity組建中去調(diào)用Service中的方法,此時(shí)Activity以綁定的方式掛靠到Service后,我們就可以輕松地方法到Service中的指定方法),組件(如Activity)可以向Service(也就是服務(wù)端)發(fā)送請(qǐng)求,或者調(diào)用Service(服務(wù)端)的方法,此時(shí)被綁定的Service(服務(wù)端)會(huì)接收信息并響應(yīng),甚至可以通過(guò)綁定服務(wù)進(jìn)行執(zhí)行進(jìn)程間通信 (即IPC,這個(gè)后面再單獨(dú)分析)。與啟動(dòng)服務(wù)不同的是綁定服務(wù)的生命周期通常只在為其他應(yīng)用組件(如Activity)服務(wù)時(shí)處于活動(dòng)狀態(tài),不會(huì)無(wú)限期在后臺(tái)運(yùn)行,也就是說(shuō)宿主(如Activity)解除綁定后,綁定服務(wù)就會(huì)被銷(xiāo)毀。那么在提供綁定的服務(wù)時(shí),該如何實(shí)現(xiàn)呢?實(shí)際上我們必須提供一個(gè) IBinder接口的實(shí)現(xiàn)類(lèi),該類(lèi)用以提供客戶端用來(lái)與服務(wù)進(jìn)行交互的編程接口,該接口可以通過(guò)三種方法定義接口:
擴(kuò)展 Binder 類(lèi)?
??如果服務(wù)是提供給自有應(yīng)用專(zhuān)用的,并且Service(服務(wù)端)與客戶端相同的進(jìn)程中運(yùn)行(常見(jiàn)情況),則應(yīng)通過(guò)擴(kuò)展 Binder 類(lèi)并從 onBind() 返回它的一個(gè)實(shí)例來(lái)創(chuàng)建接口。客戶端收到 Binder 后,可利用它直接訪問(wèn) Binder 實(shí)現(xiàn)中以及Service 中可用的公共方法。如果我們的服務(wù)只是自有應(yīng)用的后臺(tái)工作線程,則優(yōu)先采用這種方法。 不采用該方式創(chuàng)建接口的唯一原因是,服務(wù)被其他應(yīng)用或不同的進(jìn)程調(diào)用。使用 Messenger?
??Messenger可以翻譯為信使,通過(guò)它可以在不同的進(jìn)程中共傳遞Message對(duì)象(Handler中的Messager,因此 Handler 是 Messenger 的基礎(chǔ)),在Message中可以存放我們需要傳遞的數(shù)據(jù),然后在進(jìn)程間傳遞。如果需要讓接口跨不同的進(jìn)程工作,則可使用 Messenger 為服務(wù)創(chuàng)建接口,客戶端就可利用 Message 對(duì)象向服務(wù)發(fā)送命令。同時(shí)客戶端也可定義自有 Messenger,以便服務(wù)回傳消息。這是執(zhí)行進(jìn)程間通信 (IPC) 的最簡(jiǎn)單方法,因?yàn)?Messenger 會(huì)在單一線程中創(chuàng)建包含所有請(qǐng)求的隊(duì)列,也就是說(shuō)Messenger是以串行的方式處理客戶端發(fā)來(lái)的消息,這樣我們就不必對(duì)服務(wù)進(jìn)行線程安全設(shè)計(jì)了。- 使用 AIDL?
?? 由于Messenger是以串行的方式處理客戶端發(fā)來(lái)的消息,如果當(dāng)前有大量消息同時(shí)發(fā)送到Service(服務(wù)端),Service仍然只能一個(gè)個(gè)處理,這也就是Messenger跨進(jìn)程通信的缺點(diǎn)了,因此如果有大量并發(fā)請(qǐng)求,Messenger就會(huì)顯得力不從心了,這時(shí)AIDL(Android 接口定義語(yǔ)言)就派上用場(chǎng)了, 但實(shí)際上Messenger 的跨進(jìn)程方式其底層實(shí)現(xiàn) 就是AIDL,只不過(guò)android系統(tǒng)幫我們封裝成透明的Messenger罷了 。因此,如果我們想讓服務(wù)同時(shí)處理多個(gè)請(qǐng)求,則應(yīng)該使用 AIDL。 在此情況下,服務(wù)必須具備多線程處理能力,并采用線程安全式設(shè)計(jì)。使用AIDL必須創(chuàng)建一個(gè)定義編程接口的 .aidl 文件。Android SDK 工具利用該文件生成一個(gè)實(shí)現(xiàn)接口并處理 IPC 的抽象類(lèi),隨后可在服務(wù)內(nèi)對(duì)其進(jìn)行擴(kuò)展。
??以上3種實(shí)現(xiàn)方式,我們可以根據(jù)需求自由的選擇,但需要注意的是大多數(shù)應(yīng)用“都不會(huì)”使用 AIDL 來(lái)創(chuàng)建綁定服務(wù),因?yàn)樗赡芤缶邆涠嗑€程處理能力,并可能導(dǎo)致實(shí)現(xiàn)的復(fù)雜性增加。因此,AIDL 并不適合大多數(shù)應(yīng)用,本篇中也不打算闡述如何使用AIDL(后面會(huì)另開(kāi)一篇分析AIDL),接下來(lái)我們分別針對(duì)擴(kuò)展 Binder 類(lèi)和Messenger的使用進(jìn)行分析。
4.1 擴(kuò)展 Binder 類(lèi)
??前面描述過(guò),如果我們的服務(wù)僅供本地應(yīng)用使用,不需要跨進(jìn)程工作,則可以實(shí)現(xiàn)自有 Binder 類(lèi),讓客戶端通過(guò)該類(lèi)直接訪問(wèn)服務(wù)中的公共方法。其使用開(kāi)發(fā)步驟如下
- 1.創(chuàng)建BindService服務(wù)端,繼承自Service并在類(lèi)中,創(chuàng)建一個(gè)實(shí)現(xiàn)IBinder 接口的實(shí)例對(duì)象并提供公共方法給客戶端調(diào)用
- 2.從 onBind() 回調(diào)方法返回此 Binder 實(shí)例。
- 3.在客戶端中,從 onServiceConnected() 回調(diào)方法接收 Binder,并使用提供的方法調(diào)用綁定服務(wù)。
??注意:此方式只有在客戶端和服務(wù)位于同一應(yīng)用和進(jìn)程內(nèi)才有效,如對(duì)于需要將 Activity 綁定到在后臺(tái)播放音樂(lè)的自有服務(wù)的音樂(lè)應(yīng)用,此方式非常有效。另一點(diǎn)之所以要求服務(wù)和客戶端必須在同一應(yīng)用內(nèi),是為了便于客戶端轉(zhuǎn)換返回的對(duì)象和正確調(diào)用其 API。服務(wù)和客戶端還必須在同一進(jìn)程內(nèi),因?yàn)榇朔绞讲粓?zhí)行任何跨進(jìn)程編組。?
??以下是一個(gè)擴(kuò)展 Binder 類(lèi)的實(shí)例,先看看Service端的實(shí)現(xiàn)BindService.java
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
??BindService類(lèi)繼承自Service,在該類(lèi)中創(chuàng)建了一個(gè)LocalBinder繼承自Binder類(lèi),LocalBinder中聲明了一個(gè)getService方法,客戶端可訪問(wèn)該方法獲取LocalService對(duì)象的實(shí)例,只要客戶端獲取到LocalService對(duì)象的實(shí)例就可調(diào)用LocalService服務(wù)端的公共方法,如getCount方法,值得注意的是,我們?cè)趏nBind方法中返回了binder對(duì)象,該對(duì)象便是LocalBinder的具體實(shí)例,而binder對(duì)象最終會(huì)返回給客戶端,客戶端通過(guò)返回的binder對(duì)象便可以與服務(wù)端實(shí)現(xiàn)交互。接著看看客戶端BindActivity的實(shí)現(xiàn):
package com.zejian.ipctest.service;import android.app.Activity; import android.app.Service; import android.content.ComponentName; import android.content.Intent; import android.content.ServiceConnection; import android.os.Bundle; import android.os.IBinder; import android.util.Log; import android.view.View; import android.widget.Button;import com.zejian.ipctest.R;/*** Created by zejian* Time 2016/10/2.* Description:綁定服務(wù)實(shí)例--客戶端*/ public class BindActivity extends Activity {protected static final String TAG = "wzj";Button btnBind;Button btnUnBind;Button btnGetDatas;/*** ServiceConnection代表與服務(wù)的連接,它只有兩個(gè)方法,* onServiceConnected和onServiceDisconnected,* 前者是在操作者在連接一個(gè)服務(wù)成功時(shí)被調(diào)用,而后者是在服務(wù)崩潰或被殺死導(dǎo)致的連接中斷時(shí)被調(diào)用*/private ServiceConnection conn;private LocalService mService;@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_bind);btnBind = (Button) findViewById(R.id.BindService);btnUnBind = (Button) findViewById(R.id.unBindService);btnGetDatas = (Button) findViewById(R.id.getServiceDatas);//創(chuàng)建綁定對(duì)象final Intent intent = new Intent(this, LocalService.class);// 開(kāi)啟綁定btnBind.setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {Log.d(TAG, "綁定調(diào)用:bindService");//調(diào)用綁定方法bindService(intent, conn, Service.BIND_AUTO_CREATE);}});// 解除綁定btnUnBind.setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {Log.d(TAG, "解除綁定調(diào)用:unbindService");// 解除綁定if(mService!=null) {mService = null;unbindService(conn);}}});// 獲取數(shù)據(jù)btnGetDatas.setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {if (mService != null) {// 通過(guò)綁定服務(wù)傳遞的Binder對(duì)象,獲取Service暴露出來(lái)的數(shù)據(jù)Log.d(TAG, "從服務(wù)端獲取數(shù)據(jù):" + mService.getCount());} else {Log.d(TAG, "還沒(méi)綁定呢,先綁定,無(wú)法從服務(wù)端獲取數(shù)據(jù)");}}});conn = new ServiceConnection() {/*** 與服務(wù)器端交互的接口方法 綁定服務(wù)的時(shí)候被回調(diào),在這個(gè)方法獲取綁定Service傳遞過(guò)來(lái)的IBinder對(duì)象,* 通過(guò)這個(gè)IBinder對(duì)象,實(shí)現(xiàn)宿主和Service的交互。*/@Overridepublic void onServiceConnected(ComponentName name, IBinder service) {Log.d(TAG, "綁定成功調(diào)用:onServiceConnected");// 獲取BinderLocalService.LocalBinder binder = (LocalService.LocalBinder) service;mService = binder.getService();}/*** 當(dāng)取消綁定的時(shí)候被回調(diào)。但正常情況下是不被調(diào)用的,它的調(diào)用時(shí)機(jī)是當(dāng)Service服務(wù)被意外銷(xiāo)毀時(shí),* 例如內(nèi)存的資源不足時(shí)這個(gè)方法才被自動(dòng)調(diào)用。*/@Overridepublic void onServiceDisconnected(ComponentName name) {mService=null;}};} }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
??在客戶端中我們創(chuàng)建了一個(gè)ServiceConnection對(duì)象,該代表與服務(wù)的連接,它只有兩個(gè)方法, onServiceConnected和onServiceDisconnected,其含義如下:
onServiceConnected(ComponentName name, IBinder service)?
系統(tǒng)會(huì)調(diào)用該方法以傳遞服務(wù)的 onBind() 方法返回的 IBinder。其中service便是服務(wù)端返回的IBinder實(shí)現(xiàn)類(lèi)對(duì)象,通過(guò)該對(duì)象我們便可以調(diào)用獲取LocalService實(shí)例對(duì)象,進(jìn)而調(diào)用服務(wù)端的公共方法。而ComponentName是一個(gè)封裝了組件(Activity, Service, BroadcastReceiver, or ContentProvider)信息的類(lèi),如包名,組件描述等信息,較少使用該參數(shù)。onServiceDisconnected(ComponentName name)?
Android 系統(tǒng)會(huì)在與服務(wù)的連接意外中斷時(shí)(例如當(dāng)服務(wù)崩潰或被終止時(shí))調(diào)用該方法。注意:當(dāng)客戶端取消綁定時(shí),系統(tǒng)“絕對(duì)不會(huì)”調(diào)用該方法。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
??在onServiceConnected()被回調(diào)前,我們還需先把當(dāng)前Activity綁定到服務(wù)LocalService上,綁定服務(wù)是通過(guò)通過(guò)bindService()方法,解綁服務(wù)則使用unbindService()方法,這兩個(gè)方法解析如下:
bindService(Intent service, ServiceConnection conn, int flags)?
該方法執(zhí)行綁定服務(wù)操作,其中Intent是我們要綁定的服務(wù)(也就是LocalService)的意圖,而ServiceConnection代表與服務(wù)的連接,它只有兩個(gè)方法,前面已分析過(guò),flags則是指定綁定時(shí)是否自動(dòng)創(chuàng)建Service。0代表不自動(dòng)創(chuàng)建、BIND_AUTO_CREATE則代表自動(dòng)創(chuàng)建。unbindService(ServiceConnection conn)?
該方法執(zhí)行解除綁定的操作,其中ServiceConnection代表與服務(wù)的連接,它只有兩個(gè)方法,前面已分析過(guò)。
Activity通過(guò)bindService()綁定到LocalService后,ServiceConnection#onServiceConnected()便會(huì)被回調(diào)并可以獲取到LocalService實(shí)例對(duì)象mService,之后我們就可以調(diào)用LocalService服務(wù)端的公共方法了,最后還需要在清單文件中聲明該Service。而客戶端布局文件實(shí)現(xiàn)如下:
<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"android:orientation="vertical" android:layout_width="match_parent"android:layout_height="match_parent"><Button android:id="@+id/BindService"android:layout_width="wrap_content"android:layout_height="wrap_content"android:text="綁定服務(wù)器"/><Button android:id="@+id/unBindService"android:layout_width="wrap_content"android:layout_height="wrap_content"android:text="解除綁定"/><Button android:id="@+id/getServiceDatas"android:layout_width="wrap_content"android:layout_height="wrap_content"android:text="獲取服務(wù)方數(shù)據(jù)"/> </LinearLayout>- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
??我們運(yùn)行程序,點(diǎn)擊綁定服務(wù)并多次點(diǎn)擊綁定服務(wù)接著多次調(diào)用LocalService中的getCount()獲取數(shù)據(jù),最后調(diào)用解除綁定的方法移除服務(wù),其結(jié)果如下:?
?
??通過(guò)Log可知,當(dāng)我們第一次點(diǎn)擊綁定服務(wù)時(shí),LocalService服務(wù)端的onCreate()、onBind方法會(huì)依次被調(diào)用,此時(shí)客戶端的ServiceConnection#onServiceConnected()被調(diào)用并返回LocalBinder對(duì)象,接著調(diào)用LocalBinder#getService方法返回LocalService實(shí)例對(duì)象,此時(shí)客戶端便持有了LocalService的實(shí)例對(duì)象,也就可以任意調(diào)用LocalService類(lèi)中的聲明公共方法了。更值得注意的是,我們多次調(diào)用bindService方法綁定LocalService服務(wù)端,而LocalService得onBind方法只調(diào)用了一次,那就是在第一次調(diào)用bindService時(shí)才會(huì)回調(diào)onBind方法。接著我們點(diǎn)擊獲取服務(wù)端的數(shù)據(jù),從Log中看出我們點(diǎn)擊了3次通過(guò)getCount()獲取了服務(wù)端的3個(gè)不同數(shù)據(jù),最后點(diǎn)擊解除綁定,此時(shí)LocalService的onUnBind、onDestroy方法依次被回調(diào),并且多次綁定只需一次解綁即可。此情景也就說(shuō)明了綁定狀態(tài)下的Service生命周期方法的調(diào)用依次為onCreate()、onBind、onUnBind、onDestroy。ok~,以上便是同一應(yīng)用同一進(jìn)程中客戶端與服務(wù)端的綁定回調(diào)方式。
4.2 使用Messenger
??前面了解了如何使用IBinder應(yīng)用內(nèi)同一進(jìn)程的通信后,我們接著來(lái)了解服務(wù)與遠(yuǎn)程進(jìn)程(即不同進(jìn)程間)通信,而不同進(jìn)程間的通信,最簡(jiǎn)單的方式就是使用 Messenger 服務(wù)提供通信接口,利用此方式,我們無(wú)需使用 AIDL 便可執(zhí)行進(jìn)程間通信 (IPC)。以下是 Messenger 使用的主要步驟:
1.服務(wù)實(shí)現(xiàn)一個(gè) Handler,由其接收來(lái)自客戶端的每個(gè)調(diào)用的回調(diào)
2.Handler 用于創(chuàng)建 Messenger 對(duì)象(對(duì) Handler 的引用)
3.Messenger 創(chuàng)建一個(gè) IBinder,服務(wù)通過(guò) onBind() 使其返回客戶端
4.客戶端使用 IBinder 將 Messenger(引用服務(wù)的 Handler)實(shí)例化,然后使用Messenger將 Message 對(duì)象發(fā)送給服務(wù)
- 5.服務(wù)在其 Handler 中(在 handleMessage() 方法中)接收每個(gè) Message
以下是一個(gè)使用 Messenger 接口的簡(jiǎn)單服務(wù)示例,服務(wù)端進(jìn)程實(shí)現(xiàn)如下:
package com.zejian.ipctest.messenger;import android.app.Service; import android.content.Intent; import android.os.Handler; import android.os.IBinder; import android.os.Message; import android.os.Messenger; import android.util.Log;/*** Created by zejian* Time 2016/10/3.* Description:Messenger服務(wù)端簡(jiǎn)單實(shí)例,服務(wù)端進(jìn)程*/ public class MessengerService extends Service {/** Command to the service to display a message */static final int MSG_SAY_HELLO = 1;private static final String TAG ="wzj" ;/*** 用于接收從客戶端傳遞過(guò)來(lái)的數(shù)據(jù)*/class IncomingHandler extends Handler {@Overridepublic void handleMessage(Message msg) {switch (msg.what) {case MSG_SAY_HELLO:Log.i(TAG, "thanks,Service had receiver message from client!");break;default:super.handleMessage(msg);}}}/*** 創(chuàng)建Messenger并傳入Handler實(shí)例對(duì)象*/final Messenger mMessenger = new Messenger(new IncomingHandler());/*** 當(dāng)綁定Service時(shí),該方法被調(diào)用,將通過(guò)mMessenger返回一個(gè)實(shí)現(xiàn)* IBinder接口的實(shí)例對(duì)象*/@Overridepublic IBinder onBind(Intent intent) {Log.i(TAG, "Service is invoke onBind");return mMessenger.getBinder();} }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
??首先我們同樣需要?jiǎng)?chuàng)建一個(gè)服務(wù)類(lèi)MessengerService繼承自Service,同時(shí)創(chuàng)建一個(gè)繼承自Handler的IncomingHandler對(duì)象來(lái)接收客戶端進(jìn)程發(fā)送過(guò)來(lái)的消息并通過(guò)其handleMessage(Message msg)進(jìn)行消息處理。接著通過(guò)IncomingHandler對(duì)象創(chuàng)建一個(gè)Messenger對(duì)象,該對(duì)象是與客戶端交互的特殊對(duì)象,然后在Service的onBind中返回這個(gè)Messenger對(duì)象的底層Binder即可。下面看看客戶端進(jìn)程的實(shí)現(xiàn):
package com.zejian.ipctest.messenger;import android.app.Activity; import android.content.ComponentName; import android.content.Context; import android.content.Intent; import android.content.ServiceConnection; import android.os.Bundle; import android.os.IBinder; import android.os.Message; import android.os.Messenger; import android.os.RemoteException; import android.util.Log; import android.view.View; import android.widget.Button;import com.zejian.ipctest.R;/*** Created by zejian* Time 2016/10/3.* Description: 與服務(wù)器交互的客戶端*/ public class ActivityMessenger extends Activity {/*** 與服務(wù)端交互的Messenger*/Messenger mService = null;/** Flag indicating whether we have called bind on the service. */boolean mBound;/*** 實(shí)現(xiàn)與服務(wù)端鏈接的對(duì)象*/private ServiceConnection mConnection = new ServiceConnection() {public void onServiceConnected(ComponentName className, IBinder service) {/*** 通過(guò)服務(wù)端傳遞的IBinder對(duì)象,創(chuàng)建相應(yīng)的Messenger* 通過(guò)該Messenger對(duì)象與服務(wù)端進(jìn)行交互*/mService = new Messenger(service);mBound = true;}public void onServiceDisconnected(ComponentName className) {// This is called when the connection with the service has been// unexpectedly disconnected -- that is, its process crashed.mService = null;mBound = false;}};public void sayHello(View v) {if (!mBound) return;// 創(chuàng)建與服務(wù)交互的消息實(shí)體MessageMessage msg = Message.obtain(null, MessengerService.MSG_SAY_HELLO, 0, 0);try {//發(fā)送消息mService.send(msg);} catch (RemoteException e) {e.printStackTrace();}}@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_messenager);Button bindService= (Button) findViewById(R.id.bindService);Button unbindService= (Button) findViewById(R.id.unbindService);Button sendMsg= (Button) findViewById(R.id.sendMsgToService);bindService.setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {Log.d("zj","onClick-->bindService");//當(dāng)前Activity綁定服務(wù)端bindService(new Intent(ActivityMessenger.this, MessengerService.class), mConnection,Context.BIND_AUTO_CREATE);}});//發(fā)送消息給服務(wù)端sendMsg.setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {sayHello(v);}});unbindService.setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {// Unbind from the serviceif (mBound) {Log.d("zj","onClick-->unbindService");unbindService(mConnection);mBound = false;}}});}}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
??在客戶端進(jìn)程中,我們需要?jiǎng)?chuàng)建一個(gè)ServiceConnection對(duì)象,該對(duì)象代表與服務(wù)端的鏈接,當(dāng)調(diào)用bindService方法將當(dāng)前Activity綁定到MessengerService時(shí),onServiceConnected方法被調(diào)用,利用服務(wù)端傳遞給來(lái)的底層Binder對(duì)象構(gòu)造出與服務(wù)端交互的Messenger對(duì)象,接著創(chuàng)建與服務(wù)交互的消息實(shí)體Message,將要發(fā)生的信息封裝在Message中并通過(guò)Messenger實(shí)例對(duì)象發(fā)送給服務(wù)端。關(guān)于ServiceConnection、bindService方法、unbindService方法,前面已分析過(guò),這里就不重復(fù)了,最后我們需要在清單文件聲明Service和Activity,由于要測(cè)試不同進(jìn)程的交互,則需要將Service放在單獨(dú)的進(jìn)程中,因此Service聲明如下:
<service android:name=".messenger.MessengerService"android:process=":remote"/>- 1
- 2
- 3
- 1
- 2
- 3
其中android:process=":remote"代表該Service在單獨(dú)的進(jìn)程中創(chuàng)建,最后我們運(yùn)行程序,結(jié)果如下:?
?
??接著多次點(diǎn)擊綁定服務(wù),然后發(fā)送信息給服務(wù)端,最后解除綁定,Log打印如下:?
?
??通過(guò)上述例子可知Service服務(wù)端確實(shí)收到了客戶端發(fā)送的信息,而且在Messenger中進(jìn)行數(shù)據(jù)傳遞必須將數(shù)據(jù)封裝到Message中,因?yàn)镸essage和Messenger都實(shí)現(xiàn)了Parcelable接口,可以輕松跨進(jìn)程傳遞數(shù)據(jù)(關(guān)于Parcelable接口可以看博主的另一篇文章:序列化與反序列化之Parcelable和Serializable淺析),而Message可以傳遞的信息載體有,what,arg1,arg2,Bundle以及replyTo,至于object字段,對(duì)于同一進(jìn)程中的數(shù)據(jù)傳遞確實(shí)很實(shí)用,但對(duì)于進(jìn)程間的通信,則顯得相當(dāng)尷尬,在android2.2前,object不支持跨進(jìn)程傳輸,但即便是android2.2之后也只能傳遞android系統(tǒng)提供的實(shí)現(xiàn)了Parcelable接口的對(duì)象,也就是說(shuō)我們通過(guò)自定義實(shí)現(xiàn)Parcelable接口的對(duì)象無(wú)法通過(guò)object字段來(lái)傳遞,因此object字段的實(shí)用性在跨進(jìn)程中也變得相當(dāng)?shù)土恕2贿^(guò)所幸我們還有Bundle對(duì)象,Bundle可以支持大量的數(shù)據(jù)類(lèi)型。接著從Log我們也看出無(wú)論是使用拓展Binder類(lèi)的實(shí)現(xiàn)方式還是使用Messenger的實(shí)現(xiàn)方式,它們的生命周期方法的調(diào)用順序基本是一樣的,即onCreate()、onBind、onUnBind、onDestroy,而且多次綁定中也只有第一次時(shí)才調(diào)用onBind()。好~,以上的例子演示了如何在服務(wù)端解釋客戶端發(fā)送的消息,但有時(shí)候我們可能還需要服務(wù)端能回應(yīng)客戶端,這時(shí)便需要提供雙向消息傳遞了,下面就來(lái)實(shí)現(xiàn)一個(gè)簡(jiǎn)單服務(wù)端與客戶端雙向消息傳遞的簡(jiǎn)單例子。?
??先來(lái)看看服務(wù)端的修改,在服務(wù)端,我們只需修改IncomingHandler,收到消息后,給客戶端回復(fù)一條信息。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
??接著修改客戶端,為了接收服務(wù)端的回復(fù),客戶端也需要一個(gè)接收消息的Messenger和Handler,其實(shí)現(xiàn)如下:
/*** 用于接收服務(wù)器返回的信息*/private Messenger mRecevierReplyMsg= new Messenger(new ReceiverReplyMsgHandler());private static class ReceiverReplyMsgHandler extends Handler{private static final String TAG = "zj";@Overridepublic void handleMessage(Message msg) {switch (msg.what) {//接收服務(wù)端回復(fù)case MessengerService.MSG_SAY_HELLO:Log.i(TAG, "receiver message from service:"+msg.getData().getString("reply"));break;default:super.handleMessage(msg);}}}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
??除了添加以上代碼,還需要在發(fā)送信息時(shí)把接收服務(wù)器端的回復(fù)的Messenger通過(guò)Message的replyTo參數(shù)傳遞給服務(wù)端,以便作為同學(xué)橋梁,代碼如下:
public void sayHello(View v) {if (!mBound) return;// 創(chuàng)建與服務(wù)交互的消息實(shí)體MessageMessage msg = Message.obtain(null, MessengerService.MSG_SAY_HELLO, 0, 0);//把接收服務(wù)器端的回復(fù)的Messenger通過(guò)Message的replyTo參數(shù)傳遞給服務(wù)端msg.replyTo=mRecevierReplyMsg;try {//發(fā)送消息mService.send(msg);} catch (RemoteException e) {e.printStackTrace();}}- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
??ok~,到此服務(wù)端與客戶端雙向消息傳遞的簡(jiǎn)單例子修改完成,我們運(yùn)行一下代碼,看看Log打印,如下:?
?
??由Log可知,服務(wù)端和客戶端確實(shí)各自收到了信息,到此我們就把采用Messenge進(jìn)行跨進(jìn)程通信的方式分析完了,最后為了輔助大家理解,這里提供一張通過(guò)Messenge方式進(jìn)行進(jìn)程間通信的原理圖:?
4.3 關(guān)于綁定服務(wù)的注意點(diǎn)
??1.多個(gè)客戶端可同時(shí)連接到一個(gè)服務(wù)。不過(guò),只有在第一個(gè)客戶端綁定時(shí),系統(tǒng)才會(huì)調(diào)用服務(wù)的 onBind() 方法來(lái)檢索 IBinder。系統(tǒng)隨后無(wú)需再次調(diào)用 onBind(),便可將同一 IBinder 傳遞至任何其他綁定的客戶端。當(dāng)最后一個(gè)客戶端取消與服務(wù)的綁定時(shí),系統(tǒng)會(huì)將服務(wù)銷(xiāo)毀(除非 startService() 也啟動(dòng)了該服務(wù))。
??2.通常情況下我們應(yīng)該在客戶端生命周期(如Activity的生命周期)的引入 (bring-up) 和退出 (tear-down) 時(shí)刻設(shè)置綁定和取消綁定操作,以便控制綁定狀態(tài)下的Service,一般有以下兩種情況:
如果只需要在 Activity 可見(jiàn)時(shí)與服務(wù)交互,則應(yīng)在 onStart() 期間綁定,在 onStop() 期間取消綁定。
如果希望 Activity 在后臺(tái)停止運(yùn)行狀態(tài)下仍可接收響應(yīng),則可在 onCreate() 期間綁定,在 onDestroy() 期間取消綁定。需要注意的是,這意味著 Activity 在其整個(gè)運(yùn)行過(guò)程中(甚至包括后臺(tái)運(yùn)行期間)都需要使用服務(wù),因此如果服務(wù)位于其他進(jìn)程內(nèi),那么當(dāng)提高該進(jìn)程的權(quán)重時(shí),系統(tǒng)很可能會(huì)終止該進(jìn)程。
??3.通常情況下(注意),切勿在 Activity 的 onResume() 和 onPause() 期間綁定和取消綁定,因?yàn)槊恳淮紊芷谵D(zhuǎn)換都會(huì)發(fā)生這些回調(diào),這樣反復(fù)綁定與解綁是不合理的。此外,如果應(yīng)用內(nèi)的多個(gè) Activity 綁定到同一服務(wù),并且其中兩個(gè) Activity 之間發(fā)生了轉(zhuǎn)換,則如果當(dāng)前 Activity 在下一次綁定(恢復(fù)期間)之前取消綁定(暫停期間),系統(tǒng)可能會(huì)銷(xiāo)毀服務(wù)并重建服務(wù),因此服務(wù)的綁定不應(yīng)該發(fā)生在 Activity 的 onResume() 和 onPause()中。
??4.我們應(yīng)該始終捕獲 DeadObjectException DeadObjectException 異常,該異常是在連接中斷時(shí)引發(fā)的,表示調(diào)用的對(duì)象已死亡,也就是Service對(duì)象已銷(xiāo)毀,這是遠(yuǎn)程方法引發(fā)的唯一異常,DeadObjectException繼承自RemoteException,因此我們也可以捕獲RemoteException異常。
??5.應(yīng)用組件(客戶端)可通過(guò)調(diào)用 bindService() 綁定到服務(wù),Android 系統(tǒng)隨后調(diào)用服務(wù)的 onBind() 方法,該方法返回用于與服務(wù)交互的 IBinder,而該綁定是異步執(zhí)行的。
5.關(guān)于啟動(dòng)服務(wù)與綁定服務(wù)間的轉(zhuǎn)換問(wèn)題
??通過(guò)前面對(duì)兩種服務(wù)狀態(tài)的分析,相信大家已對(duì)Service的兩種狀態(tài)有了比較清晰的了解,那么現(xiàn)在我們就來(lái)分析一下當(dāng)啟動(dòng)狀態(tài)和綁定狀態(tài)同時(shí)存在時(shí),又會(huì)是怎么的場(chǎng)景??
??雖然服務(wù)的狀態(tài)有啟動(dòng)和綁定兩種,但實(shí)際上一個(gè)服務(wù)可以同時(shí)是這兩種狀態(tài),也就是說(shuō),它既可以是啟動(dòng)服務(wù)(以無(wú)限期運(yùn)行),也可以是綁定服務(wù)。有點(diǎn)需要注意的是Android系統(tǒng)僅會(huì)為一個(gè)Service創(chuàng)建一個(gè)實(shí)例對(duì)象,所以不管是啟動(dòng)服務(wù)還是綁定服務(wù),操作的是同一個(gè)Service實(shí)例,而且由于綁定服務(wù)或者啟動(dòng)服務(wù)執(zhí)行順序問(wèn)題將會(huì)出現(xiàn)以下兩種情況:
先綁定服務(wù)后啟動(dòng)服務(wù)
??如果當(dāng)前Service實(shí)例先以綁定狀態(tài)運(yùn)行,然后再以啟動(dòng)狀態(tài)運(yùn)行,那么綁定服務(wù)將會(huì)轉(zhuǎn)為啟動(dòng)服務(wù)運(yùn)行,這時(shí)如果之前綁定的宿主(Activity)被銷(xiāo)毀了,也不會(huì)影響服務(wù)的運(yùn)行,服務(wù)還是會(huì)一直運(yùn)行下去,指定收到調(diào)用停止服務(wù)或者內(nèi)存不足時(shí)才會(huì)銷(xiāo)毀該服務(wù)。
先啟動(dòng)服務(wù)后綁定服務(wù)
??如果當(dāng)前Service實(shí)例先以啟動(dòng)狀態(tài)運(yùn)行,然后再以綁定狀態(tài)運(yùn)行,當(dāng)前啟動(dòng)服務(wù)并不會(huì)轉(zhuǎn)為綁定服務(wù),但是還是會(huì)與宿主綁定,只是即使宿主解除綁定后,服務(wù)依然按啟動(dòng)服務(wù)的生命周期在后臺(tái)運(yùn)行,直到有Context調(diào)用了stopService()或是服務(wù)本身調(diào)用了stopSelf()方法抑或內(nèi)存不足時(shí)才會(huì)銷(xiāo)毀服務(wù)。
??以上兩種情況顯示出啟動(dòng)服務(wù)的優(yōu)先級(jí)確實(shí)比綁定服務(wù)高一些。不過(guò)無(wú)論Service是處于啟動(dòng)狀態(tài)還是綁定狀態(tài),或處于啟動(dòng)并且綁定狀態(tài),我們都可以像使用Activity那樣通過(guò)調(diào)用 Intent 來(lái)使用服務(wù)(即使此服務(wù)來(lái)自另一應(yīng)用)。 當(dāng)然,我們也可以通過(guò)清單文件將服務(wù)聲明為私有服務(wù),阻止其他應(yīng)用訪問(wèn)。最后這里有點(diǎn)需要特殊說(shuō)明一下的,由于服務(wù)在其托管進(jìn)程的主線程中運(yùn)行(UI線程),它既不創(chuàng)建自己的線程,也不在單獨(dú)的進(jìn)程中運(yùn)行(除非另行指定)。 這意味著,如果服務(wù)將執(zhí)行任何耗時(shí)事件或阻止性操作(例如 MP3 播放或聯(lián)網(wǎng))時(shí),則應(yīng)在服務(wù)內(nèi)創(chuàng)建新線程來(lái)完成這項(xiàng)工作,簡(jiǎn)而言之,耗時(shí)操作應(yīng)該另起線程執(zhí)行。只有通過(guò)使用單獨(dú)的線程,才可以降低發(fā)生“應(yīng)用無(wú)響應(yīng)”(ANR) 錯(cuò)誤的風(fēng)險(xiǎn),這樣應(yīng)用的主線程才能專(zhuān)注于用戶與 Activity 之間的交互, 以達(dá)到更好的用戶體驗(yàn)。
6.前臺(tái)服務(wù)以及通知發(fā)送
??前臺(tái)服務(wù)被認(rèn)為是用戶主動(dòng)意識(shí)到的一種服務(wù),因此在內(nèi)存不足時(shí),系統(tǒng)也不會(huì)考慮將其終止。 前臺(tái)服務(wù)必須為狀態(tài)欄提供通知,狀態(tài)欄位于“正在進(jìn)行”標(biāo)題下方,這意味著除非服務(wù)停止或從前臺(tái)刪除,否則不能清除通知。例如將從服務(wù)播放音樂(lè)的音樂(lè)播放器設(shè)置為在前臺(tái)運(yùn)行,這是因?yàn)橛脩裘鞔_意識(shí)到其操作。 狀態(tài)欄中的通知可能表示正在播放的歌曲,并允許用戶啟動(dòng) Activity 來(lái)與音樂(lè)播放器進(jìn)行交互。如果需要設(shè)置服務(wù)運(yùn)行于前臺(tái), 我們?cè)撊绾尾拍軐?shí)現(xiàn)呢?Android官方給我們提供了兩個(gè)方法,分別是startForeground()和stopForeground(),這兩個(gè)方式解析如下:
startForeground(int id, Notification notification)?
該方法的作用是把當(dāng)前服務(wù)設(shè)置為前臺(tái)服務(wù),其中id參數(shù)代表唯一標(biāo)識(shí)通知的整型數(shù),需要注意的是提供給 startForeground() 的整型 ID 不得為 0,而notification是一個(gè)狀態(tài)欄的通知。stopForeground(boolean removeNotification)?
該方法是用來(lái)從前臺(tái)刪除服務(wù),此方法傳入一個(gè)布爾值,指示是否也刪除狀態(tài)欄通知,true為刪除。 注意該方法并不會(huì)停止服務(wù)。 但是,如果在服務(wù)正在前臺(tái)運(yùn)行時(shí)將其停止,則通知也會(huì)被刪除。
下面我們結(jié)合一個(gè)簡(jiǎn)單案例來(lái)使用以上兩個(gè)方法,ForegroundService代碼如下:
package com.zejian.ipctest.foregroundService;import android.app.Notification; import android.app.Service; import android.content.Intent; import android.graphics.BitmapFactory; import android.os.IBinder; import android.support.annotation.Nullable; import android.support.v4.app.NotificationCompat;import com.zejian.ipctest.R;/*** Created by zejian* Time 2016/10/4.* Description:啟動(dòng)前臺(tái)服務(wù)Demo*/ public class ForegroundService extends Service {/*** id不可設(shè)置為0,否則不能設(shè)置為前臺(tái)service*/private static final int NOTIFICATION_DOWNLOAD_PROGRESS_ID = 0x0001;private boolean isRemove=false;//是否需要移除/*** Notification*/public void createNotification(){//使用兼容版本NotificationCompat.Builder builder=new NotificationCompat.Builder(this);//設(shè)置狀態(tài)欄的通知圖標(biāo)builder.setSmallIcon(R.mipmap.ic_launcher);//設(shè)置通知欄橫條的圖標(biāo)builder.setLargeIcon(BitmapFactory.decodeResource(getResources(),R.drawable.screenflash_logo));//禁止用戶點(diǎn)擊刪除按鈕刪除builder.setAutoCancel(false);//禁止滑動(dòng)刪除builder.setOngoing(true);//右上角的時(shí)間顯示builder.setShowWhen(true);//設(shè)置通知欄的標(biāo)題內(nèi)容builder.setContentTitle("I am Foreground Service!!!");//創(chuàng)建通知Notification notification = builder.build();//設(shè)置為前臺(tái)服務(wù)startForeground(NOTIFICATION_DOWNLOAD_PROGRESS_ID,notification);}@Overridepublic int onStartCommand(Intent intent, int flags, int startId) {int i=intent.getExtras().getInt("cmd");if(i==0){if(!isRemove) {createNotification();}isRemove=true;}else {//移除前臺(tái)服務(wù)if (isRemove) {stopForeground(true);}isRemove=false;}return super.onStartCommand(intent, flags, startId);}@Overridepublic void onDestroy() {//移除前臺(tái)服務(wù)if (isRemove) {stopForeground(true);}isRemove=false;super.onDestroy();}@Nullable@Overridepublic IBinder onBind(Intent intent) {return null;} }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
??在ForegroundService類(lèi)中,創(chuàng)建了一個(gè)notification的通知,并通過(guò)啟動(dòng)Service時(shí)傳遞過(guò)來(lái)的參數(shù)判斷是啟動(dòng)前臺(tái)服務(wù)還是關(guān)閉前臺(tái)服務(wù),最后在onDestroy方法被調(diào)用時(shí),也應(yīng)該移除前臺(tái)服務(wù)。以下是ForegroundActivity的實(shí)現(xiàn):
package com.zejian.ipctest.foregroundService;import android.app.Activity; import android.content.Intent; import android.os.Bundle; import android.view.View; import android.widget.Button;import com.zejian.ipctest.R;/*** Created by zejian* Time 2016/10/4.* Description:*/ public class ForegroundActivity extends Activity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_foreground);Button btnStart= (Button) findViewById(R.id.startForeground);Button btnStop= (Button) findViewById(R.id.stopForeground);final Intent intent = new Intent(this,ForegroundService.class);btnStart.setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {intent.putExtra("cmd",0);//0,開(kāi)啟前臺(tái)服務(wù),1,關(guān)閉前臺(tái)服務(wù)startService(intent);}});btnStop.setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {intent.putExtra("cmd",1);//0,開(kāi)啟前臺(tái)服務(wù),1,關(guān)閉前臺(tái)服務(wù)startService(intent);}});} }- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
??代碼比較簡(jiǎn)單,我們直接運(yùn)行程序看看結(jié)果:
??ok~,以上便是有關(guān)于Service前臺(tái)服務(wù)的內(nèi)容,接下來(lái)再聊聊服務(wù)與線程的區(qū)別
7.服務(wù)Service與線程Thread的區(qū)別
兩者概念的迥異
Thread 是程序執(zhí)行的最小單元,它是分配CPU的基本單位,android系統(tǒng)中UI線程也是線程的一種,當(dāng)然Thread還可以用于執(zhí)行一些耗時(shí)異步的操作。
Service是Android的一種機(jī)制,服務(wù)是運(yùn)行在主線程上的,它是由系統(tǒng)進(jìn)程托管。它與其他組件之間的通信類(lèi)似于client和server,是一種輕量級(jí)的IPC通信,這種通信的載體是binder,它是在linux層交換信息的一種IPC,而所謂的Service后臺(tái)任務(wù)只不過(guò)是指沒(méi)有UI的組件罷了。
兩者的執(zhí)行任務(wù)迥異
在android系統(tǒng)中,線程一般指的是工作線程(即后臺(tái)線程),而主線程是一種特殊的工作線程,它負(fù)責(zé)將事件分派給相應(yīng)的用戶界面小工具,如繪圖事件及事件響應(yīng),因此為了保證應(yīng)用 UI 的響應(yīng)能力主線程上不可執(zhí)行耗時(shí)操作。如果執(zhí)行的操作不能很快完成,則應(yīng)確保它們?cè)趩为?dú)的工作線程執(zhí)行。
Service 則是android系統(tǒng)中的組件,一般情況下它運(yùn)行于主線程中,因此在Service中是不可以執(zhí)行耗時(shí)操作的,否則系統(tǒng)會(huì)報(bào)ANR異常,之所以稱Service為后臺(tái)服務(wù),大部分原因是它本身沒(méi)有UI,用戶無(wú)法感知(當(dāng)然也可以利用某些手段讓用戶知道),但如果需要讓Service執(zhí)行耗時(shí)任務(wù),可在Service中開(kāi)啟單獨(dú)線程去執(zhí)行。
兩者使用場(chǎng)景
當(dāng)要執(zhí)行耗時(shí)的網(wǎng)絡(luò)或者數(shù)據(jù)庫(kù)查詢以及其他阻塞UI線程或密集使用CPU的任務(wù)時(shí),都應(yīng)該使用工作線程(Thread),這樣才能保證UI線程不被占用而影響用戶體驗(yàn)。
在應(yīng)用程序中,如果需要長(zhǎng)時(shí)間的在后臺(tái)運(yùn)行,而且不需要交互的情況下,使用服務(wù)。比如播放音樂(lè),通過(guò)Service+Notification方式在后臺(tái)執(zhí)行同時(shí)在通知欄顯示著。
兩者的最佳使用方式
在大部分情況下,Thread和Service都會(huì)結(jié)合著使用,比如下載文件,一般會(huì)通過(guò)Service在后臺(tái)執(zhí)行+Notification在通知欄顯示+Thread異步下載,再如應(yīng)用程序會(huì)維持一個(gè)Service來(lái)從網(wǎng)絡(luò)中獲取推送服務(wù)。在Android官方看來(lái)也是如此,所以官網(wǎng)提供了一個(gè)Thread與Service的結(jié)合來(lái)方便我們執(zhí)行后臺(tái)耗時(shí)任務(wù),它就是IntentService,(如果想更深入了解IntentService,可以看博主的另一篇文章:Android 多線程之IntentService 完全詳解),當(dāng)然 IntentService并不適用于所有的場(chǎng)景,但它的優(yōu)點(diǎn)是使用方便、代碼簡(jiǎn)潔,不需要我們創(chuàng)建Service實(shí)例并同時(shí)也創(chuàng)建線程,某些場(chǎng)景下還是非常贊的!由于IntentService是單個(gè)worker thread,所以任務(wù)需要排隊(duì),因此不適合大多數(shù)的多任務(wù)情況。
兩者的真正關(guān)系
- 兩者沒(méi)有半毛錢(qián)關(guān)系。
8.管理服務(wù)生命周期
??關(guān)于Service生命周期方法的執(zhí)行順序,前面我們已分析得差不多了,這里重新給出一張執(zhí)行的流程圖(出自Android官網(wǎng))?
?
??其中左圖顯示了使用 startService() 所創(chuàng)建的服務(wù)的生命周期,右圖顯示了使用 bindService() 所創(chuàng)建的服務(wù)的生命周期。通過(guò)圖中的生命周期方法,我們可以監(jiān)控Service的整體執(zhí)行過(guò)程,包括創(chuàng)建,運(yùn)行,銷(xiāo)毀,關(guān)于Service不同狀態(tài)下的方法回調(diào)在前面的分析中已描述得很清楚,這里就不重復(fù)了,下面給出官網(wǎng)對(duì)生命周期的原文描述:
??服務(wù)的整個(gè)生命周期從調(diào)用 onCreate() 開(kāi)始起,到 onDestroy() 返回時(shí)結(jié)束。與 Activity 類(lèi)似,服務(wù)也在 onCreate() 中完成初始設(shè)置,并在 onDestroy() 中釋放所有剩余資源。例如,音樂(lè)播放服務(wù)可以在 onCreate() 中創(chuàng)建用于播放音樂(lè)的線程,然后在 onDestroy() 中停止該線程。
??無(wú)論服務(wù)是通過(guò) startService() 還是 bindService() 創(chuàng)建,都會(huì)為所有服務(wù)調(diào)用 onCreate() 和 onDestroy() 方法。?
??服務(wù)的有效生命周期從調(diào)用 onStartCommand() 或 onBind() 方法開(kāi)始。每種方法均有 Intent 對(duì)象,該對(duì)象分別傳遞到 startService() 或 bindService()。?
??對(duì)于啟動(dòng)服務(wù),有效生命周期與整個(gè)生命周期同時(shí)結(jié)束(即便是在 onStartCommand() 返回之后,服務(wù)仍然處于活動(dòng)狀態(tài))。對(duì)于綁定服務(wù),有效生命周期在 onUnbind() 返回時(shí)結(jié)束。
??從執(zhí)行流程圖來(lái)看,服務(wù)的生命周期比 Activity 的生命周期要簡(jiǎn)單得多。但是,我們必須密切關(guān)注如何創(chuàng)建和銷(xiāo)毀服務(wù),因?yàn)榉?wù)可以在用戶沒(méi)有意識(shí)到的情況下運(yùn)行于后臺(tái)。管理服務(wù)的生命周期(從創(chuàng)建到銷(xiāo)毀)有以下兩種情況:
啟動(dòng)服務(wù)?
該服務(wù)在其他組件調(diào)用 startService() 時(shí)創(chuàng)建,然后無(wú)限期運(yùn)行,且必須通過(guò)調(diào)用 stopSelf() 來(lái)自行停止運(yùn)行。此外,其他組件也可以通過(guò)調(diào)用 stopService() 來(lái)停止服務(wù)。服務(wù)停止后,系統(tǒng)會(huì)將其銷(xiāo)毀。綁定服務(wù)?
該服務(wù)在另一個(gè)組件(客戶端)調(diào)用 bindService() 時(shí)創(chuàng)建。然后,客戶端通過(guò) IBinder 接口與服務(wù)進(jìn)行通信。客戶端可以通過(guò)調(diào)用 unbindService() 關(guān)閉連接。多個(gè)客戶端可以綁定到相同服務(wù),而且當(dāng)所有綁定全部取消后,系統(tǒng)即會(huì)銷(xiāo)毀該服務(wù)。 (服務(wù)不必自行停止運(yùn)行)
??雖然可以通過(guò)以上兩種情況管理服務(wù)的生命周期,但是我們還必須考慮另外一種情況,也就是啟動(dòng)服務(wù)與綁定服務(wù)的結(jié)合體,也就是說(shuō),我們可以綁定到已經(jīng)使用 startService() 啟動(dòng)的服務(wù)。例如,可以通過(guò)使用 Intent(標(biāo)識(shí)要播放的音樂(lè))調(diào)用 startService() 來(lái)啟動(dòng)后臺(tái)音樂(lè)服務(wù)。隨后,可能在用戶需要稍加控制播放器或獲取有關(guān)當(dāng)前播放歌曲的信息時(shí),Activity 可以通過(guò)調(diào)用 bindService() 綁定到服務(wù)。在這種情況下,除非所有客戶端均取消綁定,否則 stopService() 或 stopSelf() 不會(huì)真正停止服務(wù)。因此在這種情況下我們需要特別注意。
9.Android 5.0以上的隱式啟動(dòng)問(wèn)題
既然有隱式啟動(dòng),那么就會(huì)有顯示啟動(dòng),那就先來(lái)了解一下什么是隱式啟動(dòng)和顯示啟動(dòng)。
- 顯示啟動(dòng)?
直接上代碼一目了然,不解釋了。
- 1
- 2
- 3
- 1
- 2
- 3
- 隱式啟動(dòng)?
需要設(shè)置一個(gè)Action,我們可以把Action的名字設(shè)置成Service的全路徑名字,在這種情況下android:exported默認(rèn)為true。
- 1
- 2
- 1
- 2
存在的意義?
如果在同一個(gè)應(yīng)用中,兩者都可以用。在不同應(yīng)用時(shí),只能用隱式啟動(dòng)。Android 5.0以上的隱式啟動(dòng)問(wèn)題?
??Android 5.0之后google出于安全的角度禁止了隱式聲明Intent來(lái)啟動(dòng)Service。如果使用隱式啟動(dòng)Service,會(huì)出沒(méi)有指明Intent的錯(cuò)誤,如下:?
?
??主要原因我們可以從源碼中找到,這里看看Android 4.4的ContextImpl源碼中的validateServiceIntent(Intent service),可知如果啟動(dòng)service的intent的component和package都為空并且版本大于KITKAT的時(shí)候只是報(bào)出一個(gè)警報(bào),告訴開(kāi)發(fā)者隱式聲明intent去啟動(dòng)Service是不安全的.?
?
??而在android5.0之后呢?我們這里看的是android6.0的源碼如下(sublime text查android各個(gè)版本源碼就是爽呀!!):?
?
??從源碼可以看出如果啟動(dòng)service的intent的component和package都為空并且版本大于LOLLIPOP(5.0)的時(shí)候,直接拋出異常,該異常與之前隱式啟動(dòng)所報(bào)的異常時(shí)一致的。那么該如何解決呢?解決方式
- 設(shè)置Action和packageName
- 1
- 2
- 3
- 1
- 2
- 3
- 將隱式啟動(dòng)轉(zhuǎn)換為顯示啟動(dòng)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
調(diào)用方式如下:
Intent mIntent=new Intent();//輔助Intent mIntent.setAction("com.android.ForegroundService"); final Intent serviceIntent=new Intent(getExplicitIntent(this,mIntent)); startService(serviceIntent);- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
到此問(wèn)題完美解決。
10.如何保證服務(wù)不被殺死
??實(shí)際上這種做法并不推薦,但是既然談到了,我們這里就給出一些實(shí)現(xiàn)思路吧。主要分以下3種情況
- 因內(nèi)存資源不足而殺死Service?
這種情況比較容易處理,可將onStartCommand() 方法的返回值設(shè)為 START_STICKY或START_REDELIVER_INTENT ,該值表示服務(wù)在內(nèi)存資源緊張時(shí)被殺死后,在內(nèi)存資源足夠時(shí)再恢復(fù)。也可將Service設(shè)置為前臺(tái)服務(wù),這樣就有比較高的優(yōu)先級(jí),在內(nèi)存資源緊張時(shí)也不會(huì)被殺掉。這兩點(diǎn)的實(shí)現(xiàn),我們?cè)谇懊嬉逊治鲞^(guò)和實(shí)現(xiàn)過(guò)這里就不重復(fù)。簡(jiǎn)單代碼如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 用戶通過(guò) settings -> Apps -> Running -> Stop 方式殺死Service?
這種情況是用戶手動(dòng)干預(yù)的,不過(guò)幸運(yùn)的是這個(gè)過(guò)程會(huì)執(zhí)行Service的生命周期,也就是onDestory方法會(huì)被調(diào)用,這時(shí)便可以在 onDestory() 中發(fā)送廣播重新啟動(dòng)。這樣殺死服務(wù)后會(huì)立即啟動(dòng)。這種方案是行得通的,但為程序更健全,我們可開(kāi)啟兩個(gè)服務(wù),相互監(jiān)聽(tīng),相互啟動(dòng)。服務(wù)A監(jiān)聽(tīng)B的廣播來(lái)啟動(dòng)B,服務(wù)B監(jiān)聽(tīng)A的廣播來(lái)啟動(dòng)A。這里給出第一種方式的代碼實(shí)現(xiàn)如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 用戶通過(guò) settings -> Apps -> Downloaded -> Force Stop 方式強(qiáng)制性殺死Service?
這種方式就比較悲劇了,因?yàn)槭侵苯觡ill運(yùn)行程序的,不會(huì)走生命周期的過(guò)程,前面兩種情況只要是執(zhí)行Force Stop ,也就廢了。也就是說(shuō)這種情況下無(wú)法讓服務(wù)重啟,或者只能去設(shè)置Force Stop 無(wú)法操作了,不過(guò)也就沒(méi)必要了,太流氓了。。。。
ok~,以上便是保證服務(wù)在一定場(chǎng)景下不被殺死的解決思路,關(guān)于第3種情況,如果有解決方案,請(qǐng)留言哈。好,關(guān)于Service的全部介紹就此完結(jié)。?
主要參考資料:?
https://developer.android.com/guide/components/services.html#Notifications?
https://developer.android.com/guide/components/processes-and-threads.html?
https://developer.android.com/guide/components/bound-services.html#Lifecycle?
http://blog.csdn.net/vrix/article/details/45289207?
android 開(kāi)發(fā)藝術(shù)探索
總結(jié)
以上是生活随笔為你收集整理的关于Android Service真正的完全详解,你需要知道的一切的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: Android 7.0 init.rc的
- 下一篇: 使用Jack编译