背景

随着XX项目的不断迭代,业务复杂度日益增长,不断引入新的业务逻辑代码、图片资源和第三方SDK，直接导致客户端包体积不断增长。
包体积增长带来的问题越来越多，如CDN流量费用增加、用户安装成功率降低，甚至可能会影响用户的留存率。 业界关于应用包体积大小的研究表明，包体积过大会导致约10%的新用户流失率， 统计数据显示新版本包体增加 30 MB 后用户留存下降 4 %。

概述

• 资源在线化
  大资源在线化
  零碎资源在线化
• 工具链建设
  编译优化
  图片资源打包时自动化压缩

技术要点

大资源在线化

1.android系统的emoji字体。
Android 官方兼容库 support-emoji为了支持emoji表情，把 emoji 表情内置在 NotoColorEmojiCompat.ttf 字体文件中，最终打入了apk包体中。
我们修改官方库的依赖方式，去掉其中的绑定字体，即去除support-emoji-bundled模块依赖。然后修改EmojiCompat的初始化配置，改为支持自定义下载并且从本地目录读取字体文件的方式加载emoji

class DownloadEmojiCompatConfig : EmojiCompat.Config(MetadataLoader()) {
    private class MetadataLoader internal constructor() : EmojiCompat.MetadataRepoLoader {
        private  val filePath =  "filepath/emoji.ttf"
        override fun load(loaderCallback: EmojiCompat.MetadataRepoLoaderCallback) {
            Rx2Creator
                    .createObservable {
                        if (FileUtil.isFileExists(filePath)) {
                            return@createObservable true
                        }
                        
                        return@createObservable FileDownloader.startSync("url", filePath)
                    }
                    .compose(Rx2Schedulers.observableIoToMain())
                    .subscribe({ result ->
                        if(result!=null && result){
                             val nTtfFile = File(filePath)
                            loaderCallback.onLoaded(MetadataRepo.create(Typeface.createFromFile(nTtfFile), FileInputStream(nTtfFile)))
                        }else{
                            loaderCallback.onFailed(null)
                        }

                    }, { e ->
                        loaderCallback.onFailed(e)
                        e.printStackTrace()
                    })
        }
    }
}

2.业务性大资源迁移cms后台
业务大资源与业务强相关,不做过多介绍。比如某个页面做了仿微信炸弹、烟花爆竹表情的全屏特效。往往特效越炫酷,资源越大,这些资源最好不要放在包体内部,而是改成从网络下载。
那么，资源应何时进行下载呢？下载出现异常如何处理？如何支持资源更新？
关于下载时机问题。为了节省流量，应当尽量延迟下载，最好是等到用户用到才去下载。但是这样会在首次触发时，因为要等待资源下载而影响用户体验。因此我们将各个资源的下载时机确定为：从业务首次触发时机（真正要用到的时候）开始，往前移一个场景(举例说明)。从而解决延迟加载与用户体验的矛盾。
关于下载异常的问题。应对各类资源加载分别设计契合产品业务的兜底策略。比如不展示特效或提示用户稍后再试。
关于资源更新的问题。采用文件md5校验就可以实现。配置各资源包时，同时配置压缩包文件的md5。客户端判断该资源包是否已经下载的方法中，要判断文件md5是否和配置值一致。

零碎资源在线化管理

零碎资源主要是各个业务一些零碎的字体文件和Svg动画文件。和大资源不同的是，单个文件并不大（一般小于1M），但是数量众多，目前项目有用到几十个，而且涉及各个不同的业务模块，更新迭代频繁。
零碎资源虽然单个并不大，但是由于随着业务快速迭代，累计下来也有好几M，而且在可预见的将来显然会“越滚越大”，因此，零碎资源也需要做在线化的迁移。
零碎资源管理的难点在于：资源数量众多，涉及各个不同的业务场景，迭代频繁，对每一个单独配置，管理成本很大。为解决这一问题，我们使用了快照-差分化存储和按需下载的机制，实现了零碎资源在线化迁移。
针对Svg动画和字体文件分别设计了一层资源快照，即专门维护了一套svg动画映射和字体文件映射，快照数据为json文件格式，如下图是svg动画的快照，保存了每个动画的名称和下载地址。

download.jpeg

在cms后台的文件资源管理添加资源，会自动生成这套快照。
如下图所示，描述了多个业务场景的零碎资源管理流程。cms文件管理支持同时上传多个svg文件和字体文件，分别生成svg快照和font快照，然后更新cms后台app配置-资源包配置下的快照配置。

download (1).jpeg
客户端加载快照和下载资源的流程如下图所示。启动后加载远程cms配置的快照，同时加载本地存储的快照，差量更新资源映射assetMap。到业务场景触发的时候，先判断本地是否存在资源，若存在则直接读取。若不存在，从assetMap中查找其配置信息，根据配置的url下载资源到本地。
客户端中为了实现上述的加载流程，封装了用于播放svg的控件和设置自定义字体的控件，每个使用零碎资源的场景直接使用该控件即可。此外，对于cms无配置或下载错误的情况，该控件使用兜底策略处理，不播放svg动画或使用系统默认字体。
download (2).jpeg

编译优化

1.lint工具全局扫除冗余资源
一键去除后，发现某些使用反射方法引用的drawable丢失，还有一些动态调用的string无法显示，针对这两种情况做特殊处理。
2.大图专项整治
还发现了个别大图，超过1M不合理，对高清大图进行尺寸等比压缩和去除透明通道，最终转换为500k以内。
3.androidstudio的静态工具convertToWebp将工程的各个模块的图片资源中的png图片转为webp格式。

图片压缩插件集成到动态打包脚本

对于第三方库内引用的图片资源，不能直接使用AS提供的转换工具来转成webp格式，我们在打包脚本中部署了基于Pngquant和Guetzli的图片压缩插件，共使包体减少2M左右。
其中，Pngquant是一个用于有损压缩png图片命令行工具，经过Pngquant转换后的png能减少一半的文件大小并保留了alpha透明度。Guetzli是一个高质量压缩jpeg的图像编码器，可以将jpg图片减少35%左右。我们分别调用Pngquant工具命令行和Guetzli工具命令行来实现png和jpg图片的压缩。