App虚拟化技术初探

Plugin Technology Background

App插件开发技术或App虚拟化技术以及App热修复技术，最近几年非常火热和流行，图中列举了两种主要的需求，第一种需求是很多时候我们想在Android手机上同时登陆多个社交应用，比如QQ或者微信，在Android原生系统中肯定是无法支持的，只有登出一个账号后然后在换另外一个，因此衍生APP虚拟化技术；另外一种需求是一个大的APK文件我想分批次发布，防止一次性发布下载时间过长而损害用户体验，因此我把不同的功能以插件的形式发布，这个插件同样是APK文件，同样对于某一种功能的升级或者bug的修复都可以采用这种技术来实现。

What is Android Plugin Technology?

• Launch an APK file within an Android app.
  在一个APP内部启动一个APP
• In the unrooted device.
  不需要root手机
• “Host App” = Android app.
• “Plugin” = APK file.
• No need to install the plugin.
  这里的无需安装主要是指对系统来说，并没有实地安装，，创建沙箱环境，以用户的视角来看还是与host app一样，点击安装，然后正常运行

现有的插件框架

现有的能够实现上述需求的框架主要有DroidPlugin、VirtualApp、DynamicAPK
典型的应用有Parallel Space，截止2017年下载了达到千万级别
虽然很多类型的这种框架，但是他们得底层实现机制基本相同

Demystify Plugin Technology

插件技术最主要的中原理就是，为了让插件中的方法能够正确的调用。Host APP把所有的插件和系统（Android Framework交互）的方法都在内部Hook并替换掉了。

为什么这样做呢？

因为，这个是一个插件系统，Activity是虚拟Proxy出来的。四大组件，并不是真正的，即Context拿到不一定是真的。系统也不会有此类的回调。所以，很多单例都需要执行Context才能使用。比如：InputMethodManager.getInstance(Context context)；这时，插件中的代码将不能够直接运行。当然，还有其他原因。

动态加载运行一个Activity的基本机制

为了进一步的理解这种插件运行机制中的HOOK技术，我们来看一个简单的实例，即如何动态加载运行一个Apk中的Activity,

既然说到动态加载，我们很容易想到Davilk虚拟机中的类加载器

(1) DexClassLoader可以加载任何路径的apk/dex/jar/zip
(2) PathClassLoader只能加载缓存在/data/app中的apk，也就是已经安装到手机中的apk

那么如何加载一个apk并运行其中的Activity呢？我们很容易想到使用如下代码实现

这样显然是不行的
因为Android中的四大组件都有一个特点就是他们有自己的启动流程和生命周期，我们使用DexClassLoader加载进来的Activity是不会涉及到任何启动流程和生命周期的概念，说白了，就是一个普普通通的类，所以启动肯定会出错。
那么如何解决呢？

思路一：替换LoadedApk中mClassLoader

由于这个mClassLoader是非static类型的引用，因此我们通过反射的机制无法更改当前运行时数据，那么该怎么办呢？我们再看ActivityThread这个类

这个类中有一个静态变量，我们可以通过反射这个类，来获取LoadedApk对象，然后更改其mClassLoader

思路二：更新DexPathList数据结构

APK在启动的过程中加载的dex文件都存放在一个叫dexElements的数据结构中，我们通过将插件APK的dex文件解析后的数据结构也放入此数据中，使其成为host App的一部分，那么host app在启动其中的Activity的时候就具有上下文环境了，相应的组件也会有生命周期

思路三：使用静态代理

基本思路是使用一个在host app中具有生命周期和执行上下文的Activity代理插件Activity执行其各个生命周期的回调函数

之前三种方式共有的缺陷

(1) 需要在宿主应用的Manifest文件中注册要启动的Plugin中的组件，权限等信息，只能加载运行特定已知的apk，因此不可能将所有需要以插件方式进行运行的APK中的组件全部进行注册

思路四：使用hook技术代理实现

我们先看下启动一个Activity的基本过程，图中已说明详细，这里不再赘述了

由于前三种方式的缺陷，第四重方式通过预先在Host APP的Manifest文件中预注册一些启动插件app会用到的一些Dummy 组件，也就是图中的StubActivity，当使用intent启动一个PluginActivity的时候，使用Hook拦截此消息，将PluginActivity更换为StubActivity，通过Binder系统调用进行进程间过程调用，ActivityManngerService执行Activity的栈管理、验证等过程，由于我们使用将PluginActivity更换为StubActivity，而StubActivity又在Host APP的Manifest文件中预注册了。所以验证会通过，然后ActivityManngerService将控制权移交给APP进程（同样通过进程间的RPC调用），然后APP进程开始执行真正创建Activity的过程，这创建之前又通过hook将StubActivity更换为PluginActivity，启动真正要启动的Activity，因此这样就可以瞒天过海，欺上瞒下，骗过System_server进程，同时使得启动的Activity又具有相应的生命周期，整个过程还是比较直观的。