旧文一篇,看到移动开发前线推送了MultiDex工作原理分析和优化方案,也将我们的MultiDex启动优化思路分享给社区

MultiDex存在的问题

我们经常说的MultiDex,可以分成运行时和编译时两个部分:

  • 编译时的分包机制,将app中的class以某种策略将class分散在多个dex中,目的是减少为了第一个dex也就是main dex中包含的class。

  • 运行时: app启动时,虚拟机只加载main dex中的class。app启动以后,使用Multidex.install API,通过反射修改ClassLoader中的dexElements加载其他dex。

MultiDex机制的出现本身是为了避免出现app 65535问题的出现,但随着业务逻辑的增长,以及不合理的模块划分,可能会导致main dex的方法数也超出了65535,这就导致了main dex capacity exceeded异常。

此外,Multidex的接入额外还会对app的启动性能造成影响。Multidex在install时需要加载dex,首次启动时还需要做odex的转换,而这些都是在ui主线程中完成。 根据 Carlos Sessa的测试,启用multidex后,4.4或以下的设备,app的启动时间平均会增加15%,更严重的情况,甚至在启动时候会出现了黑屏。

目前部分app采取的策略是,放弃掉Multidex的 …


查看全文
Posted by 郑文