Android的multidex带来的性能问题－减慢app启动速度

于 2017-04-05 09:52:33 发布
阅读量622 收藏
点赞数 1
分类专栏： android

编辑推荐：稀土掘金，这是一个针对技术开发者的一个应用，你可以在掘金上获取最新最优质的技术干货，不仅仅是Android知识、前端、后端以至于产品和设计都有涉猎，想成为全栈工程师的朋友不要错过！

英文原文：Android’s multidex slows down app startup 

引言

在安卓社区中，65k方法数的限制是一个被多次提及的问题。目前解决这个问题的办法就是用multidex。虽然multidex是谷歌给出的一个非常棒的办法，但是我发现了它对app启动性能存在严重的影响，这点还没有在社区引起重视。我这篇文章的就是为那些还没有听说过这个问题（但是想使用multidexing）的开发者以及那些使用了multidexing，但是想观察本文解决办法所能能赢得性能的伙伴而写的。

blob.png

背景

先为外行做一下科普。安卓app是由被转换成一个.class文件的java写成的。然后这个class文件（以及任何jar依赖）被编译成单个classes.dex文件。然后这个dex文件和一个apk文件（即最终从app商店所下载的东西）所需要的任意资源相组合。

更多参见 这里。

这种编译过程的一个缺陷是一个dex文件系统只允许最多有65k个方法。在安卓的早期，达到65k方法上限的应用解决这个问题的办法就是使用Proguard来减少无用的代码。但是，这个方法有局限，并且只是为生产app拖延了接近65k限制的时间。

为了解决这个问题，谷歌在最近的兼容库中放出了一个针对65k方法限制的解决方案：multidexing。这个方法非常方便并且允许你突破65k方法限制，但是（就如我之前说的），对性能有一个非常严重的影响，可能会减慢app的启动速度。

设置multidex

multidex是一个文档齐全的成熟的解决方案。我强烈推荐遵循安卓开发者网站上的指示来启用multidex。你也可以参考我的github上的项目样例。

NoClassDefFoundError?!

在为项目配置multidexing 的时候，你可能会在运行的时候看到java.lang.NoClassDefFoundError。这意味着app启动的class不在main dex文件中。Android SDK Build Tools 21.1或者更高版本中的Gradle  Android 插件有对multidex 的支持。这个插件使用Proguard 来分析你的项目并在 [buildDir]/intermediates/multi-dex/[buildType]/maindexlist.txt文件中生成一个app启动classes 的列表。但是这个列表并不是100%准确，可能会丢失一些app启动所需的classes 。

YesClassDefFound

为了解决这个问题，你应该在multidex.keep 文件中罗列出那些class，以便让编译器知道在main dex文件中要保持哪些class。

  • 在工程目录中创建一个multidex.keep文件。

  • 把java.lang.NoClassDefFoundError中报告的class列举到multidex.keep文件。(注意: 不要直接修改build目录里的maindexlist.txt ，这个文件每次在编译的时候都会生成)。

  • 添加如下脚本到build.gradle。这个脚本将在编译项目的时候把multidex.keep 和 由Gradle生成的maindexlist.txt 结合在一起。

 
 
  1. android.applicationVariants.all { variant ->
  2.     task "fix${variant.name.capitalize()}MainDexClassList" << {
  3.         logger.info "Fixing main dex keep file for $variant.name"
  4.         File keepFile = new File("$buildDir/intermediates/multi-dex/$variant.buildType.name/maindexlist.txt")
  5.         keepFile.withWriterAppend { w ->
  6.             // Get a reader for the input file
  7.             w.append('\n')
  8.             new File("${projectDir}/multidex.keep").withReader { r ->
  9.                 // And write data from the input into the output
  10.                 w << r << '\n'
  11.             }
  12.             logger.info "Updated main dex keep file for ${keepFile.getAbsolutePath()}\n$keepFile.text"
  13.         }
  14.     }
  15. }
  16. tasks.whenTaskAdded { task ->
  17.     android.applicationVariants.all { variant ->
  18.         if (task.name == "create${variant.name.capitalize()}MainDexClassList") {
  19.             task.finalizedBy "fix${variant.name.capitalize()}MainDexClassList"
  20.         }
  21.     }
  22. }

multidex app启动性能问题

如果你使用multidex，你需要意识到它对app启动性能有影响。我们通过跟踪app的启动时间发现了这个问题－用户点击app图标到所有图片都下载完并显示给用户的这段时间。一旦multidex 启用，在所有运行Kitkat (4.4) 及以下的设备上我们的app启动时间就会大约增加15%。更多信息参考 Carlos Sessa的Lazy Loading Dex files 。

这是因为Android 5.0 以及更高版本使用了一个叫做ART的运行时，它天生就支持从应用的apk文件中加载multiple dex文件。

解决multidex app启动性能问题

在app启动到所有图片显示的间隙，存在着许多没有被Proguard 检测到的class，因此它们也就没有被存进main dex文件中。现在的问题是，我们如何才能知道在app启动期间什么样的calss被加载了呢？

幸运的是，在 ClassLoader中我们有 findLoadedClass 方法。我们的办法就是在app启动结束的时候做一次运行时检查。如果第二个dex 文件中存有任何在app启动期间加载的class，那么就通过添加calss  name 到multidex.keep文件中的方式来把它们移到main dex文件中。我的 项目案例  中有实现的细节，但是你也可以这样做：

  • 在你认为app启动结束的地方运行下面util类中的getLoadedExternalDexClasses 

  • 把上面这个方法返回的列表添加到你的 multidex.keep 文件然后重新编译。

 
 
  1. public class MultiDexUtils {
  2.     private static final String EXTRACTED_NAME_EXT = ".classes";
  3.     private static final String EXTRACTED_SUFFIX = ".zip";
  4.  
  5.     private static final String SECONDARY_FOLDER_NAME = "code_cache" + File.separator +
  6.             "secondary-dexes";
  7.  
  8.     private static final String PREFS_FILE = "multidex.version";
  9.     private static final String KEY_DEX_NUMBER = "dex.number";
  10.  
  11.     private SharedPreferences getMultiDexPreferences(Context context) {
  12.         return context.getSharedPreferences(PREFS_FILE,
  13.                 Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB
  14.                         ? Context.MODE_PRIVATE
  15.                         : Context.MODE_PRIVATE | Context.MODE_MULTI_PROCESS);
  16.     }
  17.  
  18.     /**
  19.      * get all the dex path
  20.      *
  21.      * @param context the application context
  22.      * @return all the dex path
  23.      * @throws PackageManager.NameNotFoundException
  24.      * @throws IOException
  25.      */
  26.     public List<String> getSourcePaths(Context context) throws PackageManager.NameNotFoundException, IOException {
  27.         final ApplicationInfo applicationInfo = context.getPackageManager().getApplicationInfo(context.getPackageName(), 0);
  28.         final File sourceApk = new File(applicationInfo.sourceDir);
  29.         final File dexDir = new File(applicationInfo.dataDir, SECONDARY_FOLDER_NAME);
  30.  
  31.         final List<String> sourcePaths = new ArrayList<>();
  32.         sourcePaths.add(applicationInfo.sourceDir); //add the default apk path
  33.  
  34.         //the prefix of extracted file, ie: test.classes
  35.         final String extractedFilePrefix = sourceApk.getName() + EXTRACTED_NAME_EXT;
  36.         //the total dex numbers
  37.         final int totalDexNumber = getMultiDexPreferences(context).getInt(KEY_DEX_NUMBER, 1);
  38.  
  39.         for (int secondaryNumber = 2; secondaryNumber <= totalDexNumber; secondaryNumber++) {
  40.             //for each dex file, ie: test.classes2.zip, test.classes3.zip...
  41.             final String fileName = extractedFilePrefix + secondaryNumber + EXTRACTED_SUFFIX;
  42.             final File extractedFile = new File(dexDir, fileName);
  43.             if (extractedFile.isFile()) {
  44.                 sourcePaths.add(extractedFile.getAbsolutePath());
  45.                 //we ignore the verify zip part
  46.             } else {
  47.                 throw new IOException("Missing extracted secondary dex file '" +
  48.                         extractedFile.getPath() + "'");
  49.             }
  50.         }
  51.  
  52.         return sourcePaths;
  53.     }
  54.  
  55.     /**
  56.      * get all the external classes name in "classes2.dex", "classes3.dex" ....
  57.      *
  58.      * @param context the application context
  59.      * @return all the classes name in the external dex
  60.      * @throws PackageManager.NameNotFoundException
  61.      * @throws IOException
  62.      */
  63.     public List<String> getExternalDexClasses(Context context) throws PackageManager.NameNotFoundException, IOException {
  64.         final List<String> paths = getSourcePaths(context);
  65.         if(paths.size() <= 1) {
  66.             // no external dex
  67.             return null;
  68.         }
  69.         // the first element is the main dex, remove it.
  70.         paths.remove(0);
  71.         final List<String> classNames = new ArrayList<>();
  72.         for (String path : paths) {
  73.             try {
  74.                 DexFile dexfile = null;
  75.                 if (path.endsWith(EXTRACTED_SUFFIX)) {
  76.                     //NOT use new DexFile(path), because it will throw "permission error in /data/dalvik-cache"
  77.                     dexfile = DexFile.loadDex(path, path + ".tmp", 0);
  78.                 } else {
  79.                     dexfile = new DexFile(path);
  80.                 }
  81.                 final Enumeration<String> dexEntries = dexfile.entries();
  82.                 while (dexEntries.hasMoreElements()) {
  83.                     classNames.add(dexEntries.nextElement());
  84.                 }
  85.             } catch (IOException e) {
  86.                 throw new IOException("Error at loading dex file '" +
  87.                         path + "'");
  88.             }
  89.         }
  90.         return classNames;
  91.     }
  92.  
  93.     /**
  94.      * Get all loaded external classes name in "classes2.dex", "classes3.dex" ....
  95.      * @param context
  96.      * @return get all loaded external classes
  97.      */
  98.     public List<String> getLoadedExternalDexClasses(Context context) {
  99.         try {
  100.             final List<String> externalDexClasses = getExternalDexClasses(context);
  101.             if (externalDexClasses != null && !externalDexClasses.isEmpty()) {
  102.                 final ArrayList<String> classList = new ArrayList<>();
  103.                 final java.lang.reflect.Method m = ClassLoader.class.getDeclaredMethod("findLoadedClass", new Class[]{String.class});
  104.                 m.setAccessible(true);
  105.                 final ClassLoader cl = context.getClassLoader();
  106.                 for (String clazz : externalDexClasses) {
  107.                     if (m.invoke(cl, clazz) != null) {
  108.                         classList.add(clazz.replaceAll("\\.", "/").replaceAll("$", ".class"));
  109.                     }
  110.                 }
  111.                 return classList;
  112.             }
  113.         } catch (Exception e) {
  114.             e.printStackTrace();
  115.         }
  116.         return null;
  117.     }
  118. }

结论

这里是我们在多个设备上观察到的启动性能的提升效果。第一列（蓝色）是没有multidexing的基准app启动时间。你可以在第二列（红色）看到明显的增加，这是启用了multidex但没有其它任何额外工作的app启动时间。第三列（绿色）是开启了multidex 并且使用了我们提升方法的app启动时间。就如图中所看到的，app启动时间降到了multidex开启之前的水平，甚至更低。自己试试吧，你应该也能观察到性能的提升。

blob.png


后记

仅仅因为你能并不意味着你应该。你应该把multidex看成最后的办法因为它对app启动时间存在很大影响而且要解决这个问题你需要维护额外的代码并解决奇怪的错误（比如： java.lang.NoClassDefFoundError）。一旦达到了65k方法数的限制，我们应该先避免去使用multidex以防止性能问题。我们不断的检查使用的sdk找出许多可以移除或者重构的无用代码。只有此时仍然没有办法的时候我们才考虑multidex。那时我们的代码质量也会有个质的飞跃。不要直接使用multidex，要先保持代码的干净，复用现有组建，或者重构代码来避免65k方法数限制。

飞翔的熊blabla
关注
专栏目录
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值