ReDex 主要的优化在于减小 APK 大小以及提高启动速度,分为 6 大点:
1. 基于反馈(启动加载顺序测试)的 Class 字节码布局
类字节码在单个 Dex 中的布局是根据编译顺序而不是运行时行为决定,即便 Multidex 会将 App 定义的组件以及部分启动需要的类放在 Main Dex 中,但依然不是根据运行时顺序布局,这会导致程序启动时需要查找随机分布在 Dex 中的类。
ReDex 会将 APK 在 Lab 中试运行,并跟踪启动时哪些类需要加载,然后将这些类字节码放到 Dex 前部,减少启动时从闪存中寻找类的时间,从而提高 App 启动速度。
2. 混淆和压缩
跟 JS 的压缩以及 Android 的 Proguard 类似。
3. 内联函数
将一些函数直接展开到调用它的函数中,减少函数调用切换的时间消耗。
4. 删除无用的 interfaces
删除只有一个实现的接口,用实现直接代替。一定程度加快函数调用时间,并减少内存空间以及函数引用。
5. 删除无用代码
通过类似早期内存回收的标记-删除策略,删除无用代码。
6. 删除 metadata
metadata 的一些数据在运行中并不需要,用 Dex 中已有的字符串代替源文件引用以及删除无用的注解来减小 Dex 大小。
ReDex 自身的运行速度很快,虽然是针对 Dex 的优化,但接受 APK 参数,方便与已有编译系统集成。
1. 基于反馈(启动加载顺序测试)的 Class 字节码布局
类字节码在单个 Dex 中的布局是根据编译顺序而不是运行时行为决定,即便 Multidex 会将 App 定义的组件以及部分启动需要的类放在 Main Dex 中,但依然不是根据运行时顺序布局,这会导致程序启动时需要查找随机分布在 Dex 中的类。
ReDex 会将 APK 在 Lab 中试运行,并跟踪启动时哪些类需要加载,然后将这些类字节码放到 Dex 前部,减少启动时从闪存中寻找类的时间,从而提高 App 启动速度。
2. 混淆和压缩
跟 JS 的压缩以及 Android 的 Proguard 类似。
3. 内联函数
将一些函数直接展开到调用它的函数中,减少函数调用切换的时间消耗。
4. 删除无用的 interfaces
删除只有一个实现的接口,用实现直接代替。一定程度加快函数调用时间,并减少内存空间以及函数引用。
5. 删除无用代码
通过类似早期内存回收的标记-删除策略,删除无用代码。
6. 删除 metadata
metadata 的一些数据在运行中并不需要,用 Dex 中已有的字符串代替源文件引用以及删除无用的注解来减小 Dex 大小。
ReDex 自身的运行速度很快,虽然是针对 Dex 的优化,但接受 APK 参数,方便与已有编译系统集成。