Binder机制（4）

纯Native的Service

纯Native的Service表示代码都在Native层。Native层有很多Service，前面的MS不就是一个重量级的吗？

假设Service叫ITest，我们该如何实现呢？完全可以模仿MS！具体实现过程如下所示：

Test是怎么定义的呢？我们是跨进程的C/S，所以本地需要一个BnTest，对端需要提供一个代理BpTest。为了不暴露Bp的身份，Bp的定义和实现在放在BnTest.cpp中了。

1. 我能干什么

ITest接口表明了它所提供的服务，例如getTest和setTest等，这个与业务逻辑相关，代码如下所示：

2. 定义BnTest和BpTest

为了把ITest融入到Binder系统，需要定义BnTest和对客户端透明的BpTest。BnTest定义既可以与上面的Test定义放在一块，也可以分开，如下所示：

另外，我们还要使用IMPLEMENT宏。参考BnMediaPlayerService的方法，把BnTest的BpTest的实现都放在ITest.cpp中，如下所示：

BpTest也在这里实现。如下所示：

纯Native的Service写起来量大一些，上面的代码还只是把C/S的框架写好了，真正的业务处理尚未开始，不过感觉却很踏实，很厚重。那么Java层的Service该怎么写呢？

扶得起的“阿斗”（aidl）

阿斗（aidl的谐音）本来是扶不起的，可是我们有了AIDL工具，就有可能将他扶起！

1. 我能干什么？

在Java层中，如果想要利用Binder进行跨进程的通信，也得定义一个类似ITest的接口，不过这是一个aidl文件。现在假设服务端程序都在com.test.service包中。

ITest.aidl文件的内容如下：

定义完后。如果使用Eclipse进行编译，会在gen目录下生成一个com.test.ITest.java文件（也会生在对应包结构的目录）。

2. 实现服务端：

com.test.ITest.java只是实现了类似BnTest的一个东西，具体的业务实现还需要从ITest.Stub派生，实现代码如下所示：

这时，你的Eclipse下会有如下目录：

1. src下有一个com.test.service包结构目录

2. gen下也有一个com.text.service包结构目录，其中的内容是由aidl工具生存的。

3. 实现代理端

代理端往往在另外一个程序中使用。假设是com.test.client包，把刚才com.test.service工程中的gen下的com.test.service目录全部复制到com.test.client中了。这样，client工程也就有两个包结构目录了：

1. com.test.client

2. com.test.service。 不过这个目录中仅有aidl生成的Java文件。

服务端一般驻留在Service进程中，所以可以在Client端的onServiceConnected函数中获得代理对象，实现代码如下：

4. 传递复杂的数据结构

AIDL支持简单数据结构与Java中String类型的数据进行跨进程传递，如果向做到跨进程传递复杂的数据结构，还需另做一些工作。

以ITest.aidl文件中使用的complicatedDataStructure为例：

1. 它必须实现implements Parcelable接口

2. 内部必须有一个静态的CREATOR类。

3. 定义一个coplicatedDataStructure.aidl文件

可参考Android API文档的parcelable类，里面有一个很简单的例子。

来看着个Java文件的实现：

complicatedDataStructure.aidl该怎么写呢？如下所示：

然后在使用它的aidl文件中添加下行代码即可：

有了AIDL，再看我们的阿斗是不是能扶得起了呢？当然，想让上面的程序正确工作，还得再努力，把未尽的业务层事业完成。另外，还要经得起残酷环境的考验(即通过测试来检验自己的程序)。