先学习一下AIDL,仔细看下面这篇文章就大概明白了。aidl其实就是对Binder和序列化反、序列化的封装,这样方便开发者开发。Binder虽说是用在跨进程调用的,可是也是可以用在一个进程中的,而且很常用,看这篇文章Android中bindService的使用及Service生命周期。aidl也是可以用在一个进程中的,只要Service不设置其它进程就行,这个时候获取到的Binder是一个本地接口实现,如果Service在另一个进行,Binder是远程的,需要采用Stub.asInterface,转换成本地代理Proxy才可以正常使用。
我们知道可以采用AIDL来实现进程间通信,AIDL其实对Binder机制的封装,让程序远少写一些通用的代码。
AIDL会帮我们生成一个接口,以IBookManager为例,接口里面有个 static abstract的Stub类,Stub继承自Binder实现了IBookManager接口,Stub里面有个static Proxy类,Proxy也实现了IBookManager接口。
服务端继承Stub类,这个类的实例mBookManager就是Service的onBind中要“返回”给客户端的,如果同一个进程在客户端的onServiceConnected中返回的IBinder就是mBookManager,这样调用的方法就是本地方法。如果不在同一个进程中,我觉得onServiceConnected中返回的IBinder是一个新的对象(Binder底层机制不了解),然后需要通过IBookManager.Stub.asInterface方法给封装成Proxy类对象,这样客户端通过Proxy类对象调用,内部通过Binder远程调用,对上层是透明的(Binder 采用transact-onTransact机制)。
从高层次来看,服务端对外暴露的是一个IBookManager的接口而已。
AIDL采用代理-桩(proxy-stub)的模式,服务端stub,客户端是proxy。
看了上面两篇文章,对Binder机制就有了一定的认识,我们看看系统是怎么使用Binder的,我们以ActivityManagerService为例
ActivityManagerService 继承自ActivityManagerNative,ActivityManagerNative继承自Binder实现了IActivityManager接口,IActivityManager实现了IInterface。
看,这是不是就是类似AIDL给我生成的Binder呀,确实是这样,ActivityManagerNative类似于Stub,IActivityManager就是要对外暴露的接口,ActivityManagerService类似于对Stub子类。
注意:上面说的ActivityManagerService这套东西是7.0源码,从8.0开始,用aidl重写了AMS。
ActiivtyManagerService系统对外提供的“服务”,说是“服务”,其实说成Binder更准确,使用Binder就可以rpc了。
以8.0为例,我们上层可以这样获取AMS,ActivityManage.getService(),看下面的代码:其实还是AIDL的那套,ServiceManager.getService("activity")获取到IBinder,类似于onServiceConnected中返回的IBinder,通过IActivityManager.Stub.asInterface接口,返回是代理对象还是本地对象。
4216 public static IActivityManager getService() {
4217 return IActivityManagerSingleton.get();
4218 }
4219
4220 private static final Singleton<IActivityManager> IActivityManagerSingleton =
4221 new Singleton<IActivityManager>() {
4222 @Override
4223 protected IActivityManager create() {
4224 final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
4225 final IActivityManager am = IActivityManager.Stub.asInterface(b);
4226 return am;
4227 }
4228 };