而addHook()最终会调用到com.lody.virtual.client.hook.base.HookDelegate#addHook，其实质便是将这个hook添加至映射表internalHookTable中：
public Hook addHook(Hook hook) { if (hook != null && !TextUtils.isEmpty(hook.getName())) { if (internalHookTable.containsKey(hook.getName())) { VLog.w(TAG, "The Hook(%s, %s) you added has been in existence.", hook.getName(), hook.getClass().getName()); return hook; } internalHookTable.put(hook.getName(), hook); } return hook; }internalHookTable维护了所有的hook，以hook的名称（一般就是所hook的方法的名称）作为key。随后，在com.lody.virtual.client.hook.base.HookDelegate.HookHandler的invoke()方法中，查找表 internalHookTable中是否包含将要执行的方法名；如果有，则依次执行对应hook的beforeCall(), call(), afterCall()：
private class HookHandler implements InvocationHandler { @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Hook hook = getHook(method.getName()); try { if (hook != null && hook.isEnable()) { if (hook.beforeCall(mBaseInterface, method, args)) { Object res = hook.call(mBaseInterface, method, args); res = hook.afterCall(mBaseInterface, method, args, res); return res; } } return method.invoke(mBaseInterface, args);而这里的类HookHandler，就是构造的Java代理的Handler：
public HookDelegate(T baseInterface, Class<?>... proxyInterfaces) { this.mBaseInterface = baseInterface; if (baseInterface != null) { if (proxyInterfaces == null) { proxyInterfaces = HookUtils.getAllInterface(baseInterface.getClass()); } mProxyInterface = (T) Proxy.newProxyInstance(baseInterface.getClass().getClassLoader(), proxyInterfaces, new HookHandler());对于ActivityManagerPatch来说，这里的baseInterface便是原始的BinderProxy:ActivityManagerProxy
public ActivityManagerPatch() { super(new HookDelegate<IInterface>(ActivityManagerNative.getDefault.call())); }综上，我们根据baseInterface，为其构造了代理mProxyInterface。从而访问mProxyInterface时，便会执行HookHandler的invoke()方法，进而查找internalHookTable，对设置了hook的方法执行hook。
系统服务的替换如之前所说，对系统服务的替换，是通过对应用所持有的系统服务的BinderProxy进行替换的。以上是构造代理的基本过程，那么如何将应用所持有的BinderProxy替换成我们构造的代理呢？回到ActivityManagerPatch，这个类的inject()方法完成了实际的替换工作：
@Override public void inject() throws Throwable { if (ActivityManagerNative.gDefault.type() == IActivityManager.TYPE) { ActivityManagerNative.gDefault.set(getHookDelegate().getProxyInterface()); } else if (ActivityManagerNative.gDefault.type() == Singleton.TYPE) { Object gDefault = ActivityManagerNative.gDefault.get(); Singleton.mInstance.set(gDefault, getHookDelegate().getProxyInterface()); } ...ActivityManagerNative.gDefault便是应用所持有的原始ActivityManagerProxy对象，通过Java反射，将替换成为getHookDelegate().getProxyInterface()。而替换的内容，便是我们所构造的代理mProxyInterface。
由此，我们完成了对系统服务进行代理和替换的整个过程。随后，在调用系统服务时，便会执行以下操作：
- 访问BinderProxy的代理，即我们设置了hook的代理
- 根据hook的具体内容操作，对数据进行处理；需要调用原始系统服务时，访问原始的BinderProxy
- 真正的系统服务接收到Binder，进行处理并返回
总结通过以上介绍可以看到，VirtualApp在原有系统服务之上构造了代理，进而为其中的应用搭建了一套虚拟环境，应用可以无感知地运行在这其中。更进一步，我们可以设置这套虚拟环境，使其实现应用多开、非侵入式应用hook等高级功能。 |
