您的位置:首页 > 其它

Binder原理 2012.11.5

2012-11-05 10:26 483 查看
http://www.cnblogs.com/linucos/archive/2012/05/24/2516623.html 详细介绍

http://blog.csdn.net/luoshengyang/article/details/6567257 很多好文章推荐大家,基本都是Android一些深层次的原来博文!

1概述

Binder是基于OpenBinder,在Android系统上使用的进程间通信机制。
Binder基于Client-Server通信模式,本质上可以理解为它实现了Client对Server对象的远程调用。比如,有某个binder对象A位于Server中,该对象提供了一套函数用以实现对服务的请求,而在一个或多个Client中包含对象A的引用,Client通过该引用可以调用远端Server中对象A的接口函数,这种远端调用对Client而言,与调用本地对象并无区别。

2 通信模型

Binder机制定义了四个组件,分别是Client,Server,ServiceManager和binder驱动,其中Client,Server,ServiceManager运行于用户空间,binder驱动运行于内核空间。



binder驱动

binder驱动是内核中的一个字符设备驱动/dev/binder,它是整个Binder通信机制的核心。Client,Server,ServiceManager通过open()和ioctl()文件操作函数与binder驱动进行通信,从而实现了Client向Server发送请求,Server处理请求并返回结果到Client。具体来说,它负责进程之间Binder通信的建立,Binder在进程之间的传递,Binder引用计数管理,数据包在进程之间的传递和交互等一系列底层支持。

ServiceManager

ServiceManager是一个守护进程,负责管理服务,即所有的Server需要向ServiceManager注册服务。同时,ServiceManager向Client提供查询和获取Server的接口。

3 binder通信实例

实现一个binder通信实例,需要经过以下步骤:

(1)获得ServiceManager的对象引用
(2)向ServiceManager注册新的Service
(3)在Client中通过ServiceManager获得Service对象引用
(3)在Client中发送请求,由Service返回结果。

下面进行详细讲述Android Binder机制问题,Binder机制是通过驱动的形式来实现,其实驱动程序的部分是保存在源代码的以下的文件中。

Android Binder机制大部分都是使用的IPC,进程间通信机制有很多种,例如linux中可以采用管道,消息队列,信号,共享内存,socket等,这些都可以实现进程间的通信。
Android Binder机制通信是基于Service与Client的,有一个ServiceManager的守 护进程管理着系统的各个服务,它负责监听是否有其他程序向其发送请求。如果有请求就响应。每个服务都要在ServiceManager中注册,而请求服务 的客户端去ServiceManager请求服务。
binder的通信操作类似线程迁移(thread migration),binder的用户空间为每一个进程维护着一个可用的线程池, 用来处理到来的IPC以及执行本地消息。两个进程间通信就好像是一个进程进入另一个进程执行代码然后带着执行的结果返回,Android和驱动程序通信采用linux的ioctl机制。下面先简单介绍一下ioctl机制。
什么是ioctl
ioctl是设备驱动程序中对设备的I/O通道进行管理的函数。所谓对I/O通道进行管理,就是对设备的一些特性进行控制,例如串口的传输波特率、 马达的转速等等。它的调用函数如下:int ioctl(int fd, ind cmd, …);其中fd就是用户程序打开设备时使用open函数返回的文件标示符,cmd就是用户程序对设备的控制命令,至于后面的省略号。
那是一些补充参数,一般最多一个,有或没有是和cmd的意义相关的。ioctl函数是文件结构中的一个属性分量。就是说如果你的驱动程序提供了对ioctl的支持,用户就可以在用户程序中使用ioctl函数控制设备的I/O通道。
ioctl的必要性
如果不用ioctl的话,也可以实现对设备I/O通道的控制,但那就太复杂了。例如,我们可以在驱动程序中实现write的时候检查一下是否有特殊 约定的数据流通过。如果有的话,那么后面就跟着控制命令(一般在socket编程中常常这样做)。但是如果这样做的话,会导致代码分工不明,程序结构混 乱。
程序员自己也会头昏眼花的。所以,我们就使用ioctl来实现控制的功能。要记住,用户程序所作的只是通过命令码告诉驱动程序它想做什么,至于怎么解释这些命令和怎么实现这些命令,这都是驱动程序要做的事情。
Android Binder机制如 何实现在驱动程序中实现的ioctl函数体内,实际上是有一个switch{case}结构,每一个case对应一个命令码,做出一些相应的操作。怎么实 现这些操作,这是每一个程序员自己的事情,因为设备都是特定的。关键在于怎么样组织命令码,因为在ioctl中命令码是唯一联系用户程序命令和驱动程序支 持的途径。命令码的组织是有一些讲究的。
因为我们一定要做到命令和设备是一一对应的,这样才不会将正确的命令发给错误的设备,或者是把错误的命令发给正确的设备。或者是把错误的命令发给错误的设备。这些错误都会导致不可预料的事情发生,而当程序员发现了这些奇怪的事情的时候,再来调试程序查找错误,那将是非常困难的事情。

第一部分 Binder的组成

1.1 驱动程序部分驱动程序的部分在以下的文件夹中:
Java代码

kernel/include/linux/binder.h

kernel/drivers/android/binder.c

binder驱动程序是一个miscdevice,主设备号为10,此设备号使用动态获得(MISC_DYNAMIC_MINOR),其设备的节点为:

/dev/binder

binder驱动程序会在proc文件系统中建立自己的信息,其文件夹为/proc/binder,其中包含如下内容:

proc目录:调用Binder各个进程的内容

state文件:使用函数binder_read_proc_state

stats文件:使用函数binder_read_proc_stats

transactions文件:使用函数binder_read_proc_transactions

transaction_log文件:使用函数binder_read_proc_transaction_log,其参数为binder_transaction_log (类型为struct binder_transaction_log)

failed_transaction_log文件:使用函数binder_read_proc_transaction_log 其参数为

binder_transaction_log_failed (类型为struct binder_transaction_log)

在binder文件被打开后,其私有数据(private_data)的类型:

struct binder_proc

在这个数据结构中,主要包含了当前进程、进程ID、内存映射信息、Binder的统计信息和线程信息等。

在用户空间对Binder驱动程序进行控制主要使用的接口是mmap、poll和ioctl,ioctl主要使用的ID为:
Java代码

#define BINDER_WRITE_READ _IOWR('b', 1, struct binder_write_read)

#define BINDER_SET_IDLE_TIMEOUT _IOW('b', 3, int64_t)

#define BINDER_SET_MAX_THREADS _IOW('b', 5, size_t)

#define BINDER_SET_IDLE_PRIORITY _IOW('b', 6, int)

#define BINDER_SET_CONTEXT_MGR _IOW('b', 7, int)

#define BINDER_THREAD_EXIT _IOW('b', 8, int)

#define BINDER_VERSION _IOWR('b', 9, struct binder_version)

BR_XXX等宏为BinderDriverReturnProtocol,表示Binder驱动返回协议。

BC_XXX等宏为BinderDriverCommandProtocol,表示Binder驱动命令协议。

binder_thread是Binder驱动程序中使用的另外一个重要的数据结构,数据结构的定义如下所示:
Java代码

struct binder_thread {

struct binder_proc *proc;

struct rb_node rb_node;

int pid;

int looper;

struct binder_transaction *transaction_stack;

struct list_head todo;

uint32_t return_error;

uint32_t return_error2;

wait_queue_head_t wait;

struct binder_stats stats;

};

binder_thread 的各个成员信息是从rb_node中得出。

BINDER_WRITE_READ是最重要的ioctl,它使用一个数据结构binder_write_read定义读写的数据。
Java代码

struct binder_write_read {

signed long write_size;

signed long write_consumed;

unsigned long write_buffer;

signed long read_size;

signed long read_consumed;

unsigned long read_buffer;

};

1.2 servicemanager部分 servicemanager是一个守护进程,用于这个进程的和/dev/binder通讯,从而达到管理系统中各个服务的作用。

可执行程序的路径:

/system/bin/servicemanager

开源版本文件的路径:
Java代码

frameworks/base/cmds/servicemanager/binder.h

frameworks/base/cmds/servicemanager/binder.c

frameworks/base/cmds/servicemanager/service_manager.c

程序执行的流程:

open():打开binder驱动

mmap():映射一个128*1024字节的内存

ioctl(BINDER_SET_CONTEXT_MGR):设置上下文为mgr

进入主循环binder_loop()

ioctl(BINDER_WRITE_READ),读取

binder_parse()进入binder处理过程循环处理

binder_parse()的处理,调用返回值:

当处理BR_TRANSACTION的时候,调用svcmgr_handler()处理增加服务、检查服务等工作。各种服务存放在一个链表(svclist)中。其中调用binder_等开头的函数,又会调用ioctl的各种命令。

处理BR_REPLY的时候,填充binder_io类型的数据结

1.3 binder的库的部分

binder相关的文件作为Android的uitls库的一部分,这个库编译后的名称为libutils.so,是Android系统中的一个公共库。

主要文件的路径如下所示:
Java代码

frameworks/base/include/utils/*

frameworks/base/libs/utils/*

主要的类为:

RefBase.h :

引用计数,定义类RefBase。

Parcel.h :

为在IPC中传输的数据定义容器,定义类Parcel

IBinder.h:

Binder对象的抽象接口, 定义类IBinder

Binder.h:

Binder对象的基本功能, 定义类Binder和BpRefBase

BpBinder.h:

BpBinder的功能,定义类BpBinder

IInterface.h:

为抽象经过Binder的接口定义通用类,

定义类IInterface,类模板BnInterface,类模板BpInterface

ProcessState.h

表示进程状态的类,定义类ProcessState

IPCThreadState.h

表示IPC线程的状态,定义类IPCThreadState

各个类之间的关系如下所示:

在IInterface.h中定义的BnInterface和BpInterface是两个重要的模版,这是为各种程序中使用的。

BnInterface模版的定义如下所示:
Java代码

template

class BnInterface : public INTERFACE, public BBinder

{

public:

virtual sp queryLocalInterface(const String16& _descriptor);

virtual String16 getInterfaceDescriptor() const;

protected:

virtual IBinder* onAsBinder();

};

BnInterface模版的定义如下所示:

template

class BpInterface : public INTERFACE, public BpRefBase

{

public:

BpInterface(const sp& remote);

protected:

virtual IBinder* onAsBinder();

};

这两个模版在使用的时候,起到得作用实际上都是双继承:使用者定义一个接口INTERFACE,然后使用BnInterface和BpInterface两个模版结合自己的接口,构建自己的BnXXX和BpXXX两个类。

DECLARE_META_INTERFACE和IMPLEMENT_META_INTERFACE两个宏用于帮助BpXXX类的实现:
Java代码

#define DECLARE_META_INTERFACE(INTERFACE) \

static const String16 descriptor; \

static sp asInterface(const sp& obj); \

virtual String16 getInterfaceDescriptor() const; \

#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \

const String16 I##INTERFACE::descriptor(NAME); \

String16 I##INTERFACE::getInterfaceDescriptor() const { \

return I##INTERFACE::descriptor; \

} \

sp I##INTERFACE::asInterface(const sp& obj) \

{ \

sp intr; \

if (obj != NULL) { \

intr = static_cast( \

obj->queryLocalInterface( \

I##INTERFACE::descriptor).get()); \

if (intr == NULL) { \

intr = new Bp##INTERFACE(obj); \

} \

} \

return intr; \

}

在定义自己的类的时候,只需要使用DECLARE_META_INTERFACE和IMPLEMENT_META_INTERFACE两个接口,并

结合类的名称,就可以实现BpInterface中的asInterface()和getInterfaceDescriptor()两个函数。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  binder