Android Service 之三(Bind Service,使用 Messenger)
上次講了第一種 Bind Service 的實現方式,今天講
第二種:使用 Messenger
這種情況適用於你想實現進程間通信的場合,它分以下幾個步驟:
① service 內部需要有一個 Handler 的實現,它被用來處理從每一個 client 發送過的來請求
② 通過這個 Handler ,來生成一個 Messenger
③ 在 service 的onBind() 方法中,需要向 client 返回由該 Messenger 生成的一個 IBinder 實例
④ client 使用從 service 返回的 IBinder 實例來初始化一個 Messenger, 然後使用該 Messenger 與 service 進行通信
⑤ service 通過它自身內部的 Handler 實現(Handler 人 handleMessage() 方法中)來處理從 client 發送過來的請求
下面給出一實例進行說明,該實現由兩個工程組成:
① BindServiceDemo_Client: 該工程中只包含一個Activity,用來綁定另一個工程中的 Service
② BindServiceDemo_Service:該工程中只包含一個Service
在實例中, Client 與 Service 中都有一個Messenger ,所以可以進行兩者的互相請求與應答。話不多說,貼上部分源碼:
① BindServiceDemoClient 中:
- // client 端 Handler 的實現
- private class IncomingHandler extends Handler {
- /*
- * 處理從Service發送至該Activity的消息
- * (non-Javadoc)
- * @see android.os.Handler#handleMessage(android.os.Message)
- */
- @Override
- public void handleMessage(Message msg) {
- switch (msg.what) {
- case MSG_SET_VALUE:
- Toast.makeText(BindServiceDemoClient.this,
- "set value as: " + msg.arg1, Toast.LENGTH_SHORT)
- .show();
- break;
- default:
- super.handleMessage(msg);
- }
- }
- }
- // client 端 ServiceConnection 的實現
- private ServiceConnection myRemoteServiceConnection = new ServiceConnection() {
- public void onServiceConnected(android.content.ComponentName name,
- android.os.IBinder service) {
- updateLog("myServiceConnection.onServiceConnected");
- // 客戶端 與 服務 不在同一個進程中的話,所以不可以進行顯示強制類型轉換的,
- // 因為,通過Debug,可以發現此時傳進來的 Service 的類型是 BinderProxy
- isBound = true;
- // 使用從Service返回的IBinder來生成一個Messenger
- Messenger serviceMessenger = new Messenger(service);
- // 生成一個Message
- Message msg = Message.obtain();
- msg.what = MSG_REGISTER_CLIENT;
- msg.replyTo = messenger;
- try {
- // 向Service 發送Message
- serviceMessenger.send(msg);
- } catch (RemoteException e) {
- e.printStackTrace();
- }
- msg = Message.obtain();
- msg.what = MSG_SET_VALUE;
- msg.replyTo = messenger;
- msg.arg1 = 10;
- try {
- serviceMessenger.send(msg);
- } catch (RemoteException e) {
- e.printStackTrace();
- }
- };
② BindServiceDemoService 中:
- // service 端的 Handler 的實現
- private class IncomingHandler extends Handler {
- @Override
- public void handleMessage(Message msg) {
- switch (msg.what) {
- case MSG_REGISTER_CLIENT:
- allClients.add(msg.replyTo);
- break;
- case MSG_UNREGISTER_CLIENT:
- allClients.remove(msg.replyTo);
- break;
- case MSG_SET_VALUE:
- int value = msg.arg1;
- for (int i = 0; i < allClients.size(); i++) {
- try {
- allClients.get(i).send(
- Message.obtain(null, MSG_SET_VALUE, value,
- 0));
- } catch (RemoteException e) {
- allClients.remove(i);
- }
- }
- break;
- default:
- super.handleMessage(msg);
- }
- }
- }
- @Override
- public IBinder onBind(Intent intent) {
- return messenger.getBinder();
- }
下面來看運行效果圖(Debug模式):
首先,啟動 BindServiceDemoClient
此時,所有的進程如下:
最下面的那個進程即為 BindServiceDemoClient 工程對應的進程,而且還沒有 BindServiceDemoService 工程的進程。下面,點擊 "Bind Service" 的按鈕,當執行下圖中的斷點時,請注意右上角 service 的類型(BindProxy),這也從一個方面說明瞭為什麼在 IPC 的時候不可以使用 IBinder 來實現。
按F8繼續執行,會得到如下截圖:
此時,再來看一下系統中的進程情況:
會發現,在最下面多了一個 BindServiceDemoService 工程的進程,這就說明瞭 client 與 service 是在不同的進程內的,這也正是本例子的意圖:使用 Messenger 在不同進程間進行通信。
現在通過 DDMS 控制檯,直接將 com.archer.rainbow.service 進程殺掉,來模擬系統資源少而急需回收系統資源的情況,如下:
系統會輸出如下日誌:
之後,當系統資源充足的時候,會自己重新啟動該進程,如下圖:
同時,系統輸出的日誌為:
另外,需要注意的是,當我們通過界面點擊 "Unbind Service" 的時候,雖然服務被解綁了,但是系統並沒有立即將 com.archer.rainbow.service 這一進程給殺掉:
但若此時,通過 DDMS 控制檯,直接將該進程殺掉的話,系統也不會重新啟動該進程
注意與上面對應的日誌進行比對,你會發現它少了 "Scheduling restart........" 的這條日誌。
PS:若想將 service 在另一個進程中啟動,你也可以在聲明 Service 的時候,使用 "android:process=":remote"" 這種方式來實現。