binder 了解

一直以来，自觉得对binder有所了解，也曾暗暗佩服本身怎么这么厉害。直到一次须要用到 binder 进行通讯，信心百倍的提出使用 service 中 binder 或者 messager 来获取，可是原来已经使用来 contentprovider ，再使用 service 就存在延迟和重复等等问题，在想着使用 aidl (思索着仍是脱离不了 service )、 contentobserver 这个到不错，可是由于须要双向通讯，总不能每一个进程在单独配一个独自的contentprovider 、再有就是使用广播来进行了，可是太依赖系统处理，实时性等都没法保证。

这时候有同事提出可使用各个进程把 binder 传到 contentprovider，这样在 cp 中就能够经过 binder 调用相关回调方法实现通讯，而各个进程访问 cp 便可。

第一反应，可行。但是转念一想，adil 的 stub 就只是建立一个 binder 对象、实例，传递到 cp 那边不就只是把这个对象传过去了吗，cp 对调用这个对象方法还能够在回到原进程？？？少了一个关键步骤啊。那就是 binder 注册哪去了,为何传个对象过去，调用方法还能够回到原进程，不是就是在当前进程了吗？

由此我提出了强烈的质疑。binder机制分为client，server，binder 驱动，ServcieManager。ServiceManager 实质上就是 server ,来进行统一管理。那咱们本身把 binder 传递过去没有意义啊。

实践出真知。咱们实验下来发现是可行的。由此我反思到本身 对 binder 理解仍是停留在表层啊。仔细看 messager 实际上也是差很少的状况。当时为这个状况反复查了很久的资料，终于肯定 binder 驱动是关键，它负责来 binder 对象本地和远端代理的关联。Binder 实体在 Binder 驱动中的传输，会被特殊处理，若是传递到其它进程会成为代理对象，其它进程便可调用对象方法。不通过 ams 只要能经过 跨进程传递对象过去便可实现。这么看来 ServiceManager 是起到注册管理显式 binder 的做用，这样能够根据名字来作到返回对应的 binder 对象。

在期间其实生出了一个想法，若是能够存储到文件里，而后在另外进程读出来不是就能够实现本身的跨进程的目的了吗。但是很遗憾，表象上的传递只是表面，实际上它在内核层还作了很多的事情，好比 binder 支持传递文件描述符，ParcelFileDescriptor ，可是其实是在内核为新的进程又申请了一个文件描述符来关联到文件。

binder 作为 android 底层的跨进程通讯基础，是有不少细节须要注意。可能这也是编码的魅力吧。每每简单的东西下有复杂的实现，可是理解后有以为简单，再往下又复杂。所谓的精通等等也只是创建在某个角度，某个层面。因此咱们更应该锻炼本身的思惟，有不断更新的架构的思惟才能保证本身永不落伍