Binder面試系列之二

談談你對 binder 的理解？

面試官提了一個問題，我們來看看 張三、李四 和 王五 三位同學的表現如何吧

---

張三自認為無所不知，水平已達應用開發天花板，目前月薪 10k

面試官️：談談你對 binder 的理解

張三：binder 是用來跨程式通訊的，可以分為 client、server、binder 驅動以及 service manager 四部分。

面試官：一次拷貝原理知道嗎？

張三：不太清楚，其實對應用開發來說，沒必要知道的。

面試官：好的，回去等通知吧

---

李四 業餘時間經常打遊戲、追劇、熬夜，目前月薪 15k

面試官：談談你對 binder 的理解

李四：binder 是一種 IPC 方式，相比於 Linux 原有的管道、共享記憶體、Socket 等，它通過 mmap 實現一次拷貝，比 Socket 、管道傳輸速度更快，比共享記憶體更安全可控，是 Android 系統中主要的 IPC 通訊方式。

面試官：Intent 傳參有大小限制，這跟 binder 有關係嗎？

李四：嗯... 應該有關係吧

面試官：binder 是如何限制這個大小的？

李四：這個不瞭解，我還沒有深入看過相關原始碼。

面試官：好的，回去等通知吧

---

王五堅持每天學習、不斷的提升自己，目前月薪 30k

面試官：談談你對 binder 的理解

王五：binder 是 Android 中主要的跨程式通訊方式，binder 驅動和 service manager 分別相當於網路協議中的路由器和 DNS，並基於 mmap 實現了 IPC 傳輸資料時只需一次拷貝。

binder 包括 BinderProxy、BpBinder 等各種 Binder 實體，以及對 binder 驅動操作的 ProcessState、IPCThreadState 封裝，再加上 binder 驅動內部的結構體、命令處理，整體貫穿 Java、Native 層，涉及使用者態、核心態，往上可以說到 Service、AIDL 等，往下可以說到 mmap、binder 驅動裝置，是相當龐大、繁瑣的一個機制。

我自己來談的話，一天時間都不夠，還是問我具體的問題吧。

面試官：基於 mmap 又是如何實現一次拷貝的？

王五：其實很簡單，我來畫一個示意圖吧：

Client 與 Server 處於不同程式有著不同的虛擬地址規則，所以無法直接通訊。而一個頁框可以對映給多個頁，那麼就可以將一塊實體記憶體分別與 Client 和 Server 的虛擬記憶體塊進行對映。

如圖， Client 就只需 copyfromuser 進行一次資料拷貝，Server 程式就能讀取到資料了。另外對映的虛擬記憶體塊大小將近 1M (1M-8K)，所以 IPC 通訊傳輸的資料量也被限制為此值。

面試官：怎麼理解頁框和頁？

：頁框是指一塊實際的實體記憶體，頁是指程式的一塊記憶體資料單元。記憶體資料一定是儲存在實際的實體記憶體上，即頁必然對應於一個頁框，頁資料實際是儲存在頁框上的。

頁框和頁一樣大，都是核心對記憶體的分塊單位。一個頁框可以對映給多個頁，也就是說一塊實際的物理儲存空間可以對映給多個程式的多個虛擬記憶體空間，這也是 mmap 機制依賴的基礎規則。

面試官：簡單說下 binder 的整體架構吧

王五：再來畫一個簡單的示意圖吧，這是一個比較典型的、兩個應用之間的 IPC 通訊流程圖：

​ Client 通過 ServiceManager 或 AMS 獲取到的遠端 binder 實體，一般會用 Proxy 做一層封裝，比如 ServiceManagerProxy、 AIDL 生成的 Proxy 類。而被封裝的遠端 binder 實體是一個 BinderProxy。

​ BpBinder 和 BinderProxy 其實是一個東西：遠端 binder 實體，只不過一個 Native 層、一個 Java 層，BpBinder 內部持有了一個 binder 控制程式碼值 handle。

​ ProcessState 是程式單例，負責開啟 Binder 驅動裝置及 mmap；IPCThreadState 為執行緒單例，負責與 binder 驅動進行具體的命令通訊。

​ 由 Proxy 發起 transact() 呼叫，會將資料打包到 Parcel 中，層層向下呼叫到 BpBinder ，在 BpBinder 中呼叫 IPCThreadState 的 transact() 方法並傳入 handle 控制程式碼值，IPCThreadState 再去執行具體的 binder 命令。

​ 由 binder 驅動到 Server 的大概流程就是：Server 通過 IPCThreadState 接收到 Client 的請求後，層層向上，最後回撥到 Stub 的 onTransact() 方法。

​ 當然這不代表所有的 IPC 流程，比如 Service Manager 作為一個 Server 時，便沒有上層的封裝，也沒有藉助 IPCThreadState，而是初始化後通過 binder_loop() 方法直接與 binder 驅動通訊的。