以MS為例，現在程序運行正常。此時MS： （1）通過startThreadPool啟動了一個線程，這個線程在talkWithDriver。 （2）主線程通過joinThreadPool，也在talkWithDriver。 至此我們已知道，有兩個線程在和Binder設備打交道。這時在業務邏輯上需要與ServiceManager交互，比如要調用listServices打印所有服務的名字，假設這是MS中的第三個線程。按照之前的分析，它最終會調用IPCThreadState的transact函數，這個函數會talkWithDriver并把請求發到ServiceManager進程，然后等待來自Binder設備的回復。那么現在一共有三個線程（不論是在等待來自其他Client的請求，還是在等待listService的回復）都在talkWithDriver。 ServiceManager處理完了listServices，把回復結果寫回Binder驅動，那么，MS中哪個線程會收到回復呢？此問題如圖6-6表示： :-:  圖6-6 本問題的示意圖 顯而易見，當然是調用listServices的那個線程會得到結果。為什么？因為如果不這么做，則會導致下面情況的發生： - 如果是沒有調用listServices的線程1或者線程2得到回復，那么它們應該喚醒調用listServices的線程3。因為這時已經有了結果，線程3應該從listServices函數調用中返回。 - 這其中的線程等待、喚醒、切換會浪費不少寶貴的時間片，而且代碼邏輯會極其復雜。 看來，Binder設備把發起請求的線程牢牢地拴住了，必須收到回復才能放它離開。這種一一對應的方式極大簡化了代碼層的處理邏輯。 * * * * * **說明**：想想socket編程吧，同一時刻不能有多個線程操作socket的讀/寫，否則數據會亂套。 另外，我們再分析executeCommand的時候，特別提到BR_SPAWN_LOOPER這個case的處理，它用于建立新的線程來和Binder通信。什么會收到這個消息呢？請讀者研究binder的驅動。如果有新發現，請告訴我，大家再一起學習。 * * * * *