Binder 不能再土的理解

先给乃们提个醒, Binder 是 android IPC ,进程间通讯用的,一般情况用不到.

一听 Binder 挺迷糊,感觉上Y就是一高大上的东西,其实就是个跑腿的.

Binder ,翻译过来是粘合剂,一听就知道是用来干嘛的了.在各个大佬之间拼缝子,贩夫走卒.

有一天,皇上想吃冰棍,就告诉太监:老子要吃冰棍,太监就去自己的牛人录里去找能弄到冰棍的人的画像,把画像发给大臣,大臣拿着画像去找这个牛人,找到了之后,牛人说:包在我万事通身上,然后心里想着,东经XXX,北纬XXX,那又卖冰棍的.去那弄到冰棍后给大臣,一级一级回溯到皇上手里.

整个过程中,皇上就是客户,调用服务的发起者, 太监就是ServiceManager , 太监的牛人录里面维护了所有牛人的画像. 牛人呐,就是咱的主角 binder,牛人的画像,就是binder的引用啦,大臣就是 linux 内核中的binder驱动(一下简称内核) , 而生产冰棍的 就是service . binder不生产服务,它只做….

倒着再来一遍奥, 生产冰棍的(service)拖牛人(binder)的关系告诉大臣 (linux内核)我能产冰棍,当然,这个能和大臣搭上关系的牛人(binder)需要卖冰棍的(service)自己去找,然后大臣(linux内核)就记下了,这孙子(binder)知道哪有卖冰棍的(service),然后把这孙子的画像(binder的引用)上交给太监(SManager),太监(SManager)记在自己的牛人录(binder名字索引表)里.等待皇帝点名(调用).
上个图

你想说,卧*,不就吃个冰棍么,咋这么复杂呢.

很简单,因为皇帝不会认识牛人,也不会知道哪卖冰棍,大臣也不会知道哪卖冰棍.因为他们不在一个级别(不同进程),所以只能通过这种人脉广的万事通(二道贩子)去办这些事.

细心的同学会发现一个BUG,尼玛,service 是一个进程, ServiceManager 也是一个进程,你可以有client调用者(皇上),可以有生产服务的service(卖冰棍的),可以有binder驱动,但是你Y哪来的ServiceManager,而且,你想实现进程间通讯,其中用到的service和serviceManager之间的通讯就是进程间通讯,丫这么大BUG还讲这么多,骗鬼呢.

太监表示,我从群众中来,到…. ServiceManager是从service进化来的,

好了,现在进入烧脑时间

现有一服务,比如播放音乐的服务,他想告诉别人 我会播放音乐,怎么办?
1.创建一个binder 记住它的名字,
2.将它连同名字以数据包的形式通过 Binder 驱动发送给ServiceManager,通知ServiceManager注册一个名叫张三的Binder，它位于某个Server中。
其中的详细过程如下所述:
注:binder驱动发送给ServiceManager的过程为:驱动为这个穿过进程边界的Binder创建位于内核中的实体节点以及ServiceManager对实体的引用，将名字及新建的引用打包传递给ServiceManager。ServiceManager收数据包后，从中取出名字和引用填入一张查找表中。
3.Client 获得实名Binder的引用
Server向ServiceManager注册了Binder实体及其名字后，Client就可以通过名字获得该Binder的引用了。Client也利用保留的0号引用向ServiceManager请求访问某个Binder：我申请获得名字叫张三的Binder的引用。ServiceManager收到这个连接请求，从请求数据包里获得Binder的名字，在查找表里找到该名字对应的条目，从条目中取出Binder的引用，将该引用作为回复发送给发起请求的Client。从面向对象的角度，这个Binder对象现在有了两个引用：一个位于ServiceManager中，一个位于发起请求的Client中。如果接下来有更多的Client请求该Binder，系统中就会有更多的引用指向该Binder，就象java里一个对象存在多个引用一样。而且类似的这些指向Binder的引用是强类型，从而确保只要有引用Binder实体就不会被释放掉。通过以上过程可以看出，ServiceManager象个火车票代售点，收集了所有火车的车票，可以通过它购买到乘坐各趟火车的票-得到某个Binder的引用。

注:除了实名binder还有 匿名 Binder
并不是所有Binder都需要注册给ServiceManager广而告之的。Server端可以通过已经建立的Binder连接将创建的Binder实体传给Client，当然这条已经建立的Binder连接必须是通过实名Binder实现。由于这个Binder没有向ServiceManager注册名字，所以是个匿名Binder。Client将会收到这个匿名Binder的引用，通过这个引用向位于Server中的实体发送请求。匿名Binder为通信双方建立一条私密通道，只要Server没有把匿名Binder发给别的进程，别的进程就无法通过穷举或猜测等任何方式获得该Binder的引用，向该Binder发送请求。

本文只做个粗解.详细底层内核源码可以参考罗老师的微博
http://blog.csdn.net/luoshengyang/article/details/6618363/