分析CmProcess跨进程通信的实现分析CmProcess跨进程通信的实现

一、基础知识准备

1.1、多进程
1.2、Bundle类

二、代码解析

2.1、AIDL接口
2.2、启动分析

三、EventReceiver

四、ServiceManagerNative

五、BinderProvider

六、BinderProvider 启动分析

七、MainActivity

八、TestActivity

一、基础知识准备
1.1、多进程
Android多进程概念：一般一个 app 只有一个进程，所有的 components 都运行在同一个进程中，进程名称就是 app 包名。但是每一个进程都有内存的限制，如果一个进程的内存超过了这个限制的时候就会报 OOM 错误。为了解决内存限制的问题，Android 引入了多进程的概念，将占用内存的操作放在一个单独的进程中分担主进程的压力。
多进程的好处：

分担主进程的内存压力。
常驻后台任务。
守护进程，主进程和守护进程相互监视，有一方被杀就重新启动它。
多么块，对有风险的模块放在单独进程，崩溃后不会影响主进程的运行。

多进程的缺点：

Applicaton的重新创建，每个进程有自己独立的virtual machine，每次创建新的进程就像创建一个新的Application
静态成员变量和单例模式失效，每个进程有自己独立的虚拟机，不同虚拟机在内存分配上有不同的地址空间，这就导致不同虚拟机在访问同一个对象时会产生多分副本。
SharedPreference的可靠性下降，不支持多进程
线程同步机制失效

1.2、Bundle类
bundle 定义 bundle 是一个 final 类，final 类通常功能是完整的，它们不能被继承。Java 中有许多类是 final 的，譬如 String, Interger 以及其他包装类。

public final class Bundle extends BaseBundle implements Cloneable, Parcelable

bundle 传递的数据可以是 boolean、byte、int、long、float、double、string 等基本类型或它们对应的数组，也可以是对象或对象数组。但是如果传递对象或对象数组，该对象必须实现 Serializable 或 Parcelable 接口。由 Bundle 定义我们也可以看到其实现了 Parcelable 接口，所以支持实现了Parcelable 接口的对象。
因此当我们在一个进程中启动了另外一个进程的 Activity、Service、Receiver，我们就可以在 Bundle 中附加我们需要传输给远程进程的信息（前提是能够被序列化）并通过 Intent 发送出去。

二、代码解析
2.1、AIDL接口
1、IEventReceiver：事件接收器

// 事件接受器interface IEventReceiver {// 这里的 event 是 bundle 类型void onEventReceive(String key,in Bundle event); }

2、IPCCallback：看名字也可以看出来是跨进程 callback

interface IPCCallback {// result 也是 bundlevoid onSuccess(in Bundle result); void onFail(String reason); }

3、IServiceFetcher：获取服务的。可以再此进行注册。

interface IServiceFetcher {// service 是 Ibinder 类型android.os.IBinder getService(java.lang.String name); // 注册服务void addService(java.lang.String name, android.os.IBinder service); // 添加回调void addEventListener(java.lang.String name, android.os.IBinder service); // 移除 service void removeService(java.lang.String name); // 移除回调void removeEventListener(java.lang.String name); // 发送消息void post(String key,in Bundle result); }

2.2、启动分析
根据代码可知，咱们有三个进程，分别是：

com.ipc.code:vc ：TestActivity 运行所在的进程；这是属于用户测的。
com.ipc.code:vm : 也就是BinderProvider 存在的进程；IPCBus 也在该进程，主要是用于保存和传递数据
com.ipc.code ：MainActivity 主进程；

也就是每个进程在初始化的时候，都会走一遍Application 的初始化，因此如果需要对进程做啥操作，可以判断出具体的进程，然后做一些额外的操作。对于 CmProcess ，所有进程的初始化逻辑都是一样的。

public class App extends Application {private static final String TAG = "App"; @Overrideprotected void attachBaseContext(Context base) {super.attachBaseContext(base); // 先启动主进程，之后才启动其他进程VCore.init(base); }}

启动过程中，会主动为每个进程注册回调，注意是每个进程。
该 init 方法最终会走入到下面的方法中：

public void startup(Context context) {if (!isStartUp) {// 在主线程启动，每个进程都有一个自己的主线程if (Looper.myLooper() != Looper.getMainLooper()) {throw new IllegalStateException("VirtualCore.startup() must called in main thread."); }ServiceManagerNative.SERVICE_CP_AUTH = context.getPackageName() + "." + ServiceManagerNative.SERVICE_DEF_AUTH; this.context = context; // 传入了一个 cache 实例，这个实例是只有主线程有的IPCBus.initialize(new IServerCache() {@Overridepublic void join(String serverName, IBinder binder) {ServiceManagerNative.addService(serverName, binder); }@Overridepublic void joinLocal(String serverName, Object object) {ServiceCache.addLocalService(serverName,object); }@Overridepublic void removeService(String serverName) {ServiceManagerNative.removeService(serverName); }@Overridepublic void removeLocalService(String serverName) {ServiceCache.removeLocalService(serverName); }@Overridepublic IBinder query(String serverName) {return ServiceManagerNative.getService(serverName); }@Overridepublic Object queryLocal(String serverName) {return ServiceCache.getLocalService(serverName); }@Overridepublic void post(String key,Bundle bundle) {ServiceManagerNative.post(key,bundle); }}); // 这里是根据进程名字添加注册的事件接收器ServiceManagerNative.addEventListener(AppUtil.getProcessName(context, Process.myPid()), EventReceiver.getInstance()); isStartUp = true; }}

这里整个逻辑很简单，就是在主线程初始化了IPCBus，然后给该进程注册了一个事件分发的监听。

三、EventReceiver

public class EventReceiver extends IEventReceiver.Stub {private static final String TAG = "EventReceiver"; private static final EventReceiver EVENT_RECEIVER = new EventReceiver(); private EventReceiver(){}public static final EventReceiver getInstance(){return EVENT_RECEIVER; }@Overridepublic void onEventReceive(String key,Bundle event) {EventCenter.onEventReceive(key,event); }}

整个类的代码很简单。但是要注意的是，其继承了IEventReceiver.Stub，说明他具有跨进程传输的能力。主要就是通过EventCenter 来分发消息。
由于每个进程都会走一遍初始化逻辑，所以每个进程都注册了事件的接收。

四、ServiceManagerNative 从名字也可以看出来，这个跟我们平时看到的ServiceManager 很像。主要就是用来获取 service 和注册 listener 的。

public static void addEventListener(String name, IBinder service) {IServiceFetcher fetcher = getServiceFetcher(); if (fetcher != null) {try {fetcher.addEventListener(name, service); } catch (RemoteException e) {e.printStackTrace(); }}}

首先是调用getServiceFetcher 来获取最终保存服务的 fetcher。
注册回调的时候，会先获取是否存在（binder）ServiceFetcher ，在将其转化为本地 binder；这样 ServiceFetcher 的管理器就可以用了。

private static IServiceFetcher getServiceFetcher() {if (sFetcher == null || !sFetcher.asBinder().isBinderAlive()) {synchronized (ServiceManagerNative.class) {Context context = VirtualCore.get().getContext(); Bundle response = new ProviderCall.Builder(context, SERVICE_CP_AUTH).methodName("@").call(); if (response != null) {IBinder binder = BundleCompat.getBinder(response, "_VM_|_binder_"); linkBinderDied(binder); sFetcher = IServiceFetcher.Stub.asInterface(binder); }}}return sFetcher; }

首先是看ProviderCall.Builder(context, SERVICE_CP_AUTH).methodName("@").call()，他最终会调用下面的方法：

//ContentProviderCompatpublic static Bundle call(Context context, Uri uri, String method, String arg, Bundle extras) {// 这里还区分了版本if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {return context.getContentResolver().call(uri, method, arg, extras); }ContentProviderClient client = crazyAcquireContentProvider(context, uri); // 这里会不断重试最终会获得对 BinderProvider 的引用Bundle res = null; try {// 通过约定好的方法名字获得bindleres = client.call(method, arg, extras); } catch (RemoteException e) {e.printStackTrace(); } finally {releaseQuietly(client); }return res; }

五、BinderProvider 下面看下 BinderProvider 的 call 方法。
新建了一个 bundle 对象，然后将 binder 保存在里面。注意这是通过跨进程调用，最终将 bundle 传回主进程，然后拿到了ServiceFetcher 的 binder，并将其转为本地 binder。
可以发现这里对于方法名是 "@" 时，就会返回 bundle ，否则就是返回 null 。

public Bundle call(String method,String arg,Bundle extras) {if ("@".equals(method)) {Bundle bundle = new Bundle(); BundleCompat.putBinder(bundle, "_VM_|_binder_", mServiceFetcher); return bundle; }return null; }

简单来说，就是大家都通过 binderProvider 这个进程来保存对于回调的注册，保存是基于进城名字来的，因此可以保证不会被覆盖。
此处的mServiceFetcher 是BinderProvider 内部内的实例，但是其继承了IServiceFetcher.Stub，因此也就有了跨进程的能力。
到这里，理一下前面的逻辑：

ServiceManagerNative.addEventListener(AppUtil.getProcessName(context, Process.myPid()), EventReceiver.getInstance());

某个进程的主线程调用这个方法，所做的具体事情如下：
1.通过 binder 拿到了binderProvider 中的 IServiceFetcher.Stub 的实例；
2.向IServiceFetcher.Stub 注册回调，该回调最终会被保存binderProvider 进程里面。

六、BinderProvider 启动分析上面介绍了其是怎么将 listener 注册到 binderProvider 进程的，但是并没有讲到接下去我们看下 BinderProvider 的启动过程，
下图是ContentProvider 的启动流程。当我们在主进程想获取 server 的时候，这时候，会看看 provider 存不存在，没有的就会进行启动，同时会走 Application 的初始化逻辑，

文章图片

具体我们可以看下面这个启动流程图：

文章图片

Application 的 attachBaseContext 方法是优先执行的；
ContentProvider 的 onCreate的方法比 Application的onCreate的方法先执行；
Activity、Service 的 onCreate 方法以及 BroadcastReceiver 的 onReceive 方法，是在 MainApplication 的 onCreate 方法之后执行的；
调用流程为： Application 的 attachBaseContext ---> ContentProvider 的 onCreate ----> Application 的 onCreate ---> Activity、Service 等的 onCreate（Activity 和 Service 不分先后）；

【分析CmProcess跨进程通信的实现】这里主要是梳理了下 provider 的启动过程，并没有很细讲，但是有必要了解一下。

七、MainActivity 接下去，开始看MainActivity 里面的代码。
调用registerService 注册服务，传入IPayManager.class 和MainActivity；记得MainActivity 也实现了IPayManager 接口。

VCore.getCore().registerService(IPayManager.class, this);

看下，里面的具体代码逻辑

// Vcorepublic VCore registerService(Class interfaceClass, Object server){if (VirtualCore.get().getContext() == null){return this; }Object o = IPCBus.getLocalService(interfaceClass); // 如果是第一次调用就会返回空IBinder service = ServiceManagerNative.getService(interfaceClass.getName()); if (service != null && o != null){return this; }IPCBus.registerLocal(interfaceClass,server); // 这里的注册就是把 server 保存到 binder 中IPCBus.register(interfaceClass,server); return this; }

这里使用了一个registerLocal和register 方法，但是本质上两个方法是有区别的。registerLocal 意思很明确，就是本地ServiceCache保存一份。但是register，确实做了一些额外的操作。

public static void register(Class interfaceClass, Object server) {checkInitialized(); // 这里主要是获取一个 binder,或者换句话来说，采用 binder 来保存相关数据ServerInterface serverInterface = new ServerInterface(interfaceClass); // 这里就是把 binder 保存到 binderProviderTransformBinder binder = new TransformBinder(serverInterface, server); sCache.join(serverInterface.getInterfaceName(), binder); }

首先这里创建了一个ServerInterface 实例，该实例内部保存了传过了来的接口和接口的方法，并将方法和 code 联系在一起。

public ServerInterface(Class interfaceClass) {this.interfaceClass = interfaceClass; Method[] methods = interfaceClass.getMethods(); codeToInterfaceMethod = new SparseArray<>(methods.length); methodToIPCMethodMap = new HashMap<>(methods.length); for (int i = 0; i < methods.length; i++) {// 这里每一个方法都有一个 code int code = Binder.FIRST_CALL_TRANSACTION + i; // 组成一个 ipcMenhodIPCMethod ipcMethod = new IPCMethod(code, methods[i], interfaceClass.getName()); codeToInterfaceMethod.put(code, ipcMethod); // 保存他们的映射关系methodToIPCMethodMap.put(methods[i], ipcMethod); }}

同时利用TransformBinder 将接口和实例保存到 binder 中。再将 binder 和接口名字保存到ServiceCache 中。
注册完以后，下面是调用获取本地服务：

// 其实 service 本质还是这个 MainActivityIPayManager service = VCore.getCore().getLocalService(IPayManager.class);

最后注册了一个回调：

VCore.getCore().subscribe("key", new EventCallback() {@Overridepublic void onEventCallBack(Bundle event) {}});

最终EventCenter 会保存相关信息；

八、TestActivity 最后启动 TestActivity ，这个是在另一个进程。在 onCreate 里面调用下面的方法：

IPayManager service = VCore.getCore().getService(IPayManager.class);

进程刚刚创建，我们看看是怎么获取服务的：

// Vcore public T getService(Class ipcClass){T localService = IPCBus.getLocalService(ipcClass); if (localService != null){return localService; }return VManager.get().getService(ipcClass); }

这里很明确，本地肯定是没有的，因此，最后会从 VManager 中获取：

// VManagerpublic T getService(Class ipcClass) {T t = IPCBus.get(ipcClass); if (t != null){return t; }IPCSingleton tipcSingleton = mIPCSingletonArrayMap.get(ipcClass); if (tipcSingleton == null){tipcSingleton = new IPCSingleton<>(ipcClass); mIPCSingletonArrayMap.put(ipcClass,tipcSingleton); }return tipcSingleton.get(); }

接下去我们看下IPCSingleton 相关逻辑

// IPCSingletonpublic T get() {if (instance == null) {synchronized (this) {if (instance == null) {instance = IPCBus.get(ipcClass); }}}return instance; }

这是一个单例，目的也很明确，就是只获取一次，可以看到后面又调到了 IPCBus 里面。

//IPCBuspublic static T get(Class interfaceClass) {checkInitialized(); ServerInterface serverInterface = new ServerInterface(interfaceClass); // 这里获取的 binder 应该是 TransformBinderIBinder binder = sCache.query(serverInterface.getInterfaceName()); if (binder == null) {return null; }// 这里使用了动态代理return (T) Proxy.newProxyInstance(interfaceClass.getClassLoader(), new Class[]{interfaceClass}, new IPCInvocationBridge(serverInterface, binder)); }

这里采用了动态代理创造了一个实例，最终返回的实例被保存在一个单例中。
可以看到，这里回去查找存不存在 binder。

// VirtualCorepublic IBinder query(String serverName) {return ServiceManagerNative.getService(serverName); }

还是通过ServiceManagerNative 来获取的 service；这里又回到我们之前分析过的逻辑。先从 binderProvider 获取fetcher，也就是 ServiceFetcher。

IServiceFetcher fetcher = getServiceFetcher();

它也会从ServiceFetcher 中获取到 binder ,而这个 binder 就是之前我们保存的TransformBinder 。拿到这个之后，还是一样，将其转化为该进程的本地 binder .

// BinderProvider private class ServiceFetcher extends IServiceFetcher.Stub {

最后，我们通过动态代理的形式，创建了一个 IPayManager 的实例。

return (T) Proxy.newProxyInstance(interfaceClass.getClassLoader(), new Class[]{interfaceClass}, new IPCInvocationBridge(serverInterface, binder));

这里需要注意的是IPCInvocationBridge 继承自InvocationHandler。
拿到后，开始调用对应的方法：

if (service != null){Log.d(TAG, "onCreate: shentestbeforevcore" + AppUtil.getAppName(this)); // 首先这个 service 是跨进程调用的，怎么才通知到其他组件？这里大家可以思考下service.pay(5000, new BaseCallback() {@Overridepublic void onSucceed(Bundle result) {textview.setText(result.getString("pay")); Bundle bundle = new Bundle(); bundle.putString("name", "DoDo"); VCore.getCore().post("key",bundle); }@Overridepublic void onFailed(String reason) {}}); }

调用 service.pay 的时候，就会调用动态代理中的 invoke 方法：

public Object invoke(Object o, Method method, Object[] args) throws Throwable {IPCMethod ipcMethod = serverInterface.getIPCMethod(method); if (ipcMethod == null) {throw new IllegalStateException("Can not found the ipc method : " + method.getDeclaringClass().getName() + "@" +method.getName()); }// 这里很关键return ipcMethod.callRemote(binder, args); }

首先根据方法名获得ipcMethod，里面保存了方法的 code，接口名字，参数，返回值。接着调用了 ipcMethod.callRemote，该方法又会调用：

// IPCMethod // 这个方法很重要，需要理解其实现过程public Object callRemote(IBinder server, Object[] args) throws RemoteException {Parcel data = https://www.it610.com/article/Parcel.obtain(); // 获取一个新的 parcel 对象Parcel reply = Parcel.obtain(); Object result; try {data.writeInterfaceToken(interfaceName); data.writeArray(args); // 这里 server 就是 transformBinderserver.transact(code, data, reply, 0); reply.readException(); result = readValue(reply); if (resultConverter != null) {result = resultConverter.convert(result); }} finally {data.recycle(); reply.recycle(); }return result; }

code 变量用于标识客户端期望调用服务端的哪个函数，因此，双方需要约定一组 int 值，不同的值代表不同的服务端函数，该值和客户端的 transact() 函数中第一个参数 code 的值是一致的。
enforceInterface() 是为了某种校验，它与客户端的 writeInterfaceToken() 对应，具体见下一小节。
readString() 用于从包裹中取出一个字符串。如果该 IPC 调用的客户端期望返回一些结果，则可以在返回包裹 reply 中调用 Parcel 提供的相关函数写入相应的结果。 Parcel.writeXXX();
现在要看的是怎么通过 binder 一步一步拿到参数。
使用 Parcel 一般是通过 Parcel.obtain() 从对象池中获取一个新的 Parcel 对象，如果对象池中没有则直接 new 的 Parcel 则直接创建新的一个 Parcel 对象，并且会自动创建一个Parcel-Native 对象。
writeInterfaceToken 用于写入 IBinder 接口标志，所带参数是 String 类型的，如 IServiceManager.descriptor = "android.os.IServiceManager"。
之前说的 code 在这里用上了，code 是一个私有变量，跟 method 绑定在一起的。
中间有个 server.transact(code, data, reply, 0); 该方法实现了跨进程调用，最终会走到 binderProvider 的下面onTransact方法：

// TransformBinder 运行在主进程@Overrideprotected boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {// 回调进来后，就到了MainActivity 的进程if (code == INTERFACE_TRANSACTION) {reply.writeString(serverInterface.getInterfaceName()); return true; }IPCMethod method = serverInterface.getIPCMethod(code); if (method != null) {try {method.handleTransact(server, data, reply); } catch (Throwable e) {e.printStackTrace(); }return true; }return super.onTransact(code, data, reply, flags); }

这里主要是根据 code 来获取到是哪个方法被调用了，下面才是真正的处理。

// IPCMethod public void handleTransact(Object server, Parcel data, Parcel reply) {data.enforceInterface(interfaceName); // 确保是目标接口Object[] parameters = data.readArray(getClass().getClassLoader()); if (parameters != null && parameters.length > 0) {for (int i = 0; i < parameters.length; i++) {if (converters[i] != null) {parameters[i] = converters[i].convert(parameters[i]); }// 如果参数里面包含有 binder if (parameters[i] instanceof IBinder){parameters[i] = IPCCallback.Stub.asInterface(((IBinder)parameters[i])); }}}try {// 最终通过反射的形式实现了的调用// 其实最主要的是通过 binder 拿到参数,然后知道对方调用的是哪个方法。// 现在要分析的是，他怎么将数据传过来的Object res = method.invoke(server, parameters); reply.writeNoException(); reply.writeValue(res); } catch (IllegalAccessException e) {e.printStackTrace(); reply.writeException(e); } catch (InvocationTargetException e) {e.printStackTrace(); reply.writeException(e); }}

看看 convert 里面的操作：

public Object convert(Object param) {if (param != null) {if (asInterfaceMethod == null) {synchronized (this) {if (asInterfaceMethod == null) {// 找到 asInterface 方法asInterfaceMethod = findAsInterfaceMethod(type); }}}try {// 因为 asInterface 方法是静态方法，所以对象可以传入空，最终转变成所需要的参数类型return asInterfaceMethod.invoke(null, param); } catch (Throwable e) {throw new IllegalStateException(e); }}return null; }

通过 convert 这个一调用，就转变成我们所需要的参数了。

private static Method findAsInterfaceMethod(Class type) {for (Class innerClass : type.getDeclaredClasses()) {// public static class Stub extends Binder implements ITypeif (Modifier.isStatic(innerClass.getModifiers())&& Binder.class.isAssignableFrom(innerClass)&& type.isAssignableFrom(innerClass)) {// public static IType asInterface(android.os.IBinder obj)for (Method method : innerClass.getDeclaredMethods()) {if (Modifier.isStatic(method.getModifiers())) {Class[] types = method.getParameterTypes(); if (types.length == 1 && types[0] == IBinder.class) {return method; }}}}}throw new IllegalStateException("Can not found the " + type.getName() + "$Stub.asInterface method."); }

findAsInterfaceMethod 通过层层筛选，最终获得需要的那个方法：

public static com.cmprocess.ipc.server.IPCCallback com.cmprocess.ipc.server.IPCCallback$Stub.asInterface(android.os.IBinder)

通过 invoke 方法，终将获得了我们需要的类型。
这里 server 就是 mainActivity。在把对应的参数传进去即可。最终调到了mainActivity 里面的 pay 方法。

public void pay(final int count, final IPCCallback callBack) {new Thread(new Runnable() {@Overridepublic void run() {SystemClock.sleep(2000); Bundle bundle = new Bundle(); bundle.putString("pay", count + 100 + ""); try {// callback 也是一个bindercallBack.onSuccess(bundle); } catch (RemoteException e) {e.printStackTrace(); }}}).start(); }

此处，callback 也是一个binder，调用成功后，发送了post。其实最终也是调用了ServiceFetcher 。

// TestActivity VCore.getCore().post("key",bundle);

其实也是通过 binder 来进行发送消息的。由于每个进程都注册了消息回调，因此，每个进程都会收到。

// ServiceCachepublic static synchronized void sendEvent(String key,Bundle event){if (sEventCache.isEmpty()){return; }for (IBinder binder:sEventCache.values()){IEventReceiver eventReceiver = IEventReceiver.Stub.asInterface(binder); try {eventReceiver.onEventReceive(key, event); } catch (RemoteException e) {e.printStackTrace(); }}}

EventReceiver 存在于每个进程，因此，对于 binderprovider 来说都是客户端，其他进程则是服务端。最终 EventCenter 会根据 KEY 值来做分发。
到这里整个流程就基本讲完了。
不过我们发现还有两个 service ,他们的作用是干嘛用的呢？感觉是用来保活的，防止 provider 死了。
以上就是分析CmProcess跨进程通信的实现的详细内容，更多关于CmProcess跨进程通信的资料请关注脚本之家其它相关文章！