Android APP 終極瘦身指南
之前寫了一篇《APK瘦身實踐》側重於實踐和效果對比,後來受徐川老師點撥,建議改寫成一篇更全面的瘦身終極殺招大全,深以為然,思考良久,新開一篇。
指南條例
第1條:使用一套資源
這是最基本的一條規則,但非常重要。
對於絕大對數APP來說,只需要取一套設計圖就足夠了。鑑於現在解析度的趨勢,建議取720p的資源,放到xhdpi目錄。
相對於多套資源,只使用720P的一套資源,在視覺上差別不大,很多大公司的產品也是如此,但卻能顯著的減少資源佔用大小,順便也能減輕設計師的出圖工作量了。
注意,這裡不是說把不是xhdpi的目錄都刪除,而是強調保留一套設計資源就夠了。
第2條:開啟minifyEnabled混淆程式碼
在gradle使用minifyEnabled進行Proguard混淆的配置,可大大減小APP大小:
android { buildTypes { release { minifyEnabled true } } }
在proguard中,是否保留符號表對APP的大小是有顯著的影響的,可酌情不保留,但是建議儘量保留用於除錯。詳細proguard的相關的配置和原理可自行查閱。
第3條:開啟shrinkResources去除無用資源
在gradle使用shrinkResources去除無用資源,效果非常好。
android { buildTypes { release { shrinkResources true } } }
第4條:刪除無用的語言資源
大部分應用其實並不需要支援幾十種語言的國際化支援。還好強大的gradle支援語言的配置,比如國內應用只支援中文:
android { defaultConfig { resConfigs "zh" } }
第5條:使用tinypng有失真壓縮
android打包本身會對png進行無失真壓縮,所以使用像tinypng這樣的有失真壓縮是有必要的。
重點是Tinypng使用智慧有失真壓縮技術,以儘量少的失真換來圖片大小的銳減,效果非常好,強烈推薦。
Tinypng的官方網站: http://tinypng.com/
第6條:使用jpg格式
如果對於非透明的大圖,jpg將會比png的大小有顯著的優勢,雖然不是絕對的,但是通常會減小到一半都不止。在啟動頁,活動頁等之類的大圖展示區採用jpg將是非常明智的選擇。
第7條:使用webp格式
webp支援透明度,壓縮比比jpg更高但顯示效果卻不輸於jpg,官方評測quality引數等於75均衡最佳。
相對於jpg、png,webp作為一種新的圖片格式,限於android的支援情況暫時還沒用在手機端廣泛應用起來。從Android 4.0+開始原生支援,但是不支援包含透明度,直到Android 4.2.1+才支援顯示含透明度的webp,使用的時候要特別注意。
官方介紹: https://developers.google.com/speed/webp/docs/precompiled
第8條:縮小大圖
如果經過上述步驟之後,你的工程裡面還有一些大圖,考慮是否有必要維持這樣的大尺寸,是否能適當的縮小。事實上,由於設計師出圖的原因,我們拿到的很多圖片完全可以適當的縮小而對視覺影響是極小的。
第9條:覆蓋第三庫裡的大圖
有些第三庫裡引用了一些大圖但是實際上並不會被我們用到,就可以考慮用1×1的透明圖片覆蓋。你可能會有點不舒服,因為你的drawable下竟然包含了一些莫名其妙的名稱的1×1圖片…
第10條:刪除armable-v7包下的so
基本上armable的so也是相容armable-v7的,armable-v7a的庫會對圖形渲染方面有很大的改進,如果沒有這方面的要求,可以精簡。這裡不排除有極少數裝置會Crash,可能和不同的so有一定的關係,請大家務必測試周全後再發布。
第11條:刪除x86包下的so
與第十條不同的是,x86包下的so在x86型號的手機是需要的,如果產品沒用這方面的要求也可以精簡。建議實際工作的配置是隻保留armable、armable-x86下的so檔案,算是一個折中的方案。
第12條:使用微信資源壓縮打包工具
微信資源壓縮打包工具通過短資源名稱,採用7zip對APP進行極致壓縮實現減小APP的目標,效果非常的好,強烈推薦。
詳情參考: Android資源混淆工具使用說明
原理介紹: 安裝包立減1M–微信Android資源混淆打包工具
建議開啟7zip,注意白名單的配置,否則會導致有些資源找不到,粗略配置如下,
<?xml version="1.0" encoding="UTF-8"?> <resproguard> <!--defaut property to set --> <issue id="property" > <seventzip value= "true" /> <!-- ... --> </issue> <issue id="whitelist" isactive="true"> <path value ="com.xxx.yyy.R.drawable.emoji_*" /> <path value ="com.xxx.yyy.... /> </issue> <issue id ="compress" isactive="true"> <!-- ... --> </issue> </resproguard>
第13條:使用provided編譯
對於一些庫是按照需要動態的載入,可能在某些版本並不需要,但是程式碼又不方便去除否則會編譯不過。
使用provided可以保證程式碼編譯通過,但是實際打包中並不引用此第三方庫,實現了控制APP大小的目標。
但是也同時就需要開發者自己判斷不引用這個第三方庫時就不要執行到相關的程式碼,避免APP崩潰。
第14條:使用shape背景
特別是在扁平化盛行的當下,很多純色的漸變的圓角的圖片都可以用shape實現,程式碼靈活可控,省去了大量的背景圖片。
第15條:使用著色方案
相信你的工程裡也有很多selector檔案,也有很多相似的圖片只是顏色不同,通過著色方案我們能大大減輕這樣的工作量,減少這樣的檔案。
藉助於android support庫可實現一個全版本相容的著色方案,參考程式碼: DrawableLess.java
第16條:線上化素材庫
如果你的APP支援素材庫(比如聊天表情庫)的話,考慮線上載入模式,因為往往素材庫都有不小的體積。這一步需要開發者實現線上載入,一方面增加程式碼的複雜度,一方面提高了APP的流量消耗,建議酌情選擇。
第17條:避免重複庫
避免重複庫看上去是理所當然的,但是祕密總是藏的很深,一定要當心你引用的第三方庫又引用了哪個第三方庫,這就很容易出現功能重複的庫了,比如使用了兩個圖片載入庫:Glide和Picasso。通過檢視exploded-aar目錄和External Libraries或者反編譯生成的APK,儘量避免重複庫的大小,減小APP大小。
第18條:使用更小的庫
同樣功能的庫在大小上是不同的,甚至會懸殊很大。如果並無對某個庫特別需求而又對APP大小有嚴格要求的話,比較這些相同功能第三方庫的大小,選擇更小的庫會減小APP大小。
第19條:支援外掛化
過去的一年,外掛化技術雨後春筍一樣的都冒了出來,這些技術支援動態的載入程式碼和動態的載入資源,把APP的一部分分離出來了,對於業務龐大的專案來說非常有用,極大的分解了APP大小。因為外掛化技術需要一定的技術保障和服務端系統支援,有一定的風險,如無必要(比如一些小型專案,也沒什麼擴充套件業務)就不需要了,建議酌情選擇。
第20條:精簡功能業務
這條完全取決於業務需求。從統計資料分析砍掉一些沒用的功能是完全有可能的,甚至乾脆去掉一些花哨的功能出個輕聊版、極速版也不是不可以的。
第21條:重複執行第1到20條
多次執行上述步驟,你總能發現一些蛛絲馬跡,這是一個好訊息,不是嗎?
線上評估
針對很多朋友的反饋,有必要對條例的適用範圍、易用性和風險指數做個粗略的評估,彙總如下,方便大家執行。
指南條例 | 適用範圍 | 易用性 | 風險指數 | 備註 |
---|---|---|---|---|
使用一套資源 | 非極高UI要求的APP | 易 | 無 | |
開啟minifyEnabled | 全部 | 易 | 無 | |
開啟shrinkResources | 全部 | 易 | 無 | |
刪除無用的語言資源 | 非全球國際化應用 | 易 | 無 | |
使用tinypng有失真壓縮 | 非極高UI要求的APP | 易 | 低 | |
使用jpg格式 | 僅限非透明大圖 | 易 | 中 | |
使用webp格式 | 僅限4.0+,4.2+裝置 | 中 | 中 | |
縮小大圖 | 限允許縮小的大圖 | 易 | 中 | |
覆蓋第三庫裡的無用大圖 | 全部 | 中 | 高 | |
刪除armable-v7包下的so | 限允許對極少數裝置不相容 | 易 | 中 | |
刪除x86包下的so | 限允許對x86裝置不相容 | 易 | 高 | |
使用微信資源壓縮打包工具 | 全部 | 中 | 中 | 切記要配置白名單 |
使使用provided編譯 | 全部 | 易 | 低 | 容錯處理 |
使用shape背景 | 全部 | 易 | 無 | |
使用著色方案 | 全部 | 易 | 低 | |
表情線上化 | 限含表情包的APP | 中 | 高 | |
避免重複庫 | 全部 | 中 | 中 | |
使用更小的庫 | 全部 | 中 | 高 | |
支援外掛化 | 限擴充套件性要求高的APP | 難 | 高 | |
精簡功能業務 | 限允許精簡的APP | 難 | 高 |
小結
相信經過上述步驟,一定可以把你的Android APP極大的瘦身下去。考慮到一定的風險性,建議挑選適合自己的方法就行;同時,我也會跟蹤最新的瘦身技巧,及時補充更新。
相關文章
- Angular CLI 終極指南Angular
- App極限瘦身: 動態下發soAPP
- nmap終極使用指南
- Java日誌終極指南Java
- A/B測試終極指南
- ChatGPT的終極指南概要ChatGPT
- Android App程式碼混淆終極解決方案AndroidAPP
- 建立和釋出 Android 開發庫的終極指南Android
- CSS居中對齊終極指南CSS
- UI設計終極配色指南UI
- FFmpeg - 終極指南 | IMG.LY
- Linux 日誌終極指南Linux
- App瘦身APP
- Bug Bounty平臺的終極指南
- [譯]移動API安全終極指南API
- Linux桌面環境終極指南Linux
- WordPress 遷移外掛終極指南
- 資料庫效能提升終極指南資料庫
- Android效能優化(十)之App瘦身攻略Android優化APP
- Python除錯終極指南 - martinheinzPython除錯
- Kubernetes部署之終極指南 - semaphoreci
- CUDA 矩陣乘法終極優化指南矩陣優化
- surface安裝linux終極拯救指南Linux
- 區塊鏈學習者終極指南區塊鏈
- Python語音識別終極指南Python
- 終極自託管解決方案指南
- Android Studio終極配置方案Android
- 創業起步?先收藏這份終極指南創業
- 更快學會任何東西的終極指南
- gradle構建springboot專案瘦身,外部依賴jar的終極方法GradleSpring BootJAR
- GitHub終極指南,教你如何在GitHub中“挖礦”Github
- 3xx HTTP狀態碼的終極指南HTTP
- 扁平化圖示的終極設計指南
- [譯] Go 終極指南:編寫一個 Go 工具Go
- iPhone螢幕解析度終極指南–資訊圖iPhone
- App瘦身最佳實踐APP
- Android應用瘦身Android
- 「Android」 APK瘦身探索AndroidAPK