用戶抱怨安裝包越來越大？印度友人反饋裝不上微信？歡迎來到本期的走進科學(xué)--安裝包速成記。做一個有節(jié)操的安裝包，我們希望它越小越好，并且確保用戶都能安裝的上。

Android的安裝包，簡單來說就是一個壓縮包，首先我們了解一下它的生成過程。

一、安裝包編譯過程

一般我們使用ant、gradle等方式編譯生成安裝包，它一般包含以下幾個步驟。

但是對于多l(xiāng)ibrary的結(jié)構(gòu)下，ant與gradle的并行度并不足夠。當(dāng)前微信已經(jīng)切換到Facebook的開源編譯工具buck(相關(guān)介紹http://facebook.github.io/buck/)，編譯速度得到了大大提升。

在buck的基礎(chǔ)上我們主要做了以下兩個工作：

EclipseToBuck，開發(fā)者無須關(guān)心buck腳本的編寫，buck腳本使用代碼自動生成

微信使用多l(xiāng)ibrary結(jié)構(gòu)，每次編譯后監(jiān)控每個模塊的線性內(nèi)存、方法數(shù)、資源大小。

二、減少安裝包大小的Tips

現(xiàn)在我們開始***項主要內(nèi)容，如何減少安裝包的體積？

1. 安裝包監(jiān)控

我們做安裝包優(yōu)化，首先要對我們安裝包每一部分有一個詳細的了解，知道安裝包大在什么地方，與上一版本有著怎么樣的變化。所以我們首先實現(xiàn)了一個安裝包檢測工具：

監(jiān)控

1. 每個dex方法數(shù)的變更情況；

2. 每個模塊線性內(nèi)存的變化情況；

3. 沒有alpha通道的png圖，可壓縮成jpg減少體積；

4. 超過一定數(shù)值的大文件，特別是圖片資源可采用有損壓縮；

5. 安裝包的大小、文件數(shù)變化；

6. 新增文件、減少文件，文件大小發(fā)生變化的情況；

現(xiàn)時微信的安裝包監(jiān)控包括兩個維度，一是每日的監(jiān)控，采用的是***一個包與昨日的***一個包對比；二是版本之間的對比，發(fā)布前需要用待上線版本與線上版本對比。我們希望若發(fā)現(xiàn)問題，能立刻警報，提交到bug系統(tǒng)。

2. 刪除無用資源

在產(chǎn)品的大錘下，每個模塊不修改個三五十次，都不好意思說自己是微信的開發(fā)。在不停的迭代中，或多或少會出現(xiàn)無用的資源，包括但不限于xml、png、id、string。

查找無用資源主要使用lint的UnusedResources以及UnusedIds兩個檢查規(guī)則，但是針對多l(xiāng)ibrary結(jié)構(gòu)，官方的lint在某些方面不符合我們的要求，所以我們修改了一些地方。

對于使用gradle的童鞋，可以采用：

android { 
... 
buildTypes { 
release { 
minifyEnabled true 
shrinkResources true 
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' 
} 
} 
} 

3. 圖片處理

.png、.9.png、.jpg、.gif資源是每一個安裝包永遠的痛，追求美感的設(shè)計師希望每個像素都是***的。這邊的tip有以下幾點：

詳細描述

1.對于體積特別大(超過50k)的圖片資源可以考慮有損壓縮，jpg采用優(yōu)圖壓縮，png嘗試采用pngquant壓縮，輸出視覺判斷是否可行；

2.對assets中的圖片資源也使用aapt的crunch做圖片預(yù)處理；

3.crunch有可能會使圖片變大，在這種情況，我們可以替換成原圖。需要注意的是對于.9.png，由于crunch過程中去除了黑邊，所以不能替換；

4.對于沒有透明區(qū)域的png圖片，可以轉(zhuǎn)成jpg格式。

4. 字符串編碼

為了節(jié)省空間，resources.arsc中的會有一個去重過的字符串資源池(相同的兩個字符串其實用的是同一份)，每個String使用偏移值來獲取資源池中的數(shù)值。ResourceTable的編碼對于resources.arsc的體積有很大影響。

從Android 2.2 API Level8開始APK文件的資源resources.arsc的編碼有了小幅的改變，過去使用的是UTF-16編碼方式被轉(zhuǎn)換成了UTF-8編碼。這樣的好處就是處理純英文等直接通過ascii存儲語言的國家資源文件將會更小，而對于中文、日文這些國家的資源文件有可能會變大。

bool getUTF16StringsOption() {

return mWantUTF16 || !isMinSdkAtLeast(SDK_FROYO);

}

當(dāng)然如果你發(fā)現(xiàn)使用UTF-8后resources.arsc反而變大，你可以強制使用UTF-16編碼。只需要在aapt中指定--utf16參數(shù)，也就是指定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>

參數(shù)：

-v:會以table的形式輸出目錄，table的表目有：Length、Method、Size、Ratio、Date、Time、CRC-32、Name。

其中Method表示壓縮形式，有：Deflate及Stored兩種，即該Zip目錄采用的算法是壓縮模式還是存儲模式；可以看出resources.arsc、*.png采用存儲模式，而其它采用壓縮模式。

有時候我們?yōu)榱税涯硞€數(shù)據(jù)文件不壓縮，而把它的后綴名改成png(其實可以指定appt參數(shù) -0 )。其實aapt對于某些壓縮率不會太高的文件都默認(rèn)使用了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是壓縮的，程序需要把它讀到內(nèi)存，也就是會增大運行內(nèi)存；

3. 對于安裝包中的jar可以指定不壓縮，其實二次壓縮的壓縮率非常低；

此外，7z壓縮算法號稱優(yōu)化了字典，完全兼容zip，使用7zip的***壓縮模式比傳統(tǒng)zip方式的確有所提升，但是這里需要注意兩個問題：

上文kNoCompressExt說到的流媒體文件，是通過mediaplay直接拿文件句柄(沒有像assetmanager會先解壓文件，要求文件是seekable)也不能壓縮。

那么說一般來說只有.jpg、.jpeg、.png、.gif可以壓縮，對于不需要兼容低版本或者resources.arsc小于1M的apk，可選擇壓縮resources.arsc。

6. C++的So庫

5.1. C++運行時庫統(tǒng)一使用stlport_shared

之前微信中的C++運行庫大多使用靜態(tài)編譯方式，使用stlport_shared方式可減小APK包大小，相當(dāng)于把大家公有的代碼提取出來放一份，減少冗余。同時也會節(jié)省一點內(nèi)存，加載so的時候動態(tài)庫只會加載一次，靜態(tài)庫則隨著so的加載被加載多份內(nèi)存映像。

5.2. 把公用的C++模塊抽成功能庫

其實與上面的思路是一致的，主要為了減少冗余模塊。大家都用到的一些基礎(chǔ)功能，應(yīng)該抽成基礎(chǔ)模塊。

7. 語言包動態(tài)加載

由于微信是一個國際化軟件，我們在String中添加了20多種語言支持。這也導(dǎo)致我們的resources.arsc有5M多之巨，嘗試過假如只留下默認(rèn)的中文，resources.arsc可減少超過一半。事實上，大多數(shù)的語言我們并沒有使用到，這里提到的一個思路是動態(tài)下發(fā)語言包，程序中繼承Resource實現(xiàn)getString方式讀取即可。

假若你的apk并不要求聯(lián)網(wǎng)，要求用戶動態(tài)下發(fā)語言包似乎不work。這里在研究buck編譯的時候看到另外一個思路，即把大部分的語言二進制存放在assets。這個由于是普通數(shù)據(jù)文件，采用Deflate壓縮方式，會有比較大的壓縮率(與數(shù)據(jù)存儲方式也有關(guān)系)。

8. 資源混淆

我們常常用proguard來混淆代碼，那我們有沒有想過資源是否可以混淆？而混淆資源能帶來什么樣的好處？

建議

1. 比較酷，讓反編譯的人更加難受一下。面對一大堆以a,b,c,d命名的png、xml;

2. 由于resources.arsc需要記錄id與name的鍵值對，資源混淆對減少安裝包體積也有幫助。具體數(shù)值與編碼方式、id數(shù)量、平均減少命名長度有關(guān)(其實可以自己估量一下)。

微信的資源混淆工具不依賴源碼，只要輸入一個apk就能得到一個混淆之后的apk，大家有興趣的話，可以后續(xù)單獨來講。通過資源混淆微信大約能減少1M左右的大小，效果如下：

9. 持續(xù)交付

持續(xù)交互的***目標(biāo)就是讓使用某個功能的人才會真正去下載某個模塊，這首先需要我們代碼結(jié)構(gòu)的支持，即模塊化以及支持動態(tài)加載。微信對gpserver、打飛機等功能試用動態(tài)加載方式。其實這塊的核心思想就是將一些邊緣的，不常用的功能，都盡量采用這種方式加載。但需要與產(chǎn)品大大們激烈PK，用戶至上嘛。

記住，砍功能永遠是減少安裝包的***法寶！

三、安裝包是否能安裝

這里討論第二個主要問題，如何確保我們的安裝包用戶都能安裝的上，特別是2.3以下的爺們(希望有不需要考慮它們的一天)。

1. Dex的65536高壓線

原因你懂得，超過請減少方法數(shù),或自行拆多dex。其實在這里，我們這邊有一點積累，但不在這篇文章的討論范圍。具體可參考km中的一些文章：

計算某個dex的方法總數(shù)，可使用：

function dex-method-count() {

cat $1 | head -c 92 | tail -c 4 | hexdump -e '1/4 "%d\n"'

}

想看到所有的方法，用dexdump吧。

2. 任何壓縮的資源的原始大小不能超過1M

具體參考減少安裝包大小tips中的第五點。

3. 線性內(nèi)存限制

其實這個往往才是決定安裝包是否能安裝的上的阿喀琉斯之踵(用完這個名詞，頓時高大上)。

關(guān)于線性內(nèi)存的限制，可參考文章：

https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920

簡單來說就是在dexopt過程中，系統(tǒng)限制一個5-16M的線性內(nèi)存，如果在讀取dex數(shù)據(jù)過程中超過了這塊內(nèi)存，就會出現(xiàn)dexopt失敗。

由于dalvik加載系統(tǒng)模塊時需要占用部分內(nèi)存，facebook的推薦值我們自身dex的***值是4M，但我們發(fā)現(xiàn)在某些2.3的機器超過3.5M之后依然會dexopt失敗。微信計算線性內(nèi)存使用的是buck中asm-debug-all中提供的方法，計算class中會被dexopt中會讀入線性內(nèi)存的總大小：

(buck源碼：https://github.com/facebook/buck)

通過baksmali反編譯dex，也能得到相同的效果。在上面的那篇Facebook文章中，它們通過hack的方式更改系統(tǒng)線性內(nèi)存的值，這涉及兼容性的問題，但按它們說只在三星的某些機型需要適配，so名稱是：

(庫地址：http://asm.ow2.org/)