背景
隨著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動畫的快照，保存了每個動畫的名稱和下載地址。
在cms后臺的文件資源管理添加資源，會自動生成這套快照。
如下圖所示，描述了多個業務場景的零碎資源管理流程。cms文件管理支持同時上傳多個svg文件和字體文件，分別生成svg快照和font快照，然后更新cms后臺app配置-資源包配置下的快照配置。
客戶端加載快照和下載資源的流程如下圖所示。啟動后加載遠程cms配置的快照，同時加載本地存儲的快照，差量更新資源映射assetMap。到業務場景觸發的時候，先判斷本地是否存在資源，若存在則直接讀取。若不存在，從assetMap中查找其配置信息，根據配置的url下載資源到本地。
客戶端中為了實現上述的加載流程，封裝了用于播放svg的控件和設置自定義字體的控件，每個使用零碎資源的場景直接使用該控件即可。此外，對于cms無配置或下載錯誤的情況，該控件使用兜底策略處理，不播放svg動畫或使用系統默認字體。
編譯優化
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圖片的壓縮。
