以前使用到AIDL的时候感觉操作是蛮简单的,原理好像一点看不懂,后来才发现,原来原理这么复杂,怪不得光看代码看不懂。。。。。。
没办法,UML图画的太丑。。
一、先来讲讲Android进程之间的通信
差不多就是这样的一个图,进程间通信都得通过一个单一IBinder接口,Android框架在Client端放了一个BinderProxy,在服务端放了一个Binder,Binder实现了IBinder接口,而BinderProxy又是Binder的子类。其中Binder实现类中有4个比较重要的方法提下:
1.init():在类初始化的时候调用,本地方法,用来与底层的c/c++沟通,传递对象的地址(指针)
2.transact():java层使用的代码,主要内容是调用onTransact()
3.execTransact():c/c++使用的代码,也是调用onTransact()
4.onTransact():这个方法可以由Binder的子类来重写,在用到的时候会自动回调。
在Android中每个进程都是在不同的dalvikvm上运行的,所以不同的进程间是无法靠java代码通信的。这就要用到底层的c代码,Linux驱动,这里只要先记住MyActivity端的ServiceConnection 类中方法的IBinder对象其实是一个BinderProxy对象(可以用service.getClass().getName()打印出来看看),在服务端也有个自定义的MyBinder对象(准确的说是Service中onBInd()方法中返回的那个对象),当调用到BinderProxy的transact方法时,通过底层的代码,最终会调用到MyBinder中的onTransact方法。
二、AIDL是干嘛的呢?
AIDL其实就是为了方便,将上面的东西给封装起来了,AP开发者不用知道有BinderProxy这个东西,也不用知道transact这个方法,只要调用这边接口的方法,那边实现类的方法就会执行了。
还记得AIDL的Stub中有个anInterface方法,这个方法就是将IBinder对象放入到了他的Proxy中,为什么呢,因为他的Proxy不管做什么事,都要用到transact方法,而这个方法当然得有传回来的这个Ibinder对象来执行,所以结构就应该是Proxy中有个IBinder属性。
再来看看上图。IFakerAIDL用来模拟aidl文件,都是一个接口,图中的FakeBinder与FakeProxy实现了这个接口,其中FakeBinder是一个抽象类,具体的方法由用户自定义。当AP开发者调用了FakeProxy中的doSomeThing的时候,框架就自动去调用了IBinder中的transact方法(2,3),然后又会调用到onTransact方法(4),还记得之前说过,先记住框架的底层会帮助我们,最终调用到进程另外一端的onTransact方