滴滴插件化方案 VirtualApk 源码解析
ChelseaSnip
7年前
<h2>一、概述</h2> <p>之前一直没有写过插件化相关的博客，刚好最近滴滴和360分别开源了自家的插件化方案，赶紧学习下，写两篇博客，第一篇是滴滴的方案：</p> <ul> <li><a href="/misc/goto?guid=4959750224245156431" rel="nofollow,noindex">https://github.com/didi/VirtualAPK</a></li> </ul> <p>那么其中的难点很明显是对四大组件支持，因为大家都清楚，四大组件都是需要在AndroidManifest中注册的，而插件apk中的组件是不可能预先知晓名字，提前注册中宿主apk中的，所以现在基本都采用一些hack方案类解决，VirtualAPK大体方案如下：</p> <ul> <li>Activity：在宿主apk中提前占几个坑，然后通过“欺上瞒下”（这个词好像是360之前的ppt中提到）的方式，启动插件apk的Activity；因为要支持不同的launchMode以及一些特殊的属性，需要占多个坑。</li> <li>Service：通过代理Service的方式去分发；主进程和其他进程，VirtualAPK使用了两个代理Service。</li> <li>BroadcastReceiver：静态转动态</li> <li>ContentProvider：通过一个代理Provider进行分发。</li> </ul> <p>这些占坑的数量并不是固定的，比如Activity想支持某个属性，该属性不能动态设置，只能在Manifest中设置，那就需要去占坑支持。所以占坑数量这些，可以根据自己的需求进行调整。</p> <p>下面就逐一去分析代码啦~</p> <p>注：本篇博客涉及到的framework逻辑，为API 22.</p> <p>分期版本为 com.didi.virtualapk:core:0.9.0</p> <h2>二、Activity的支持</h2> <p>这里就不按照某个流程一行行代码往下读了，针对性的讲一些关键流程，可能更好阅读一些。</p> <p>首先看一段启动插件Activity的代码：</p> <pre> <code class="language-java">final String pkg = "com.didi.virtualapk.demo"; if (PluginManager.getInstance(this).getLoadedPlugin(pkg) == null) { Toast.makeText(this, "plugin [com.didi.virtualapk.demo] not loaded", Toast.LENGTH_SHORT).show(); return; } // test Activity and Service Intent intent = new Intent(); intent.setClassName(pkg, "com.didi.virtualapk.demo.aidl.BookManagerActivity"); startActivity(intent);</code></pre> <p>可以看到优先根据包名判断该插件是否已经加载，所以在插件使用前其实还需要调用</p> <pre> <code class="language-java">pluginManager.loadPlugin(apk);</code></pre> <p>加载插件。</p> <p>这里就不赘述源码了，大致为调用 PackageParser.parsePackage 解析apk，获得该apk对应的PackageInfo，资源相关（AssetManager，Resources），DexClassLoader（加载类），四大组件相关集合（mActivityInfos，mServiceInfos，mReceiverInfos，mProviderInfos），针对Plugin的PluginContext等一堆信息，封装为LoadedPlugin对象。</p> <p>详细可以参考 com.didi.virtualapk.internal.LoadedPlugin 类。</p> <p>ok，如果该插件以及加载过，则直接通过startActivity去启动插件中目标Activity。</p> <h3>（1）替换Activity</h3> <p>这里大家肯定会有疑惑，该Activity必然没有在Manifest中注册，这么启动不会报错吗？</p> <p>正常肯定会报错呀，所以我们看看它是怎么做的吧。</p> <p>跟进startActivity的调用流程，会发现其最终会进入Instrumentation的execStartActivity方法，然后再通过ActivityManagerProxy与AMS进行交互。</p> <p>而Activity是否存在的校验是发生在AMS端，所以我们在于AMS交互前，提前将Activity的ComponentName进行替换为占坑的名字不就好了么？</p> <p>这里可以选择hook Instrumentation，或者ActivityManagerProxy都可以达到目标，VirtualAPK选择了hook Instrumentation.</p> <p>打开 PluginManager 可以看到如下方法：</p> <pre> <code class="language-java">private void hookInstrumentationAndHandler() { try { Instrumentation baseInstrumentation = ReflectUtil.getInstrumentation(this.mContext); if (baseInstrumentation.getClass().getName().contains("lbe")) { // reject executing in paralell space, for example, lbe. System.exit(0); } final VAInstrumentation instrumentation = new VAInstrumentation(this, baseInstrumentation); Object activityThread = ReflectUtil.getActivityThread(this.mContext); ReflectUtil.setInstrumentation(activityThread, instrumentation); ReflectUtil.setHandlerCallback(this.mContext, instrumentation); this.mInstrumentation = instrumentation; } catch (Exception e) { e.printStackTrace(); } }</code></pre> <p>可以看到首先通过反射拿到了原本的 Instrumentation 对象，拿的过程是首先拿到ActivityThread，由于ActivityThread可以通过静态变量 sCurrentActivityThread 或者静态方法 currentActivityThread() 获取，所以拿到其对象相当轻松。拿到ActivityThread对象后，调用其 getInstrumentation() 方法，即可获取当前的Instrumentation对象。</p> <p>然后自己创建了一个VAInstrumentation对象，接下来就直接反射将VAInstrumentation对象设置给ActivityThread对象即可。</p> <p>这样就完成了hook Instrumentation,之后调用Instrumentation的任何方法，都可以在VAInstrumentation进行拦截并做一些修改。</p> <p>这里还hook了ActivityThread的mH类的Callback，暂不赘述。</p> <p>刚才说了，可以通过Instrumentation的execStartActivity方法进行偷梁换柱，所以我们直接看对应的方法：</p> <pre> <code class="language-java">public ActivityResult execStartActivity( Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) { mPluginManager.getComponentsHandler().transformIntentToExplicitAsNeeded(intent); // null component is an implicitly intent if (intent.getComponent() != null) { Log.i(TAG, String.format("execStartActivity[%s : %s]", intent.getComponent().getPackageName(), intent.getComponent().getClassName())); // resolve intent with Stub Activity if needed this.mPluginManager.getComponentsHandler().markIntentIfNeeded(intent); } ActivityResult result = realExecStartActivity(who, contextThread, token, target, intent, requestCode, options); return result; }</code></pre> <p>首先调用transformIntentToExplicitAsNeeded，这个主要是当component为null时，根据启动Activity时，配置的action，data,category等去已加载的plugin中匹配到确定的Activity的。</p> <p>本例我们的写法ComponentName肯定不为null，所以直接看 markIntentIfNeeded() 方法：</p> <pre> <code class="language-java">public void markIntentIfNeeded(Intent intent) { if (intent.getComponent() == null) { return; } String targetPackageName = intent.getComponent().getPackageName(); String targetClassName = intent.getComponent().getClassName(); // search map and return specific launchmode stub activity if (!targetPackageName.equals(mContext.getPackageName()) && mPluginManager.getLoadedPlugin(targetPackageName) != null) { intent.putExtra(Constants.KEY_IS_PLUGIN, true); intent.putExtra(Constants.KEY_TARGET_PACKAGE, targetPackageName); intent.putExtra(Constants.KEY_TARGET_ACTIVITY, targetClassName); dispatchStubActivity(intent); } }</code></pre> <p>在该方法中判断如果启动的是插件中类，则将启动的包名和Activity类名存到了intent中，可以看到这里存储明显是为了后面恢复用的。</p> <p>然后调用了 dispatchStubActivity(intent)</p> <pre> <code class="language-java">private void dispatchStubActivity(Intent intent) { ComponentName component = intent.getComponent(); String targetClassName = intent.getComponent().getClassName(); LoadedPlugin loadedPlugin = mPluginManager.getLoadedPlugin(intent); ActivityInfo info = loadedPlugin.getActivityInfo(component); if (info == null) { throw new RuntimeException("can not find " + component); } int launchMode = info.launchMode; Resources.Theme themeObj = loadedPlugin.getResources().newTheme(); themeObj.applyStyle(info.theme, true); String stubActivity = mStubActivityInfo.getStubActivity(targetClassName, launchMode, themeObj); Log.i(TAG, String.format("dispatchStubActivity,[%s -> %s]", targetClassName, stubActivity)); intent.setClassName(mContext, stubActivity); }</code></pre> <p>可以直接看最后一行，intent通过setClassName替换启动的目标Activity了！这个stubActivity是由 mStubActivityInfo.getStubActivity(targetClassName, launchMode, themeObj) 返回。</p> <p>很明显，传入的参数launchMode、themeObj都是决定选择哪一个占坑类用的。</p> <pre> <code class="language-java">public String getStubActivity(String className, int launchMode, Theme theme) { String stubActivity= mCachedStubActivity.get(className); if (stubActivity != null) { return stubActivity; } TypedArray array = theme.obtainStyledAttributes(new int[]{ android.R.attr.windowIsTranslucent, android.R.attr.windowBackground }); boolean windowIsTranslucent = array.getBoolean(0, false); array.recycle(); if (Constants.DEBUG) { Log.d("StubActivityInfo", "getStubActivity, is transparent theme ? " + windowIsTranslucent); } stubActivity = String.format(STUB_ACTIVITY_STANDARD, corePackage, usedStandardStubActivity); switch (launchMode) { case ActivityInfo.LAUNCH_MULTIPLE: { stubActivity = String.format(STUB_ACTIVITY_STANDARD, corePackage, usedStandardStubActivity); if (windowIsTranslucent) { stubActivity = String.format(STUB_ACTIVITY_STANDARD, corePackage, 2); } break; } case ActivityInfo.LAUNCH_SINGLE_TOP: { usedSingleTopStubActivity = usedSingleTopStubActivity % MAX_COUNT_SINGLETOP + 1; stubActivity = String.format(STUB_ACTIVITY_SINGLETOP, corePackage, usedSingleTopStubActivity); break; } // 省略LAUNCH_SINGLE_TASK，LAUNCH_SINGLE_INSTANCE } mCachedStubActivity.put(className, stubActivity); return stubActivity; }</code></pre> <p>可以看到主要就是根据launchMode去选择不同的占坑类。</p> <p>例如：</p> <pre> <code class="language-java">stubActivity = String.format(STUB_ACTIVITY_STANDARD, corePackage, usedStandardStubActivity);</code></pre> <p>STUB_ACTIVITY_STANDARD值为："%s.A$%d" , corePackage值为 com.didi.virtualapk.core ，usedStandardStubActivity为数字值。</p> <p>所以最终类名格式为： com.didi.virtualapk.core.A$1</p> <p>再看一眼，CoreLibrary下的AndroidManifest中：</p> <pre> <code class="language-java"><activity android:name=".A$1" android:launchMode="standard"/> <activity android:name=".A$2" android:launchMode="standard" android:theme="@android:style/Theme.Translucent" /> <!-- Stub Activities --> <activity android:name=".B$1" android:launchMode="singleTop"/> <activity android:name=".B$2" android:launchMode="singleTop"/> <activity android:name=".B$3" android:launchMode="singleTop"/> // 省略很多...</code></pre> <p>就完全明白了。</p> <p>到这里就可以看到，替换我们启动的Activity为占坑Activity，将我们原本启动的包名，类名存储到了Intent中。</p> <p>这样做只完成了一半，为什么这么说呢？</p> <h3>(2) 还原Activity</h3> <p>因为欺骗过了AMS，AMS执行完成后，最终要启动的不可能是占坑Activity，还应该是我们的启动的目标Activity呀。</p> <p>这里需要知道Activity的启动流程：</p> <p>AMS在处理完启动Activity后，会调用： app.thread.scheduleLaunchActivity ，这里的thread对应的server端未我们ActivityThread中的ApplicationThread对象(binder可以理解有一个client端和一个server端)，所以会调用 ApplicationThread.scheduleLaunchActivity 方法，在其内部会调用mH类的sendMessage方法，传递的标识为 H.LAUNCH_ACTIVITY ，进入调用到ActivityThread的handleLaunchActivity方法->ActivityThread#handleLaunchActivity->mInstrumentation.newActivity()。</p> <p>ps:这里流程不清楚没关系，暂时理解为最终会回调到Instrumentation的newActivity方法即可，细节可以自己去查看结合老罗的blog理解。</p> <p>关键的来了，最终又到了Instrumentation的newActivity方法，还记得这个类我们已经改为VAInstrumentation啦：</p> <p>直接看其newActivity方法：</p> <pre> <code class="language-java">@Override public Activity newActivity(ClassLoader cl, String className, Intent intent) throws InstantiationException, IllegalAccessException, ClassNotFoundException { try { cl.loadClass(className); } catch (ClassNotFoundException e) { LoadedPlugin plugin = this.mPluginManager.getLoadedPlugin(intent); String targetClassName = PluginUtil.getTargetActivity(intent); if (targetClassName != null) { Activity activity = mBase.newActivity(plugin.getClassLoader(), targetClassName, intent); activity.setIntent(intent); // 省略兼容性处理代码 return activity; } } return mBase.newActivity(cl, className, intent); }</code></pre> <p>核心就是首先从intent中取出我们的目标Activity，然后通过plugin的ClassLoader去加载（还记得在加载插件时，会生成一个LoadedPlugin对象，其中会对应其初始化一个DexClassLoader）。</p> <p>这样就完成了Activity的“偷梁换柱”。</p> <p>还没完，接下来在 callActivityOnCreate 方法中：</p> <pre> <code class="language-java">@Override public void callActivityOnCreate(Activity activity, Bundle icicle) { final Intent intent = activity.getIntent(); if (PluginUtil.isIntentFromPlugin(intent)) { Context base = activity.getBaseContext(); try { LoadedPlugin plugin = this.mPluginManager.getLoadedPlugin(intent); ReflectUtil.setField(base.getClass(), base, "mResources", plugin.getResources()); ReflectUtil.setField(ContextWrapper.class, activity, "mBase", plugin.getPluginContext()); ReflectUtil.setField(Activity.class, activity, "mApplication", plugin.getApplication()); ReflectUtil.setFieldNoException(ContextThemeWrapper.class, activity, "mBase", plugin.getPluginContext()); // set screenOrientation ActivityInfo activityInfo = plugin.getActivityInfo(PluginUtil.getComponent(intent)); if (activityInfo.screenOrientation != ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED) { activity.setRequestedOrientation(activityInfo.screenOrientation); } } catch (Exception e) { e.printStackTrace(); } } mBase.callActivityOnCreate(activity, icicle); }</code></pre> <p>设置了修改了mResources、mBase（Context）、mApplication对象。以及设置一些可动态设置的属性，这里仅设置了屏幕方向。</p> <p>这里提一下，将mBase替换为PluginContext，可以修改Resources、AssetManager以及拦截相当多的操作。</p> <p>看一眼代码就清楚了：</p> <p>原本Activity的部分get操作</p> <pre> <code class="language-java"># ContextWrapper @Override public AssetManager getAssets() { return mBase.getAssets(); } @Override public Resources getResources() { return mBase.getResources(); } @Override public PackageManager getPackageManager() { return mBase.getPackageManager(); } @Override public ContentResolver getContentResolver() { return mBase.getContentResolver(); }</code></pre> <p>直接替换为：</p> <pre> <code class="language-java"># PluginContext @Override public Resources getResources() { return this.mPlugin.getResources(); } @Override public AssetManager getAssets() { return this.mPlugin.getAssets(); } @Override public ContentResolver getContentResolver() { return new PluginContentResolver(getHostContext()); }</code></pre> <p>看得出来还是非常巧妙的。可以做的事情也非常多，后面对ContentProvider的描述也会提现出来。</p> <p>好了，到此Activity就可以正常启动了。</p> <p>下面看Service。</p> <h2>三、Service的支持</h2> <p>Service和Activity有点不同，显而易见的首先我们也会将要启动的Service类替换为占坑的Service类，但是有一点不同，在Standard模式下多次启动同一个占坑Activity会创建多个对象来对象我们的目标类。而Service多次启动只会调用onStartCommond方法，甚至常规多次调用bindService，seviceConn对象不变，甚至都不会多次回调bindService方法（多次调用可以通过给Intent设置不同Action解决）。</p> <p>还有一点，最明显的差异是，Activity的生命周期是由用户交互决定的，而Service的声明周期是我们主动通过代码调用的。</p> <p>也就是说，start、stop、bind、unbind都是我们显示调用的，所以我们可以拦截这几个方法，做一些事情。</p> <p>Virtual Apk的做法，即将所有的操作进行拦截，都改为startService，然后统一在onStartCommond中分发。</p> <p>下面看详细代码：</p> <h3>(1) hook IActivityManager</h3> <p>再次来到PluginManager，发下如下方法：</p> <pre> <code class="language-java">private void hookSystemServices() { try { Singleton<IActivityManager> defaultSingleton = (Singleton<IActivityManager>) ReflectUtil.getField(ActivityManagerNative.class, null, "gDefault"); IActivityManager activityManagerProxy = ActivityManagerProxy.newInstance(this, defaultSingleton.get()); // Hook IActivityManager from ActivityManagerNative ReflectUtil.setField(defaultSingleton.getClass().getSuperclass(), defaultSingleton, "mInstance", activityManagerProxy); if (defaultSingleton.get() == activityManagerProxy) { this.mActivityManager = activityManagerProxy; } } catch (Exception e) { e.printStackTrace(); } }</code></pre> <p>首先拿到ActivityManagerNative中的gDefault对象，该对象返回的是一个 Singleton<IActivityManager> ,然后拿到其mInstance对象，即IActivityManager对象（可以理解为和AMS交互的binder的client对象）对象。</p> <p>然后通过动态代理的方式，替换为了一个代理对象。</p> <p>那么重点看对应的InvocationHandler对象即可，该代理对象调用的方法都会辗转到其invoke方法：</p> <pre> <code class="language-java">@Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { if ("startService".equals(method.getName())) { try { return startService(proxy, method, args); } catch (Throwable e) { Log.e(TAG, "Start service error", e); } } else if ("stopService".equals(method.getName())) { try { return stopService(proxy, method, args); } catch (Throwable e) { Log.e(TAG, "Stop Service error", e); } } else if ("stopServiceToken".equals(method.getName())) { try { return stopServiceToken(proxy, method, args); } catch (Throwable e) { Log.e(TAG, "Stop service token error", e); } } // 省略bindService，unbindService等方法 }</code></pre> <p>当我们调用startService时，跟进代码，可以发现调用流程为：</p> <pre> <code class="language-java">startService->startServiceCommon->ActivityManagerNative.getDefault().startService</code></pre> <p>这个getDefault刚被我们hook，所以会被上述方法拦截，然后调用： startService(proxy, method, args)</p> <pre> <code class="language-java">private Object startService(Object proxy, Method method, Object[] args) throws Throwable { IApplicationThread appThread = (IApplicationThread) args[0]; Intent target = (Intent) args[1]; ResolveInfo resolveInfo = this.mPluginManager.resolveService(target, 0); if (null == resolveInfo || null == resolveInfo.serviceInfo) { // is host service return method.invoke(this.mActivityManager, args); } return startDelegateServiceForTarget(target, resolveInfo.serviceInfo, null, RemoteService.EXTRA_COMMAND_START_SERVICE); }</code></pre> <p>先不看代码，考虑下我们这里唯一要做的就是通过Intent保存关键数据，替换启动的Service类为占坑类。</p> <p>所以直接看最后的方法：</p> <pre> <code class="language-java">private ComponentName startDelegateServiceForTarget(Intent target, ServiceInfo serviceInfo, Bundle extras, int command) { Intent wrapperIntent = wrapperTargetIntent(target, serviceInfo, extras, command); return mPluginManager.getHostContext().startService(wrapperIntent); }</code></pre> <p>最后一行就是启动了，那么替换的操作应该在wrapperTargetIntent中完成：</p> <pre> <code class="language-java">private Intent wrapperTargetIntent(Intent target, ServiceInfo serviceInfo, Bundle extras, int command) { // fill in service with ComponentName target.setComponent(new ComponentName(serviceInfo.packageName, serviceInfo.name)); String pluginLocation = mPluginManager.getLoadedPlugin(target.getComponent()).getLocation(); // start delegate service to run plugin service inside boolean local = PluginUtil.isLocalService(serviceInfo); Class<? extends Service> delegate = local ? LocalService.class : RemoteService.class; Intent intent = new Intent(); intent.setClass(mPluginManager.getHostContext(), delegate); intent.putExtra(RemoteService.EXTRA_TARGET, target); intent.putExtra(RemoteService.EXTRA_COMMAND, command); intent.putExtra(RemoteService.EXTRA_PLUGIN_LOCATION, pluginLocation); if (extras != null) { intent.putExtras(extras); } return intent; }</code></pre> <p>果不其然，重新初始化了Intent，设置了目标类为LocalService（多进程时设置为RemoteService），然后将原本的Intent存储到 EXTRA_TARGET ，携带command为 EXTRA_COMMAND_START_SERVICE ，以及插件apk路径。</p> <h3>（2）代理分发</h3> <p>那么接下来代码就到了LocalService的onStartCommond中啦：</p> <pre> <code class="language-java">@Override public int onStartCommand(Intent intent, int flags, int startId) { // 省略一些代码... Intent target = intent.getParcelableExtra(EXTRA_TARGET); int command = intent.getIntExtra(EXTRA_COMMAND, 0); if (null == target || command <= 0) { return START_STICKY; } ComponentName component = target.getComponent(); LoadedPlugin plugin = mPluginManager.getLoadedPlugin(component); switch (command) { case EXTRA_COMMAND_START_SERVICE: { ActivityThread mainThread = (ActivityThread)ReflectUtil.getActivityThread(getBaseContext()); IApplicationThread appThread = mainThread.getApplicationThread(); Service service; if (this.mPluginManager.getComponentsHandler().isServiceAvailable(component)) { service = this.mPluginManager.getComponentsHandler().getService(component); } else { try { service = (Service) plugin.getClassLoader().loadClass(component.getClassName()).newInstance(); Application app = plugin.getApplication(); IBinder token = appThread.asBinder(); Method attach = service.getClass().getMethod("attach", Context.class, ActivityThread.class, String.class, IBinder.class, Application.class, Object.class); IActivityManager am = mPluginManager.getActivityManager(); attach.invoke(service, plugin.getPluginContext(), mainThread, component.getClassName(), token, app, am); service.onCreate(); this.mPluginManager.getComponentsHandler().rememberService(component, service); } catch (Throwable t) { return START_STICKY; } } service.onStartCommand(target, 0, this.mPluginManager.getComponentsHandler().getServiceCounter(service).getAndIncrement()); break; } // 省略下面的代码 case EXTRA_COMMAND_BIND_SERVICE:break; case EXTRA_COMMAND_STOP_SERVICE:break; case EXTRA_COMMAND_UNBIND_SERVICE:break; }</code></pre> <p>这里代码很简单了，根据command类型，比如 EXTRA_COMMAND_START_SERVICE ，直接通过plugin的ClassLoader去load目标Service的class，然后反射创建实例。比较重要的是，Service创建好后，需要调用它的attach方法，这里凑够参数，然后反射调用即可，最后调用onCreate、onStartCommand收工。然后将其保存起来，stop的时候取出来调用其onDestroy即可。</p> <p>bind、unbind以及stop的代码与上述基本一致，不在赘述。</p> <p>唯一提醒的就是，刚才看到还hook了一个方法叫做： stopServiceToken ，该方法是什么时候用的呢？</p> <p>主要有一些特殊的Service，比如IntentService，其stopSelf是由自身调用的，最终会调用 mActivityManager.stopServiceToken 方法，同样的中转为STOP操作即可。</p> <h2>四、BroadcastReceiver的支持</h2> <p>这个比较简单，直接解析Manifest后，静态转动态即可。</p> <p>相关代码在LoadedPlugin的构造方法中：</p> <pre> <code class="language-java">for (PackageParser.Activity receiver : this.mPackage.receivers) { receivers.put(receiver.getComponentName(), receiver.info); try { BroadcastReceiver br = BroadcastReceiver.class.cast(getClassLoader().loadClass(receiver.getComponentName().getClassName()).newInstance()); for (PackageParser.ActivityIntentInfo aii : receiver.intents) { this.mHostContext.registerReceiver(br, aii); } } catch (Exception e) { e.printStackTrace(); } }</code></pre> <p>可以看到解析到receiver信息后，直接通过pluginClassloader去loadClass拿到receiver对象，然后调用this.mHostContext.registerReceiver即可。</p> <p>开心，最后一个了~</p> <h2>五、ContentProvider的支持</h2> <h3>（1）hook IContentProvider</h3> <p>ContentProvider的支持依然是通过代理分发。</p> <p>看一段CP使用的代码：</p> <pre> <code class="language-java">Cursor bookCursor = getContentResolver().query(bookUri, new String[]{"_id", "name"}, null, null, null);</code></pre> <p>这里用到了PluginContext，在生成Activity、Service的时候，为其设置的Context都为PluginContext对象。</p> <p>所以当你调用getContentResolver时，调用的为PluginContext的getContentResolver。</p> <pre> <code class="language-java">@Override public ContentResolver getContentResolver() { return new PluginContentResolver(getHostContext()); }</code></pre> <p>返回的是一个PluginContentResolver对象，当我们调用query方法时，会辗转调用到</p> <p>ContentResolver.acquireUnstableProvider 方法。该方法被PluginContentResolver中复写:</p> <pre> <code class="language-java">protected IContentProvider acquireUnstableProvider(Context context, String auth) { try { if (mPluginManager.resolveContentProvider(auth, 0) != null) { return mPluginManager.getIContentProvider(); } return (IContentProvider) sAcquireUnstableProvider.invoke(mBase, context, auth); } catch (Exception e) { e.printStackTrace(); } return null; }</code></pre> <p>如果调用的auth为插件apk中的provider，则直接返回 mPluginManager.getIContentProvider() 。</p> <pre> <code class="language-java">public synchronized IContentProvider getIContentProvider() { if (mIContentProvider == null) { hookIContentProviderAsNeeded(); } return mIContentProvider; }</code></pre> <p>咦，又看到一个hook方法：</p> <pre> <code class="language-java">private void hookIContentProviderAsNeeded() { Uri uri = Uri.parse(PluginContentResolver.getUri(mContext)); mContext.getContentResolver().call(uri, "wakeup", null, null); try { Field authority = null; Field mProvider = null; ActivityThread activityThread = (ActivityThread) ReflectUtil.getActivityThread(mContext); Map mProviderMap = (Map) ReflectUtil.getField(activityThread.getClass(), activityThread, "mProviderMap"); Iterator iter = mProviderMap.entrySet().iterator(); while (iter.hasNext()) { Map.Entry entry = (Map.Entry) iter.next(); Object key = entry.getKey(); Object val = entry.getValue(); String auth; if (key instanceof String) { auth = (String) key; } else { if (authority == null) { authority = key.getClass().getDeclaredField("authority"); authority.setAccessible(true); } auth = (String) authority.get(key); } if (auth.equals(PluginContentResolver.getAuthority(mContext))) { if (mProvider == null) { mProvider = val.getClass().getDeclaredField("mProvider"); mProvider.setAccessible(true); } IContentProvider rawProvider = (IContentProvider) mProvider.get(val); IContentProvider proxy = IContentProviderProxy.newInstance(mContext, rawProvider); mIContentProvider = proxy; Log.d(TAG, "hookIContentProvider succeed : " + mIContentProvider); break; } } } catch (Exception e) { e.printStackTrace(); } }</code></pre> <p>前两行比较重要，第一行是拿到了占坑的provider的uri，然后主动调用了其call方法。</p> <p>如果你跟进去，会发现，其会调用acquireProvider->mMainThread.acquireProvider->ActivityManagerNative.getDefault().getContentProvider->installProvider。简单来说，其首先调用已经注册provider，得到返回的IContentProvider对象。</p> <p>这个IContentProvider对象是在ActivityThread.installProvider方法中加入到mProviderMap中。</p> <p>而ActivityThread对象又容易获取，mProviderMap又是它成员变量，那么也容易获取，所以上面的一大坨（除了前两行）代码，就为了拿到占坑的provider对应的IContentProvider对象。</p> <p>然后通过动态代理的方式，进行了hook，关注InvocationHandler的实例IContentProviderProxy。</p> <p>IContentProvider能干吗呢？其实就能拦截我们正常的query、insert、update、delete等操作。</p> <p>拦截这些方法干嘛？</p> <p>当然是修改uri啦，把用户调用的uri，替换为占坑provider的uri，再把原本的uri作为参数拼接在占坑provider的uri后面即可。</p> <p>好了，直接看invoke方法：</p> <pre> <code class="language-java">@Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Log.v(TAG, method.toGenericString() + " : " + Arrays.toString(args)); wrapperUri(method, args); try { return method.invoke(mBase, args); } catch (InvocationTargetException e) { throw e.getTargetException(); } }</code></pre> <p>直接看wrapperUri</p> <pre> <code class="language-java">private void wrapperUri(Method method, Object[] args) { Uri uri = null; int index = 0; if (args != null) { for (int i = 0; i < args.length; i++) { if (args[i] instanceof Uri) { uri = (Uri) args[i]; index = i; break; } } } // 省略部分代码 PluginManager pluginManager = PluginManager.getInstance(mContext); ProviderInfo info = pluginManager.resolveContentProvider(uri.getAuthority(), 0); if (info != null) { String pkg = info.packageName; LoadedPlugin plugin = pluginManager.getLoadedPlugin(pkg); String pluginUri = Uri.encode(uri.toString()); StringBuilder builder = new StringBuilder(PluginContentResolver.getUri(mContext)); builder.append("/?plugin=" + plugin.getLocation()); builder.append("&pkg=" + pkg); builder.append("&uri=" + pluginUri); Uri wrapperUri = Uri.parse(builder.toString()); if (method.getName().equals("call")) { bundleInCallMethod.putString(KEY_WRAPPER_URI, wrapperUri.toString()); } else { args[index] = wrapperUri; } } }</code></pre> <p>从参数中找到uri，往下看，搞了个StringBuilder首先加入占坑provider的uri，然后将目标uri，pkg,plugin等参数等拼接上去，替换到args中的uri，然后继续走原本的流程。</p> <p>假设是query方法，应该就到达我们占坑provider的query方法啦。</p> <h3>（2）代理分发</h3> <p>占坑如下：</p> <pre> <code class="language-java"><provider android:name="com.didi.virtualapk.delegate.RemoteContentProvider" android:authorities="${applicationId}.VirtualAPK.Provider" android:process=":daemon" /></code></pre> <p>打开RemoteContentProvider，直接看query方法：</p> <pre> <code class="language-java">@Override public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) { ContentProvider provider = getContentProvider(uri); Uri pluginUri = Uri.parse(uri.getQueryParameter(KEY_URI)); if (provider != null) { return provider.query(pluginUri, projection, selection, selectionArgs, sortOrder); } return null; }</code></pre> <p>可以看到通过传入的生成了一个新的provider,然后拿到目标uri，在直接调用provider.query传入目标uri即可。</p> <p>那么这个provider实际上是这个代理类帮我们生成的：</p> <pre> <code class="language-java">private ContentProvider getContentProvider(final Uri uri) { final PluginManager pluginManager = PluginManager.getInstance(getContext()); Uri pluginUri = Uri.parse(uri.getQueryParameter(KEY_URI)); final String auth = pluginUri.getAuthority(); // 省略了缓存管理 LoadedPlugin plugin = pluginManager.getLoadedPlugin(uri.getQueryParameter(KEY_PKG)); if (plugin == null) { try { pluginManager.loadPlugin(new File(uri.getQueryParameter(KEY_PLUGIN))); } catch (Exception e) { e.printStackTrace(); } } final ProviderInfo providerInfo = pluginManager.resolveContentProvider(auth, 0); if (providerInfo != null) { RunUtil.runOnUiThread(new Runnable() { @Override public void run() { try { LoadedPlugin loadedPlugin = pluginManager.getLoadedPlugin(uri.getQueryParameter(KEY_PKG)); ContentProvider contentProvider = (ContentProvider) Class.forName(providerInfo.name).newInstance(); contentProvider.attachInfo(loadedPlugin.getPluginContext(), providerInfo); sCachedProviders.put(auth, contentProvider); } catch (Exception e) { e.printStackTrace(); } } }, true); return sCachedProviders.get(auth); } return null; }</code></pre> <p>很简单，取出原本的uri，拿到auth，在通过加载plugin得到providerInfo，反射生成provider对象，在调用其attachInfo方法即可。</p> <p>其他的几个方法：insert、update、delete、call逻辑基本相同，就不赘述了。</p> <p>感觉这里其实通过hook AMS的getContentProvider方法也能完成上述流程，感觉好像可以更彻底，不需要依赖PluginContext了。</p> <h2>六、总结</h2> <p>总结下，其实就是文初的内容，可以看到VritualApk大体方案如下：</p> <ul> <li>Activity：在宿主apk中提前占几个坑，然后通过“欺上瞒下”（这个词好像是360之前的ppt中提到）的方式，启动插件apk的Activity；因为要支持不同的launchMode以及一些特殊的属性，需要占多个坑。</li> <li>Service：通过代理Service的方式去分发；主进程和其他进程，VirtualAPK使用了两个代理Service。</li> <li>BroadcastReceiver：静态转动态。</li> <li>ContentProvider：通过一个代理Provider进行分发。</li> </ul> <p>整体代码看起来还是很轻松的~</p> <p>当然如果你要选择某一个插件化方案进行使用，一定要了解其中的实现原理，文档上描述的并不是所有细节，很多一些属性什么的，以及由于其实现的方式造成一些特性的不支持。了解源码，可以方便自己排查问题，扩展，甚至写一套根据自己业务需求的插件化方案~~</p> <p>再多嘴一句，还是建议大多多在某一方面深入了解，不要痴迷于UI特效（上班路上看看我的推文就好啦~玩笑~，很多特效的，了解下原理即可）~~其实我早期浪费了很多时间在上面，在你掌握了自定义View的详细细节、事件分发机制这些机制后，大部分UI的编写都是时间问题。</p> <p>不要在上面浪费过多时间，比别人多研究几个特效并不会对自己的提升有巨大的帮助，过来人，忠言逆耳~。</p> <p>支持我的话可以关注下我的公众号，每天都会推送新知识~</p> <p>欢迎关注我的微信公众号：hongyangAndroid</p> <p>（可以给我留言你想学习的文章，支持投稿）</p> <p><img src="https://simg.open-open.com/show/c3e50c0dbf308fef67eae2372e27aff0.jpg"></p> <p> </p> <p>来自：http://blog.csdn.net/lmj623565791/article/details/75000580</p> <p> </p>