来自微信团队的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

参数：

-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名称是：

(库地址：http://asm.ow2.org/)

网站名称：来自微信团队的Apk瘦身经验
URL网址：http://www.shufengxianlan.com/qtweb/news37/481387.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联