優化Android工程中的圖片資源

場景

在一些上古工程中，因爲年久失修，架構演進跟不上業務發展須要，會衍生出很是多比較明顯的性能問題，其中就包括工程中圖片資源的問題。

最明顯的例子就是，工程中的圖片資源未經任何壓縮，直接使用來自設計稿中的原圖，很是佔用安裝包體積；其次，顯示效果不理想，在對應分辨率的圖片資源文件夾中放入了錯誤尺寸的圖片，致使應用運行時 UI 圖片出現模糊、大顆粒等狀況。

優化方案

壓縮圖片資源文件夾的大小

優化工做每每要從業務入手，在業務發展方向明確的前提下，並非全部的 UI 效果都須要用圖片文件的方式進行顯示，對於一些簡單的 UI，能夠考慮使用代碼進行繪製。使用代碼繪製能夠極其明顯的減小圖片對硬件資源的佔用，一來能夠減少包體積，二來一般能夠減少運行時的內存。

對於一些必須須要經過圖片文件來實現的 UI 效果，也須要對圖片文件進行相應的壓縮後再放入對應分辨率的文件夾，能夠考慮無損壓縮和有損壓縮。

這裏重點提下有損壓縮，並非全部的有損壓縮都會直接影響 UI 呈現的，若是事先獲知應用所運行的設備屏幕硬件自己色彩還原度不好，尺寸較小，分辨率也較低，那麼有損壓縮每每是更具性價比的選擇。

注意這裏的壓縮不僅僅指圖片質量的壓縮，同時也包括圖片尺寸的縮放。對於一些特定設備屏幕尺寸，咱們能夠限定一個最大的圖片尺寸做爲約束。

檢查對應分辨率資源文件夾下的圖片

種種緣由下，代碼工程中每每會存在對於分辨率資源文件夾下放錯圖片資源的狀況。

好比，在 drawable-xxhdpi 下放入了本應該放在 drawable-mdpi 的圖片資源，那麼最終的 UI 呈現就可能會出現模糊、大顆粒、鋸齒感等狀況。

好比下圖，在一個 xhdpi 的設備中，實際加載了 mdpi 的圖片資源，致使出現 UI 模糊狀況。

定義一個 48dp×48dp 的控件，實際控件大小爲 96px×96px

<ImageView    android:id="@+id/iv"    android:src="@mipmap/ic_launcher"    app:layout_constraintBottom_toBottomOf="parent"    app:layout_constraintTop_toTopOf="parent"    app:layout_constraintRight_toRightOf="parent"    app:layout_constraintLeft_toLeftOf="parent"    android:layout_width="48dp"    android:layout_height="48dp"/>
複製代碼

若是放錯了圖片資源，則實際加載了 48px×48px 大小的圖片。

將應用進行截圖，放大後能夠很明顯看到模糊狀況。

提供兩種方案供參考。

第一種是運行時檢查，結合 BitmapCanary 工具，判斷應用運行時 UI 控件是否加載了對應尺寸的圖片，若是加載的圖片資源尺寸小於控件自身的尺寸，那麼就須要特別關注，並返回代碼工程中進行修改。

第二種是開發時檢查，經過腳本工具遍歷工程圖片資源文件夾中的圖片文件，逐一檢查圖片尺寸，結合咱們以前定義過的圖片最大尺寸約束，能夠剔除並發現放錯的圖片資源，再針對篩選出的這些特定的圖片資源做壓縮和縮放。

優化工具

爲了讓優化工具更加通用，我編寫了 ImageRes361Tool 工具，它的工做流程和架構圖以下。

架構圖

• ImageRes361Tool 層：應用層，負責一鍵執行
• ImageFinder 層：負責查找工程中不合規的圖片資源
• ImageSaver 層：保存圖片
• Config 層：配置壓縮等級、策略以及目標文件夾
• ImageCompressTool 層：包裝圖片壓縮功能，簡化壓縮 API
• PIL、OpenCV 層：負責壓縮、處理圖片
• Logger 層：記錄日誌
• Thread 層：多線程操做，提高執行效率

工做流程

使用流程

python 環境

python3 環境要求

輸入工程地址

回車運行

最終效果

以工程中其中一個 module 爲例，清理掉超出圖片最大尺寸約束的圖片後，圖片資源大小能夠由 4.4Mb 銳減至 88Kb ；檢查並修改對應分辨率的圖片資源後，應用運行時再也不出現 UI 模糊的狀況。

後記

優化類工做每每解決的不單單是技術問題，更是管理問題。

制定了開發標準可否順利執行？架構演進可否跟上業務的不斷髮展？爲了性能指標可否排除萬難團結協做？......

管理類問題只能交由管理解決，毫不是某個技術工具就能解決得了的。

看着那些來自大廠的頭部 APP，白屏、卡頓、高內存佔用等都很是常見，再加上給用戶定製的「私人專屬」開屏廣告，使得啓動速度異常地慢。從用戶體驗的角度來講，不可謂優秀。是它們的技術力不夠嗎？

應該不是。