隨著業(yè)務的快速迭代，抖音 Android 端的包大小爆發(fā)式增長。包大小直接影響到下載轉(zhuǎn)化率、推廣成本、運行內(nèi)存和安裝時間等因素，因此對 apk 進行瘦身是一件很有必要且收益很大的事情。apk 主要由 dex、resource、asserts、native libraries 和 meta-data 組成，針對每一部分，都可以專項去做包大小優(yōu)化。抖音 Android 端經(jīng)過一段時間努力，包大小優(yōu)化已經(jīng)取得了階段性的成果。目前仍在持續(xù)的優(yōu)化中。
其中，資源在 apk 包體積中占比很大，針對資源進行優(yōu)化是包大小優(yōu)化中很重要的部分。本著追求極致的原則，本文將詳細闡述抖音 Android 端針對資源部分的優(yōu)化措施。
在不進行壓縮的情況下，圖片大小計算公式：圖片大小=長 x 寬 x 圖片位深。一張原始圖像(1920x1080)，如果每個像素 32bit 表示(RGBA)，那么圖像需要的存儲大小 1920x1080x4=8294400Byte，大約 8M，一張圖這么大是難以接受的。因此我們使用的圖片都是經(jīng)過壓縮的。圖片壓縮利用的是空間冗余和視覺冗余原理：
抖音 Android 研發(fā)團隊開發(fā)了 Gradle 插件 McImage，在編譯期間 hook 資源，采用開源的算法 pngquant/guetzli 進行壓縮，支持 webp 壓縮。與 tinypng 等一些已知的方案相比，存在以下優(yōu)勢：
McImage 支持兩種優(yōu)化方式，這兩種優(yōu)化方式不可同時使用:
webp 的壓縮比要高于 pngquant、guetzli，所以現(xiàn)在更推薦使用 ConvertWebp 這種壓縮方式。
McImage 還被應用于字節(jié)跳動旗下多個產(chǎn)品的圖片壓縮優(yōu)化工作中，收益如下：
除了壓縮、優(yōu)化圖片，McImage 還提供了以下功能：
tinypng 與 webp 到底哪個壓縮比更高呢？在網(wǎng)上找不到兩種壓縮算法壓縮比的直接比較，需要更直觀的對比，于是做了如下的實驗：
通過這兩組實驗對比，可以看出 webp 的壓縮比是優(yōu)于 tinypng 的。之前也手動的使用 webp 工具壓縮過抖音工程中所有圖片，包大小減少了 1.6MB 左右。因此選擇了 Webp 壓縮算法。
webp 壓縮算法，相較于 pngquant、guetzli、tinypng，webp 壓縮比更高，所以 webbp 壓縮圖片應該是更優(yōu)的選擇。但是 Android 設備對 webp 的支持存在兼容性問題，在 4.3 以上才完全支持。通過官網(wǎng)我們知道，想在應用中直接使用帶有透明度的 webp，minSDK 至少需要是 18。
包括抖音、在內(nèi)的頭條系 Android 應用，大部分 minSDK 是 16，無法直接使用 webp 圖片，需要做低版本兼容。通過大量調(diào)研，找到了三種兼容的方式：
想要做到無侵入式的兼容，運行時 hook 不失為一種最佳的選擇。但是運行時 hook 方案，需要解決以下幾點問題：
通過對 Xposed、AndFix、Cydia Substrate、dexposed 等常見的 Android Java hook 方案的調(diào)研對比，dexposed 具有不需要 root、又能 hook 系統(tǒng)方法的特點，最終選擇 dexposed:
通過閱讀源碼，發(fā)現(xiàn)所有圖片被加載解析成 Bitmap 的過程，最終都調(diào)用到了 BitmapFactory 中的方法。 比如 ImageView 的 setImageResource() 的調(diào)用路徑如下:
ImageView 的 setImageResource 過程，Bitmap 的創(chuàng)建是通過 BitmapFactory 來實現(xiàn)。 如 View 的 setBackgroundResource(int resid)的源碼如下：
查閱所有加載圖片的 api，都會經(jīng)歷 Resources 調(diào)用 getDrawable 的過程。會調(diào)用到 Drawable 的相關方法，然后通過 BitmapFactory 去解析不同的資源類型（File\ByteArray\Stream\FileDescriptory）為 Bitmap。由此可以推斷出，BitmapFactory 是 Android 系統(tǒng)通過不同的資源類型加載成 Bitmap 的統(tǒng)一接口，這一點從 BitmapFactory 的類注釋中也能看出：
由于系統(tǒng)加載解析 Bitmap 的過程已經(jīng)足夠收斂，都是通過 BitmapFactory 來實現(xiàn)，因此 BitmapFactory 是一個非常不錯的 hook 點。
有了穩(wěn)定的 Hook 方案和足夠收斂的 Hook 點，方案的實現(xiàn)起來就手到擒來了，利用 dexposed 對 BitmapFactory 里的關鍵方法進行替換就可以了。
Android 為了適配各種不同分辨率或者模式的設備，為開發(fā)者設計了同一資源多個配置的資源路徑，app 通過 resource 獲取圖片資源時，自動根據(jù)設備配置加載適配的資源，但這些配置伴隨著的問題就是高分辨率的設備包含低分辨率的無用圖片或者低分辨率的設備包含高分辨率的無用圖片。
一般情況下，針對國內(nèi)應用市場，App 為了減少包大小，會選用市場占有率最高的一套 dpi（google 推薦 xxhdpi）兼容所有設備。 而針對海外應用市場的 APP，大多會通過 AppBundle 打包上傳至 Google Play，能夠享受動態(tài)分發(fā) dpi 這一功能，不同分辨率手機可以下載不同 dpi 的圖片資源，因此我們需要提供多套 dpi 來滿足所有設備。 在項目中，我們的圖片有的只有一套 dpi，有的有多套 dpi，針對上述兩種場景，我們分別在打包時合并資源、復制資源，減少了包大小。
在國內(nèi)項目中，為了減少圖片的占用，一般都會對市場占用率高的 dpi 進行適配，比如只保留 xxhdpi 分辨率的圖片。這樣就導致了兩個問題，一個是市場上 2k 分辨率手機越來越多，如果以后手機主流分辨率是 xxxhdpi，那么項目中幾千張圖片修改成本會非常高。 另一個問題是，公司不少海外產(chǎn)品是通過 AppBundle 打包上傳到 Google Play 的，能夠給不同設備用戶下發(fā)不同 dpi 的資源。但項目中只有 xxhdpi，仍然下發(fā) xxhdpi 的圖片，無法通過降低 dpi 減小包大小。在巴西，我們 80%用戶都使用 xhdpi 和 hdpi 手機，xxhdpi 圖片相比 hdpi 占用多了一倍，這部分收益相當高。
因此，我們通過壓縮分辨率的方式將高分辨率的圖片降低到低分辨，項目業(yè)務只存放最高 dpi 圖片，在打包的時候按需求復制篩選。 我們在 hook 了圖片壓縮的 task，在圖片壓縮前，獲取到包括依賴庫在內(nèi)的所有 PNG 圖片，利用 Graphics2D 降低圖片分辨率，放在對應分辨率文件夾中。之后再執(zhí)行圖片壓縮 task，防止一些圖片重采樣后大小增加。
我們僅對圖片的分辨率進行縮放，并不降低圖片采樣率，因此在顯示效果上沒有區(qū)別。 不同 dpi 具體應該調(diào)整到多少分辨率，我們根據(jù) Google 的定義制作了一個表格：
我們復制一張 xxhdpi 的默認 logo 到所有 dpi，流程如下圖，xhdpi 和 mdpi 文件夾下沒有對應圖片，復制；在 hdpi 中有對應圖片，跳過；xxxhdpi 也沒有對應圖片，但為了避免降低圖片精度，不能向更高分辨率文件夾復制，跳過。
最終收益如圖，公司內(nèi)海外產(chǎn)品 TikTok 研發(fā)團隊在使用該方案優(yōu)化時，ldpi 相比 xxhdpi 減少了 2.5M 包大小。同時，低分辨率手機加載圖片時直接加載對應 dpi 圖片資源，不再需要對高分辨率圖片進行縮放處理，提高了性能。
在復制時需要注意這些問題： 為了處理包括依賴庫中的所有圖片，在資源合并階段進行了復制，這樣會導致.cache 目錄的很多路徑下會多出大量圖片資源，因此這個插件我們在 CI 上開啟，避免本地打包新增大量圖片，提交到代碼倉庫。同時，由于.cache 中被復制了多份圖片，需要在 assemble 打包流程中進行多 dpi 去重。 在 CI 上會有并發(fā)場景，同時復制和壓縮會導致.cache 目錄下同時存在 a.png 和 a.webp，出現(xiàn) Duplicated 錯誤，因此最后需要掃描刪除同名的.png 文件。
針對普通打包模式(直接產(chǎn)出 apk,比如抖音包)，我們可以選擇只保留一份分辨率偏高的的圖片，這樣高分辨率設備可以拿到合適的圖片、低分辨率設備通過 Resource 獲取時會自動進行縮放，依然可以保證合理的運行內(nèi)存。
多 dpi 圖片可以通過 Android 自帶的 resConfig 去重，但這個配置只對資源的 qualifier 去重，比如對像素密度和屏幕尺寸不會同時做去重，抖音使用基于 AndResguard 修改的方式對 drawable 去重，可以定義不同配置的優(yōu)先級和作用范圍。 根據(jù)優(yōu)化配置確保留一份資源，優(yōu)化方式如下圖(灰色數(shù)據(jù)表示會被刪除)：
隨著項目的迭代，項目中難免會出現(xiàn)相同的資源被重復添加到資源路徑中，對于這類文件，人工處理肯定是不可行的，可以在打包階段自動去重。
抖音選擇在 AndResguard 階段對所有的資源進行分析，對 md5 相同的資源文件保留一份，刪除其余的重復的文件，然后在 AndResguard 寫入 arsc 文件時進行將刪除的資源文件對應的資源路徑指向唯一保留的一份資源文件。 優(yōu)化方式如下圖：
下圖是抖音 511 版本接入多 dpi 去重與重復資源合并功能的優(yōu)化結(jié)果：
隨著項目的開發(fā)迭代，我們會有許多資源已經(jīng)不再使用了，但仍然存在于項目中。雖然我們可以使用公司開源的字節(jié)碼插件開發(fā)平臺 ByteX 開發(fā)插件在 ProGuard 之前掃描出一些無用資源，但因為這一步?jīng)]有經(jīng)過無用代碼刪除，因此掃描出的結(jié)果并不全。而 shrinkResources 是 google 官方提供的優(yōu)化此類無用資源的方法，它運行在 Proguard 之后，能標記所有無用資源并將其優(yōu)化。
抖音 Android 在開啟 shrinkResources 嚴格模式后，shrink 資源數(shù) 600+，收益大小 0.57MB。
shrinkResources 是由 Google 官方提供的工具，因此詳細的接入方式參考 Google Developer 上的文檔即可。
默認情況下，Resource shrink 是 safe 模式的，即其會幫助我們識別類似 val name=String.format("img_%1d", angle + 1) val res=resources.getIdentifier(name, "drawable", packageName) 這樣模式的代碼，從而保證我們在反射調(diào)用資源文件的時候，也是能夠安全返回資源的。 從源碼來看，Resource shrink 時會幫助我們識別以下五種情況：
而 Resource shrink 使用了一種最笨但卻最安全的方法去獲取匹配的前綴/后綴字符串，那就是將應用中所有的字符串都認為是可能的前綴/后綴匹配字符串。
所以這就造成了在安全模式下，不小心被某個字符串所匹配到的資源，即使沒有被使用也會被保留下來。以我們的項目為例，在 com.ss.android.ugc.aweme.utils.PatternUtils 中，我們有以下代碼：
在安全模式下，這就造成了所有以 tt 開頭的無用資源都不會被 shrink 掉（這也就是為什么嚴格模式一開，ttlive_ 開頭的無用資源那么多的原因）。
而嚴格模式打開后，其作用便是強行關閉這一段的字符匹配的過程：
當然這也就造成了我們在使用 getIdentifier() 的時候是不安全的，因為嚴格模式下是不會匹配任何字符串的，所以在開啟嚴格模式之后，一定要嚴格檢查所有被 shrink 的資源，是否有自己需要反射的資源！
AppBundle 是 Google 近年來力推的一個功能，它能夠讓我們的 apk 按照不同的維度生成下發(fā)，也提供了一個動態(tài)下發(fā)功能的方式，Dynamic Feature。但是如果我們在開啟 Dynamic Feature 之后使用 shrinkResources，則提示以下錯誤：
由此看來 Google 官方并不支持 App Bundle 使用 Dynamic Feature 時使用 shrink resource。在 Google Issue Tracker 上發(fā)現(xiàn)已經(jīng)有人對此提交過 Issue 了，相關 Issue。而 Google 的回復也是簡單粗暴----計劃中，但是沒有時間：
但是正常來說，如果做的好的話，我們的 App Bundle 的 Dynamic Feature 模塊是很少會引用 Master 的資源的，即使有，使用 keep.xml 的方式也能將這種資源給保留下來。因此，理論上來說，單獨對 Master 模塊進行 shrinkResource 并注意反射調(diào)用的話，是沒多大問題的。 Dynamic Feature 下檢查 shrinkResources 配置是在 Configuring 階段
因此我們的想法便是在配置階段不開啟 shrinkResources 開關，而在后面執(zhí)行資源處理任務的時候自行插入 shrinkResources 的 Task：
這樣就能在 Dynamic Feature 下開啟 shrinkResources 的 Task 了，整個代碼編寫十分簡單，不到 50 行就能完成：
資源 id 與資源全路徑的映射關系記錄在 arsc 文件中，app 通過資源 id 再通過 Resource 獲取對應的資源，所以對于映射關系中的資源路徑做名字混淆可以達到減少包體積的效果。
抖音啟用了微信開源的 AndResguard 進行資源混淆，在開源的基礎上進行了增加了 MD5 去、多 DPI 只保留一份資源等優(yōu)化。 由于公司內(nèi)部有很多海外產(chǎn)品，在上架 Google Play 時需要走 aab，因此團隊做了資源混淆的 aab 兼容-- aabResguard（開源 | AabResGuard: AAB 資源混淆工具），已開源。
resources.arsc 這個文件在很多項目中都占用了相當多的空間。常見的優(yōu)化方法是使用 AndResGuard 混淆減少文件名及目錄長度，7z 壓縮，如果有海外產(chǎn)品的話可以動態(tài)下發(fā)語言。 我們在做完這些優(yōu)化后，由于公司內(nèi)部有很多海外產(chǎn)品，涉及到多語言的關系，ARSC 依然很大，我們決定嘗試進一步優(yōu)化。經(jīng)過調(diào)研，最終我們對 3 個方面做了優(yōu)化，分別是刪除無用 Name、合并字符串池中重復字符串、刪除無用文案，最終帶來的收益是 1.6MB。 在此之前，我們還在 AndResGuard 的基礎上完成了重復 MD5 文件圖片合并，原理是一樣的。
先貼一張 arsc 結(jié)構(gòu)的圖，這個二進制文件的數(shù)據(jù)結(jié)構(gòu)相當復雜，AndResGuard 其實只修改了這個文件的一小部分，至于更多的修改就無能為力了，于是我們自己解析了這個文件進行分析。 網(wǎng)上也有不少關于這個文件格式的說明，這里就不贅述了。推薦老羅和尼古拉斯的博客以及 aapt2 源碼。google 提供的 android-arscblamer 和 apktool 的代碼也值得一看。
下面用一張圖簡單描述一下修改過程：
如圖，字符串其實是通過索引的方式來獲取的，所有字符串都保存在兩個字符串池中（單個 package），一個是全局字符串池，一個是 package 下的字符串池，我們只需要修改指向全局字符串的偏移值就行了。name 和 value 所在二進制位置如下圖。
AndResGuard 在今年的 7 月也增加了這個功能，我們來看一下實現(xiàn)原理。 Name 對應的字符串池是 package 字符串池，由于這個字符串池中只包含所有 Name，我們操作可以稍微暴力一點，先做一份備份，然后清空字符串池，添加一個用于替換的字符串，賦值為 [name_removed]。
首先要確定哪些 name 是通過 getIdentifier 調(diào)用，配置成白名單。 遍歷 name 項，如果不在白名單，那么把這一個 name 的偏移替換成 0，使其指向[name_removed]。 如果 name 在白名單，那么不應該刪除，我們通過備份的字符串池找到這個 name 對應的字符串，添加到字符串池中，把偏移指向?qū)聵思纯伞?/p>
抖音通過這個優(yōu)化減少了包大小 70k。
value 所對應的是全局字符串池，雖然名字聽起來不會有重復值，但在我們掃描排序后發(fā)現(xiàn)其實有很多重復字符串（用 AppBundle 打包就不會存在這個問題） 在抖音項目中，這個字符串池里有 1k+個重復字符串，合并這些字符串是非常必要的。
我們先遍歷所有數(shù)據(jù)，然后把字符串池的重復字符串合并，記錄偏移的修改，最后把需要修改的 value 的引用指向新的偏移。這個過程需要操作 arsc 數(shù)據(jù)結(jié)構(gòu)的 ResValuel 和 ResTableMap，以保證所有 string 類型的值都能得到替換。
抖音通過這個優(yōu)化減少了包大小 30k。
在打包過程中，其實所有 strings.xml 中保存的字符串都是不會被優(yōu)化的，隨著項目逐漸變大，一些廢棄文案或者下個版本才有用的文案被引入了 apk 中，我們在 Proguard 后再次掃描，發(fā)現(xiàn)了 3000+個無用字符串。在公司內(nèi)部的一些海外項目中，有的文案被翻譯成 100 多個國家的語言，占用了極大的空間。
刪除的方法和上面類似，都是指向替換的字符串所在偏移。 如圖可能會存在兩個不同 name 指向同一個字符串，需要判斷待刪除的字符串是否還有其他引用。
不同項目收益可能不太一樣，公司內(nèi)部海外項目對這些無用文案進行了替換，減少了 1.5M 包大小左右。
如果是普通的 assemble 打包，直接在 ProcessResources 過程中獲取 ap_文件中的 arsc 文件，利用我們的工具修改即可。
如果是 AppBundle 方式打包，修改 ap_是沒有用的，因為最后產(chǎn)物是用 aapt 以 proto 格式生成的 resources.pb 文件，要修改只能 hook aapt 過程。這個文件和 arsc 文件結(jié)構(gòu)不太一樣，好在我們可以使用官方提供的 Resources 類解析、生成 pb 文件，使用相似的方法修改即可。
修改效果如圖：
arsc 中的偏移數(shù)組是有優(yōu)化空間的，我們會在未來嘗試進行優(yōu)化。 用二進制編輯器打開 arsc 文件可以發(fā)現(xiàn)，這樣的 FF 值在文件中大量存在。
是什么導致了這樣的空間浪費？ 我們可以看到下圖中框選的空白，每一個都代表了其字符串所在的偏移值，這里并沒有值，賦值 FF FF FF FF 作為默認偏移值，浪費了 4 字節(jié)空間。 某些列（configuration）可能就只有幾個格子有值，如圖抖音中 drawable 有 4k+張圖片，有 24 列，大多數(shù) configuration 只有幾張圖片，因此浪費了 4k*23*4≈380k。大致估算，抖音可以減少 1M 體積。（壓縮前）
如下圖 facebook 針對 arsc 文件的處理，我們可以把一行只有一個值的 id 抽出來，單獨放到一個 Resource Type 中，每一個 id 只有一個值，避免了上述空間浪費情況。 但這樣做修改了 ID，因此對應的代碼中的 ID 也要修改，涉及了逆向 xml 以及 dex，提高了修改成本。還有一種思路是修改 aapt 源碼，沒有直接改 arsc 靈活。
上述就是我們抖音 Android 端在包大小優(yōu)化方面針對資源做的一些嘗試和積累，力求追求極致。
我們針對包大小優(yōu)化，在其他方面還做了很多優(yōu)化措施:針對 so 優(yōu)化，做了 so 合并、stl 版本統(tǒng)一、精簡導出符號表和 so 壓縮等措施；針對代碼優(yōu)化，細化混淆規(guī)則，開發(fā) bytex 插件進行無用代碼掃描、acess 方法內(nèi)聯(lián)、getter/setter 方法內(nèi)聯(lián)、刪除行號等優(yōu)化措施。
除了優(yōu)化措施，良好的包大小監(jiān)控系統(tǒng)是防止包大小劣化最重要的工具，否則包大小優(yōu)化措施取得的收益抵不過業(yè)務快速迭代帶來的包大小增長。抖音 Android 端結(jié)合 CI、Cony 平臺，開發(fā)出了一套代碼合入前置檢查系統(tǒng)，每個分支增量超過閾值不準合入；還開發(fā)了分業(yè)務線監(jiān)控包大小的工具，便于監(jiān)控每個業(yè)務線包大小增長和給各個業(yè)務線定包大小指標。
最后，抖音 Android 誠招對技術有無限熱情的小伙伴。感興趣的小伙伴都可以通過 字節(jié)跳動招聘官網(wǎng)查詢抖音 Android 相關職位（「鏈接」） 或簡歷發(fā)送至 shipeiqing@bytedance.com。
抖音BoostMultiDex：Android低版本上首次啟動時間減少80%（二）
抖音BoostMultiDex：Android低版本上首次啟動時間減少80%（一）
開源 | AabResGuard: AAB 資源混淆工具
歡迎關注字節(jié)跳動技術團隊
在arXiv上發(fā)現(xiàn)了一篇中意的論文，當然是下載保存慢慢研究！
然而，等你好不容易看完了文章，發(fā)現(xiàn)作者又上傳了V2、V3，一眼望去卻看不出差別，這種情況令人頭疼不已，難道又要花幾個晚上時間研究新版本？
Github上的一個比較預印本論文版本差別的工具也許能幫到你，而且只需一行代碼就能實現(xiàn)。
運行這個工具你需要安裝PyPI包、以及帶有pdflatex和latexdiff的文本分布工具。
對于Linux系統(tǒng)，可以通過運行這個指令來安裝文本分布工具：
sudo apt-get install texlive-fullMacOS系統(tǒng)通過這個指令安裝：
brew cask install mactex前提是你已經(jīng)安裝過了Homebrew。
使用環(huán)境都配置好以后，直接使用指令安裝comparxiv工具：
pip install comparxiv或從項目地址安裝：
git clone https://github.com/temken/comparxiv.gitcd comparxivpython setup.py install安裝完成就可以開始使用了。
如果我們要比較某一篇論文的最近兩個版本，只需要提供論文的ID：
comparxiv hep-ph/0612370如果要比較第N和N-1版本，運行這個指令：
comparxiv 1709.06573vN比較兩個特定版本N、M，運行：
comparxiv 1905.06348 N M或者：
comparxiv 1905.06348vN M如果運行成功，會輸出一個pdf文件并自動打開：
此外，還有一些實用指令，輸入：
comparxiv —help可查看，包括：
這個項目于4月24日上傳Github，作者聲明現(xiàn)在還處在b測階段，除了一些測試的論文實例，無法應用在所有的arXiv論文上。
但是從已有的測試結(jié)果來看，完全稱得上便捷實用。
所以建議你先馬后看，等待正式版本問世，大概率會是一個人見人愛的實用工具。
Github項目地址：https://github.com/temken/comparxiv