• Dex分包处理及classloader学习


    当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象

    1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT

    2. 方法数量过多,编译时出错,提示:

    Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536  

    出现这种问题的原因是

    1. Android2.3及以前版本用来执行dexopt(用于优化dex文件)的内存只分配了5M

    2. 一个dex文件最多只支持65536个方法。

    针对上述问题,也出现了诸多解决方案,使用的最多的是插件化,即将一些独立的功能做成一个单独的apk,当打开的时候使用DexClassLoader动态加载,然后使用反射机制来调用插件中的类和方法。这固然是一种解决问题的方案:但这种方案存在着以下两个问题:

    1. 插件化只适合一些比较独立的模块;

    2. 必须通过反射机制去调用插件的类和方法,因此,必须搭配一套插件框架来配合使用;

    由于上述问题的存在,通过不断研究,便有了dex分包的解决方案。简单来说,其原理是将编译好的class文件拆分打包成两个dex,绕过dex方法数量的限制以及安装时的检查,在运行时再动态加载第二个dex文件中。faceBook曾经遇到相似的问题,具体可参考:

    https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920

    文中有这么一段话:

    However, there was no way we could break our app up this way--too many of our classes are accessed directly by the Android framework. Instead, we needed to inject our secondary dex files directly into the system class loader。

    文中说得比较简单,我们来完善一下该方案:除了第一个dex文件(即正常apk包唯一包含的Dex文件),其它dex文件都以资源的方式放在安装包中,并在Application的onCreate回调中被注入到系统的ClassLoader。因此,对于那些在注入之前已经引用到的类(以及它们所在的jar),必须放入第一个Dex文件中。

    下面通过一个简单的demo来讲述dex分包方案,该方案分为两步执行:

    整个demo的目录结构是这样,我打算将SecondActivity,MyContainer以及DropDownView放入第二个dex包中,其它保留在第一个dex包。

    一、编译时分包

    整个编译流程如下:

    除了框出来的两Target,其它都是编译的标准流程。而这两个Target正是我们的分包操作。首先来看看spliteClasses target。

    由于我们这里仅仅是一个demo,因此放到第二个包中的文件很少,就是上面提到的三个文件。分好包之后就要开始生成dex文件,首先打包第一个dex文件: 

    由这里将${classes}(该文件夹下都是要打包到第一个dex的文件)打包生成第一个dex。接着生成第二个dex,并将其打包到资资源文件中:

    可以看到,此时是将${secclasses}中的文件打包生成dex,并将其加入ap文件(打包的资源文件)中。到此,分包完毕,接下来,便来分析一下如何动态将第二个dex包注入系统的ClassLoader。

    二、将dex分包注入ClassLoader

    这里谈到注入,就要谈到Android的ClassLoader体系。

    由上图可以看出,在叶子节点上,我们能使用到的是DexClassLoader和PathClassLoader,通过查阅开发文档,我们发现他们有如下使用场景:

    1. 关于PathClassLoader,文档中写到: Android uses this class for its system class loader and for its application class loader(s),

    由此可知,Android应用就是用它来加载;

    2. DexClass可以加载apk,jar,及dex文件,但PathClassLoader只能加载已安装到系统中(即/data/app目录下)的apk文件。

    知道了两者的使用场景,下面来分析下具体的加载原理,由上图可以看到,两个叶子节点的类都继承BaseDexClassLoader中,而具体的类加载逻辑也在此类中:

    BaseDexClassLoader:  

    [java] view plaincopy在CODE上查看代码片派生到我的代码片

    1. @Override  

    2. protected Class<?> findClass(String name) throws ClassNotFoundException {  

    3.     List<Throwable> suppressedExceptions = new ArrayList<Throwable>();  

    4.     Class c = pathList.findClass(name, suppressedExceptions);  

    5.     if (c == null) {  

    6.         ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class "" + name + "" on path: " + pathList);  

    7.         for (Throwable t : suppressedExceptions) {  

    8.             cnfe.addSuppressed(t);  

    9.        }  

    10.         throw cnfe;  

    11.     }  

    12.      return c;  

    13. }  

    由上述函数可知,当我们需要加载一个class时,实际是从pathList中去需要的,查阅源码,发现pathList是DexPathList类的一个实例。ok,接着去分析DexPathList类中的findClass函数,

    DexPathList:

    [java] view plaincopy在CODE上查看代码片派生到我的代码片

    1. public Class findClass(String name, List<Throwable> suppressed) {  

    2.     for (Element element : dexElements) {  

    3.         DexFile dex = element.dexFile;  

    4.         if (dex != null) {  

    5.             Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);  

    6.             if (clazz != null) {  

    7.                 return clazz;  

    8.             }  

    9.         }  

    10.    }  

    11.     if (dexElementsSuppressedExceptions != null) {  

    12.         suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));  

    13.     }  

    14.     return null;  

    15. }  

    上述函数的大致逻辑为:遍历一个装在dex文件(每个dex文件实际上是一个DexFile对象)的数组(Element数组,Element是一个内部类),然后依次去加载所需要的class文件,直到找到为止。

    看到这里,注入的解决方案也就浮出水面,假如我们将第二个dex文件放入Element数组中,那么在加载第二个dex包中的类时,应该可以直接找到。

    带着这个假设,来完善demo。

    在我们自定义的BaseApplication的onCreate中,我们执行注入操作:

    public String inject() {  
    	    File decryptFile = new File(getDir("dex",MODE_PRIVATE), "test.dex");
    		File odexDir = getDir("odex_dir", MODE_PRIVATE);
    		try {
    			InputStream encryptDexIn = getAssets().open("test.dex");
    			decryptDex(encryptDexIn, decryptFile);
    		} catch (IOException e1) {
    			e1.printStackTrace();
    			return "FAIL";
    		}
    		try{
    		pathClassLoader=(PathClassLoader)getBaseContext().getClassLoader();
    		dexClassLoader = new DexClassLoader(decryptFile.getPath(), odexDir.getPath(),getApplicationInfo().nativeLibraryDir, getClassLoader());
    		Object[] dexElements =  getDexElements(getPathList(dexClassLoader));  
    		Object pathList = getPathList(pathClassLoader); 
    		expandFieldArray(pathList,"dexElements",dexElements);
    	        return "SUCCESS";  
    	    } catch (Throwable e) {  
    	        e.printStackTrace();  
    	        return android.util.Log.getStackTraceString(e);  
    	    }  	       
    	}  
    

      

    这是注入的关键函数,分析一下这个函数:

    参数libPath是第二个dex包的文件信息(包含完整路径,我们当初将其打包到了assets目录下),然后将其使用DexClassLoader来加载(这里为什么必须使用DexClassLoader加载,回顾以上的使用场景),然后通过反射获取PathClassLoader中的DexPathList中的Element数组(已加载了第一个dex包,由系统加载),以及DexClassLoader中的DexPathList中的Element数组(刚将第二个dex包加载进去),将两个Element数组合并之后,再将其赋值给PathClassLoader的Element数组,到此,注入完毕。

    这里的expandFieldArray方法根据Android源码multidex.java中的源码内容进行修改即可实现:

    private  void expandFieldArray(Object pathList, String fieldName,
                Object[] extraElements) throws NoSuchFieldException, IllegalArgumentException,
                IllegalAccessException {
            Field jlrField = findField(pathList, fieldName);
            Object[] original = (Object[]) jlrField.get(pathList);
            Object[] combined = (Object[]) Array.newInstance(original.getClass().getComponentType(), original.length + extraElements.length);
            System.arraycopy(original, 0, combined, 0, original.length);
            System.arraycopy(extraElements, 0, combined, original.length, extraElements.length);
            jlrField.set(pathList, combined);
        }
    

    至于getDexElements、getPathList通过反射获得即可。

    现在试着启动app,并在MainActivity(在第一个dex包中)中去启动SecondActivity(在第二个dex包中),启动成功。这种方案是可行。

    但是使用dex分包方案仍然有几个注意点:

    1. 由于第二个dex包是在Application的onCreate中动态注入的,如果dex包过大,会使app的启动速度变慢,因此,在dex分包过程中一定要注意,第二个dex包不宜过大。

    2. 由于上述第一点的限制,假如我们的app越来越臃肿和庞大,往往会采取dex分包方案和插件化方案配合使用,将一些非核心独立功能做成插件加载,核心功能再分包加载。

    关于动态加载时classloader详解

    在项目中我尝试了动态加载second.dex时在当前类中

    如果是通过ForName的反射调动,则没有问题,

    如果是通过直接调用出现classnotfound异常,

    查看相关文档和代码,原因是:

    Class 类中有个静态方法 forName,这个方法和 ClassLoader 中的 loadClass
    方法的目的一样,都是用来加载 class 的,但是两者在作用上却有所区别。
    Class<?> loadClass(String name)
    Class<?> loadClass(String name, boolean resolve)
    我们看到上面两个方法声明,第二个方法的第二个参数是用于设置加载类的时候是否连接该
    类, true 就连接,否则就不连接。
    通过 loadClass 加载类实际上就是加载的时候并不对该类进行解释,因
    此也不会初始化该类。而 Class 类的 forName 方法则是相反,使用 forName 加载的时候就
    会将 Class 进行解释和初始化。


  • 相关阅读:
    [CF920E] Connected Components?
    [CF981E] Addition on Segments
    [BZOJ2152] 聪聪可可
    [CF1355E] Restorer Distance
    [CF1101D] GCD Counting
    [CF827C] DNA Evolution
    [HNOI2008] 明明的烦恼
    [CF712D] Memory and Scores
    [CF609E] Minimum spanning tree for each edge
    后缀自动机应用小结 I
  • 原文地址:https://www.cnblogs.com/twlqx/p/4716026.html
Copyright © 2020-2023  润新知