前言

經(jīng)過前面三章的學(xué)習(xí)，各位對Binder框架，AIDL機(jī)制已經(jīng)有一個宏觀的概念了，更多的細(xì)節(jié)，各位需要自己再去研究，推薦老羅的《Android系統(tǒng)源代碼情景分析》，市面上講Binder講的組好的書，沒有之一，這一篇也是完結(jié)篇，我眼中的Binder

Binder-BinderProxy（Java層）和BBinder-BpBinder（Native C++層）

假如你要在java中創(chuàng)建Binder服務(wù)端，請繼承Binder
假如你要在Native中創(chuàng)建Binder服務(wù)端，請繼承BBinder

BinderProxy和BpBinder都是Binder驅(qū)動創(chuàng)建給你的。你拿來調(diào)用接口就會通過Binder驅(qū)動調(diào)用到服務(wù)端的Binder和BBinder

實(shí)名Binder

實(shí)名Binder是只在ServiceManager中注冊的Binder對象，大家可以通過ServiceManager.getService("服務(wù)A")，拿到服務(wù)A的BinderProxy對象

匿名Binder

假如進(jìn)程A已經(jīng)持有了進(jìn)程B中服務(wù)Bi的BinderProxyB對象，服務(wù)B有一個接口叫做setCallBack(Binder binder).這個時候進(jìn)程A也創(chuàng)建一個服務(wù)A的BinderA，并調(diào)用服務(wù)B setCallBack(BinderA),因為Binder驅(qū)動幫你在底層實(shí)現(xiàn)了，所以進(jìn)程B中可以獲得服務(wù)A的BinderProxyA對象，可以使用BinderProxyA來操作進(jìn)程A中服務(wù)A。這樣子實(shí)現(xiàn)了進(jìn)程A和B的雙向通信。

實(shí)名Binder和匿名Binder的區(qū)別

透過現(xiàn)象看本質(zhì)，兩者沒有區(qū)別，一句話總結(jié)：服務(wù)端可以創(chuàng)建Binder對象，客戶端可以通過已經(jīng)搭建起來的Binder通信的接口通知Binder驅(qū)動給你創(chuàng)建出來BinderProxy對象。

實(shí)名Binder利用的通信接口就是ServiceManager這個最原始的接口getServcie,addService
匿名Binder利用的通信接口就是工程師自己實(shí)現(xiàn)的setCallBack。

宏觀上看Binder驅(qū)動給你提供的功能

1.Binder和BinderProxy對象的跨進(jìn)程通信的功能
2.跨進(jìn)程傳遞Binder對象時，客戶端拿到的對象不是Binder，而是Binder驅(qū)動生成BinderProxy對象

Binder機(jī)制為了提升性能，做了一件事

假如BinderProxy和Binder都在同一進(jìn)程中，如果這兩者的通信還要通過Binder驅(qū)動不是太浪費(fèi)了嗎，直接拿Binder對象，作為普通的類來調(diào)用不就好了嗎？所以Binder機(jī)制的工程師早就幫你們想好了，在為客戶端生成BinderProxy對象的時候，會判斷是不是同一進(jìn)程，如果是同一進(jìn)程就把Binder對象直接返回給客戶端。

看源碼的技巧

很多人看源碼很容易迷失的原因就是因為搞不清楚服務(wù)端和客戶端，調(diào)來調(diào)去就亂了。你們只要永遠(yuǎn)記住這句話就不會亂了：Binder（服務(wù)端）和BinderProxy（客戶端）成對出現(xiàn)，服務(wù)端和客戶端在同一進(jìn)程中，Binder驅(qū)動為了性能會自動返回Binder對象而不是BinderProxy。

小結(jié)

小編終于把自己理解的Binder都寫出來了，源碼比較少，更多的是從大局觀上看待Binder，更多的細(xì)節(jié)可以看《Android系統(tǒng)源代碼情景分析》，建議大家買一個本這個書支持一下老羅，因為我希望老羅可以出第二本有關(guān)SurfaceFlinger的。