歡迎通過我的個人博客來查看此文章
老專案代碼中發現有的圖片放到了
drawable中, 有的圖片放到了mipmap中, 開發時秉承哪個目錄下檔案多放哪里的原則, 偶爾有疑惑搜一搜文章, 看到了結論也就這么使用了, 不過今日有時間, 依次檢驗了一下文章中的內容, 發現和實際的表現出入甚遠.
常見的幾種結論
Case 1 drawable會剔除其它密度, mipmap會保留全部(實際上最終的結論和這個有關聯)
當xhdpi密度的手機在加載apk的時候Google是有一個優化的，是會剔除drawable其他密度的檔案，只保留一個基本的drawable和drawable-xhdpi的檔案，而mipmap是會全部保留的，
檢測方法也比較簡單, 在drawable和mipmap不同密度的問價夾下分別放入同一類圖片(圖片標文字用于檢查), 分別打包并檢查其大小
Case1.1 安裝包與應用大小
| 安裝包大小 | 應用大小 | |
|---|---|---|
| drawable | 13.3 MB (14,016,841 位元組) | 14.04MB |
| mipmap | 13.3 MB (14,017,191 位元組) | 14.04MB |
結論1.1
由此可見, 雖然兩個安裝包大小略有差異, 考慮到圖片本身的大小(每張圖片都在1Mb作用), 可以認為放入drawable和mipmap檔案夾中的圖片在安裝包和應用安裝后沒有差異
Case1.2 應用內表現
排除安裝包的情況, 我們看一下在應用內的表現情況(通過adb shell wm density保證只修改手機的dpi資訊)
| 100 | 420 | 800 | |
|---|---|---|---|
| drawable |  |
 |
 |
| mipmap |  |
 |
 |
結論1.2
由此可見, 檔案不論放在哪個目錄下, 在手機中都會正確的顯示為其匹配的圖片資源
Case 1.3 應用內縮放
如果一個 imageView 有縮放影片，使用 drawable 下的圖片，會一直使用一張來縮放圖片實作 imageView 縮放影片，
如果使用 mipmap 下的圖片，會根據縮放程度自動選擇比當前解析度大而又最接近當前解析度的圖片來做縮放處理，
這個可能大家見得不是很多, 不過既然有這種說法, 那就來測驗一下
drawable
| 小縮放比例 | 大縮放比例 |
|---|---|
 |
 |
mipmap
| 小縮放比例 | 大縮放比例 |
|---|---|
 |
 |
結論1.3
可以看到在縮放影片的程序中, 一直顯示的都是同一個影片
Case 2 應用內性能
Google對mipmap的圖片進行了性能優化, 使其可以表現的更好
drawable
| 性能檢查一覽 | MEMORY | 10次圖片加載平均時間 |
|---|---|---|
 |
 |
146 |
mipmap
| 性能檢查一覽 | MEMORY | 10次圖片加載平均時間 |
|---|---|---|
 |
 |
151 |
結論2
可以看到, 加載單張圖片的情況下其性能基本一致,不排除圖片太小/太少性能優化不明顯的情況, 不過嘗試單證圖片重復加載的情況下依舊表現為性能相近的情況, 或許時只針對特殊型別有優化? 如各位知道的更詳細, 歡迎和我進行交流.
Case3 啟動圖示
在查閱資料的時候, 發現多次提及minmap應用只放入應用的啟動圖示, 使其可以得到優化.
| 100dpi | 420dpi | 800dpi | |
|---|---|---|---|
 |
 |
|
結論3
可以看到, 不同dpi的情況下應用圖示的顯示情況都是一致的. 其應用圖示切換的邊界值也是一致的.
關于420dpi和800dpi顯示效果一樣的情況, 因為種種原因, 應用圖片在選擇圖片資源的時候, 需要將密度擴大25%左右[1].
看到這里大家應該和我有著一樣的疑惑, 既然drawable和mipmap下圖片的表現不論是安裝包還是應用內, 甚至連官方檔案都這么說了, 為什么各種測驗結果下來, 兩者的表現基本的一致呢?
罪魁禍首 Bundle(.aab)
提到Bundle(.aab)國內的開發者可能都比較陌生, 甚至不少之前做過Google Play上架應用的都不是很熟悉. 這個其實在我們每次手動打包的時候都會出現.
簡單來說.aab包一般用于Google Play商店使用, 在你從Google Play商店下載應用時, 它會根據你手機的實際使用情況來下載不同drawable中的資源. 以期望達到減少安裝包大小的目的. (一般情況下手機dpi不會改變, 其它密度下的資源檔案直到應用卸載時都不會被使用).
下面的測驗使用到的工具為bundletool[2], 簡單來說, 就是模擬從Google Play下載應用和安裝應用的程序.
安裝包比較
| 安裝包(apks)大小 | 應用大小 | |
|---|---|---|
| drawable | 5.91 MB (6,201,543 位元組) | 6.22MB |
| mipmap | 12.6 MB (13,230,670 位元組) | 13.26MB |
應用內表現
| 100 | 420 | |
|---|---|---|
| drawable |  |
 |
| mipmap |  |
 |
可以看到, 當圖片放到drawable相關檔案夾下的時候, 通過.aab包安裝的應用會比放到minmap的下的應用小許多, 并且應用內更改dpi的時候頁可以看到其不再能自動根據當前dpi選擇對應的圖片了. |
結論
那么通過以上的測驗, 我們可以得到以下結論了
以下結論均不涉及mipmap的性能優化相關(主要是暫未能設計好一個比較明確的測驗對比)
以下測驗機型為pixel 7, 測驗Android版本為13
- 當應用構建為.apk的情況下,
drawable和mipmap檔案夾下的資源表現無差異, 不論是應用內表現還是在啟動器(應用圖示)中表現. - 當應用構建為.aab的情況下,
drawable檔案夾下的資源會尋找匹配的設備密度保留, 不匹配的資源會被洗掉已保證apk的大小.而mipmap檔案夾下的資源檔案會全部被保留.
那么我們應用內使用的圖片就可以放到任意的目錄下么?
如果你的應用是通過.apk分發安裝的, 原則上是沒有區別的. 但是Google對相關的目錄也有推薦說明:
可以看到, mipmap目錄下原則上只能保存應用圖示. 同樣, 其官方專案及單密度資源專案也都是這樣使用設計這兩個檔案夾的.
.aab包內mipmap保留機制是否是只適用于應用圖示
測驗后可以發現, mipmap的保留機制適用于mipmap下所有的圖片資源, 不論是否為應用圖示
相關代碼可以訪問我的GitHub
https://developer.android.com/training/multiscreen/screendensities#mipmap ??
https://github.com/google/bundletool/ ??
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/545082.html
標籤：Android