Android Activity與Service的交互方式

參考: http://blog.csdn.net/gebitan505/article/details/18151203

 

實現更新下載進度的功能

 

1. 經過廣播交互

 Server端將目前的下載進度，經過廣播的方式發送出來，Client端註冊此廣播的監聽器，當獲取到該廣播後，將廣播中當前的下載進度解析出來並更新到界面上。

優缺點分析:

    經過廣播的方式實現Activity與Service的交互操做簡單且容易實現，能夠勝任簡單級的應用。但缺點也十分明顯，發送廣播受到系統制約。系統會優先發送系統級廣播，在某些特定的狀況下，咱們自定義的廣播可能會延遲。同時在廣播接收器中不能處理長耗時操做，不然系統會出現ANR即應用程序無響應

 

 2. 共享文件交互

    這裏提到的共享文件指的是Activity和Service使用同一個文件來達到傳遞數據的目的。咱們使用SharedPreferences來實現共享，固然也可使用其它IO方法實現，經過這種方式實現交互時須要注意，對於文件的讀寫的時候，同一時間只能一方讀一方寫，不能兩方同時寫

優缺點分析:

    對於這種方式實現Activity與Service的交互，能夠說很方便，就像使用管道，一個往裡寫，一個往外讀。但這種方式也有缺陷，寫入數據較爲複雜以及數據量較大時，就有可能致使寫入與讀數據出不一致的錯誤。同時由於通過了一箇中轉站，這種操做將更耗時。

 

3. Messenger交互(信使交互) Handler

    Messenger翻譯過來指的是信使，它引用了一個Handler對象，別人可以向它發送消息(使用mMessenger.send(Message msg)方法)。該類容許跨進程間基於Message通訊，在服務端使用Handler建立一個 Messenger，客戶端只要得到這個服務端的Messenger對象就能夠與服務端通訊了。也就是說咱們能夠把Messenger當作Client端與Server端的傳話筒，這樣就能夠溝通交流了

優缺點分析:

    經過Messenger來實現Activity和Service的交互，稍微深刻一點咱們就能夠知道，其實Messenger也是經過AIDL來實現的。對於前兩種實現方式，Messenger方式整體上來說也是比較容易理解的，這就和平時使用Handler和Thread通訊一個道理。

 

4. Server中自定義接口交互

    自定義一個接口，該接口中有一個獲取當前下載進度的空方法。Server端用一個類繼承自Binder並實現該接口，覆寫了其中獲取當前下載進度的方法。Client端經過ServiceConnection獲取到該類的對象，從而可以使用該獲取當前下載進度的方法，最終實現實時交互。

public interface ICountService {  
    public int getCurrentLoad();  
} 

public class DownLoadService extends Service implements ICountService{  
private ServiceBinder serviceBinder = new ServiceBinder();    
public class ServiceBinder extends Binder implements ICountService{  
    @Override  
    public int getCurrentLoad() {  
        Log.i(TAG, "ServiceBinder getCurrentLoad()... i=:"+i);  
        return i;  
    }     
}  
@Override  
public int getCurrentLoad() {  
    return 0;  
}  
}  

@Override  
public IBinder onBind(Intent intent) {  
    Log.i(TAG, "DownLoadService.onBind()...");  
    return serviceBinder;  
}  

     Client端的Timer在bindService()完成以後1秒再開始獲取下載進度，獲取方法是直接經過int curLoad = iCountService.getCurrentLoad()；這裏的getCurrentLoad()方法是DownLoadService內部類ServiceBinder中的方法。Client端將獲取到的下載進度更新到介面上並更新進度條。

優缺點分析:

    這種方法簡單實用，擴展性強，但其也有一些缺點，好比須要延遲一些再開始獲取Server端的數據，從而沒法徹底實現從零開始同步更新。綜其所述，經過自定義接口實現Activity與Service交互的方法仍是比較實用的。適用於同進程中通訊，不能進行跨進程通訊。

 

 5. AIDL交互

    原理: AIDL屬於Android的IPC機制，經常使用於跨進程通訊，主要實現原理基於底層Binder機制。

優缺點分析:

    AIDL在Android中是進程間通訊經常使用的方式，可能使用較為複雜，但效率高，擴展性好。同時不少系統服務就是以這種方式完成與應用程序通訊的。