1.概述

随着业务的快速迭代，抖音 Android 端的包大小爆发式增长。包大小直接影响到下载转化率、推广成本、运行内存和安装时间等因素，因此对 apk 进行瘦身是一件很有必要且收益很大的事情。apk 主要由 dex、resource、asserts、native libraries 和 meta-data 组成，针对每一部分，都可以专项去做包大小优化。
抖音 Android 端经过一段时间努力，包大小优化已经取得了阶段性的成果。目前仍在持续的优化中。

-	优化前	优化后	百分比
抖音	73MB	61.5MB	15.7%
抖音 lite	10MB	4.9MB	51%

其中，资源在 apk 包体积中占比很大，针对资源进行优化是包大小优化中很重要的部分。本着追求极致的原则，本文将详细阐述抖音 Android 端针对资源部分的优化措施。

2.图片压缩

2.1 图片压缩原理

在不进行压缩的情况下，图片大小计算公式：图片大小=长 x 宽 x 图片位深。一张原始图像(1920x1080)，如果每个像素 32bit 表示(RGBA)，那么图像需要的存储大小 1920x1080x4 = 8294400Byte，大约 8M，一张图这么大是难以接受的。因此我们使用的图片都是经过压缩的。
图片压缩利用的是空间冗余和视觉冗余原理：

空间冗余利用的是图像上各采样点颜色之间存在着的空间连贯性，把本该一个一个像素存储的数据，合并压缩存储，加载时进行解压还原。通常无损压缩利用的就是空间冗余原理。
视觉冗余是指人类的视觉系统由于受生理特性的限制，对于图像场的注意是非均匀的，人对细微的颜色差异感觉不明显。例如，人类视觉的一般分辨能力为 26 灰度等级，而一般的图像的量化采用的是 28 灰度等级，即存在视觉冗余。通常有损压缩利用的是人的视觉冗余原理，擦除了对人的眼睛来说冗余的信息。

2.2 优势

抖音 Android 研发团队开发了 Gradle 插件 McImage，在编译期间 hook 资源，采用开源的算法 pngquant/guetzli 进行压缩，支持 webp 压缩。与 tinypng 等一些已知的方案相比，存在以下优势：

McImage 现支持 webp 压缩，压缩比高于 tinypng，不过 Android 上 webp 需要做兼容，下文会详细介绍；
tinypng 不开源，每个账号每个月只能免费压缩 500 张；McImage 使用的压缩算法都是基于开源算法；
McImage 不仅可以压缩 module 中的图片，还能压缩 jar 和 aar 中的图片；
McImage 支持压缩算法扩展，有更优的压缩算法选择时扩展方便；
和行业里其他方案相比，McImage 还能够支持压缩包含透明度的 webp 图片，并且兼容了 aapt2 对资源的 hook。

2.3 收益

McImage 支持两种优化方式，这两种优化方式不可同时使用:

Compress，pngquant 压缩 png 图片，guetzli 压缩 jpg 图片；
ConvertWebp，webp 压缩 png\png 图片。

webp 的压缩比要高于 pngquant、guetzli，所以现在更推荐使用 ConvertWebp 这种压缩方式。

McImage 还被应用于字节跳动旗下多个产品的图片压缩优化工作中，收益如下：

描述	收益
抖音-Compress	9.5MB
抖音-ConvertWebp	11.6MB
火山-ConvertWebp	3.6MB
Vigo-ConvertWebp	4MB
Vigo aab-Compress	1.2MB
vigo aab-ConvertWebp	3.2MB
多闪-ConvertWebp	3.5MB

2.4 其他

除了压缩、优化图片，McImage 还提供了以下功能：

大图检测。在 app/build/mcimage_result 目录下会生成 mcimage_log.txt 日志文件，除了输出转换结果的日志外，在最后还输出了大像素图片和大体积图片，阈值可在 McImageConfig 里进行设置，方便大图复盘优化包大小；也支持编译阶段检测，检测到大图直接 block 编译，可及时发现大图提交；
压缩算法方便扩展。如果想接入其他压缩算法，只需要继承 AbstractTask，实现 ITask 接口中的 work 方法即可；
支持多线程压缩。把所有 task 的执行放入线程池中执行，大大缩短了 mcimage 的执行时间；
增加了图片缓存 cache，进一步缩短打包时间。在开启多线程+图片缓存的情况下，全部命中缓存的情况下，整个 mcimage 的过程不到 10s；缓存路径可配置；
压缩质量可配置，满足不同的压缩质量需求，缓存文件也会按照不同的压缩质量进行保存和命中；
扫描不包含透明通道的图片到 app/build/mcimage_result 目录下。

3.webp 无侵入式兼容

3.1 tinypng 和 webp 的选择

tinypng 与 webp 到底哪个压缩比更高呢？在网上找不到两种压缩算法压缩比的直接比较，需要更直观的对比，于是做了如下的实验：

扫描项目中 1960 张图片，通过不同的算法压缩进行对比：

描述	大小
原图	13463.07KB
webp 压缩	4177.18KB
tinypng 压缩	6732.18KB

从项目中找 490 张图片，新建 demo，不同算法压缩图片后比较打包 apk 的大小：

描述	大小
原图 APK	9617.53KB
webp 压缩 APK	3924.06KB
tinypng 压缩 APK	5386.80KB

通过这两组实验对比，可以看出 webp 的压缩比是优于 tinypng 的。之前也手动的使用 webp 工具压缩过抖音工程中所有图片，包大小减少了 1.6MB 左右。因此选择了 Webp 压缩算法。

3.2 方案选型

webp 压缩算法，相较于 pngquant、guetzli、tinypng，webp 压缩比更高，所以 webbp 压缩图片应该是更优的选择。但是 Android 设备对 webp 的支持存在兼容性问题，在 4.3 以上才完全支持。通过官网我们知道，想在应用中直接使用带有透明度的 webp，minSDK 至少需要是 18。

包括抖音、今日头条在内的头条系 Android 应用，大部分 minSDK 是 16，无法直接使用 webp 图片，需要做低版本兼容。通过大量调研，找到了三种兼容的方式：

-	优点	缺点
提供特定 api 兼容	实现起来简单	侵入性太强，必须用特定接口或特定 View 进行加载
LayoutInflater setFactory 进行兼容	实现起来简单	需要针对所有的 ImageView 及子 View 处理，且必须有统一的 Activity、Fregment 的基类处理
运行时 hook 系统关键方法	方法替换，可以做到无侵入式	实现起来复杂些

3.3 方案实现

想要做到无侵入式的兼容，运行时 hook 不失为一种最佳的选择。但是运行时 hook 方案，需要解决以下几点问题：

选择的 hook 方案要稳定可靠；
hook 点要足够收敛，保证所有解析图片的操作都能符合预期。

3.3.1 Hook 方案要稳定可靠

通过对 Xposed、AndFix、Cydia Substrate、dexposed 等常见的 Android Java hook 方案的调研对比，dexposed 具有不需要 root、又能 hook 系统方法的特点，最终选择 dexposed:

dexposed 在 Dalvik 上比较稳定，只需要针对 4.3 以下的手机版本做 hook，不需要考虑版本兼容性问题和系统升级问题；
通过内部数据可以知道，抖音 4.3 以下的用户并不多，在十万级别，占总用户数的万分之几，风险较低。

3.3.2 Hook 点要足够收敛

通过阅读源码，发现所有图片被加载解析成 Bitmap 的过程，最终都调用到了 BitmapFactory 中的方法。比如 ImageView 的 setImageResource() 的调用路径如下:

ImageView 的 setImageResource 过程，Bitmap 的创建是通过 BitmapFactory 来实现。如 View 的 setBackgroundResource(int resid)的源码如下：

查阅所有加载图片的 api，都会经历 Resources 调用 getDrawable 的过程。会调用到 Drawable 的相关方法，然后通过 BitmapFactory 去解析不同的资源类型（File\ByteArray\Stream\FileDescriptory）为 Bitmap。由此可以推断出，BitmapFactory 是 Android 系统通过不同的资源类型加载成 Bitmap 的统一接口，这一点从 BitmapFactory 的类注释中也能看出：

由于系统加载解析 Bitmap 的过程已经足够收敛，都是通过 BitmapFactory 来实现，因此 BitmapFactory 是一个非常不错的 hook 点。

有了稳定的 Hook 方案和足够收敛的 Hook 点，方案的实现起来就手到擒来了，利用 dexposed 对 BitmapFactory 里的关键方法进行替换就可以了。

4.多 DPI 优化

Android 为了适配各种不同分辨率或者模式的设备，为开发者设计了同一资源多个配置的资源路径，app 通过 resource 获取图片资源时，自动根据设备配置加载适配的资源，但这些配置伴随着的问题就是高分辨率的设备包含低分辨率的无用图片或者低分辨率的设备包含高分辨率的无用图片。

一般情况下，针对国内应用市场，App 为了减少包大小，会选用市场占有率最高的一套 dpi（google 推荐 xxhdpi）兼容所有设备。而针对海外应用市场的 APP，大多会通过 AppBundle 打包上传至 Google Play，能够享受动态分发 dpi 这一功能，不同分辨率手机可以下载不同 dpi 的图片资源，因此我们需要提供多套 dpi 来满足所有设备。在项目中，我们的图片有的只有一套 dpi，有的有多套 dpi，针对上述两种场景，我们分别在打包时合并资源、复制资源，减少了包大小。

4.1 DPI 复制（bundle 打包）

在国内项目中，为了减少图片的占用，一般都会对市场占用率高的 dpi 进行适配，比如只保留 xxhdpi 分辨率的图片。这样就导致了两个问题，一个是市场上 2k 分辨率手机越来越多，如果以后手机主流分辨率是 xxxhdpi，那么项目中几千张图片修改成本会非常高。另一个问题是，公司不少海外产品是通过 AppBundle 打包上传到 Google Play 的，能够给不同设备用户下发不同 dpi 的资源。但项目中只有 xxhdpi，仍然下发 xxhdpi 的图片，无法通过降低 dpi 减小包大小。在巴西，我们 80%用户都使用 xhdpi 和 hdpi 手机，xxhdpi 图片相比 hdpi 占用多了一倍，这部分收益相当高。

因此，我们通过压缩分辨率的方式将高分辨率的图片降低到低分辨，项目业务只存放最高 dpi 图片，在打包的时候按需求复制筛选。我们在 hook 了图片压缩的 task，在图片压缩前，获取到包括依赖库在内的所有 PNG 图片，利用 Graphics2D 降低图片分辨率，放在对应分辨率文件夹中。之后再执行图片压缩 task，防止一些图片重采样后大小增加。

我们仅对图片的分辨率进行缩放，并不降低图片采样率，因此在显示效果上没有区别。不同 dpi 具体应该调整到多少分辨率，我们根据 Google 的定义制作了一个表格：

-	LDPI	MDPI	HDPI	XHDPI	XXHDPI	XXXHDPI
分辨率(普遍)	240x320	320x480	480x800	720x1280	1080x1920	2k
倍率	3	4	6	8	12	16

我们复制一张 xxhdpi 的默认 logo 到所有 dpi，流程如下图，xhdpi 和 mdpi 文件夹下没有对应图片，复制；在 hdpi 中有对应图片，跳过；xxxhdpi 也没有对应图片，但为了避免降低图片精度，不能向更高分辨率文件夹复制，跳过。

最终收益如图，公司内海外产品 TikTok 研发团队在使用该方案优化时，ldpi 相比 xxhdpi 减少了 2.5M 包大小。同时，低分辨率手机加载图片时直接加载对应 dpi 图片资源，不再需要对高分辨率图片进行缩放处理，提高了性能。

在复制时需要注意这些问题：为了处理包括依赖库中的所有图片，在资源合并阶段进行了复制，这样会导致.cache 目录的很多路径下会多出大量图片资源，因此这个插件我们在 CI 上开启，避免本地打包新增大量图片，提交到代码仓库。同时，由于.cache 中被复制了多份图片，需要在 assemble 打包流程中进行多 dpi 去重。在 CI 上会有并发场景，同时复制和压缩会导致.cache 目录下同时存在 a.png 和 a.webp，出现 Duplicated 错误，因此最后需要扫描删除同名的.png 文件。

4.2 多 DPI 去重(assemble 打包）

针对普通打包模式(直接产出 apk,比如抖音包)，我们可以选择只保留一份分辨率偏高的的图片，这样高分辨率设备可以拿到合适的图片、低分辨率设备通过 Resource 获取时会自动进行缩放，依然可以保证合理的运行内存。

多 dpi 图片可以通过 Android 自带的 resConfig 去重，但这个配置只对资源的 qualifier 去重，比如对像素密度和屏幕尺寸不会同时做去重，抖音使用基于 AndResguard 修改的方式对 drawable 去重，可以定义不同配置的优先级和作用范围。根据优化配置确保留一份资源，优化方式如下图(灰色数据表示会被删除)：

5.重复资源合并

随着项目的迭代，项目中难免会出现相同的资源被重复添加到资源路径中，对于这类文件，人工处理肯定是不可行的，可以在打包阶段自动去重。

抖音选择在 AndResguard 阶段对所有的资源进行分析，对 md5 相同的资源文件保留一份，删除其余的重复的文件，然后在 AndResguard 写入 arsc 文件时进行将删除的资源文件对应的资源路径指向唯一保留的一份资源文件。优化方式如下图：

下图是抖音 511 版本接入多 dpi 去重与重复资源合并功能的优化结果：

MD5 文件去重	DPI 图片去重	MD5 文件去重减少文件数量	MD5 文件去重减少文件总体积	DPI 图片文件去重减少文件数量	DPI 图片文件去重减少文件总体积	apk 大小	相比于原始包减少
false	false	-	-	-	-	85,030,636	-
true	false	171	156.6KB	-	-	84,883,829	143KB
true	true	171	156.6KB	391	312.9KB	84,507,008	511KB
false	true	-	-	422	434.5KB	84,523,236	495KB
true	true（配置全开）	171	156.6KB	463	465.4KB	84,352,272	662KB

6.shrinkResource 严格模式

6.1 背景

随着项目的开发迭代，我们会有许多资源已经不再使用了，但仍然存在于项目中。虽然我们可以使用公司开源的字节码插件开发平台 ByteX 开发插件在 ProGuard 之前扫描出一些无用资源，但因为这一步没有经过无用代码删除，因此扫描出的结果并不全。而 shrinkResources 是 google 官方提供的优化此类无用资源的方法，它运行在 Proguard 之后，能标记所有无用资源并将其优化。

6.2 收益

抖音 Android 在开启 shrinkResources 严格模式后，shrink 资源数 600+，收益大小 0.57MB。

6.3 接入方法

shrinkResources 是由 Google 官方提供的工具，因此详细的接入方式参考 Google Developer 上的文档即可。

6.4shrinkResources 原理

默认情况下，Resource shrink 是 safe 模式的，即其会帮助我们识别类似 val name = String.format("img_%1d", angle + 1) val res = resources.getIdentifier(name, "drawable", packageName) 这样模式的代码，从而保证我们在反射调用资源文件的时候，也是能够安全返回资源的。从源码来看，Resource shrink 时会帮助我们识别以下五种情况：

而 Resource shrink 使用了一种最笨但却最安全的方法去获取匹配的前缀/后缀字符串，那就是将应用中所有的字符串都认为是可能的前缀/后缀匹配字符串。

所以这就造成了在安全模式下，不小心被某个字符串所匹配到的资源，即使没有被使用也会被保留下来。以我们的项目为例，在 com.ss.android.ugc.aweme.utils.PatternUtils 中，我们有以下代码：

在安全模式下，这就造成了所有以 tt 开头的无用资源都不会被 shrink 掉（这也就是为什么严格模式一开，ttlive_ 开头的无用资源那么多的原因）。

而严格模式打开后，其作用便是强行关闭这一段的字符匹配的过程：

当然这也就造成了我们在使用 getIdentifier() 的时候是不安全的，因为严格模式下是不会匹配任何字符串的，所以在开启严格模式之后，一定要严格检查所有被 shrink 的资源，是否有自己需要反射的资源！

6.5 shrinkResources 兼容 Dynamic Feature

AppBundle 是 Google 近年来力推的一个功能，它能够让我们的 apk 按照不同的维度生成下发，也提供了一个动态下发功能的方式，Dynamic Feature。但是如果我们在开启 Dynamic Feature 之后使用 shrinkResources，则提示以下错误：

由此看来 Google 官方并不支持 App Bundle 使用 Dynamic Feature 时使用 shrink resource。在 Google Issue Tracker 上发现已经有人对此提交过 Issue 了，相关 Issue。而 Google 的回复也是简单粗暴----计划中，但是没有时间：

但是正常来说，如果做的好的话，我们的 App Bundle 的 Dynamic Feature 模块是很少会引用 Master 的资源的，即使有，使用 keep.xml 的方式也能将这种资源给保留下来。因此，理论上来说，单独对 Master 模块进行 shrinkResource 并注意反射调用的话，是没多大问题的。 Dynamic Feature 下检查 shrinkResources 配置是在 Configuring 阶段

因此我们的想法便是在配置阶段不开启 shrinkResources 开关，而在后面执行资源处理任务的时候自行插入 shrinkResources 的 Task：

这样就能在 Dynamic Feature 下开启 shrinkResources 的 Task 了，整个代码编写十分简单，不到 50 行就能完成：

7.资源混淆(兼容 aab 模式)

资源 id 与资源全路径的映射关系记录在 arsc 文件中，app 通过资源 id 再通过 Resource 获取对应的资源，所以对于映射关系中的资源路径做名字混淆可以达到减少包体积的效果。

抖音启用了微信开源的 AndResguard 进行资源混淆，在开源的基础上进行了增加了 MD5 去、多 DPI 只保留一份资源等优化。由于公司内部有很多海外产品，在上架 Google Play 时需要走 aab，因此团队做了资源混淆的 aab 兼容-- aabResguard，已开源。

8.ARSC 瘦身

8.1 背景

resources.arsc 这个文件在很多项目中都占用了相当多的空间。常见的优化方法是使用 AndResGuard 混淆减少文件名及目录长度，7z 压缩，如果有海外产品的话可以动态下发语言。我们在做完这些优化后，由于公司内部有很多海外产品，涉及到多语言的关系，ARSC 依然很大，我们决定尝试进一步优化。
经过调研，最终我们对 3 个方面做了优化，分别是删除无用 Name、合并字符串池中重复字符串、删除无用文案，最终带来的收益是 1.6MB。在此之前，我们还在 AndResGuard 的基础上完成了重复 MD5 文件图片合并，原理是一样的。

8.2 原理

先贴一张 arsc 结构的图，这个二进制文件的数据结构相当复杂，AndResGuard 其实只修改了这个文件的一小部分，至于更多的修改就无能为力了，于是我们自己解析了这个文件进行分析。网上也有不少关于这个文件格式的说明，这里就不赘述了。推荐老罗和尼古拉斯的博客以及 aapt2 源码。google 提供的 android-arscblamer 和 apktool 的代码也值得一看。

下面用一张图简单描述一下修改过程：

如图，字符串其实是通过索引的方式来获取的，所有字符串都保存在两个字符串池中（单个 package），一个是全局字符串池，一个是 package 下的字符串池，我们只需要修改指向全局字符串的偏移值就行了。name 和 value 所在二进制位置如下图。

8.3 方案

8.3.1 删除无用 Name

AndResGuard 在今年的 7 月也增加了这个功能，我们来看一下实现原理。 Name 对应的字符串池是 package 字符串池，由于这个字符串池中只包含所有 Name，我们操作可以稍微暴力一点，先做一份备份，然后清空字符串池，添加一个用于替换的字符串，赋值为 [name_removed]。

首先要确定哪些 name 是通过 getIdentifier 调用，配置成白名单。遍历 name 项，如果不在白名单，那么把这一个 name 的偏移替换成 0，使其指向[name_removed]。如果 name 在白名单，那么不应该删除，我们通过备份的字符串池找到这个 name 对应的字符串，添加到字符串池中，把偏移指向对应下标即可。

抖音通过这个优化减少了包大小 70k。

8.3.2 合并重复字符串

value 所对应的是全局字符串池，虽然名字听起来不会有重复值，但在我们扫描排序后发现其实有很多重复字符串（用 AppBundle 打包就不会存在这个问题）在抖音项目中，这个字符串池里有 1k+个重复字符串，合并这些字符串是非常必要的。

我们先遍历所有数据，然后把字符串池的重复字符串合并，记录偏移的修改，最后把需要修改的 value 的引用指向新的偏移。这个过程需要操作 arsc 数据结构的 ResValuel 和 ResTableMap，以保证所有 string 类型的值都能得到替换。

抖音通过这个优化减少了包大小 30k。

8.3.3 删除无用文案

在打包过程中，其实所有 strings.xml 中保存的字符串都是不会被优化的，随着项目逐渐变大，一些废弃文案或者下个版本才有用的文案被引入了 apk 中，我们在 Proguard 后再次扫描，发现了 3000+个无用字符串。在公司内部的一些海外项目中，有的文案被翻译成 100 多个国家的语言，占用了极大的空间。

删除的方法和上面类似，都是指向替换的字符串所在偏移。如图可能会存在两个不同 name 指向同一个字符串，需要判断待删除的字符串是否还有其他引用。

不同项目收益可能不太一样，公司内部海外项目对这些无用文案进行了替换，减少了 1.5M 包大小左右。

8.4 实现

如果是普通的 assemble 打包，直接在 ProcessResources 过程中获取 ap_文件中的 arsc 文件，利用我们的工具修改即可。

如果是 AppBundle 方式打包，修改 ap_是没有用的，因为最后产物是用 aapt 以 proto 格式生成的 resources.pb 文件，要修改只能 hook aapt 过程。这个文件和 arsc 文件结构不太一样，好在我们可以使用官方提供的 Resources 类解析、生成 pb 文件，使用相似的方法修改即可。

修改效果如图：

8.5 进一步优化

arsc 中的偏移数组是有优化空间的，我们会在未来尝试进行优化。用二进制编辑器打开 arsc 文件可以发现，这样的 FF 值在文件中大量存在。

是什么导致了这样的空间浪费？我们可以看到下图中框选的空白，每一个都代表了其字符串所在的偏移值，这里并没有值，赋值 FF FF FF FF 作为默认偏移值，浪费了 4 字节空间。某些列（configuration）可能就只有几个格子有值，如图抖音中 drawable 有 4k+张图片，有 24 列，大多数 configuration 只有几张图片，因此浪费了 4k*23*4≈380k。大致估算，抖音可以减少 1M 体积。（压缩前）

如下图 facebook 针对 arsc 文件的处理，我们可以把一行只有一个值的 id 抽出来，单独放到一个 Resource Type 中，每一个 id 只有一个值，避免了上述空间浪费情况。但这样做修改了 ID，因此对应的代码中的 ID 也要修改，涉及了逆向 xml 以及 dex，提高了修改成本。还有一种思路是修改 aapt 源码，没有直接改 arsc 灵活。

9.总结

上述就是我们抖音 Android 端在包大小优化方面针对资源做的一些尝试和积累，力求追求极致。

我们针对包大小优化，在其他方面还做了很多优化措施:针对 so 优化，做了 so 合并、stl 版本统一、精简导出符号表和 so 压缩等措施；针对代码优化，细化混淆规则，开发 bytex 插件进行无用代码扫描、acess 方法内联、getter/setter 方法内联、删除行号等优化措施。

除了优化措施，良好的包大小监控系统是防止包大小劣化最重要的工具，否则包大小优化措施取得的收益抵不过业务快速迭代带来的包大小增长。抖音 Android 端结合 CI、Cony 平台，开发出了一套代码合入前置检查系统，每个分支增量超过阈值不准合入；还开发了分业务线监控包大小的工具，便于监控每个业务线包大小增长和给各个业务线定包大小指标。

最后，抖音 Android 诚招对技术有无限热情的小伙伴。感兴趣的小伙伴都可以通过字节跳动招聘官网查询抖音 Android 相关职位或简历发送至 shipeiqing@bytedance.com。

更多分享

抖音BoostMultiDex优化实践：Android低版本上APP首次启动时间减少80%（二）

抖音BoostMultiDex优化实践：Android低版本上APP首次启动时间减少80%（一）

开源 | AabResGuard: AAB 资源混淆工具

欢迎关注字节跳动技术团队