在前面的小节中，使用CC编写了hello服务，并且注册使用了这个服务，我们编写的代码十分的简单，那是因为我们利用了别人制作好的类，为了我们的程序更加容易的使用binder系统，别人实现了很多类。该小节我们分析这些类的内部机制，不管这些类多么的复杂，其最终都是使用binder驱动进行通信。在这之前我们需要回顾一下，因应用程序如何使用binder驱动完成进程间的通信。这些知识在前面都已经进行了详细的讲解，现在我们只做简单的回顾。
假设有一个这样的应以场景：
test_server提供Hello服务与Goodbye服务，test_client使用这些服务。其过程涉及到三个应用程序，test_server，test_client以及service_maneger。
首先是test_server通过addserver向service_maneger注册服务，然后是test_client从service_maneger获取服务，然后test_client与test_server就能直接通信了，下面我们看看这3个应用程序驱动的调用过程，下面是一张流程框图：
test_server
1.addserver：
a. test_client会为每一个服务构造一个flat_binder_object结构体，定义如下：
struct flat_binder_object {
struct binder_object_header hdr;
__u32 flags;
/* 8 bytes of data. */
union {
binder_uintptr_t binder; /* local object */
__u32 handle; /* remote object */
};
/* extra data associated with local object */
binder_uintptr_t cookie;
};
对于不同的服务，他们主要的区别在于binder，cookie的不同，即可以通过binder，cookie区分不同的服务
b. 调用ioctl发送数据，这些数据包括了flat_binder_object机构提，以及服务的名字，以及目的
（handle：service_maneger进程）。
c. 驱动程序对每一个flat_binder_object构造一个binder_node节点，其中的ptr成员，来自flat_binder_object.cookie与binder。
d. 驱动程序根据handle=0，找到service_maneger进程，把这些数据发发送给service_maneger，
并且创建buder_ref结构体，
e.
service_maneger
在binder驱动中中，对每个服务都存在一个binder_ref结构体，这些结构体合成一个链表，binder_ref包括
desc与node成员，node成员指向与服务对应的binder_node结构体，
在应用层，存在一个svclist链表，每个svclist包含了name（如：hello）以及对应的handle。这里handle与驱动的desc相同。
test_client
1.通过getService获取服务
test_client首先构建数据，数据包括服务名称，以及目的（handlr=0），然后调用ioctl发送数据。进
入驱动程序，根据handle=0，找到service_maneger，把数据给service_maneger。service_maneger
从svclist链表中，根据name找到对应的一项，得到handle，然后service_maneger调用ioctl返回数
据，该些数据中包括了，flat_binder_object。service_maneger调用ioctl之后，进入启动程序，
驱动程序中发送的数据包括了flat_binder_object。其成员type表示应用，根据传入的handlr找到
binder_ref，再找到binder_node，然后为test_client也将建立binder_ref。
testService接收到数据之后，