前言
经过前面三章的学习，各位对Binder框架，AIDL机制已经有一个宏观的概念了，更多的细节，各位需要自己再去研究，推荐老罗的《Android系统源代码情景分析》，市面上讲Binder讲的组好的书，没有之一，这一篇也是完结篇，我眼中的Binder
Binder-BinderProxy（Java层）和BBinder-BpBinder（Native C++层）
假如你要在java中创建Binder服务端，请继承Binder
假如你要在Native中创建Binder服务端，请继承BBinder
BinderProxy和BpBinder都是Binder驱动创建给你的。你拿来调用接口就会通过Binder驱动调用到服务端的Binder和BBinder
实名Binder
实名Binder是只在ServiceManager中注册的Binder对象，大家可以通过ServiceManager.getService("服务A")，拿到服务A的BinderProxy对象
匿名Binder
假如进程A已经持有了进程B中服务Bi的BinderProxyB对象，服务B有一个接口叫做setCallBack(Binder binder).这个时候进程A也创建一个服务A的BinderA，并调用服务B setCallBack(BinderA),因为Binder驱动帮你在底层实现了，所以进程B中可以获得服务A的BinderProxyA对象，可以使用BinderProxyA来操作进程A中服务A。这样子实现了进程A和B的双向通信。
实名Binder和匿名Binder的区别
透过现象看本质，两者没有区别，一句话总结：服务端可以创建Binder对象，客户端可以通过已经搭建起来的Binder通信的接口通知Binder驱动给你创建出来BinderProxy对象。
实名Binder利用的通信接口就是ServiceManager这个最原始的接口getServcie,addService
匿名Binder利用的通信接口就是工程师自己实现的setCallBack。
宏观上看Binder驱动给你提供的功能
1.Binder和BinderProxy对象的跨进程通信的功能
2.跨进程传递Binder对象时，客户端拿到的对象不是Binder，而是Binder驱动生成BinderProxy对象
Binder机制为了提升性能，做了一件事
假如BinderProxy和Binder都在同一进程中，如果这两者的通信还要通过Binder驱动不是太浪费了吗，直接拿Binder对象，作为普通的类来调用不就好了吗？所以Binder机制的工程师早就帮你们想好了，在为客户端生成BinderProxy对象的时候，会判断是不是同一进程，如果是同一进程就把Binder对象直接返回给客户端。
看源码的技巧
很多人看源码很容易迷失的原因就是因为搞不清楚服务端和客户端，调来调去就乱了。你们只要永远记住这句话就不会乱了：Binder（服务端）和BinderProxy（客户端）成对出现，服务端和客户端在同一进程中，Binder驱动为了性能会自动返回Binder对象而不是BinderProxy。
小结
小编终于把自己理解的Binder都写出来了，源码比较少，更多的是从大局观上看待Binder，更多的细节可以看《Android系统源代码情景分析》，建议大家买一个本这个书支持一下老罗，因为我希望老罗可以出第二本有关SurfaceFlinger的。
