Java層Binder框架
BpBinder和JavaBBinder是一對的 ，是通信架構的一部分，應該算是身份證的持有者。
通信時，是通過IPCThreadState和binder驅動交互。例如在客戶端發送請求時，是BpBinder把要通信的BBinder的handle告訴binder線程的IPCThreadState，然後IPCThreadState就把handle告訴binder驅動，然後把請求數據包交給binder驅動，binder驅動放到binder驅動內存中分配給服務端進程所屬的buffer。
接着binder驅動喚醒一個binder線程，最後屬於該binder線程的IPCThreadState根據handle，找到對應的BBinder，接着就可以調用業務層邏輯了。
Java構架和native構架基本上是一一對應的（服務端的業務邏輯不算），因爲最終是要與binder驅動通信的，包括數據包parcel等，parcel是要給BpBinder使用的，BpBinder只接受native類型的Parcel指針，那爲什麼BpBinder不直接接收jni類型的jObject，而那麼麻煩將jObject的Java Parcel轉爲native類型的Parcel。因爲不只是java應用程序使用binder通信，而一些native程序也使用binder通信，如media server進程。
native層Binder框架
IPCThreadState.cpp
直接和Binder驅動通信的一個類，talkWithDriver()和ioctl(...)
Parcel.cpp和Parcel.java
Parcel只是數據的封裝，和通信無關。
android_os_Binder.cpp和Binder
Binder和通信相關，但是隻是一箇中介，主要是作爲服務的業務邏輯和通信邏輯的橋樑
BpBinder.cpp
可以看到和binder驅動通信的任務是完全交給IPCThreadState
那麼服務端的native層的BBinder是如何處理的：
當有請求的時候，binder驅動將會喚醒服務所在進程的binder線程，然後調用IPCThreadState#executeCommand（cmd），其中參數爲BR_TRANSACTION。接着binder線程回去binder驅動讀取請求參數，讀到tr中。然後再調用BBinder#transact(...),這樣就會逐步去到服務端的業務層，這個業務層的實現可以使用native語言，也可以使用java。所以Java層的binder框架不是必須的。
參考自深入理解AndroidⅠ的第六章深入理解Binder和深入理解AndroidⅡ的第二章深入理解Android Java Binder和Message Queue