包体积优化

为什么需要优化包体积

• 下载转化率，包体积增加不利于用户下载
• 推广成本，包体积增大推广成本也会加大
• 应用市场限制

包体积与性能

• 安装时间，文件拷贝、Library解压、编译ODEX，签名校验等随着包体积增大，耗时也会相应增加
• 运行内存，Resource资源、Library以及Dex类加载这些都会占用不少内存
• ROM空间，如果闪存空间不足，非常容易出现写入放大的情况。

包体积优化

海外Google Play市场，可以根据用户的ABI、density和language发布，也可以使用App Bundle。

1、代码

ProGuard

仔细检查配置文件，尤其是第三方SDK，是不是存在过度keep的现象。一般来说，应用都会keep住四大组件以及View的部分方法，这样是为了再代码和XML布局中可以引用到它们。事实上，我们完全可以把非exported的四大组件以及View混淆，但是需要完成下面几个工作：

• XML替换，在代码混淆之后，需要同时修改AndroidManifest以及资源文件XML中引用的名称。
• 代码替换，需要遍历其他已经混淆好的代码，将变量或者方法体中定义的字符串也同时修改。需要注意的是，代码中不能出现经过运算得到的类名，这种情况会导致替换失败。

去掉Debug信息或者去掉行号

DebugItem里面主要包含两种信息：

• 调试的信息，函数的参数变量和所有的局部变量
• 排查问题的信息，所有的指令集行号和源文件的对应关系。

Dex分包

如下图所示如果将Class A与Class B分别编译到不同的Dex中，由于method a 调用了method b，所以在classes2.dex中也需要加上method b的id。

因为跨dex调用造成的这些冗余信息，它对Dex的大小会造成如下影响：

• method id爆表，每个Dex的method id需要小于65536，因为method id的大量冗余导致每个Dex真正可以放Class变少，这是造成最终编译的Dex数量增多
• 信息冗余，因为我们需要记录跨Dex调用的方法的详细信息，所以classes2.dex还需要记录Class B以及method b的定义，造成string_ids、type_ids、proto_ids这几部分信息的冗余。

Dex压缩

逆向Facebook的App时会惊讶的发现，它只有一个700多KB的Dex，事实上Facebook APP的dex只是一个壳，真正的代码都放到assets下面，它们把所有的Dex都合并成同一个secondary.dex.jar.xzs文件，并通过XZ压缩。
XZ压缩算法和7-Zip一样内部使用的都是LZMA算法，对于Dex格式来说，XZ的压缩可以比Zip高30%左右。这套方案似乎存在一些问题：

• 首次启动解压，应用首次启动时，需要将secondary.dex.jar.xzs解压缩，Facebook使用多线程解压的方式，这个耗时在高端机是几百毫秒左右，在低端机可能需要3~5秒。

• ODEX文件生成，当Dex非常多的时候回增加应用安装时间，对于Facebook的这个做法，首次生成ODEX的时间可能会达到分钟级。Facebook为解决这个问题，使用了ReDe的oatmeal。
  oatmeal的原理非常简单，就是更具ODEX文件的格式，自己生成一个ODEX文件，它生成的结果跟解释执行的ODEX一样，内部是没有机器码的。

  
  

2、Native Library

Library压缩

跟Dex压缩一样，Libray优化的有效方法就是使用XZ或者7-Zip压缩。Facebook有一个So加载的开源库SoLoader，它可以跟改套方案配合使用。和Dex压缩一样，压缩方案的主要缺点在于首次启动的时间，毕竟对于低端机来说，多线程的意义不大，一次我们要再包体积和用户体验之间做好平衡。

Library合并与裁剪

• Library合并，在Android4.3之前，进程加载的Library数量是有限制的，在编译过程，可以自动将部分Library合并成一个。

• Library裁剪，Buck里面有个relinker的功能，原理就是分析代码中JINI方法以及不同Library的方法调用，找到没有使用的导出symbol，将它们删掉，这样linker在编译的时候也会把对应的无用代码同时删除。

  
  

AndResGuard工具

1、资源混淆

ProGuard的优化核心主要有三个:Shrink、Optimize和Obfuscate，也就是裁剪、优化和混淆。资源混淆的思路其实非常简单，就是把资源文件和文件的名字混淆成短路径，这样做有如下优化作用：

• resources.arsc，因为资源文件resources.arsc需要记录资源文件的名称与路径，使用混淆后的段路径，可以减少整个文件的大小。
• metadata签名文件，签名文件MF与SF都需要记录所有文件的路径及它们的哈希值，使用短路径可以减少这两个文件的大小。
• ZIP文件索引，ZIP文件格式里面也需要记录每个文件的Entry的路径、压缩算法、CRC、文件大小等信息，使用短路径本身就可以减少记录文件路径的字符串大小。

2、极限压缩

• 更高的压缩率
• 压缩更多的文件

资源合并

在资源混淆方案中，发现资源文件的路径对于resources.arsc、签名信息以及ZIP文件信息都会有影响，而且资源文件数量非常之多，导致这部分体积非常客观。
那我们能否将所有资源文件都合并成同一个大文件，这样做肯定会比资源混淆方案更好。事实上大部分的换肤方案也是采用这个思路，这个大资源文件就相当于一套资源文件。

• 资源的解析，我们需要模拟系统实现资源文件的解析，例如把PNG、JPG以及文件转换为Bitmap或者Drawable，这样获取资源文件的方法需要改成我们自定义的方法。
• 资源的管理，考虑到内存和启动时间，所有的资源有是用时架子，我们需要使用mmap来加载“Big resource File”，同时还要实现自己的资源缓存池ResourceCache，释放不再使用的资源文件。

无用资源

• Lint
• shrindResources