【51CTO.com原創(chuàng)稿件】　　扇貝是一個全面有效提升英語的移動互聯網學習平臺，有包括單詞、聽力、口語、新聞、閱讀、煉句在內的六大應用，是目前國內唯一能讓用戶在移動端完成英語學習整個一套閉環(huán)的學習系統(tǒng)。

[[174713]]

　　為什么要做APK瘦身?

　　一個很現實的事情是，到上個月底有23.49%用戶使用移動網絡使用App，其中有4.09%用戶還在使用2G網絡，這是一個很可怕的數字，因為到今天為止仍在使用Android2.3的用戶已經是1%甚至連1%都不到的在網用戶量，然而使用2G網絡用戶還有4.09%。因為現在用戶使用移動網絡時有一個比較高的成本，大致如果要超了套餐1M在0.1元左右，如果做一次App更新或者一個新用戶安裝用戶成本是多少?現在國內應用市場還是劣幣驅逐良幣的環(huán)境，沒有一家市場能夠做到50%以上的量，意味著很多市場還是屬于不是Sister map，帶來***的問題是并沒有一個進網安裝權限，一旦如果涉及到應用更新，沒有辦法做到用戶無感知進行更新，用戶會很煩這件事，有一些第三方市場會用Work round，比如做自動點擊，這不是很好的解決方案。在升級成本本身除了費用上的成本，還有用戶操作成本的情況下，結合這兩者就帶來了一個結果，用戶對APK大小非常敏感，這里指的是Android用戶。APK大小會帶來兩個附加影響，分別是安裝時間，很好理解，當可視性文件跟so文件，變大安裝時間一定會有影響，不管是在安裝5.0之前，從DEX到ODEX的優(yōu)化，還是安裝5.0之后從DEX到OAT文件的預編譯，時間肯定是正常的。還有一個問題是安裝成功率，為什么APK大小對安裝成功率有影響?比如1.0版本是10M，1.1版本變成了100M，用戶只有50M空間，這當然是個極端例子，類似這樣的問題就會導致如果APK大小突然變大，也有可能導致下發(fā)出現問題。

　　APK瘦身

　　APK瘦身只有一個大小的概念，談到APK瘦身涉及到四個不同大小。首先是Raw APK Size，APK文件大小。除此之外還有三個不同的，Download Size，為什么跟Raw APK Size不一樣?最早是國外做，但現在已經有很多國內市場也會做，在下發(fā)時會做一層，最簡單可以做把APK本身在傳輸時做一層封裝。第三點是在安裝時，因為需要對DEX文件和so文件做相應操作，so文件跟DEX文件不一樣，so文件需要拷貝出來，本身占用的體積一定跟APK Size不一樣。***一個是Update Size，為什么跟APK文件本身大小不一樣?因為現在大部分應用市場已經做了這點，如果好一些可能會有自研的東西，可以做到一點，更新一個App，下載的并不是一個完整的APK，而是下載一個diff文件，本地合成完整的APK，從而減少用戶在網絡傳輸流量上的壓力。

　　這四個Size當中，作為應用開發(fā)者最關心的應該是***個和第三個，能控制的是***個和第三個，不是說第二個和第四個沒有辦法控制，國內炒得非常熱的插件化和Hotfix，就能夠部分意義上解決第二個和第四個在應用開發(fā)者這一側的控制問題。

　　簡單看一下APK文件的生命周期。在前兩行是APK文件生成和打***程，從Source Code到class，到Dex文件。Resources和Native Code，在后面會插進來，Resources本身的流程當中會有一個簡單的優(yōu)化，APK會做，就現在的時間點來說比較傻，甚至還會有把Resources文件越壓越大的問題。因為需要做不管是Dex到Odex的優(yōu)化，還是要做Dex到OAT文件的預編譯，這邊一定會產生文件大小上的影響，會變大。Native code都是黃線，往下走時直到今天，Google在處理Native code還是使用了比較原始的方案，會把相應版本以so文件拷貝出來。

　　音頻文件，是時候該放棄mp3了，如果App中包含了音頻文件，建議大家直接選擇aac，在任何意義上都比mp3好得多，在同樣的編碼率下可以平均能夠減少20%的Size。圖片文件都可以腳本化做，不應該由人工做這件事。首先要把meta data刪掉，第二步要做無損壓縮，格式選定時也可以用一些簡單標準做一個判斷，

　　***要做的，App本身有做這樣的優(yōu)化，在這樣的情況下手動做這些優(yōu)化App是不知道的，做了這樣的優(yōu)化，把App本身比較笨的優(yōu)化關掉，否則會發(fā)現好不容易壓下來的東西會被App重壓過以后變大了。

【51CTO原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為51CTO.com】