In old project code, some images were use in the 'drawable' folder, and other in the 'mipmap' folder. Occasionally, I had doubts and searched for articles. But I an not understand enough. Recently, I try to find it. so I checked the content of the article one by one and found that the actual results were far from the conclusion.
Several common conclusions
Case 1 drawable will remove other densities, mipmap will retain all (the final conclusion is related to this)
When a xhdpi density phone loads this apk, Google has an optimization that will remove the other density files in the drawable folder, Just leaving only a basic drawable and the drawable-xhdpi folder, But mipmap will retain this all.
The detection method is also relatively simple. Put the same type of image (with image text for tag) in the folders to different densities folder of drawable and mipmap, Then check this installation package and application size
Case1.1 Installation package and application size
| Installation package size | Application size | |
|---|---|---|
| drawable | 13.3 MB (14,016,841 bytes) | 14.04MB |
| mipmap | 13.3 MB (14,017,191 bytes) | 14.04MB |
Conclusion1.1
From this, although the size of two installation packages is slightly different, considering the size of image itself (each image is more than 1MB), it can be considered that there is no difference between the images placed in the drawable and mipmap folders after the installation of the application.
Case1.2 In-app performance
Excluding the installation package situation, let's take a look at the performance in the app (use adb shell wm density to ensure density without change other info).
| 100 | 420 | 800 | |
|---|---|---|---|
| drawable |  |
 |
 |
| mipmap |  |
 |
 |
Conclusion1.2
From this, it can be seen that no matter which folder the file is placed in, it will be correctly displayed as its matching image resource on the phone.
Case 1.3 In-app scaling
If an imageView have scaling animation, using the image under drawable, one image will be continuously used to scale the image to achieve imageView scaling animation.
If you use the image under mipmap, the image with the closest resolution to the current resolution and larger than the current resolution will be automatically selected for scaling according.
This conclusions may be not is an common conclusions, but since there is shuch a saying, let is test it.
drawable
| Small Scaling Ratio | Large Scaling Ratio |
|---|---|
 |
 |
mipmap
| Small Scaling Ratio | Large Scaling Ratio |
|---|---|
 |
 |
Conclusion 1.3
It can be seen that the same animation is displayed throughout the scaling animation process.
Case 2 Application Performance
Google has optimized the performance of mipmap images to make them perform better.
drawable
| Performance Overview | MEMORY | Average time for loading 10 images |
|---|---|---|
 |
 |
146 |
mipmap
| Performance Overview | MEMORY | Average time for loading 10 images |
|---|---|---|
 |
 |
151 |
Conclusion 2
It can be seen that in the case when system loading a single image, their performance is basically the same, except for the case where this image is too small or too few to optimize the performance obviously. However, even in the case of repeated loading of images, the performance is still similar. Perhaps the optimization is only for specific types of images? If you know more details, feel free to communicate with me.
Case3 Launcher icons
While researching, it was found that the minmap folder is often recommended to only include the launcher icon of the application, this way can make performance optimize better.
| 100dpi | 420dpi | 800dpi | |
|---|---|---|---|
 |
 |
|
Conclusion 3
It can be seen the display of application icon is consistent across different dpi settings, and the boundary value for switching the application icon is also consistent. As for the situation why this display effect is same for 420dpi and 800dpi, because app icon need to be enlarged by about 25% when selecting image resources for various reasons. 1
At this point, you may have the same doubts as me. Since the performance of the images under drawable and mipmap is the same, whether it is in installation package or in application itself, and even the official documentation says so, why do various test results show that the performance of the two is basically consistent?
The Culprit: Bundle (.aab)
If you do not use Google Play to pushing you apk(like me), you will unfamiliar adbout this. and even many who have previously published app on Google Play are not very familiar with it. This actually appears every time we manually package an app.
Simply put, the .aab package is generally used for the Google Play store. When you download an app from the Google Play store, it will download resources from different drawables based on your phone's actual usage to reduce the size of the installation package. (In general, the phone's dpi does not change, and other resources densities will not be used until the app is uninstalled.)
The tool used in the following test is bundletool 2, which simulates the process of downloading and installing an app from Google Play.
Comparison of installation packages
| Installation Package (apks) Size | Application Size | |
|---|---|---|
| drawable | 5.91 MB (6,201,543 字节) | 6.22MB |
| mipmap | 12.6 MB (13,230,670 字节) | 13.26MB |
In-app performance
| 100 | 420 | |
|---|---|---|
| drawable |  |
 |
| mipmap |  |
 |
It can be seen that when the image is used on the drawable folder, the application installed through the .aab package will be smaller than the one used under minmap folder, and when changing the DPI in the application, it not can longer automatically select the corresponding image according to the current DPI.
Conclusion
Based on the above tests, we can get the following conclusions.
The following conclusions do not involve performance optimization related to mipmap (mainly because we have not yet designed a clear comparison test)
The test phone model is Pixel 7, and the tested Android version is 13
- When the application is built as an .apk, there is no difference between drawable or mipmap folders, whether it is in the application or in the launcher (application icon).
- When the application is built as an .aab, the resources in the drawable folder will look for matching device density to keep, and unmatched resources will be deleted to ensure the size of the .apk. However, all resources files in the mipmap folder will be kept.
Can we place the images used in the application in any directory?
If your application is distributed and installed through .apk, there is no difference in principle. However, Google also has recommended instructions for the related directories, as shown below:
As we can see, mipmap directory can only save application icons in principle. Similarly, their official projects and single density resource projects also use these two folders in this way.
Is the retention mechanism of the mipmap folder in the .aab package only applicable to application icons?
After testing, it can be found that the retention mechanism of mipmap is applicable to all image resources under mipmap, whether they are application icons or not.
Related code can be accessed on my GitHub.
Top comments (0)