随着项目的业务和复杂度的增大，对内存的压力越来越明显，有时不得不使用多进程的方案，将一些功能放到另一个进程中去完成。其实很多时候，简单的业务也需要开一个单独的进程，如音乐播放器。
我们就以音乐播放器为例，播放音乐的实现功能部份我们往往放在Service中去做，并把这个Service运行在一个单独的进程中（通过设置android:process属性）。这样做的好处是，音乐播放器的UI部份在一个进程，可以退出释放内存。而Service部份所在的进程没有UI资源，占用的内存也较少。
麻烦一点的就是，每次UI进程打开Activity界面时需要使用bindService来绑定Service，才能和它进行通讯，如读取现在的播放进度，控制暂停快进等功能。
其实在音乐播放器这个场景中，Service这个方案是很合理的。但有些时候，我们需要调用一个远程进程中的功能，但是想在一个同步方法中调用，而且不能排除用户是在主线程调用。这种情况如果用Service的方案来实现，那么，我们只能通过bindService去绑定Service获取它的服务接口（Binder实例），但问题出在这个bindService是异步方法，调用后要在它的回调方法ServiceConnection中才能获取到它的服务接口。
如果我们想同步调用一个远程进程中提供的方法，应该怎么办呢？
我有想过像系统提供的服务一样，如ActivityManagerService，在系统服务注册，然后提供给Client端同步调用。
后来一想，这种方案大复杂了。很多时候我们单独进程中跑的功能并不复杂，有点杀鸡用牛刀的感觉。然后就是查找一些资料，没查到什么好的方案，我就去看一下ContentProvider的源码，想看看它是怎么实现，其实他和我的需求很像，可以进程间访问，每个方法都是同步的，需要时才启动，就是方法要封装成insert/delete/query这样的。后来一看，ContentProvider有一个call方法，完全可以实现我的需求。
@Override
public Bundle call(String method, String arg, Bundle extras) {
if (extras == null) {
return null;
}
extras.setClassLoader(GoeasywayContentProvider.class.getClassLoader());
CallArgs callBundleArgs = extras.getParcelable(METHOD_CALL_ARGS);
......
注意代码中的extras.setClassLoader，如果我们需要用extras传递自定义的Pacelable对象，那么这里要指定一下它的ClassLoader，不然这里会无法解封CallArgs（自定义的Pacelable对象）。
可以用method区分每个方法，参数可以放到Bundle中。返回值也是一个Bundle对象，可以在返回值也传递一个自己定义的Pacelable对象。我把参数和返回值放在一个Pacelable中:
public class CallArgs implements Parcelable {
public String method;
public Object[] methodArgs;
public Object result;
public CallArgs() {
}
protected CallArgs(Parcel in) {
readFromParcel(in);
}
public static final Creator<CallArgs> CREATOR = new Creator<CallArgs>() {
@Override
public CallArgs createFromParcel(Parcel in) {
return new CallArgs(in);
}
@Override
public CallArgs[] newArray(int size) {
return new CallArgs[size];
}
};
@Override
public int describeContents() {
return 0;
}
@Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeString(method);
dest.writeArray(methodArgs);
dest.writeValue(result);
}
public void readFromParcel(Parcel in) {
method = in.readString();
methodArgs = in.readArray(CallArgs.class.getClassLoader());
result = in.readValue(CallArgs.class.getClassLoader());
}
}
访问就是通过getContentResolver().call这个方法，我们简单的封装了一下:
private CallArgs callRemoteMethod(String method, Object... args) {
CallArgs CallArgs = new CallArgs();
CallArgs.method = method;
CallArgs.methodArgs = args;
android.os.Bundle bundleArgs = new android.os.Bundle();
bundleArgs.putParcelable(METHOD_CALL_ARGS, CallArgs);
android.os.Bundle bundleResult = hostContext.getContentResolver().call(
CALL_URI, // 一个Uri,和使用ContentProvider的query方法一样的
method, null, bundleArgs);
if (bundleResult == null) {
return null;
}
bundleResult.setClassLoader(CallArgs.class.getClassLoader());
CallArgs result = bundleResult.getParcelable(METHOD_CALL_RESULT);
return result;
}
这个使用起来就像一个简单的API调用，我们用很少的代码就实现了一个进程间的同步调用，不用但心远程进程已经被系统KILL掉，Android系统会帮我们重新创一个进程并继续之前的调用。
这里要注意：
- 在进程间传递的对象都是现实Parcelable接口，即CallArgs方法中的参数（methodArgs）和返回值（result）都应该实现Parcelable接口。
- 进程间通信是通过Binder机制进行的，每个调用线程都会被block，不管它是主线程还是子线程，直到Binder的服务端（本例中是ContentProvider）的binder线程执行完成返回给调用端时，线程才会继续运行。所以如果ContentProvider中的操作较耗时，最好是用子线程去调用。
- 每个Binder线程能传输的数据是有大小受Binder缓冲区的大小限制的，一般一个线程最大能占用128KB。超过这个限制会报TransactionTooLargeException异常。
