上次講了第一種 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"" 這種方式來實現。