Android源码中的代理模式解析

Android源码下的比较经典的代理模式其中之一是ActivityManagerProxy代理类，其具体代理的ActivityManagerNative的子类ActivityManagerService，ActivityManagerService在这里就不在具体赘述了，这里主要梳理一下整个代理的框架。

ActivityManagerProxy是ActivityManagerNative的内部类，定义如下：

class ActivityManagerProxy implements IActivityManager

ActivityManagerProxy实现了IActivityManager的接口，该接口定义了一些Activity相关的接口方法，其中有些是我们平时用到的。

public interface IActivityManager extends IInterface {


	public int startActivity(IApplicationThread caller, String callingPackage, Intent intent,
            String resolvedType, IBinder resultTo, String resultWho, int requestCode, int flags,
            ProfilerInfo profilerInfo, Bundle options) throws RemoteException;
	//...........
	public Intent registerReceiver(IApplicationThread caller, String callerPackage,
            IIntentReceiver receiver, IntentFilter filter,
            String requiredPermission, int userId) throws RemoteException;

	//...........

       public void unregisterReceiver(IIntentReceiver receiver) throws RemoteException;
	//...........

    public int bindService(IApplicationThread caller, IBinder token, Intent service,
            String resolvedType, IServiceConnection connection, int flags,
            String callingPackage, int userId) throws RemoteException;
    public boolean unbindService(IServiceConnection connection) throws RemoteException;

	//...........

	//...........
}

上面的这个IActivityManager相当于代理模式中的抽象主题Subject， ActivityManagerProxy相当于代理类Proxy，那么具体的实现主题角色RealSubject是谁呢？

其实就是上面提到的ActivityManagerNative子类ActivityManagerService。因为ActivityManagerNative也实现了抽象主题角色IActivityManager。

public abstract class ActivityManagerNative extends Binder implements IActivityManager

这几个类之间的关系可以用以下UML类图表示为：

通过UML类图可以清晰的看出，ActivityManagerProxy和ActivityManagerNative都实现了IActivityManager，严格来说，ActivityManagerProxy就是代理部分，而ActivityManagerNative就是真实部分，但是ActivityManagerNative抽象类，其并不能处理过多的逻辑，大部分逻辑的实现都是由其子类ActivityManagerService承担，ActivityManagerService是真正意义上的真实主题。所以可以说ActivityManagerService实现了IActivityManager的所有功能，比如启动Activity，绑定服务，注册广播等等，这些逻辑最终都是交给ActivityManagerService实现的。

ActivityManagerService是系统级的Service并且运行与独立的进程中，可以通过ServiceManager获取它，ActivityManagerProxy也运行与独立的进程中，两者之间的通信属于进程间通信，也就是IPC，通过上面的UML类图，可以看出，这里的IPC的方式是通过Binder实现的，Android系统中的Binder机制是一种非常重要的IPC方式。

ActivityManagerProxy在实际的逻辑处理中并未过多的被外部类调用，因为在Activity相关信息的类还有一个ActivityManager类，ActivityManager从名字上看出管理者Activity的信息，但是ActivityManager的大部分逻辑实现都交给ActivityManagerProxy了。

这里以ActivityManager的getAppTasks方法举例说明代理模式。

    public List<ActivityManager.AppTask> getAppTasks() {
        ArrayList<AppTask> tasks = new ArrayList<AppTask>();
        List<IAppTask> appTasks;
        try {
            appTasks = ActivityManagerNative.getDefault().getAppTasks(mContext.getPackageName());
        } catch (RemoteException e) {
            // System dead, we will be dead too soon!
            return null;
        }
        int numAppTasks = appTasks.size();
        for (int i = 0; i < numAppTasks; i++) {
            tasks.add(new AppTask(appTasks.get(i)));
        }
        return tasks;
    }

这个方法就是通过ActivityManagerNatived的gDefault方法获取一个IActivityManager对象，再通过其调用调用getAppTasks方法。ActivityManagerNatived的gDefault方法源码如下：

    static public IActivityManager getDefault() {
        return gDefault.get();
    }

而gDefault只是单纯返回，继续跟踪源码。

    private static final Singleton<IActivityManager> gDefault = new Singleton<IActivityManager>() {
        protected IActivityManager create() {
            IBinder b = ServiceManager.getService("activity");
            if (false) {
                Log.v("ActivityManager", "default service binder = " + b);
            }
            IActivityManager am = asInterface(b);
            if (false) {
                Log.v("ActivityManager", "default service = " + am);
            }
            return am;
        }
    };

上面代码通过单例模式构造了Singleton<IActivityManager >类型的gDefault，其中通过ServiceManager.getService("activity");获取了一个系统级别及的Service，而这个Service其实就是ActivityManagerService，然后通过asInterface方法返回一个IActivityManager对象，传入的参数是ActivityManagerService的一个binder对象，相当于远程引用。下面再看asInterface方法，这个方法非常关键，代理模式在这个方法中也提现的淋漓尽致！！！

    static public IActivityManager asInterface(IBinder obj) {
        if (obj == null) {
            return null;
        }
        IActivityManager in =
            (IActivityManager)obj.queryLocalInterface(descriptor);
        if (in != null) {
            return in;
        }

        return new ActivityManagerProxy(obj);
    }

在这个方法的最后一句，new ActivityManagerProxy(obj);传入了ActivityManagerService的引用，构造了代理对象返回，这个刚好符合静态代理模式。

分析到这里，也就完成了创建持有ActivityManagerService的引用的代理ActivityManagerProxy的实例。也就是说，ActivityManagerNatived.gDefault返回的实质上时一个代理对象，ActivityManagerProxy的实例。

 appTasks = ActivityManagerNative.getDefault().getAppTasks(mContext.getPackageName());

上面代码实际上调用的是ActivityManagerProxy类中的getTasks方法，继续跟踪源码，查看ActivityManagerProxy的getTasks方法，源码如下：

    public List<IAppTask> getAppTasks(String callingPackage) throws RemoteException {
        Parcel data = Parcel.obtain();
        Parcel reply = Parcel.obtain();
        data.writeInterfaceToken(IActivityManager.descriptor);
        data.writeString(callingPackage);
        mRemote.transact(GET_APP_TASKS_TRANSACTION, data, reply, 0);
        reply.readException();
        ArrayList<IAppTask> list = null;
        int N = reply.readInt();
        if (N >= 0) {
            list = new ArrayList<>();
            while (N > 0) {
                IAppTask task = IAppTask.Stub.asInterface(reply.readStrongBinder());
                list.add(task);
                N--;
            }
        }
        data.recycle();
        reply.recycle();
        return list;
    }

这里的源码的逻辑就比较明确了，通过 mRemote.transact方法将数据打包跨进程传递给Server端的 ActivityManagerService处理并返回结果。ActivityManagerService的getAppTasks方法会被调用并返回结果， mRemote是IBinder对象，transact方法我们在aidl中已经详细说明过了，这里不再赘述，然后将返回数据的Binder对象解析获得数据，还是通过asInterface方法将Binder对象转换为我们需要的对象。

最后ActivityManagerService的getAppTasks方法就不再赘述了。

通过上面的源码，应该对源码中的代理模式有很深的理解了。