android IPC机制讲解(三)

ok，接android IPC机制讲解(二)继续

可以看到IBookManager.aidl系统为我们生成了IBookManager.java这个类，他继承了IInterface这个接口。具体看代码，首先，他申明了两个方法getBookList和addBook，显然这就是我们再IBookManager.aidl中所申明的方法。同时他还申明了两个整型的id分别用于标识这两个方法。这两个id用于标识在transact过程中客户端请求的到底是哪个方法。接着，他申明了一个内部类Stub，这个Stub就是一个Binder类，当客户端和服务器都位于同一个进程时，方法调用不会走跨进程的transact过程，而当两者位于不用进程的时候，方法调用需要走transacthi赔偿金额美好，这个逻辑由Stub的内部代理类Proxy来完成，这么看来，IBookManager这个接口的确很简单，但是我们 应该认识到这个接口的核心实现就是他的内部类Stub和Stub的内部代理Proxy

DESCRIPTOR

Binder的唯一标识，一般用当前Binder的类名标识，例如"包名"+“.IBookManager”

asInterface(android.os.IBinder obj)

用于服务端的Binder对象转换成客户端所需要的AIDL接口类型的对象，这种转换是区分进程的，如果客户端和服务端位于同一进程，那么此方法返回的就是服务端的Stub对象本身，否则返回的是系统封装后的Stub.proxy对象

asBinder

此方法用于返回当前Binder对象

onTransact

这个方法运行在服务端中的Binder线程池中，当客户端发起跨进程请求时，远程请求会通过系统底层封装后交由此方法来处理。该方法的原型是public boolean onTransact(int code, android.os.Parcel data, android.os.Parcel reply, int flags)  服务端通过code可以确定客户端所请求的目标方法是什么，接着从data中去除目标方法所需参数，然后执行目标方法。当目标方法执行完成之后，就向reply中写入返回值，onTransact方法的执行过程就是这样的。需要注意的是，如果此方法返回false，那么客户端的请求会失败，因此，我们可以利用这个特性。来做权限验证，毕竟我们也不希望随便一个进程都能远程调用我们的服务。

Proxy#getBookList

这个方法运行在客户端，当客户端远程调用此方法，他的内部实现是这样的，首先创建该方法所需要的输入型Parcel对象_data,输出型Parcel对象_reply和返回值对象List，然后把该方法的参数信息写入_data中，接着调用tracsact方法来发起RPC（远程调用）请求，同时当前线程挂起，然后服务端的onTransact方法会被调用，知道RPC过程返回后，当前线程继续执行，并从_reply中取出RPC过程的返回结果，最后返回_reply中的数据

Proxy#addBook

这个方法也是在客户端，其执行的方式和getBookList是类似的。

上述的分析中还需要注意的地方，首先，当客户端发起远程请求时，由于当前线程会被挂起直至服务端进程返回数据，所以如果一个远程方法是很耗时的，那么不能再UI线程中发起此远程请求，其次，由于服务端Binder方法运行在Binder的线程池中。为了更好的说明Binder。下面给出一个Binder的工作机制图:

楼主第一次画图，比较挫哈，不过也能凑合看吧。

从上述分析过程来看，我们完全可以不提供AIDL文件即可实现Binder，之所以提供AIDL文件，是为了方便系统为我们生成代码，系统根据AIDL文件生成Java文件的格式是固定的，我们可以抛开AIDL文件直接写一个Binder出来，接下来我们就介绍如何手动写一个Binder。

首先，他本身是一