上次講了第一種 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); } } }</pre>
Java代碼
- @Override
- public IBinder onBind(Intent intent) {
- return messenger.getBinder();
- }
@Override public IBinder onBind(Intent intent) { return messenger.getBinder(); }
下面來看運行效果圖(Debug模式):
首先,啟動 BindServiceDemoClient
最下面的那個進程即為 BindServiceDemoClient 工程對應的進程,而且還沒有 BindServiceDemoService 工程的進程。下面,點擊 "Bind Service" 的按鈕,當執行下圖中的斷點時,請注意右上角 service 的類型(BindProxy),這也從一個方面說明瞭為什麼在 IPC 的時候不可以使用 IBinder 來實現。此時,再來看一下系統中的進程情況:
會發現,在最下面多了一個 BindServiceDemoService 工程的進程,這就說明瞭 client 與 service 是在不同的進程內的,這也正是本例子的意圖:使用 Messenger 在不同進程間進行通信。
現在通過 DDMS 控制檯,直接將 com.archer.rainbow.service 進程殺掉,來模擬系統資源少而急需回收系統資源的情況,如下:
另外,需要注意的是,當我們通過界面點擊 "Unbind Service" 的時候,雖然服務被解綁了,但是系統並沒有立即將 com.archer.rainbow.service 這一進程給殺掉:
但若此時,通過 DDMS 控制檯,直接將該進程殺掉的話,系統也不會重新啟動該進程
注意與上面對應的日誌進行比對,你會發現它少了 "Scheduling restart........" 的這條日誌。
PS:若想將 service 在另一個進程中啟動,你也可以在聲明 Service 的時候,使用 "android:process=":remote"" 這種方式來實現。