简单的说，这套机制是这样工作的：一开始，你用简单的IDL（界面描绘语言）声明一个你想要实现的RPC接口。然后用aidl 工具为这个声明生成一个Java接口定义，这个定义必须对本地和远程进程都可见。它包含两个内部类。内部类中有管理实现了你用IDL声明的接口的远程方法调用所需要的所有代码。两个内部类均实现了IBinder接口。一个用于系统在本地内部使用，你些的代码可以忽略它；另外一个，我们称为Stub，扩展了Binder类。除了实现了IPC调用的内部代码之外，它还包括了你声明的RPC接口中的方法的声明。一般情况下，远程过程是被一个服务所管理的（因为服务可以通知系统关于进程以及它连接到别的进程的信息）。它包含着aidl工具产生的接口文件和实现了RPC方法的Stub的子类。而客户端只需要包括aidl工具产生的接口文件。

　　下面将说明服务与其客户端之间的连接是如何建立的，更为详细的有关RPC机制的讨论和知识，读者可以参见坦尼保姆所著的《分布式系统》一书，里面有非常详细和精彩的论述：

　　1）服务的客户端（位于本地）应该实现onServiceConnected() 和onServiceDisconnected() 方法。这样，当至远程服务的连接成功建立或者断开的时候，它们会收到通知。这样它们就可以调用bindService() 来设置连接。

　　2）而服务则应该实现onBind() 方法以接受或拒绝连接。这取决于它收到的intent（intent将传递给bindService()）。如果接受了连接，它会返回一个Stub的子类的实例。

　　3）如果服务接受了连接，Android将会调用客户端的onServiceConnected()方法，并传递给它一个IBinder对象，它是由服务所管理的Stub的子类的代理。通过这个代理，客户端可以对远程服务进行调用。

　　掌握线程安全方法

　　在一些情况下，你所实现的方法有可能会被多于一个的线程所调用，所以它们必须被写成线程安全的。

　　对于我们上面所讨论的RPC机制中的可以被远程调用的方法来说，这是必须首先考虑的。如果针对一个IBinder对象中实现的方法的调用源自这个IBinder对象所在的进程时，这个方法将会在调用者的线程中执行。然而，如果这个调用源自其它的进程，则这个方法将会在一个线程池中选出的线程中运行，这个线程池由Android加以管理，并与IBinder存在于同一进程内；这个方法不会在进程的主线程内执行。反过来说，一个服务的onBind() 方法应为服务进程的主线程所调用，而实现了由onBind() 返回的对象（比如说，一个实现了RPC方法的Stub的子类）的方法将为池中的线程所调用。因为服务可以拥有多于一个的客户端，而同一时间，也会有多个池中的线程调用同一个IBinder方法。因此IBinder方法必须实现为线程安全的。

　　类似的，一个内容提供者能接受源自其它进程的请求数据。尽管ContentResolver和ContentProvider类隐藏了交互沟通过程的管理细节，ContentProvider会由query()，insert()，delete()，update()和getType()方法来相应这些请求，而这些方法也都是由那个内容提供者的进程中所包涵的线程池提供的，而不是进程的主线程本身。