一般的APK安装包包含了以下一些目录和资源：（排序）

META-INF/ 签名文件

assets/ 程序使用的辅助资源文件

res/ 没有编译进入resources.arsc 资源文件，一般是图片

lib/ 依赖的不同native平台的库文件

resource.arsc 编译之后的文案、色值、大小、主题等资源索引

classes.dex 编译后的代码

AndroidMenifest.xml 应用的名称、版本、访问权限和引用的库文件信息

我们最初使用的抖音的McImage插件对图片进行处理，不过这个方案存在一些明显的问题：

1.方案采用有损webp，有损webp无法定一个通用的压缩质量适应所有场景。

2.每次打包都要对所有图进行压缩，严重影响迭代效率。打包机要40分钟，且经常OOM。

3.没有对assets目录的图片进行处理。

1.对于大图png，用手工压成有损webp。收益大，且风险可控。

2.对于非大图，开发了一个image-optimization插件进行压缩。该插件方案为：

· png转tinypng。虽然是有损的，但从抽样来看，肉眼完全看不到明显变化。

· 对assets进行处理。assets内有前端png图，转tinypng不转webp的好处是不需要单独改html、js等文件，且对低版本系统兼容性更友好。flutter相关项目的flutter_assets图片比较大且没注意压缩。插件统一处理可以不需要打开flutter工程单独优化、重新打包。

· 对于已压缩的图片，做缓存处理，不需要重新压缩，打包的时候动态替换。压缩缓存跟随词典工程提交到gitlab统一管理。

附加1：

因为已经用了tinypng统一压缩，那么google官方自带的crunchPng建议关闭，否则打包速度变慢，而且优化好的图片也可能又变大，加入这行即可：

buildTypes.all { 
  isCrunchPngs = false
}

附加2：

无损webp和tinypng对比

如图所示，全量换tinypng比全量换webp（包含assets）少7.7MB。如果考虑到assets内的14.7MB其实是不能简单换webp的，差距会更大。

附加3：

tinypng已经是最好的方案吗？

参考另一个ImageOptim工具，它结合OptiPNG, PNGCrush, AdvanceComp, PNGOUT, Jpegoptim + Jpegtran, 和 Gifsicle 等几个工具提供最好的优化效果，而且是几乎无损的。对于小部分图片ImageOptim压出来小，看起来没有差别。不过压缩速度非常慢。

所以，如果做到极致的话，可以进行多种压缩方案，选最佳的图作为替换。且我们的image-optimization插件从一开始设计的时候就预留了这种可扩展性。

附加4：

AndResGuard优化对比

试了一下效果不明显，且出现部分资源丢失而崩溃的情况。效果不明显的原因，猜测是目前R8对资源名也有混淆压缩（以前proguard没有），所以AndResGuard现在的作用比较微弱。至于7zip的压缩没有开，理论上会导致启动速度变慢，觉得得不偿失（另外会导致Google Pay的Patch优化算法失效）。

buildTypes {
        release {
            // Zipalign优化
            zipAlignEnabled true
            // 移除无用的resource文件
            shrinkResources true
            // 移除没用的代码
            minifyEnabled true
        }
}

使用R8工具在编译阶段对代码进行压缩混淆，从而达到压缩安装包体积的效果。主要分为以下4个步骤：

1. 压缩（shrink） 移除未使用的类、方法、字段等；

2. 优化（optimize） 优化字节码、简化代码等操作；

3. 混淆（obfuscate） 使用简短的、无意义的名称重命名类名、方法名、字段等；

4. 预校验（preverify） 为class添加预校验信息。

Caused by: java.lang.IllegalArgumentException: Method return type must not include a type variable or wildcard: ho8<su3<?>>
    for method CheckInApi.popupConfig
    at retrofit2.Utils.methodError(SourceFile:5)
    at retrofit2.Utils.methodError(SourceFile:1)
    at retrofit2.ServiceMethod.parseAnnotations(SourceFile:7)
    at retrofit2.Retrofit.loadServiceMethod(SourceFile:4)
    at retrofit2.Retrofit$1.invoke(SourceFile:6)
    at java.lang.reflect.Proxy.invoke(Proxy.java:1006)
    at $Proxy23.popupConfig(Unknown Source)
    at com.youdao.dict.checkin.CheckInPopupManager.requestPopupConfig(SourceFile:3)
    at java.lang.reflect.Method.invoke(Native Method)

· 字体裁剪

一般的字体库大小会有十几二十兆。但实际上用到的字符只有很少一部分，因此针对实际的使用场景对字体库进行适当的裁剪，收益非常大。

常用字列表：https://github.com/DavidSheh/CommonChineseCharacter

字体压缩工具：https://github.com/forJrking/FontZip

· 字体合并

一般来说，我们开发都会模块化，不同的团队采用在开发不同功能的时候，有可能用到相同的字体。如果稍不注意就会复制成两份、三份，文件大大增加。词典这边的方案是把共有的字体下沉到底层core基础库，供各个模块引用。

打包任务完成之后，如果需要检查包大小，那就开始触发apkcheck步骤；具体如下：

1. 打包任务完成之后增加脚本操作，把本次构建的数据（如apk文件地址，mapping文件地址，R文本地址等）写入临时文件；

2. 打包任务构建后操作增加 Trigger parameterized build on other projects，触发apk 大小检查任务；

3. 开始检查流程，检查流程根据参数对apk进行检查任务，并且把任务结果生成html；

1. 数据库(单词锁屏8MB)

单词锁屏可以保留几百kb数据在本地让用户备用，同时再下载完整的词库。

2. OCR引擎数据（22.5MB）

用户应该可以按需下载训练模型，而不是直接内置；当没有训练模型的时候，可以直接网络请求。

3. 字体（9.1MB）

除了查词等高频业务，低频业务的字体可以动态分发，有则显示，无则使用系统的即可。但emoji的兼容库比较特殊，主要用在首页信息流的帖子、UGC发帖等。如果没有兼容库，用户在遇到特别的emoji中可能会显示“豆腐块”，这个时候如果emoji字体库还没下载完成，需要进行替换兜底处理。另外哪怕用户系统已经有这个emoji内置字体，也有可能显示效果各个手机不太一样，需要跟UI确认一下是要替换掉，还是暂时这样显示。