問題等同：Binder是如何實(shí)現(xiàn)進(jìn)程間通信的新博？或者AIDL的原理？
我們在客戶端通過IBookManager接口對象嘗試調(diào)用接口方法時(shí)，接口內(nèi)部是如何工作的呢蹄咖？到底是如何使用Binder實(shí)現(xiàn)跨進(jìn)程通信的呢根盒？
要明白上面的問題钳幅，就需要對IBookManager類進(jìn)行分析才能得到答案
一、IBookManager.java的結(jié)構(gòu)
- 首先IBookManager接口繼承了IInterface接口, 所有在Binder中傳輸?shù)慕涌诙夹枰^承IInterface
- 聲明內(nèi)部Stub類,繼承Binder并且實(shí)現(xiàn)了IBookManager炎滞。（由此可見Stub為核心類）
-
聲明我們在IBookManager.aidl定義的方法getBookList和addBook
image.png
二贡这、核心實(shí)現(xiàn)IBookManager.Stub（Binder）類分析
- DESCRIPTOR常量：為Binder指定唯一標(biāo)識(shí)
- 整形id常量：為getBookList和addBookfangf方法指定標(biāo)識(shí)
- 構(gòu)造方法：調(diào)用asInterface
4. asInterface方法： 將服務(wù)端的Binder對象轉(zhuǎn)換成客戶端需要的AIDL接口類型對象。
- 如果服務(wù)端和客戶端同進(jìn)程厂榛，返回IBookManager接口對象本身盖矫，否則返回系統(tǒng)封裝后的Stub.Proxy對象
- 之前的項(xiàng)目案例中，我們在客戶端就是通過IBookManager.Stub.asInterface(service)來獲取接口對象的
- asBinder方法： 返回當(dāng)前Binder對象
6. onTransact方法：這個(gè)方法運(yùn)行在服務(wù)端中的Binder線程池击奶，當(dāng)客服端發(fā)起跨進(jìn)程請求時(shí)辈双，遠(yuǎn)程請求通過系統(tǒng)底層封裝后交由此方法處理。工作過程如下：
onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags)
- 服務(wù)端通過code確定請求的目標(biāo)方法
- 從data中取出目標(biāo)方法需要的參數(shù)（如果目標(biāo)方法有參數(shù)）柜砾，然后執(zhí)行目標(biāo)方法
- 執(zhí)行完畢后湃望，就向reply中寫入返回值（如果目標(biāo)方法有返回值）
- 此方法返回false時(shí)，客戶端請求失斕登（會(huì)拋出異常）
7. 聲明內(nèi)部類Proxy實(shí)現(xiàn)IBookManager接口证芭，為Stub的代理類（由4可以知）。主要工作重寫getBookList和addBook方法担映。
分析Proxy#getBookList废士，這個(gè)方法運(yùn)行在客戶端
- 創(chuàng)建所需要的Parcel對象：輸入型_data损姜、輸出型_reply善玫，以及返回值對象List
- 然后將方法的參數(shù)信息寫入_data中（如果有參數(shù)的話）
- 接著通過IBinder類型的成員變量mRemote（實(shí)際就是通過綁定服務(wù)成功獲得的IBinder對象）調(diào)用transact方法來發(fā)起RPC（遠(yuǎn)程過程調(diào)用）請求，同時(shí)線程掛起拿愧；
- 然后服務(wù)端onTransact方法被調(diào)用，直到RPC過程返回氢架，當(dāng)前線程繼續(xù)執(zhí)行傻咖，并從_reply取出返回結(jié)果（即6中的reply）
- 最后返回_reply結(jié)果
注意：
- 客戶端的發(fā)出的同步請求，所以不能在UI線程發(fā)起遠(yuǎn)程請求
- 服務(wù)端Binder運(yùn)行在Binder線程池岖研，即onTransact方法執(zhí)行在Binder方法池中卿操，在此方法中最終執(zhí)行了我們接口中定義方法的具體實(shí)現(xiàn)。所以在AIDLService中的IBookManager.Stub對象實(shí)現(xiàn)接口方法時(shí)孙援，不管操作是否耗時(shí)都要采用同步的方式硬纤。
三、Binder的工作機(jī)制總結(jié)
image.png
從上面的分析我們可以總結(jié)出Binder工作流程（跨進(jìn)程）大致如下：
客戶端：
- 綁定服務(wù)赃磨，并獲得Binder對象
- 通過asInterface方法以（1）中的Binder對象為參數(shù)筝家，獲得Stub.Proxy代理類實(shí)例；
- 在子線程中通過Stub.Proxy實(shí)例調(diào)用其實(shí)現(xiàn)的接口方法邻辉。_data中寫入?yún)?shù)溪王，并通過Binder調(diào)用transact方法發(fā)起RPC，線程掛起值骇，等待RPC返回結(jié)果
服務(wù)端： - 通過底層封裝后回調(diào)onTransact方法莹菱。在此方法中從data取出參數(shù)，并執(zhí)行目標(biāo)吱瘩，執(zhí)行完畢在reply中寫入目標(biāo)方法的返回值道伟。最后返回onTransact方法的執(zhí)行結(jié)果，true則代表客戶端請求成功使碾，RPC將會(huì)返回結(jié)果蜜徽，執(zhí)行過程也將回到客戶端。
客戶端： - RPC過程返回后票摇，原本掛起的客戶端線程繼續(xù)執(zhí)行拘鞋，從_reply中取出服務(wù)端方法執(zhí)行的結(jié)果并返回。
這樣就實(shí)現(xiàn)了進(jìn)程間通信了矢门，至于RPC的調(diào)用過程及reply盆色、_reply是如何在內(nèi)存中存儲(chǔ)數(shù)據(jù)的暫不討論
