日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
AndroidAPK瘦身實(shí)踐

因?yàn)橥茝V的需要，公司需要把APK的大小再“減小”一下，4M以內(nèi)!

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、小程序制作、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了龍圩免費(fèi)建站歡迎大家使用！

當(dāng)達(dá)到4M以內(nèi)之后，公司建議說，能否再壓壓?2M如何?

瘦身前

因?yàn)槠綍r(shí)就考慮到大小的限制，所以很多工作已經(jīng)做過了，如下列舉現(xiàn)在的狀態(tài)：

  1. 7.3M(Debug版本)和6.5M(Release版本)
  2. 開啟minifyEnabled
  3. 開啟shrinkResources
  4. 已經(jīng)去除不相關(guān)的大型庫(kù)
  5. 圖片和代碼已經(jīng)經(jīng)歷過粗略的一輪清理

開始魔鬼瘦身

1. tinypng有損壓縮

Android打包本身會(huì)對(duì)png進(jìn)行無損壓縮，不信大家可以看看apk中的圖片的大小實(shí)際上比你代碼工程里的圖片要小(針對(duì)沒進(jìn)行過無損壓縮的那些png圖)。

所以，純粹的進(jìn)行無損壓縮并不會(huì)對(duì)apk的減小有任何效果，這是我特別想在這里強(qiáng)調(diào)的一個(gè)經(jīng)驗(yàn)。

現(xiàn)在大家主流的比較喜歡用的tinypng其實(shí)是有損壓縮：

https://tinypng.com/

[原文] TinyPNG uses smart lossy compression techniques to reduce the file size of your PNG files…

[翻譯] TinyPNG使用智能有損壓縮技術(shù)，來減少PNG文件的大小…

通過tinypng確實(shí)能在盡量少的損失下再減小apk，如果圖片資源多或者大的話，效果還是很明顯的。

具體減少多少，因?yàn)檫@個(gè)處理過程我們是間隔做的，無法準(zhǔn)確給出結(jié)果，就按200k～500k算吧。

2. png換成jpg

經(jīng)驗(yàn)發(fā)現(xiàn)，一些背景，啟動(dòng)頁，宣傳頁的PNG圖片比較大，這些圖片圖形比較復(fù)雜，如果轉(zhuǎn)用有損JPG可能只有不到一半(當(dāng)然是有損，不過通過設(shè)置壓縮參數(shù)可以這種損失比較小到忽略)。

因?yàn)槎际谴髨D，所以這種方式能有效減小apk的大小。

這種情況下的apk的減小是不可估量的。

3. jpg換成webp

如果png大圖轉(zhuǎn)成jpg還是很大，或者想壓的更小，而盡量不降低畫質(zhì)，那么可以考慮一下webp。

android 4.0+才原生支持webp, 但是我們的app是兼容2.3+，所以4.0以下的設(shè)備將無法看到圖片。

考慮到我們4.0以下的所有設(shè)備比例之和大約在0.44%，非常少

4.0以下的設(shè)備不會(huì)崩潰

我們選擇不對(duì)4.0以下做webp兼容處理，不顯示就不顯示。否則，要引入webp相關(guān)so文件增大apk大小。

通過把下面四張大圖換成webp，webp的quality參數(shù)按50配置(據(jù)說官方評(píng)測(cè)75是最佳值)，清晰度勉強(qiáng)可以接受，這個(gè)值大家具體按產(chǎn)品要求來定。

其中安裝jpg轉(zhuǎn)webp工具:

 
 
 
 
    
  
  
  
  
  1. brew install webp 
    2.

轉(zhuǎn)換命令如下

 
 
 
 
    
  
  
  
  
  1. cwebp -q input.jpg output.webp// Example:cwebp -q 50 a.jpg a.webp 
    2.

更多下載：https://developers.google.com/speed/webp/docs/precompiled

最終，apk減小了188k。

4. 大圖縮小

如果經(jīng)過上面的步驟，依然存在大圖的話，說明確實(shí)圖有點(diǎn)大了，可能真的有點(diǎn)大了!

所以，要考慮的問題是，是否有必要保證如此的大小?能否縮小?

如果這方面能減小的話，apk瘦身的效果必然又會(huì)上一個(gè)檔次。

這種情況下的apk的減小是不可估量的。

5. 覆蓋aar里的一些默認(rèn)的大圖

一些aar庫(kù)里面包含根本就沒有用的圖。最典型的是support-v4兼容庫(kù)中包含一些“可能”用到的圖片，實(shí)際上在你的app中不會(huì)用到。

我沒有把所有圖都替換掉，只是把幾張大一點(diǎn)點(diǎn)的圖(選中的那些圖)用1×1的圖片替換，如果9patch圖的話，要做成3×3的9patch圖替換。

support庫(kù)可能還算好的，就怕有些庫(kù)引用了一些大圖而不自知，可以在/build/intermediates/exploded-aar/下的各個(gè)aar庫(kù)的res目錄查找檢驗(yàn)。

apk減小了18k。

6. 刪除armable-v7包的so

感謝@楊輝__ ,@kymjs張濤的提醒，armable-v7和armable文件夾可以只保留armable。

當(dāng)然，armable-v7a的庫(kù)會(huì)對(duì)圖形渲染方面有很大的改進(jìn)，因?yàn)槲覀冎饕且恍I(yè)務(wù)上動(dòng)態(tài)庫(kù)，所以刪掉無大礙。

apk減小了191k。

7. 微信資源壓縮打包

這個(gè)方案網(wǎng)上一直在說，之前一直沒有需求或者動(dòng)力實(shí)踐，在這里感謝一下@裸奔的凱子哥的推薦和交流，他那邊的apk可以壓小1M，效果還是比較驚人的。

這個(gè)步驟我是在后面很多步壓縮之后測(cè)試的，每個(gè)階段的壓縮結(jié)果都會(huì)有些許出入，所以數(shù)據(jù)僅供參考。

  • 通過正常壓縮，apk包減小了464k。
  • 如果開啟7zip，apk包減小了594k。
  • apk減小了594k。

PS: 關(guān)于這個(gè)壓縮，我集成到了gradle腳本中了，新建了一個(gè)Task，大概代碼如下：

 
 
 
 
    
  
  
  
  
  1. task compressReleaseApp { 
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3.     // 在現(xiàn)有release的版本上生成到compressed目錄下 
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5.     def appid = "appid" 
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7.     def channel = "abcdefghijkl" 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9.     def guardJarFile = file('../AndResGuard/andresguard-1.1.jar') 
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11.     def guardConfigFile = file('../AndResGuard/config.xml') 
    12.   
  
  
  
  12.  
    13.   
  
  
  
  13.     def originApkFile = file("../app.${appid}/build/outputs/apk/release/${appid}-release-${rootProject.ext.versionName}-${rootProject.ext.versionCode}-${channel}.apk") 
    14.   
  
  
  
  14.  
    15.   
  
  
  
  15.     def outputDir = file("../app.${appid}/build/outputs/apk/compressed/") 
    16.   
  
  
  
  16.  
    17.   
  
  
  
  17.     def keystoreFile = file(RELEASE_STORE_FILE) 
    18.   
  
  
  
  18.  
    19.   
  
  
  
  19.     // 開始執(zhí)行壓縮命令 
    20.   
  
  
  
  20.  
    21.   
  
  
  
  21.     def proc = "java -jar ${guardJarFile} ${originApkFile} -config ${guardConfigFile} -out ${outputDir} -signature ${keystoreFile} ${RELEASE_STORE_PASSWORD} ${RELEASE_KEY_PASSWORD} ${RELEASE_KEY_ALIAS}".execute(); 
    22.   
  
  
  
  22.  
    23.   
  
  
  
  23.     proc.waitFor(); 
    24.   
  
  
  
  24.  
    25.   
  
  
  
  25.     println "return code: ${ proc.exitValue()}" + ", stderr: ${proc.err.text}" + " stdout: ${proc.in.text}" 
    26.   
  
  
  
  26.  
    27.   
  
  
  
  27. } 
    28.

 config開啟了7zip, 部分配置如下：

 
 
 
 
    
  
  
  
  
  1.  
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3.  
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5.      
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7.      
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9.          
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11.          
    12.   
  
  
  
  12.  
    13.   
  
  
  
  13.      
    14.   
  
  
  
  14.  
    15.   
  
  
  
  15.   
    16.   
  
  
  
  16.  
    17.   
  
  
  
  17.      
    18.   
  
  
  
  18.  
    19.   
  
  
  
  19.          
    20.   
  
  
  
  20.  
    21.   
  
  
  
  21.          
    22.   
  
  
  
  22.  
    23.   
  
  
  
  23.      
    24.   
  
  
  
  24.  
    25.   
  
  
  
  25.   
    26.   
  
  
  
  26.  
    27.   
  
  
  
  27.      
    28.   
  
  
  
  28.  
    29.   
  
  
  
  29.          
    30.   
  
  
  
  30.  
    31.   
  
  
  
  31.      
    32.   
  
  
  
  32.  
    33.   
  
  
  
  33.   
    34.

詳情參考：https://github.com/shwenzhang/AndResGuard

原理介紹：

http://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=208135658&idx=1&sn=ac9bd6b4927e9e82f9fa14e396183a8f#rd

8. proguard深度混淆代碼

之前為了簡(jiǎn)單起見，很多包都直接忽略了，現(xiàn)在啟動(dòng)嚴(yán)格模式，把能混淆的都混淆了：

采用微信壓縮方案最終效果比較：

apk減小了215k。

PS:混淆后，一定要經(jīng)過嚴(yán)格測(cè)試，有時(shí)候甚至很難發(fā)現(xiàn)錯(cuò)誤，比如我開啟嚴(yán)格混淆，用了一段時(shí)間之后慢慢發(fā)現(xiàn)了兩個(gè)bug，排除了兩個(gè)包程序才正常。

9. 深度清理代碼和資源

有意思的是，無論何時(shí)何地去清理代碼和資源，總能有新的發(fā)現(xiàn):

  • 新發(fā)現(xiàn)或者新引入的無用圖片
  • 這幾張圖怎么一樣
  • 這個(gè)類好像沒有用
  • 沒用的類相關(guān)的圖片也沒用
  • 有些圖片可以用著色方案替換
  • 有些圖片可以用shape來代替
  • hdpi里的ic_luancher.png好像也可以刪掉
  • …

apk減小了66k。

10. proguard去符號(hào)表

之前為了保留調(diào)試信息，我們是在Proguard保留了符號(hào)表的：

-keepattributes SourceFile,LineNumberTable

官方渠道我覺得還是盡量保留這個(gè)，現(xiàn)在針對(duì)推廣渠道，只能采用特殊手段，注釋這一行。

apk減小了230k。

ps:以后友盟上看推廣渠道的bug要辛苦一點(diǎn)，手動(dòng)上傳mapping.txt了。

11. provided關(guān)鍵字

可以對(duì)僅在運(yùn)行時(shí)需要的庫(kù)設(shè)置provided關(guān)鍵字，實(shí)際并不被打包：

 
 
 
 
    
  
  
  
  
  1. provided 'com.android.support:support-annotations:22.0.0' 
    2.

我沒有發(fā)現(xiàn)這樣的場(chǎng)景，如果說有的話，就是support-annotations，但是經(jīng)過后來的測(cè)試驗(yàn)證，support-annotations本來就會(huì)在release版本中被minifyEnabled掉，所以對(duì)support-annotations設(shè)置provided是沒有意義的。

如果有實(shí)際場(chǎng)景，歡迎留言說明，不甚感激。

apk沒有減小。

12. 表情包在線化

雖然應(yīng)用的表情不多，只有50來個(gè)，但是如果能把這部分表情放到網(wǎng)上，不僅能有效減小apk大小，還可以方便后期擴(kuò)展支持：

打包成emoji_v1.zip, 大小是202k。

現(xiàn)在把emoji_v1.zip放到網(wǎng)上，按需下載后使用，最終對(duì)比結(jié)果如下：

apk減小了193k。

13. 全版本兼容的著色方案

考慮著色方案主要目的是更方便支持多主題，減輕UI工作量，減少工程里一大堆selector文件等，然后才是，順便的減小一下apk大小。

通過著色方案，我們?nèi)コ?0多張純色的按下狀態(tài)圖片和對(duì)應(yīng)的xml等等。

apk減小了15k。

PS: 具體實(shí)現(xiàn)可以參考 http://www.race604.com/tint-drawable/ ，而我也把它集成到了我的LessCode庫(kù)中了：DrawableLess.java：https://github.com/openproject/LessCode/blob/master/lesscode-core/src/main/java/com/jayfeng/lesscode/core/DrawableLess.java

14. 去除重復(fù)庫(kù)

發(fā)現(xiàn)兩個(gè)地方：

  • 現(xiàn)在發(fā)現(xiàn)七牛的SDK引用了android-async-http-1.4.6.jar，雖然不大，只有95.4k，但是感覺完全可以寫一個(gè)輕量級(jí)的jar，控制在10～20k就足夠了，具體可以在現(xiàn)有的網(wǎng)絡(luò)庫(kù)上實(shí)現(xiàn)。
  • 自己工程使用的是UIL，但是引入的第三方庫(kù)引用了picasso，兩個(gè)重復(fù)的圖片下載庫(kù)也是完全沒用必要的。

現(xiàn)在還沒有處理這塊，新任務(wù)介入，延期優(yōu)化，敬請(qǐng)期待。

15. 去除無用庫(kù)

這是一個(gè)很基本的點(diǎn)，但是確很容易被人忽視，當(dāng)你仔細(xì)回顧的時(shí)候，有一些雞肋的功能或者庫(kù)，是幾無用處的。不如干脆去掉。

比如，在很早的時(shí)候，我就把我們app里的sharesdk刪除了，因?yàn)閷?duì)于我們的產(chǎn)品定位和推廣來看，這毫無意義。

這種情況下的apk的減小是不可估量的。

16. 去除百度統(tǒng)計(jì)

這個(gè)視具體情況決定。

因?yàn)槲覀兊腁PP里面包含友盟和百度兩套統(tǒng)計(jì)系統(tǒng)，早期老板要求，事實(shí)上后面已經(jīng)很少看這方面的數(shù)據(jù)，百度統(tǒng)計(jì)的數(shù)據(jù)幾乎沒用人去看，可以暫時(shí)先去除。

原本的百度統(tǒng)計(jì)的jar有130多k，去除之后的apk的減小會(huì)遠(yuǎn)遠(yuǎn)沒有這么多。

apk減小了20k。

17. 使用更小的庫(kù)

使用更小的庫(kù)不應(yīng)該成為你選擇方案的決定性因素，但是可以作為參考因素(freso確實(shí)太大了，這個(gè)大小也可以成為決定性因素)。

圖片下載，網(wǎng)絡(luò)請(qǐng)求，json解析等等的庫(kù)和它的競(jìng)品都有多大，你心里有數(shù)嗎?

以工具庫(kù)為例，網(wǎng)上有很多工具庫(kù)，但是往往它們的大小很難控制。

  • xutils-3.2.6.aar – 843.8k
  • lite-common-1.1.3.jar – 148.1k
  • lesscode-core-0.8.2.aar – 64k
  • …

上面最后一個(gè)庫(kù)LessCode是我自己收集的工具類集合，非常?。篖essCode，混淆后只有不到50k大小。

不僅提高了開發(fā)效率，減少了冗余代碼，而且能避免引用一些其他大型的庫(kù)，有效避免包的增大。

比如，我們碰到過這樣的一個(gè)bug，快速點(diǎn)擊按鈕多次觸發(fā)跳轉(zhuǎn)，現(xiàn)在RxJava結(jié)合RxBind有這樣的一個(gè)場(chǎng)景解決方案，如果引入這些庫(kù)的話必然會(huì)增大apk大小，實(shí)際上就幾行代碼，我把這樣的解決方案集成到了LessCode，下次別的項(xiàng)目碰到這樣的問題不用再猶豫是否要引入一個(gè)這么大的庫(kù)了。

這些小的工具庫(kù)，建議根據(jù)自己的經(jīng)驗(yàn)人手總結(jié)一個(gè)，不求全，但求精!

這種情況下的apk的減小是不可估量的。

18. 插件化

尷尬的是，我們所呈現(xiàn)的功能大部分都是重要的不可分割的功能，很難從業(yè)務(wù)上分離出來。

今年預(yù)計(jì)要實(shí)踐一個(gè)輕量級(jí)的插件化方案，用別人的也好，自己寫也好，希望能解決或者優(yōu)化一些安裝包加載多模塊，或者主題切換，或者熱修復(fù)的問題。

這里作為候選方案?jìng)溆谩?/p>

這種情況下的apk的減小是不可估量的。

19. 功能業(yè)務(wù)取舍

一開始考慮瘦身，領(lǐng)導(dǎo)是允許適當(dāng)?shù)目车粢恍┕δ?，因?yàn)?M的目標(biāo)我們已經(jīng)實(shí)現(xiàn)了，所以現(xiàn)在還沒有到砍功能的地步。

這里作為候選方案?jìng)溆谩?/p>

這種情況下的apk的減小是不可估量的。

補(bǔ)充

文章發(fā)出后，收到了一些朋友的建議，補(bǔ)充幾點(diǎn)。

1. 去除無用的語言資源

感謝@牧志軒的建議，通過配置resConfigs可以選擇只打包哪幾種語言，進(jìn)而去掉各種aar包中全世界的語言，尤其是support包中的。

選擇保留什么語言要根據(jù)產(chǎn)品的用戶和市場(chǎng)來定，如果只選擇默認(rèn)英語和中文語言，配置如下

 
 
 
 
    
  
  
  
  
  1. android { 
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3.     defaultConfig { 
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5.         resConfigs "zh" 
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7.     } 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9. }  
    10.

看看效果：

如果不采用微信壓縮方案結(jié)果對(duì)比，apk減小了197k。

如果采用微信壓縮(開啟7zip)對(duì)比結(jié)果，apk只減小了16k，因?yàn)槲⑿艑?duì)resources.arsc進(jìn)行了強(qiáng)力壓縮，厲害!

apk減小了16k。

2. 刪除x86包的so

再次感謝@楊輝__的建議，x86的包刪除了之后，測(cè)試反應(yīng)好像有些機(jī)器容易崩潰，未能經(jīng)過嚴(yán)格測(cè)試，所以主版本又復(fù)原了，只在個(gè)別渠道執(zhí)行這條措施。

一般情況下不會(huì)有問題，測(cè)試了一下效果，apk減小了78k。

這里作為候選方案?jìng)溆谩?/p>

小結(jié)

最終，我們成功的把a(bǔ)pk壓到了2.9M，如果把上面遺漏的步驟繼續(xù)再做，應(yīng)該還能再減小一點(diǎn)。

客戶反應(yīng)壓的好小，領(lǐng)導(dǎo)簡(jiǎn)直不敢相信～

瘦身不難，難的是魔鬼瘦身!


網(wǎng)頁標(biāo)題：AndroidAPK瘦身實(shí)踐
本文網(wǎng)址：http://www.5511xx.com/article/dpojopc.html