来自微信团队的Apk瘦身经验
用户抱怨安装包越来越大？印度友人反馈装不上微信？欢迎来到本期的走进科学--安装包速成记。做一个有节操的安装包，我们希望它越小越好，并且确保用户都能安装的上。
Android的安装包，简单来说就是一个压缩包，首先我们了解一下它的生成过程。
一、安装包编译过程
一般我们使用ant、gradle等方式编译生成安装包，它一般包含以下几个步骤。
但是对于多library的结构下，ant与gradle的并行度并不足够。当前微信已经切换到Facebook的开源编译工具buck(相关介绍http://facebook.github.io/buck/)，编译速度得到了大大提升。
在buck的基础上我们主要做了以下两个工作：
EclipseToBuck，开发者无须关心buck脚本的编写，buck脚本使用代码自动生成
微信使用多library结构，每次编译后监控每个模块的线性内存、方法数、资源大小。
二、减少安装包大小的Tips
现在我们开始第一项主要内容，如何减少安装包的体积？
1. 安装包监控
我们做安装包优化，首先要对我们安装包每一部分有一个详细的了解，知道安装包大在什么地方，与上一版本有着怎么样的变化。所以我们首先实现了一个安装包检测工具：
监控
1. 每个dex方法数的变更情况；
2. 每个模块线性内存的变化情况；
3. 没有alpha通道的png图，可压缩成jpg减少体积；
4. 超过一定数值的大文件，特别是图片资源可采用有损压缩；
5. 安装包的大小、文件数变化；
6. 新增文件、减少文件，文件大小发生变化的情况；
现时微信的安装包监控包括两个维度，一是每日的监控，采用的是最后一个包与昨日的最后一个包对比；二是版本之间的对比，发布前需要用待上线版本与线上版本对比。我们希望若发现问题，能立刻警报，提交到bug系统。
2. 删除无用资源
在产品的大锤下，每个模块不修改个三五十次，都不好意思说自己是微信的开发。在不停的迭代中，或多或少会出现无用的资源，包括但不限于xml、png、id、string。
查找无用资源主要使用lint的UnusedResources以及UnusedIds两个检查规则，但是针对多library结构，官方的lint在某些方面不符合我们的要求，所以我们修改了一些地方。
对于使用gradle的童鞋，可以采用：
android {
...
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
} 3. 图片处理
.png、.9.png、.jpg、.gif资源是每一个安装包永远的痛，追求美感的设计师希望每个像素都是完美的。这边的tip有以下几点：
详细描述
1.对于体积特别大(超过50k)的图片资源可以考虑有损压缩，jpg采用优图压缩，png尝试采用pngquant压缩，输出视觉判断是否可行；
2.对assets中的图片资源也使用aapt的crunch做图片预处理；
3.crunch有可能会使图片变大，在这种情况，我们可以替换成原图。需要注意的是对于.9.png，由于crunch过程中去除了黑边，所以不能替换；
4.对于没有透明区域的png图片，可以转成jpg格式。
4. 字符串编码
为了节省空间，resources.arsc中的会有一个去重过的字符串资源池(相同的两个字符串其实用的是同一份)，每个String使用偏移值来获取资源池中的数值。ResourceTable的编码对于resources.arsc的体积有很大影响。
从Android 2.2 API Level8开始APK文件的资源resources.arsc的编码有了小幅的改变，过去使用的是UTF-16编码方式被转换成了UTF-8编码。这样的好处就是处理纯英文等直接通过ascii存储语言的国家资源文件将会更小，而对于中文、日文这些国家的资源文件有可能会变大。
bool getUTF16StringsOption() {
return mWantUTF16 || !isMinSdkAtLeast(SDK_FROYO);
}
当然如果你发现使用UTF-8后resources.arsc反而变大，你可以强制使用UTF-16编码。只需要在aapt中指定--utf16参数，也就是指定mWantUTF16为true(下面的注释似乎跟代码有出入)。
" --utf16\n"
" changes default encoding for resources to UTF-16. Only useful when API\n"
" level is set to 7 or higher where the default encoding is UTF-8.\n"
微信5.2.1把minSdkVersion更改到8，使用utf8编码后，resources.arsc减少了将近1M。
5. 指定文件的压缩方式与7zip压缩
安装包是一个压缩文件，我们可以指定里面的文件采用哪种压缩方式。假若我们输入下面的命令：
aapt l <file_path.apk>
参数：
-v:会以table的形式输出目录，table的表目有：Length、Method、Size、Ratio、Date、Time、CRC-32、Name。
其中Method表示压缩形式，有：Deflate及Stored两种，即该Zip目录采用的算法是压缩模式还是存储模式；可以看出resources.arsc、*.png采用存储模式，而其它采用压缩模式。
有时候我们为了把某个数据文件不压缩，而把它的后缀名改成png(其实可以指定appt参数 -0 )。其实aapt对于某些压缩率不会太高的文件都默认使用了Stored模式。具体如下：
/* these formats are already compressed, or don't compress well */
static const char* kNoCompressExt[] = {".jpg", ".jpeg", ".png", ".gif", ".wav", ".mp2", ".mp3", ".ogg", ".aac", ".mpg", ".mpeg", ".mid", ".midi", ".smf", ".jet", ".rtttl", ".imy", ".xmf", ".mp4", ".m4a", ".m4v", ".3gp", ".3gpp", ".3g2", ".3gpp2", ".amr", ".awb", ".wma", ".wmv"};
文件如果采用Deflate方式存储，意味着通过AssetManager读取时需要解压，耗费的时间与文件的压缩比成比例。但大家记得这里面有一个坑，在Android 2.3以前的任何压缩的资源的原始大小超过1M，AssetManger读取时会抛出异常。这里面的Tip有：
Tips
1. 对.png、.jpg强制压缩，但是的确普遍压缩率在3%-5%，收益不是特别高；
2. 假若你的resources.arsc小于1M，可以对它进行压缩，这边可压缩50-70%。需要注意的是，如果你的resources.arsc是压缩的，程序需要把它读到内存，也就是会增大运行内存；
3. 对于安装包中的jar可以指定不压缩，其实二次压缩的压缩率非常低；
此外，7z压缩算法号称优化了字典，完全兼容zip，使用7zip的最大压缩模式比传统zip方式的确有所提升，但是这里需要注意两个问题：
上文kNoCompressExt说到的流媒体文件，是通过mediaplay直接拿文件句柄(没有像assetmanager会先解压文件，要求文件是seekable)也不能压缩。
那么说一般来说只有.jpg、.jpeg、.png、.gif可以压缩，对于不需要兼容低版本或者resources.arsc小于1M的apk，可选择压缩resources.arsc。
6. C++的So库
5.1. C++运行时库统一使用stlport_shared
之前微信中的C++运行库大多使用静态编译方式，使用stlport_shared方式可减小APK包大小，相当于把大家公有的代码提取出来放一份，减少冗余。同时也会节省一点内存，加载so的时候动态库只会加载一次，静态库则随着so的加载被加载多份内存映像。
5.2. 把公用的C++模块抽成功能库
其实与上面的思路是一致的，主要为了减少冗余模块。大家都用到的一些基础功能，应该抽成基础模块。
7. 语言包动态加载
由于微信是一个国际化软件，我们在String中添加了20多种语言支持。这也导致我们的resources.arsc有5M多之巨，尝试过假如只留下默认的中文，resources.arsc可减少超过一半。事实上，大多数的语言我们并没有使用到，这里提到的一个思路是动态下发语言包，程序中继承Resource实现getString方式读取即可。
假若你的apk并不要求联网，要求用户动态下发语言包似乎不work。这里在研究buck编译的时候看到另外一个思路，即把大部分的语言二进制存放在assets。这个由于是普通数据文件，采用Deflate压缩方式，会有比较大的压缩率(与数据存储方式也有关系)。
8. 资源混淆
我们常常用proguard来混淆代码，那我们有没有想过资源是否可以混淆？而混淆资源能带来什么样的好处？
建议
1. 比较酷，让反编译的人更加难受一下。面对一大堆以a,b,c,d命名的png、xml;
2. 由于resources.arsc需要记录id与name的键值对，资源混淆对减少安装包体积也有帮助。具体数值与编码方式、id数量、平均减少命名长度有关(其实可以自己估量一下)。
微信的资源混淆工具不依赖源码，只要输入一个apk就能得到一个混淆之后的apk，大家有兴趣的话，可以后续单独来讲。通过资源混淆微信大约能减少1M左右的大小，效果如下：
9. 持续交付
持续交互的终极目标就是让使用某个功能的人才会真正去下载某个模块，这首先需要我们代码结构的支持，即模块化以及支持动态加载。微信对gpserver、打飞机等功能试用动态加载方式。其实这块的核心思想就是将一些边缘的，不常用的功能，都尽量采用这种方式加载。但需要与产品大大们激烈PK，用户至上嘛。
记住，砍功能永远是减少安装包的第一法宝！
三、安装包是否能安装
这里讨论第二个主要问题，如何确保我们的安装包用户都能安装的上，特别是2.3以下的爷们(希望有不需要考虑它们的一天)。
1. Dex的65536高压线
原因你懂得，超过请减少方法数,或自行拆多dex。其实在这里，我们这边有一点积累，但不在这篇文章的讨论范围。具体可参考km中的一些文章：
计算某个dex的方法总数，可使用：
function dex-method-count() {
cat $1 | head -c 92 | tail -c 4 | hexdump -e '1/4 "%d\n"'
}
想看到所有的方法，用dexdump吧。
2. 任何压缩的资源的原始大小不能超过1M
具体参考减少安装包大小tips中的第五点。
3. 线性内存限制
其实这个往往才是决定安装包是否能安装的上的阿喀琉斯之踵(用完这个名词，顿时高大上)。
关于线性内存的限制，可参考文章：
https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920
简单来说就是在dexopt过程中，系统限制一个5-16M的线性内存，如果在读取dex数据过程中超过了这块内存，就会出现dexopt失败。
由于dalvik加载系统模块时需要占用部分内存，facebook的推荐值我们自身dex的最大值是4M，但我们发现在某些2.3的机器超过3.5M之后依然会dexopt失败。微信计算线性内存使用的是buck中asm-debug-all中提供的方法，计算class中会被dexopt中会读入线性内存的总大小：
(buck源码：https://github.com/facebook/buck)
通过baksmali反编译dex，也能得到相同的效果。在上面的那篇Facebook文章中，它们通过hack的方式更改系统线性内存的值，这涉及兼容性的问题，但按它们说只在三星的某些机型需要适配，so名称是：