service与serviceManager之间的通信也是跨进程通信?
这个好象不是喔，因为WindowManager与WindowManagerSerivce都是在system_server进程
而Binder就是进程通信的中转站。下文会提到
系统的service 的binder实现方式大多是用AIDL，而应用层去调用远程服务时是通过对应的Manager来作为中间人，这个过程有没有体现出IPC进程通信的呢？（这还不能确定，因为不知道各manager是否与App处于不同的进程）
而确定的是在ServiceManger在获取相应的service远程Binder对象这个过程中是IPC通信，因为ServiceManger和各个service肯定是在不同的进程，代码如下：
registerService(Context.ALARM_SERVICE, AlarmManager.class,
new CachedServiceFetcher<AlarmManager>() {
@Override
public AlarmManager createService(ContextImpl ctx) {
//下面这句体现IPC通信
IBinder b = ServiceManager.getService(Context.ALARM_SERVICE);
IAlarmManager service = IAlarmManager.Stub.asInterface(b);
return new AlarmManager(service, ctx);
}});
以AlarmManagerService为例，说明一下AlarmManager，AlarmManagerService，IAlarmManager，Stub，Proxy，onTransact()，transact()之间的关系：
读懂了AlarmManagerService这个Binder例子，其他的都是依葫芦画瓢。
首先奉上自己画的UML图一张
其实按照AIDL生成的文件中的Stub类只是一个抽象类，stub实现了IAlarmManager接口，该IAlarmManager接口中定义了AlarmManagerService应该要提供的功能函数，所以说到底Stub类还只是一个上层封装的一个功能模板，具体实现还是要有一个子类去实现，而这个子类就是AlarmManagerService，AlarmManagerService继承了Stub类并且实现了IAlarmManager接口，重写了IAlarmManager接口的各个功能函数的具体业务逻辑实现，
然后这个Stub有个内部类Proxy，这个Proxy也是实现了IAlarmManager接口，这个Proxy内部类也实现了IAlarmManager接口的功能函数，但是这种函数实现方式并不是具体业务逻辑实现，而只是利用transact函数，将远程客户端调用者提供的参数传送给服务端的具体实现者，也就是AlarmManagerService中的对应的具体函数实现，以setTimeZone为例：
public void setTimeZone(String zone) throws RemoteException {
Parcel _data = Parcel.obtain();//传送给服务端的数据
Parcel _reply = Parcel.obtain();//服务端返回给客户端的数据
try {
_data.writeInterfaceToken("android.app.IAlarmManager");
_data.writeString(zone);
//传送关键
this.mRemote.transact(3, _data, _reply, 0);
//mRemote是什么呢？请看下文
_reply.readException();
} finally {
_reply.recycle();
_data.recycle();
}
}
说到这不得不说在Stub中定义的onTransact()函数，上面说到Proxy的各个IAlarmManager接口的功能函数利用transact函数，将远程客户端调用者提供的参数传送给服务端的具体实现者，那么在服务端的接受者就是onTransact()函数，在onTransact()函数中利用switch与case的分发将远程传过来的参数精准调用对应的具体实现函数，而这个具体实现函数是由AlarmManagerService实现的,以下是setTimeZone对应的case代码：
case 3:
data.enforceInterface("android.app.IAlarmManager");
String _arg02 = data.readString();
//因为在Stub中的setTimeZone()是抽象的，所以具体是由AlarmManagerService实现的，当然这里调用的也是AlarmManagerService的setTimeZone()
this.setTimeZone(_arg02);
//因为这个函数不需要给客户端反馈数据，所以就直接调用这句。
reply.writeNoException();
return true;
至于AlarmManager就是暴露给应用层调用的角色，因为在AlarmManager中持有AlarmManagerService的Proxy引用，其实这个Proxy的实质是IAlarmManager对象。根据上面分析所得就可以层层调用到服务端的具体实现。
上文说到在Proxy中有一个mRemote对象，这个mRemote的定义是一个IBinder类型，而且在Proxy的setTimeZone()方法中这个mRemote还调用了transact()函数，代码如下：
this.mRemote.transact(3, _data, _reply, 0);
我们先从transact()函数入手，直接按代码跳转发现，此方法来自IBinder，据上面的UML图可也知transact()函数确实最早定义在IBinder接口，后来被Binder类实现并且重写该方法，transact()重写如下：
public final boolean transact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {
if(data != null) {
data.setDataPosition(0);
}
boolean r = this.onTransact(code, data, reply, flags);
if(reply != null) {
reply.setDataPosition(0);
}
return r;
}
可以看到在transact()会调用onTransact()函数，b对象是IBinder类型，Binder实现了IBinder，重写了transact()，Stub继承于Binder，自然也继承了Binder中transact()，而且它还重写了Binder中的onTransact()函数，那么可以说IBinder是Stub类的上转型对象，也可以说IBinder是Binder类的上转型对象。这可以写个demo验证一下这个上转型关系喔！反正我验证通过了。那么问题来了，因为从transact()的实现来说，并不能知道这个IBinder b上转型对象的具体实现来自于谁？mRemote的实质是什么？
既然不能确定这个，那我们就从IBinder b的赋值入手吧，接下来就开始追踪把 》》》
首先mRemote是在Proxy的构造函数赋值的，
Proxy(IBinder remote) {this.mRemote = remote;}
而Proxy的构造函数又在哪被调用传进参数呢？这里直接按代码跳转竟然是找不到的，那么这里就要讲到SystemServicesRegistry.java中的registerService()函数，代码如下：
IBinder b = ServiceManager.getService(Context.ALARM_SERVICE);
IAlarmManager service = IAlarmManager.Stub.asInterface(b);
我们点进去Stub的asInterface()函数，代码如下：
public static IAlarmManager asInterface(IBinder obj) {
if(obj == null) {
return null;
} else {
IInterface iin = obj.queryLocalInterface("android.app.IAlarmManager");
return (IAlarmManager)(iin != null && iin instanceof IAlarmManager?(IAlarmManager)iin:new IAlarmManager.Stub.Proxy(obj));
}
}
Proxy的构造函数就是在这里调用的，可以看到传进去Proxy构造函数的参数就是obj，而obj就是asInterface函数的参数 obj，也是ServiceManager.getService(Context.ALARM_SERVICE)得到的IBinder b。
ServiceManager.getService(Context.ALARM_SERVICE)返回的就是Stub类的引用，为什么呢？因为上文可知IBinder可以是Binder或者Stub的上转型对象，所以这里的b引用有可能是两者其一，但是从下面代码可知，是用惟一的名字Context.ALARM_SERVICE作为参数，那自然得到的IBinder b就是具体的实现，所以就排除了Binder。
到这里就可以知道了mRemote的实质是Stub。
IBinder b = ServiceManager.getService(Context.ALARM_SERVICE);
其实Binder就是核心类，正因为它有transact()与onTransact()，这两个函数就是客户端代理proxy与服务端Stub的中转站，客户端与服务端进程通信时的函数参数转换就是在这两个方法实现的，也可以说是转换的地方！
