iBinder android binder

参考：http://www.360doc.com/content/10/1227/14/4525948_81732732.shtml

iBinder介面与AIDL介面：

iBinder只提供了单一函数transact来进行远距离通信，呼叫不方便，如SipService中有多个函数，客户端呼叫不方便；AIDL提供Proxy/Stub结构化解这个问题。

在开始本章之前，先向大家介绍COM的一个概念---------Proxy/Stub结构（代理/存根结构）

打个比方，你到自动取款机上去取款；你就是客户，取款机就是你的代理；你不会在乎钱具体放在那里，你只想看到足够或更多的钱从出口出来（这就是com的透明性）。你同银行之间的操作完全是取款机代理实现。你的取款请求通过取款机，传到另一头，银行的服务器，他也没有必要知道你在哪儿取钱，他所关心的是你的身份，和你取款多少。当他确认你的权限，就进行相应的操作，返回操作结果给取款机，取款机根据服务器返回结果，从保险柜里取出相应数量的钱给你。你取出卡后，操作完成。取款机不是直接同服务器连接的，他们之间还有一个“存根”，取款机与存根通信，服务器与存根通信。从某种意义上说存根就是服务器的代理。（参考COM代理与存根）

AIDLFramework层的架构，如下图：

换而言之，Android就是在传统的C/S架构中加入了一层，实现IPC。图中表明，AIDL类似COM的Proxy/Stub架构。不过是现在android自己的序列化类Pacel。

看过源代码，我们不难发现上图中对应的角色：

Client ------StorageManager

Proxy ------IMountServie.Stub.Proxy

Parcel------对象序列化类，数据只有继承Parcelable才能进行RPC

Stub ------IMountService.Stub

Server ------MountService

当StorageManager调用MountService方法时，例如调用registerListener，步骤如下：

²进入IMountServie.Stub.Proxy找到对应的方法registerListener。

²IMountServie.Stub.ProxyregisterListener利用Parcel将函数调用的序列化为android理解的结构

²调用onTransact函数，onTransact根据参数，找到对应registerListenerSwitch-case语句执行

²数据通过Binder机制进行写操作，客户端调用阻塞，等待服务端reply

²服务端处理完request返回

²客户端取回数据

当service经常被远程调用时，我们常常用到aidl来定一个接口供service和client来使用，这个其实就是使用Binder机制的IPC通信。当clientbindservice成功之后，系统AM会调用回调函数onServiceConnected将service的IBinder传递给client，client再通过调用aidl生成的asInterface()方法获得service的调用接口，此时一个bind过程结束了，我们在client端就可以远程调用service的方法了。例如

public void onServiceConnected(ComponentNameclassName,

IBinder service) {

mSecondaryService =ISecondary.Stub.asInterface(service);

}

IBinder接口是对跨进程的对象的抽象。普通对象在当前进程可以访问，如果希望对象能被其它进程访问，那就必须实现IBinder接口。IBinder接口可以指向本地对象，也可以指向远程对象，调用者不需要关心指向的对象是本地的还是远程。

transact是IBinder接口中一个比较重要的函数，它的函数原型如下：

viewplain

1.virtualstatus_ttransact(uint32_tcode,constParcel&data,Parcel*reply,uint32_tflags

android中的IPC的基本模型是基于客户/服务器(C/S)架构的。

如果IBinder指向的是一个客户端代理，那transact只是把请求发送给服务器。服务端的IBinder的transact则提供了实际的服务。

客户端

BpBinder是远程对象在当前进程的代理，它实现了IBinder接口。

这里transact把请求经内核模块发送了给服务端，服务端处理完请求之后，沿原路返回结果给调用者。这里也可以看出请求是同步操作，它会等待直到结果返回为止。

在BpBinder之上进行简单包装，我们可以得到与服务对象相同的接口，调用者无需要关心调用的对象是远程的还是本地的。

服务端

服务端也要实现IBinder接口，BBinder类对IBinder接口提供了部分默认实现

其它的请求交给onTransact处理。onTransact是BBinder里声明的一个protected类型的虚函数，这个要求它的子类去实现。

由此可见，服务端的onTransact是一个请求分发函数，它根据请求码(code)做相应的处理。

消息循环

服务端(任何进程都可以作为服务端)有一个线程监听来自客户端的请求，并循环处理这些请求。

内核模块

android使用了一个内核模块binder来中转各个进程之间的消息。模块源代码放在binder.c里，它是一个字符驱动程序，主要通过binder_ioctl与用户空间的进程交换数据。其中BINDER_WRITE_READ用来读写数据，数据包中有一个cmd域用于区分不同的请求：

1. binder_thread_write用于发送请求或返回结果。
2. binder_thread_read用于读取结果。

从binder_thread_write中调用binder_transaction中转请求和返回结果，binder_transaction的实现如下：

对请求的处理：

1. 通过对象的handle找到对象所在的进程，如果handle为空就认为对象是context_mgr，把请求发给context_mgr所在的进程。
2. 把请求中所有的binder对象全部放到一个RB树中。
3. 把请求放到目标进程的队列中，等待目标进程读取。

如何得到服务对象的handle

1. 服务提供者通过defaultServiceManager得到ServiceManager对象，然后调用addService向服务管理器注册。
2. 服务使用者通过defaultServiceManager得到ServiceManager对象，然后调用getService通过服务名称查找到服务对象的handle。

如何通过服务对象的handle找到服务所在的进程

表示服务管理器的handle，getService可以查找到系统服务的handle。这个handle只是代表了服务对象，内核模块是如何通过handle找到服务所在的进程的呢？

1. 对于ServiceManager:ServiceManager调用了binder_become_context_manager使用自己成为context_mgr，所有handle为0的请求都会被转发给ServiceManager。
2. 对于系统服务和应用程序的Listener，在第一次请求内核模块时(比如调用addService)，内核模块在一个RB树中建立了服务对象和进程的对应关系。
3. 请求服务时，内核先通过handle找到对应的进程，然后把请求放到服务进程的队列中。

爱华网本文地址 » http://www.413yy.cn/a/25101017/365754.html