Android的IPC机制Binder的各个部分

1.1 驱动 程序部分 驱动程序的部分在以下的文件夹中:
kernel/include/linux/binder.h
kernel/drivers/android/binder.c

binder
驱动程序是一个 miscdevice ,主设备号为 10 ,此设备号使用动态获得( MISC_DYNAMIC_MINOR ),其设备的节点为:
/dev/binder
    binder 驱动程序会在 proc 文件系统中建立自己的信息,其文件夹为 /proc/binde ,其中包含如下内容:
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 为:
#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驱动程序中使用的另外一个重要的数据结构,数据结构的定义如下所示:
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定义读写的数据。
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.3 binder 的库的部分
    binder 相关的文件作为 Android uitls 库的一部分,这个库编译后的名称为 libutils.so ,是 Android 系统中的一个公共库。
    主要文件的路径如下所示:
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

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

1.2 servicemanager 部分          servicemanager 是一个守护进程,用于这个进程的和 /dev/binder 通讯,从而达到管理系统中各个服务的作用。
         可执行程序的路径:
         /system/bin/ servicemanager         
开源版本文件的路径:
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 类型的数据结

第二部分 Binder的运作

   2.1 Binder的工作机制
Service Manager是一个守护进程,它负责启动各个进程之间的服务,对于相关的两个需要通讯的进程,它们通过调用 libutil.so库实现通讯,而真正通讯的机制,是内核空间中的一块共享内存

   2 .2 从应    用程序的角度看 Binder

   从应用程序的角度看 Binder 一共有三个方面:

   Native 本地:例如 BnABC,这是一个需要被继承和实现的类。
   Proxy 代理:例如 BpABC,这是一个在接口框架中被实现,但是在接口中没有体现的类。
  客户端:例如客户端得到一个接口 ABC,在调用的时候实际上被调用的是 BpABC

本地功能( Bn )部分做的:
    实现 BnABC:: BnTransact()
    注册服务: IServiceManager :: AddService
代理部分( Bp )做的:
    实现几个功能函数,调用 BpABC::remote()->transact()

客户端做的:
    获得 ABC 接口,然后调用接口(实际上调用了 BpABC ,继而通过 IPC 调用了 BnABC ,然后调用了具体的功能)

       在程序的实现过程中 BnABC BpABC 是双继承了接口 ABC 。一般来说 BpABC 是一个实现类,这个实现类不需要在接口中体现,它实际上负责的只是通讯功能,不执行具体的功能; BnABC 则是一个接口类,需要一个真正工作的类来继承、实现它,这个类才是真正执行具体功能的类。

       在客户端中,从 ISeriviceManager 中获得一个 ABC 的接口,客户端调用这个接口,实际上是在调用 BpABC ,而 BpABC 又通过 Binder IPC 机制和 BnABC 通讯, BnABC 的实现类在后面执行。

  事实上, 服务器 的具体实现和客户端是两个不同的进程,如果不考虑进程间通讯的过程,从调用者的角度,似乎客户端在直接调用另外一个进程间的函数——当然这个函数必须是接口 ABC 中定义的。

   2.3 ISericeManager的作用
      ISericeManager涉及的两个文件是 ISericeManager.h ISericeManager.cpp。这两个文件基本上是 ISericeManager ISericeManager是系统最先被启动的服务。非常值得注意的是: ISericeManager本地功能并没有使 现,它实际上由 ServiceManager守护进程执行,而用户程序通过调用 BpServiceManager来获得其他的服务。
ISericeManager.h中定义了一个接口,用于得到默认的 ISericeManager
        sp<IServiceManager> defaultServiceManager();
这时得到的 ISericeManager实际上是一个全局的 ISericeManager。 

第三部分 程序中 Binder 的具体实现

     3.1 一个利用接口的具体实现
    PermissionController也是 libutils中定义的一个有关权限控制的接口,它一共包含两个文件: IPermissionController.h IPermissionController.cpp这个结构在所有类的实现中都是类似的。
头文件 IPermissionController.h的主要内容是定义 IPermissionController接口和类 BnPermissionController
class IPermissionController : public IInterface
{
public:
DECLARE_META_INTERFACE(PermissionController);
virtual bool   checkPermission(const String16& permission,int32_t pid, int32_t uid) = 0;
enum {
CHECK_PERMISSION_TRANSACTION = IBinder::FIRST_CALL_TRANSACTION
};
};
class BnPermissionController : public BnInterface<IPermissionController>
{
public:
virtual status_t    onTransact( uint32_t code,
const Parcel& data,
Parcel* reply,
uint32_t flags = 0);
};

IPermissionController是一个接口类,只有 checkPermission()一个纯虚函数。
BnPermissionController继承了以 BnPermissionController实例化模版类 BnInterface。因 此, BnPermissionController,事实上 BnPermissionController双继承了 BBinder IPermissionController
实现文件 IPermissionController.cpp中,首先实现了一个 BpPermissionController

class BpPermissionController : public BpInterface<IPermissionController>
{
public:
BpPermissionController(const sp<IBinder>& impl)
: BpInterface<IPermissionController>(impl)
{
}
virtual bool checkPermission(const String16& permission, int32_t pid, int32_t uid)
{
Parcel data, reply;
data.writeInterfaceToken(IPermissionController::
getInterfaceDescriptor());
data.writeString16(permission);
data.writeInt32(pid);
data.writeInt32(uid);
remote()->transact(CHECK_PERMISSION_TRANSACTION, data, &reply);
if (reply.readInt32() != 0) return 0;
return reply.readInt32() != 0;
}
};
IMPLEMENT_META_INTERFACE(PermissionController, “android.os.IPermissionController”);

BpPermissionController继承了 BpInterface<IPermissionController>,它本身是一个 已经实现的类,而且并没有在接口中体现。这个类按照格式写就可以,在实现 checkPermission()函数的过程中,使用 Parcel作为传输数据 的容器,传输中时候 transact()函数,其参数需要包含枚举值 CHECK_PERMISSION_TRANSACTION IMPLEMENT_META_INTERFACE用于扶助生成。
BnPermissionController中实现的 onTransact()函数如下所示:

status_t BnPermissionController:: BnTransact(
uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
switch(code) {
case CHECK_PERMISSION_TRANSACTION: {
CHECK_INTERFACE(IPermissionController, data, reply);
String16 permission = data.readString16();
int32_t pid = data.readInt32();
int32_t uid = data.readInt32();
bool res = checkPermission(permission, pid, uid);
reply->writeInt32(0);
reply->writeInt32(res ? 1 : 0);
return NO_ERROR;
} break;
default:
return BBinder:: BnTransact(code, data, reply, flags);
}
}

onTransact()函数中根据枚举值判断数据使用的方式。注意,由于 BnPermissionController也是继承了类 IPermissionController,但是纯虚函数 checkPermission()依然没有实现。因此这个 BnPermissionController类并不能实例化,它其实也还是一个接口,需要一个实现类来继承它,那才是实现具体功能的类。

   3.2 BnABC的实现
    本地服务启动后将形成一个守护进程,具体的本地服务是由一个实现类继承 BnABC来实现的,这个服务的名称通常叫做 ABC
在其中,通常包含了一个 instantiate()函数,这个函数一般按照如下的方式实现:
void ABC::instantiate() {
defaultServiceManager()->addService(
String16(“XXX.ABC”), new ABC ());
}

    按照这种方式,通过调用 defaultServiceManager()函数,将增加一个名为 “XXX.ABC”的服务。
在这个 defaultServiceManager()函数中调用了:
ProcessState::self()->getContextObject(NULL));
IPCThreadState* ipc = IPCThreadState::self();
IPCThreadState::talkWithDriver()

ProcessState 类建立的过程中调用 open_driver()打开驱动 程序,在 talkWithDriver()的执行过程中。

   3.3 BpABC调用的实现
BpABC调用的过程主要通过 mRemote()->transact() 来传输数据, mRemote() BpRefBase的成员,它是一个 IBinder。这个调用过程如下所示:
    mRemote()->transact()
Process::self()
IPCThreadState::self()->transact()
writeTransactionData()
waitForResponse()
talkWithDriver()
ioctl(fd, BINDER_WRITE_READ, &bwr)

IPCThreadState::executeCommand()函数中,实现传输操作。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值