HansChen的博客

博观而约取,厚积而薄发

Android最大方法数和解决方案

转载请标明出处:http://blog.csdn.net/shensky711/article/details/52329035
本文出自: 【HansChen的博客】

什么是64K限制和LinearAlloc限制

64K限制

随着Android应用功能的增加,代码量不断地增大,当应用方法数量超过了65536的时候,编译的时候便会提示:
这里写图片描述

这个Android著名的Dex 64k method数量上限。那么,是什么原因导致方法数不能超过64K呢?网上搜集了一下资料,原因一般有:

  1. DexOpt优化的限制:当Android系统启动一个应用的时候,有一步是对Dex进行优化,这个过程有一个专门的工具来处理,叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件,即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。但是在早期的Android系统中,DexOpt有一个问题,也就是这篇文章想要说明并解决的问题。DexOpt会把每一个类的方法id检索起来,存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的,导致了方法id的数目不能够超过65536个。当一个项目足够大的时候,显然这个方法数的上限是不够的。尽管在新版本的Android系统中,DexOpt修复了这个问题,但是我们仍然需要对老系统做兼容
  2. dalvik bytecode的限制:因为 Dalvik 的 invoke-kind 指令集中,method reference index 只留了 16 bits,最多能引用 65535 个方法,参考链接:http://stackoverflow.com/questions/21490382/does-the-android-art-runtime-have-the-same-method-limit-limitations-as-dalvik/21492160#21492160http://source.android.com/devices/tech/dalvik/dalvik-bytecode.html

鉴于以上原因,在打包Android应用的时候,会对方法数做一个检测,当方法数超过了DexFormat.MAX_MEMBER_IDX(定义为0Xffff, 注意,这个不是Dex文件格式的限制,Dex文件中存储方法ID用的并不是short类型,无论最新的DexFile.h新定义的u4是uint32_t,还是老版本DexFile引用的vm/Common.h里定义的u4是uint32或者unsigned int,都不是short类型,特此说明)便报错

LinearAlloc限制

即使方法数没有超过65536,能正常编译打包成apk,在安装的时候,也有可能会提示INSTALL_FAILED_DEXOPT而导致安装失败,这个一般就是因为LinearAlloc的限制导致的。这个主要是因为Dexopt 使用 LinearAlloc 来存储应用的方法信息。Dalvik LinearAlloc 是一个固定大小的缓冲区。在Android 版本的历史上,LinearAlloc 分别经历了4M/5M/8M/16M限制。Android 2.2和2.3的缓冲区只有5MB,Android 4.x提高到了8MB 或16MB。当方法数量过多导致超出缓冲区大小时,也会造成dexopt崩溃

谷歌分包方案

谷歌提供了一个multiDex的分包方案,当方法数超过65536的时候,生成多个dex文件,把应用启动时必须用到的类和该类的直接引用类放到main dex中,把其他类放到second dex中。当应用启动之后,动态加载second dex,从而避免64k问题。使用Android Studio很容易实现分包方案:
这里写图片描述

  1. 在build.gradle中添加:multiDexEnabled true
  2. 加入依赖‘compile ‘com.android.support:multidex:1.0.1’’
  3. 让应用的Application类直接使用或者继承MultiDexApplication
  4. 如果你想使用自定义的Application,又不想继承MultiDexApplication,那么可以在attachBaseContext方法里执行MultiDex.install(base)

以上就是谷歌multiDex方案所需做的设置,通过配置multiDex,便可解决64k方法数限制

谷歌multiDex存在的问题

虽然谷歌的分包方案很简单,但是效果并不是那么好,谷歌本身也枚举了分包方案的缺点

  1. 如果在主线程中执行MultiDex.install,加载second dex,因为加载从dex是同步的,会阻塞线程,second dex太大的话,有可能导致ANR
  2. API Level 14之前,由于Dalvik LinearAlloc bug(问题22586,就是上文提到的LinearAlloc问题),很可能会出问题的
  3. 应用程序使用了multiedex配置的,会造成使用比较大的内存
  4. 对于应用程序比较复杂的,存在较多的library的项目。multidex可能会造成不同依赖项目间的dex文件函数相互调用,找不到方法

如何解决谷歌分包方案的问题

针对上面的问题,参考网上的一些解决方案,如美团、facebook、微信等,初步使用的解决方法如下:

  1. 第一次启动的时候,检测到未曾加载过second dex,那么启动欢迎页面(启动新的进程,原来进程进入阻塞等待,注意,此时不会发生ANR,因为已经不是前台进程了),在欢迎页面里面进行second dex的加载,加载完成后通知主线程继续
  2. 设定单个dex文件最大方法数为48000(经验值)而不是65536,避免内存问题
  3. 同上
  4. 控制程序逻辑,未曾加载完second dex之前,进入阻塞等待,直到加载完程序才往下走

下面是流程图:

这里写图片描述

阅读更多
版权声明:本文为博主原创文章,转载请标明出处,谢谢 https://blog.csdn.net/shensky711/article/details/52329035
个人分类: Android
所属专栏: Android
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭