背景
隨著XX項(xiàng)目的不斷迭代,業(yè)務(wù)復(fù)雜度日益增長,不斷引入新的業(yè)務(wù)邏輯代碼、圖片資源和第三方SDK，直接導(dǎo)致客戶端包體積不斷增長。
包體積增長帶來的問題越來越多，如CDN流量費(fèi)用增加、用戶安裝成功率降低，甚至可能會(huì)影響用戶的留存率。 業(yè)界關(guān)于應(yīng)用包體積大小的研究表明，包體積過大會(huì)導(dǎo)致約10%的新用戶流失率， 統(tǒng)計(jì)數(shù)據(jù)顯示新版本包體增加 30 MB 后用戶留存下降 4 %。
概述
- 資源在線化
大資源在線化
零碎資源在線化 - 工具鏈建設(shè)
編譯優(yōu)化
圖片資源打包時(shí)自動(dòng)化壓縮
技術(shù)要點(diǎn)
大資源在線化
1.android系統(tǒng)的emoji字體。
Android 官方兼容庫 support-emoji為了支持emoji表情，把 emoji 表情內(nèi)置在 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.業(yè)務(wù)性大資源遷移cms后臺(tái)
業(yè)務(wù)大資源與業(yè)務(wù)強(qiáng)相關(guān),不做過多介紹。比如某個(gè)頁面做了仿微信炸彈、煙花爆竹表情的全屏特效。往往特效越炫酷,資源越大,這些資源最好不要放在包體內(nèi)部,而是改成從網(wǎng)絡(luò)下載。
那么，資源應(yīng)何時(shí)進(jìn)行下載呢？下載出現(xiàn)異常如何處理？如何支持資源更新？
關(guān)于下載時(shí)機(jī)問題。為了節(jié)省流量，應(yīng)當(dāng)盡量延遲下載，最好是等到用戶用到才去下載。但是這樣會(huì)在首次觸發(fā)時(shí)，因?yàn)橐却Y源下載而影響用戶體驗(yàn)。因此我們將各個(gè)資源的下載時(shí)機(jī)確定為：從業(yè)務(wù)首次觸發(fā)時(shí)機(jī)（真正要用到的時(shí)候）開始，往前移一個(gè)場(chǎng)景(舉例說明)。從而解決延遲加載與用戶體驗(yàn)的矛盾。
關(guān)于下載異常的問題。應(yīng)對(duì)各類資源加載分別設(shè)計(jì)契合產(chǎn)品業(yè)務(wù)的兜底策略。比如不展示特效或提示用戶稍后再試。
關(guān)于資源更新的問題。采用文件md5校驗(yàn)就可以實(shí)現(xiàn)。配置各資源包時(shí)，同時(shí)配置壓縮包文件的md5。客戶端判斷該資源包是否已經(jīng)下載的方法中，要判斷文件md5是否和配置值一致。
零碎資源在線化管理
零碎資源主要是各個(gè)業(yè)務(wù)一些零碎的字體文件和Svg動(dòng)畫文件。和大資源不同的是，單個(gè)文件并不大（一般小于1M），但是數(shù)量眾多，目前項(xiàng)目有用到幾十個(gè)，而且涉及各個(gè)不同的業(yè)務(wù)模塊，更新迭代頻繁。
零碎資源雖然單個(gè)并不大，但是由于隨著業(yè)務(wù)快速迭代，累計(jì)下來也有好幾M，而且在可預(yù)見的將來顯然會(huì)“越滾越大”，因此，零碎資源也需要做在線化的遷移。
零碎資源管理的難點(diǎn)在于：資源數(shù)量眾多，涉及各個(gè)不同的業(yè)務(wù)場(chǎng)景，迭代頻繁，對(duì)每一個(gè)單獨(dú)配置，管理成本很大。為解決這一問題，我們使用了快照-差分化存儲(chǔ)和按需下載的機(jī)制，實(shí)現(xiàn)了零碎資源在線化遷移。
針對(duì)Svg動(dòng)畫和字體文件分別設(shè)計(jì)了一層資源快照，即專門維護(hù)了一套svg動(dòng)畫映射和字體文件映射，快照數(shù)據(jù)為json文件格式，如下圖是svg動(dòng)畫的快照，保存了每個(gè)動(dòng)畫的名稱和下載地址。
在cms后臺(tái)的文件資源管理添加資源，會(huì)自動(dòng)生成這套快照。
如下圖所示，描述了多個(gè)業(yè)務(wù)場(chǎng)景的零碎資源管理流程。cms文件管理支持同時(shí)上傳多個(gè)svg文件和字體文件，分別生成svg快照和font快照，然后更新cms后臺(tái)app配置-資源包配置下的快照配置。
客戶端加載快照和下載資源的流程如下圖所示。啟動(dòng)后加載遠(yuǎn)程cms配置的快照，同時(shí)加載本地存儲(chǔ)的快照，差量更新資源映射assetMap。到業(yè)務(wù)場(chǎng)景觸發(fā)的時(shí)候，先判斷本地是否存在資源，若存在則直接讀取。若不存在，從assetMap中查找其配置信息，根據(jù)配置的url下載資源到本地。
客戶端中為了實(shí)現(xiàn)上述的加載流程，封裝了用于播放svg的控件和設(shè)置自定義字體的控件，每個(gè)使用零碎資源的場(chǎng)景直接使用該控件即可。此外，對(duì)于cms無配置或下載錯(cuò)誤的情況，該控件使用兜底策略處理，不播放svg動(dòng)畫或使用系統(tǒng)默認(rèn)字體。
編譯優(yōu)化
1.lint工具全局掃除冗余資源
一鍵去除后，發(fā)現(xiàn)某些使用反射方法引用的drawable丟失，還有一些動(dòng)態(tài)調(diào)用的string無法顯示，針對(duì)這兩種情況做特殊處理。
2.大圖專項(xiàng)整治
還發(fā)現(xiàn)了個(gè)別大圖，超過1M不合理，對(duì)高清大圖進(jìn)行尺寸等比壓縮和去除透明通道，最終轉(zhuǎn)換為500k以內(nèi)。
3.androidstudio的靜態(tài)工具convertToWebp將工程的各個(gè)模塊的圖片資源中的png圖片轉(zhuǎn)為webp格式。
圖片壓縮插件集成到動(dòng)態(tài)打包腳本
對(duì)于第三方庫內(nèi)引用的圖片資源，不能直接使用AS提供的轉(zhuǎn)換工具來轉(zhuǎn)成webp格式，我們?cè)诖虬_本中部署了基于Pngquant和Guetzli的圖片壓縮插件，共使包體減少2M左右。
其中，Pngquant是一個(gè)用于有損壓縮png圖片命令行工具，經(jīng)過Pngquant轉(zhuǎn)換后的png能減少一半的文件大小并保留了alpha透明度。Guetzli是一個(gè)高質(zhì)量壓縮jpeg的圖像編碼器，可以將jpg圖片減少35%左右。我們分別調(diào)用Pngquant工具命令行和Guetzli工具命令行來實(shí)現(xiàn)png和jpg圖片的壓縮。
