Android Small插件化原理

最新推荐文章于 2024-03-23 13:53:50 发布

安卓兼职framework应用工程师

最新推荐文章于 2024-03-23 13:53:50 发布

阅读量393

点赞数 2

分类专栏： android

本文链接：https://blog.csdn.net/baidu_41666295/article/details/103735327

版权

android 专栏收录该内容

232 篇文章 40 订阅

订阅专栏

插件化原理(small)
ClassLoader
DexClassLoader 和 PathClassLoader

android 中的calssloader，区别在于DexClassLoader多了一个optimize的优化目录，其可以加载外部的dex，zip，so等包，而pathclassloader只能加载内部的dex，apk等包

而两个都是继承自BaseDexClassLoader ，而BaseDexClassLoader的主要工作是交给DexPathList是做,接下来让我们看看这个DexPathList的构造方法

 public DexPathList(ClassLoader definingContext, String dexPath,
            String libraryPath, File optimizedDirectory) {
        if (definingContext == null) {
            throw new NullPointerException("definingContext == null");
        }
        if (dexPath == null) {
            throw new NullPointerException("dexPath == null");
        }
        if (optimizedDirectory != null) {
            if (!optimizedDirectory.exists())  {
                throw new IllegalArgumentException(
                        "optimizedDirectory doesn't exist: "
                        + optimizedDirectory);
            }
            if (!(optimizedDirectory.canRead()
                            && optimizedDirectory.canWrite())) {
                throw new IllegalArgumentException(
                        "optimizedDirectory not readable/writable: "
                        + optimizedDirectory);
            }
        }
        this.definingContext = definingContext;
        this.dexElements =
            makeDexElements(splitDexPath(dexPath), optimizedDirectory);
        this.nativeLibraryDirectories = splitLibraryPath(libraryPath);
    }

dexPath就是我们需要加载插件的路径，可以看到主要是由makeDexElements这个方法实现

private static Element[] makeDexElements(ArrayList<File> files,
        File optimizedDirectory) {
    ArrayList<Element> elements = new ArrayList<Element>();
    /*
     * Open all files and load the (direct or contained) dex files
     * up front.
     */
    for (File file : files) {
        ZipFile zip = null;
        DexFile dex = null;
        String name = file.getName();
        if (name.endsWith(DEX_SUFFIX)) {
            // Raw dex file (not inside a zip/jar).
            try {
                dex = loadDexFile(file, optimizedDirectory);
            } catch (IOException ex) {
                System.logE("Unable to load dex file: " + file, ex);
            }
        } else if (name.endsWith(APK_SUFFIX) || name.endsWith(JAR_SUFFIX)
                || name.endsWith(ZIP_SUFFIX)) {
            try {
                zip = new ZipFile(file);
            } catch (IOException ex) {
                /*
                 * Note: ZipException (a subclass of IOException)
                 * might get thrown by the ZipFile constructor
                 * (e.g. if the file isn't actually a zip/jar
                 * file).
                 */
                System.logE("Unable to open zip file: " + file, ex);
            }
            try {
                dex = loadDexFile(file, optimizedDirectory);
            } catch (IOException ignored) {
                /*
                 * IOException might get thrown "legitimately" by
                 * the DexFile constructor if the zip file turns
                 * out to be resource-only (that is, no
                 * classes.dex file in it). Safe to just ignore
                 * the exception here, and let dex == null.
                 */
            }
        } else {
            System.logW("Unknown file type for: " + file);
        }
        if ((zip != null) || (dex != null)) {
            elements.add(new Element(file, zip, dex));
        }
    }
    return elements.toArray(new Element[elements.size()]);
}

该方法返回的是一个element的数组。
看到这里，我们先不用深入理解makeDexElements内部的逻辑实现，先思考一个问题，何为插件化？
我们做插件的目的是有很多种，例如：减少包体积，热更新。。。
插件化意味着宿主和插件之间能够进行通信，宿主可以调用插件里的对象，宿主可以访问插件里的资源等等。

所以每个BaseDexClassLoader构造完之后都会有一个dexElements，这就说明宿主的classloader有一个，我们插件内部自己的classloader也会有一个，说到这里已经说明插件化类访问的原理了。其核心就是分为以下步骤:

宿主的classloader通过反射拿到内部的dexPathList数组
构造一个我们插件的DexClassLoader（而不是PathClassLoader），然后通过反射拿到其中的dexPathList数组
将两个数组进行合并，然后通过反射设置会宿主的classloader中
事实上，Android官方的multidex就是这个原理。完成这些步骤以后，我们在宿主中就可以调用插件的类了，但是工作还没完，资源如何访问？

Resources
设想一个问题，我们将两个dexPathList进行了合并，此时宿主可以调用插件,但是假设插件内部根据一个id查找一个资源，会报ResourcesNotFind的异常，为什么呢？我们来看看源码，假设当前处在插件中的某个activity，根据id获取获取某个drawable并设置进
imageview中

    imageview.setImageDrawable(getResources().getDrawable(R.drawable.ic_launcher_background))

最终回到ContextThemeWrapper中：

    @Override
    public Resources getResources() {
        return getResourcesInternal();
    }

    private Resources getResourcesInternal() {
        //mResouces为空
        if (mResources == null) {
            if (mOverrideConfiguration == null) {
                    //将会调用super.getResources()
                mResources = super.getResources();
            } else {
                final Context resContext = createConfigurationContext(mOverrideConfiguration);
                mResources = resContext.getResources();
            }
        }
        return mResources;
    }

而super.getReources最终实现是ContextImpl.getResources()中
而ContextImpl是在ActivityThread中由系统执行各个步骤时创建的，我们插件化的activity根本不会走这样一套流程(如果走这套流程的话，插件化就毫无意义啦~~)
所以，拿到的ContextImpl则是宿主的。而这个ComtextImpl在Application到Activity的各个阶段都会有所区别

具体在于，Application的mBase成员是通过ContextImpl.createAppContext经过attachBaseContext后创建的，而Activity的mBase成员是通过ContextImpl.createActivityContext创建的，两者的区别有兴趣可以阅读下源码

无论以哪种方式，最终都会来到ResourcesManager.getOrCreateResources（）方法创建资源对象，
而经过层层判断之后，又会来到createResourcesImpl()方法，
而createResourcesImpl()内部

    private @Nullable ResourcesImpl createResourcesImpl(@NonNull ResourcesKey key) {

        final AssetManager assets = createAssetManager(key);
        if (assets == null) {
            return null;
        }

        final DisplayMetrics dm = getDisplayMetrics(key.mDisplayId, daj);
        final Configuration config = generateConfig(key, dm);
        final ResourcesImpl impl = new ResourcesImpl(assets, dm, config, daj);


        return impl;
    }

而createAssetManager（）方法：

 protected @Nullable AssetManager createAssetManager(@NonNull final ResourcesKey key) {
        AssetManager assets = new AssetManager();

        // resDir can be null if the 'android' package is creating a new Resources object.
        // This is fine, since each AssetManager automatically loads the 'android' package
        // already.
        if (key.mResDir != null) {
        
                //看到这里大概猜到为什么插件无法访问资源了
            if (assets.addAssetPath(key.mResDir) == 0) {
                    ...
                return null;
            }
        }
            
        ...
        ...

        return assets;
    }

原来assets.addAssetPath（）方法是把key.mResDir加进去assetmanager中，这样就可以访问到资源，mResDir就是res文件
至此我们终于知道为啥在插件访问不到资源了。

看到这里有两个实现方法

在插件的Activity重写getResources方法，然后根据重新创建一个AssetManager，这样插件内的资源可能通过自己的AssetManager进行资源
通过反射拿到宿主的AssetManager，然后调用内部addAssetPath()将当前插件的路径传进去，相当于进行资源的合并。
这两种方法都可行，第一种会导致资源爆炸，宿主一份，插件一份，而且这里面的资源无法公用。第二种则会导致资源id冲突，但是可以通过某些手段进行控制（比如控制分配id的段达到防止资源id冲突）

而small用的是第二种，并且配合gradle介入资源id段(PP)的分配情况
具体原理则是：在gradle执行到mergeAndroidResources这个task时，将R.java，R.txt替换为small extention中配置的packageId字段，并且替换完成后，重写整个resources.arsc文件，将原来的arsc文件里面的索引的id替换成配置后的id。如原来生成的id为0x7F010001 替换成自定义 0x21010001

替换资源id这个方法，除了上述这个之外，还可以手动修改AAPT的源码,然后重新编译一个aapt工具

至此，资源也可以访问了。

四大组件
类和资源都可以访问了，我们都知道四大组件要在宿主的AndroidManifest.xml中注册才可以使用，否则会提示找不到该component。以activity为例，如果将插件中的activity在宿主AndroidManifest中注册,那插件化将毫无意义，因为每次有新activity都需要更新宿主，插件的思想也就无从谈起。

有什么办法可以做到不在宿主中注册也可以调用呢？

Small使用hook，主要是hook住Instrumentation,ActivityThread和mH这几个类。

App创建过程说过 Instrumentation最初的目的是为了给UI测试预留的接口，没想到可以被插件化玩出花样来，可能谷歌一开始也没想到。

步骤如下：

Step 1

public static void hookInstrumentation() {
        
        try {
            Class at = Class.forName("android.app.ActivityThread");
            Method atMethod = at.getDeclaredMethod("currentActivityThread",null);
            atMethod.setAccessible(true);
            Object activityThread = atMethod.invoke(null,null
            );
            
            Field instruFiled = at.getDeclaredField("mInstrumentation");
            instruFiled.setAccessible(true);
            Instrumentation instrumentation = (Instrumentation) instruFiled.get(activityThread);
            
            TestInstrumentationWrapper wrapper = new TestInstrumentationWrapper(instrumentation);
            instruFiled.set(activityThread, wrapper);
            Log.d(TAG,"hook init success");
        } catch (Throwable e) {
            e.printStackTrace();
        }
        
    }
    
    private static class TestInstrumentationWrapper extends Instrumentation {
        
        private Instrumentation mBase;
        
        public TestInstrumentationWrapper(Instrumentation base) {
            mBase = base;
        }
        
        public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target, Intent
                intent,
                int requestCode, Bundle options) {
            Log.d(TAG, "TestInstrumentationWrapper hook 1");
            //step1
            return realExecStartActivity1(who, contextThread, token, target, intent, requestCode, options);
        }
        
        public ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, String target, Intent intent,
                int requestCode, Bundle options) {
            
            Log.d(TAG, "TestInstrumentationWrapper hook 2");
            
            return realExecStartActivity2(who, contextThread, token, target, intent, requestCode, options);
        }
        
        public ActivityResult execStartActivity(
                Context who, IBinder contextThread, IBinder token, String resultWho,
                Intent intent, int requestCode, Bundle options, UserHandle user) {
            
            Log.d(TAG, "TestInstrumentationWrapper hook 3");
            
            return realExecStartActivity3(who,contextThread,token,resultWho,intent,requestCode,options,user);
        }
        
        @SuppressWarnings("NewApi")
        private ActivityResult realExecStartActivity3(Context who, IBinder contextThread, IBinder token, String resultWho,
                Intent intent, int requestCode, Bundle options, UserHandle user) {
            ActivityResult activityResult = null;
            try {
                Class c = mBase.getClass();
                Method execStartActivity = c.getDeclaredMethod("execStartActivity",
                        Context.class,
                        IBinder.class,
                        IBinder.class,
                        String.class,
                        Intent.class,
                        int.class,
                        Bundle.class,
                        UserHandle.class
                );
                
                activityResult = (ActivityResult) execStartActivity.invoke(mBase,
                        who,
                        contextThread,
                        token,
                        resultWho,
                        intent,
                        requestCode,
                        options,
                        user
                );
                
            } catch (Exception e) {
                e.printStackTrace();
            }
            
            return activityResult;
            
        }
        
        
        private ActivityResult realExecStartActivity2(Context who, IBinder contextThread, IBinder token, String target,
                Intent intent, int requestCode, Bundle options) {
            ActivityResult activityResult = null;
            try {
                Class c = mBase.getClass();
                Method execStartActivity = c.getDeclaredMethod("execStartActivity",
                        Context.class,
                        IBinder.class,
                        IBinder.class,
                        String.class,
                        Intent.class,
                        int.class,
                        Bundle.class
                );
                
                activityResult = (ActivityResult) execStartActivity.invoke(mBase,
                        who,
                        contextThread,
                        token,
                        target,
                        intent,
                        requestCode,
                        options
                );
                
            } catch (Exception e) {
                e.printStackTrace();
            }
            
            return activityResult;
            
        }
        
        private ActivityResult realExecStartActivity1(Context who, IBinder contextThread, IBinder token, Activity target,
                Intent intent, int requestCode, Bundle options) {
            ActivityResult activityResult = null;
            try {
                Class c = mBase.getClass();
                Method execStartActivity = c.getDeclaredMethod("execStartActivity",
                        Context.class,
                        IBinder.class,
                        IBinder.class,
                        Activity.class,
                        Intent.class,
                        int.class,
                        Bundle.class
                );
                
                activityResult = (ActivityResult) execStartActivity.invoke(mBase,
                        who,
                        contextThread,
                        token,
                        target,
                        intent,
                        requestCode,
                        options
                );
                
            } catch (Exception e) {
                e.printStackTrace();
            }
            
            return activityResult;
            
        }
        
        @Override
        public Activity newActivity(ClassLoader cl, String className, Intent intent)
                throws InstantiationException, IllegalAccessException, ClassNotFoundException {
            //step2
            //在这里实例化插件的activity
            return super.newActivity(cl, className, intent);
        }


    // on Applicaiton
    
class App : Application(){

    override fun onCreate() {
        super.onCreate()
        HookUtil.hookInstrumentation()
    }
    
}

在MainActivity中通过intent启动一个TestActivity，运行结果：

2019-03-23 15:36:09.820 6537-6537/com.example.simpleapp D/Hook: hook init success
2019-03-23 15:36:13.068 6537-6537/com.example.simpleapp D/Hook: TestInstrumentationWrapper hook 1

此时我们已经hook住了startActivity过程，那么我可以在宿主中占坑一个ProxyActivity，在启动插件activity的过程中，重定向至ProxyActivity达到偷梁换柱的目的。

step2:
有去有回，经过上面已经可以做到将插件的activity换了个皮变成宿主中的ProxyActivity,但是怎么将这个ProxyActivity换回来呢？

这涉及app启动流程，主要是本地app进程（ActivityThread）和系统SystemServer进程(ActivityManagerService)进行binder通信的过程,有兴趣的看下之前写过的一篇文章分析app创建流程

现在我们只需要知道，Context.startActivity()最终会来到

ActivityStackSupervisor.realStartActivityLocked()


  final boolean realStartActivityLocked(ActivityRecord r, ProcessRecord app,
            boolean andResume, boolean checkConfig) throws RemoteException {
    
    ...
     app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
                        System.identityHashCode(r), r.info,
                        // TODO: Have this take the merged configuration instead of separate global
                        // and override configs.
                        mergedConfiguration.getGlobalConfiguration(),
                        mergedConfiguration.getOverrideConfiguration(), r.compat,
                        r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
                        r.persistentState, results, newIntents, !andResume,
                        mService.isNextTransitionForward(), profilerInfo);           
 
 
 }

而app.thread是ApplicationThread，它是一个ActivityThread的内部类，可以理解为在ActivityManagerService这一侧的ActivityThread代理对象，主要是通过binder与远端(app进程)进行调用，接着我们分析

 public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
                ActivityInfo info, Configuration curConfig, Configuration overrideConfig,
                CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor,
                int procState, Bundle state, PersistableBundle persistentState,
                List<ResultInfo> pendingResults, List<ReferrerIntent> pendingNewIntents,
                boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) {

            updateProcessState(procState, false);

            ActivityClientRecord r = new ActivityClientRecord();

            r.token = token;
            r.ident = ident;
            r.intent = intent;
            r.referrer = referrer;
            r.voiceInteractor = voiceInteractor;
            r.activityInfo = info;
            r.compatInfo = compatInfo;
            r.state = state;
            r.persistentState = persistentState;

            r.pendingResults = pendingResults;
            r.pendingIntents = pendingNewIntents;

            r.startsNotResumed = notResumed;
            r.isForward = isForward;

            r.profilerInfo = profilerInfo;

            r.overrideConfig = overrideConfig;
            updatePendingConfiguration(curConfig);

            sendMessage(H.LAUNCH_ACTIVITY, r);
        }

主要是通过mH这个handler发送消息然后进行处理，最终又会来到performLaunchActivity这个方法里面:

 private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
        ...
        ...
        Activity activity = null;
        try {
            java.lang.ClassLoader cl = appContext.getClassLoader();
            activity = mInstrumentation.newActivity(
                    cl, component.getClassName(), r.intent);
            StrictMode.incrementExpectedActivityCount(activity.getClass());
            r.intent.setExtrasClassLoader(cl);
            r.intent.prepareToEnterProcess();
            if (r.state != null) {
                r.state.setClassLoader(cl);
            }
        } catch (Exception e) {
            if (!mInstrumentation.onException(activity, e)) {
                throw new RuntimeException(
                    "Unable to instantiate activity " + component
                    + ": " + e.toString(), e);
            }
        }

        ...
        ...


        return activity;
    }

就是利用Instrumentation.newActivity()方法通过反射调用实例化我们插件中的activity，从而将插件中的activity交给系统托管。

而Small正是利用了这一点，核心原理大概讲完了.而其余组件的

总结
当然这里只是对核心原理进行了一下简略的描述，要想达到生产需求还要许多工作要做。

例如：正确区分宿主的activity和插件的activity，当某个activity处在宿主中且已注册时，直接跳过插件化的步骤，交给系统处理即可。

再例如，当我们的需求需要在start多个相同的launchMode的activity时，需要在宿主占坑多少个这样的proxy activity？

像上文提到的mH这个handler，我们其实可以hook住这个mH然后所有的分发事件。插件化的实现有很多种，但无非都是在App创建流程中在ActivityThread，Instrumentation,ActivityManagerNative(AMS的本地代理对象)做文章，所以理解App创建流程对于插件化思想至关重要，说不定可以找到某个新奇的突破点进行插件化。

值得一提的是Android9开始对反射进行限制，像反射调用ActivityThread里的currentActivityThread(),mH都被标为浅灰名单。
可能在日后的版本中插件化思想将不能使用了。。。

安卓兼职framework应用工程师

关注

2
点赞
踩
3

收藏

觉得还不错? 一键收藏
打赏
1
评论
Android Small插件化原理

插件化原理(small)ClassLoaderDexClassLoader 和 PathClassLoaderandroid 中的calssloader，区别在于DexClassLoader多了一个optimize的优化目录，其可以加载外部的dex，zip，so等包，而pathclassloader只能加载内部的dex，apk等包而两个都是继承自BaseDexClassLoader ，而B...
复制链接

扫一扫