來自微信團隊的Apk瘦身經驗
用戶抱怨安裝包越來越大？印度友人反饋裝不上微信？歡迎來到本期的走進科學--安裝包速成記。做一個有節操的安裝包，我們希望它越小越好，并且確保用戶都能安裝的上。
Android的安裝包，簡單來說就是一個壓縮包，首先我們了解一下它的生成過程。
一、安裝包編譯過程
一般我們使用ant、gradle等方式編譯生成安裝包，它一般包含以下幾個步驟。
但是對于多library的結構下，ant與gradle的并行度并不足夠。當前微信已經切換到Facebook的開源編譯工具buck(相關介紹http://facebook.github.io/buck/)，編譯速度得到了大大提升。
在buck的基礎上我們主要做了以下兩個工作：
EclipseToBuck，開發者無須關心buck腳本的編寫，buck腳本使用代碼自動生成
微信使用多library結構，每次編譯后監控每個模塊的線性內存、方法數、資源大小。
二、減少安裝包大小的Tips
現在我們開始***項主要內容，如何減少安裝包的體積？
1. 安裝包監控
我們做安裝包優化，首先要對我們安裝包每一部分有一個詳細的了解，知道安裝包大在什么地方，與上一版本有著怎么樣的變化。所以我們首先實現了一個安裝包檢測工具：
監控
1. 每個dex方法數的變更情況；
2. 每個模塊線性內存的變化情況；
3. 沒有alpha通道的png圖，可壓縮成jpg減少體積；
4. 超過一定數值的大文件，特別是圖片資源可采用有損壓縮；
5. 安裝包的大小、文件數變化；
6. 新增文件、減少文件，文件大小發生變化的情況；
現時微信的安裝包監控包括兩個維度，一是每日的監控，采用的是***一個包與昨日的***一個包對比；二是版本之間的對比，發布前需要用待上線版本與線上版本對比。我們希望若發現問題，能立刻警報，提交到bug系統。
2. 刪除無用資源
在產品的大錘下，每個模塊不修改個三五十次，都不好意思說自己是微信的開發。在不停的迭代中，或多或少會出現無用的資源，包括但不限于xml、png、id、string。
查找無用資源主要使用lint的UnusedResources以及UnusedIds兩個檢查規則，但是針對多library結構，官方的lint在某些方面不符合我們的要求，所以我們修改了一些地方。
對于使用gradle的童鞋，可以采用：
- android {
- ...
- buildTypes {
- release {
- minifyEnabled true
- shrinkResources true
- proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
- }
- }
- }
3. 圖片處理
.png、.9.png、.jpg、.gif資源是每一個安裝包永遠的痛，追求美感的設計師希望每個像素都是***的。這邊的tip有以下幾點：
詳細描述
1.對于體積特別大(超過50k)的圖片資源可以考慮有損壓縮，jpg采用優圖壓縮，png嘗試采用pngquant壓縮，輸出視覺判斷是否可行；
2.對assets中的圖片資源也使用aapt的crunch做圖片預處理；
3.crunch有可能會使圖片變大，在這種情況，我們可以替換成原圖。需要注意的是對于.9.png，由于crunch過程中去除了黑邊，所以不能替換；
4.對于沒有透明區域的png圖片，可以轉成jpg格式。
4. 字符串編碼
為了節省空間，resources.arsc中的會有一個去重過的字符串資源池(相同的兩個字符串其實用的是同一份)，每個String使用偏移值來獲取資源池中的數值。ResourceTable的編碼對于resources.arsc的體積有很大影響。
從Android 2.2 API Level8開始APK文件的資源resources.arsc的編碼有了小幅的改變，過去使用的是UTF-16編碼方式被轉換成了UTF-8編碼。這樣的好處就是處理純英文等直接通過ascii存儲語言的國家資源文件將會更小，而對于中文、日文這些國家的資源文件有可能會變大。
bool getUTF16StringsOption() {
return mWantUTF16 || !isMinSdkAtLeast(SDK_FROYO);
}
當然如果你發現使用UTF-8后resources.arsc反而變大，你可以強制使用UTF-16編碼。只需要在aapt中指定--utf16參數，也就是指定mWantUTF16為true(下面的注釋似乎跟代碼有出入)。
" --utf16\n"
" changes default encoding for resources to UTF-16. Only useful when API\n"
" level is set to 7 or higher where the default encoding is UTF-8.\n"
微信5.2.1把minSdkVersion更改到8，使用utf8編碼后，resources.arsc減少了將近1M。
5. 指定文件的壓縮方式與7zip壓縮
安裝包是一個壓縮文件，我們可以指定里面的文件采用哪種壓縮方式。假若我們輸入下面的命令：
aapt l <file_path.apk>
參數：
-v:會以table的形式輸出目錄，table的表目有：Length、Method、Size、Ratio、Date、Time、CRC-32、Name。
其中Method表示壓縮形式，有：Deflate及Stored兩種，即該Zip目錄采用的算法是壓縮模式還是存儲模式；可以看出resources.arsc、*.png采用存儲模式，而其它采用壓縮模式。
有時候我們為了把某個數據文件不壓縮，而把它的后綴名改成png(其實可以指定appt參數 -0 )。其實aapt對于某些壓縮率不會太高的文件都默認使用了Stored模式。具體如下：
/* these formats are already compressed, or don't compress well */
static const char* kNoCompressExt[] = {".jpg", ".jpeg", ".png", ".gif", ".wav", ".mp2", ".mp3", ".ogg", ".aac", ".mpg", ".mpeg", ".mid", ".midi", ".smf", ".jet", ".rtttl", ".imy", ".xmf", ".mp4", ".m4a", ".m4v", ".3gp", ".3gpp", ".3g2", ".3gpp2", ".amr", ".awb", ".wma", ".wmv"};
文件如果采用Deflate方式存儲，意味著通過AssetManager讀取時需要解壓，耗費的時間與文件的壓縮比成比例。但大家記得這里面有一個坑，在Android 2.3以前的任何壓縮的資源的原始大小超過1M，AssetManger讀取時會拋出異常。這里面的Tip有：
Tips
1. 對.png、.jpg強制壓縮，但是的確普遍壓縮率在3%-5%，收益不是特別高；
2. 假若你的resources.arsc小于1M，可以對它進行壓縮，這邊可壓縮50-70%。需要注意的是，如果你的resources.arsc是壓縮的，程序需要把它讀到內存，也就是會增大運行內存；
3. 對于安裝包中的jar可以指定不壓縮，其實二次壓縮的壓縮率非常低；
此外，7z壓縮算法號稱優化了字典，完全兼容zip，使用7zip的***壓縮模式比傳統zip方式的確有所提升，但是這里需要注意兩個問題：
上文kNoCompressExt說到的流媒體文件，是通過mediaplay直接拿文件句柄(沒有像assetmanager會先解壓文件，要求文件是seekable)也不能壓縮。
那么說一般來說只有.jpg、.jpeg、.png、.gif可以壓縮，對于不需要兼容低版本或者resources.arsc小于1M的apk，可選擇壓縮resources.arsc。
6. C++的So庫
5.1. C++運行時庫統一使用stlport_shared
之前微信中的C++運行庫大多使用靜態編譯方式，使用stlport_shared方式可減小APK包大小，相當于把大家公有的代碼提取出來放一份，減少冗余。同時也會節省一點內存，加載so的時候動態庫只會加載一次，靜態庫則隨著so的加載被加載多份內存映像。
5.2. 把公用的C++模塊抽成功能庫
其實與上面的思路是一致的，主要為了減少冗余模塊。大家都用到的一些基礎功能，應該抽成基礎模塊。
7. 語言包動態加載
由于微信是一個國際化軟件，我們在String中添加了20多種語言支持。這也導致我們的resources.arsc有5M多之巨，嘗試過假如只留下默認的中文，resources.arsc可減少超過一半。事實上，大多數的語言我們并沒有使用到，這里提到的一個思路是動態下發語言包，程序中繼承Resource實現getString方式讀取即可。
假若你的apk并不要求聯網，要求用戶動態下發語言包似乎不work。這里在研究buck編譯的時候看到另外一個思路，即把大部分的語言二進制存放在assets。這個由于是普通數據文件，采用Deflate壓縮方式，會有比較大的壓縮率(與數據存儲方式也有關系)。
8. 資源混淆
我們常常用proguard來混淆代碼，那我們有沒有想過資源是否可以混淆？而混淆資源能帶來什么樣的好處？
建議
1. 比較酷，讓反編譯的人更加難受一下。面對一大堆以a,b,c,d命名的png、xml;
2. 由于resources.arsc需要記錄id與name的鍵值對，資源混淆對減少安裝包體積也有幫助。具體數值與編碼方式、id數量、平均減少命名長度有關(其實可以自己估量一下)。
微信的資源混淆工具不依賴源碼，只要輸入一個apk就能得到一個混淆之后的apk，大家有興趣的話，可以后續單獨來講。通過資源混淆微信大約能減少1M左右的大小，效果如下：
9. 持續交付
持續交互的***目標就是讓使用某個功能的人才會真正去下載某個模塊，這首先需要我們代碼結構的支持，即模塊化以及支持動態加載。微信對gpserver、打飛機等功能試用動態加載方式。其實這塊的核心思想就是將一些邊緣的，不常用的功能，都盡量采用這種方式加載。但需要與產品大大們激烈PK，用戶至上嘛。
記住，砍功能永遠是減少安裝包的***法寶！
三、安裝包是否能安裝
這里討論第二個主要問題，如何確保我們的安裝包用戶都能安裝的上，特別是2.3以下的爺們(希望有不需要考慮它們的一天)。
1. Dex的65536高壓線
原因你懂得，超過請減少方法數,或自行拆多dex。其實在這里，我們這邊有一點積累，但不在這篇文章的討論范圍。具體可參考km中的一些文章：
計算某個dex的方法總數，可使用：
function dex-method-count() {
cat $1 | head -c 92 | tail -c 4 | hexdump -e '1/4 "%d\n"'
}
想看到所有的方法，用dexdump吧。
2. 任何壓縮的資源的原始大小不能超過1M
具體參考減少安裝包大小tips中的第五點。
3. 線性內存限制
其實這個往往才是決定安裝包是否能安裝的上的阿喀琉斯之踵(用完這個名詞，頓時高大上)。
關于線性內存的限制，可參考文章：
https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920
簡單來說就是在dexopt過程中，系統限制一個5-16M的線性內存，如果在讀取dex數據過程中超過了這塊內存，就會出現dexopt失敗。
由于dalvik加載系統模塊時需要占用部分內存，facebook的推薦值我們自身dex的***值是4M，但我們發現在某些2.3的機器超過3.5M之后依然會dexopt失敗。微信計算線性內存使用的是buck中asm-debug-all中提供的方法，計算class中會被dexopt中會讀入線性內存的總大小：
(buck源碼：https://github.com/facebook/buck)
通過baksmali反編譯dex，也能得到相同的效果。在上面的那篇Facebook文章中，它們通過hack的方式更改系統線性內存的值，這涉及兼容性的問題，但按它們說只在三星的某些機型需要適配，so名稱是：
(庫地址：http://asm.ow2.org/)
