Preface
Once you enter Android, you are as deep as the sea. I believe many Android developers have a deep understanding of the fragmentation of Android system versions, the diversity of Android hardware devices, and the uncertainties of third-party Rom. It is really not easy to develop a qualified commercial app now. Not to mention anything else, application compatibility is a double test of technology and patience. It is impossible to perfectly adapt to various situations. It is often a balance between manpower and adaptation rate. The drawable we are going to talk about today is an important role that needs to be adapted.
Configuration qualifiers
Different screen density, different device directions, different languages and regions will involve alternative drawable resources. At runtime, Android will detect the current device configuration and load appropriate resources for the application according to specific rules (mentioned later). The following are configuration qualifiers that can be used. It should be noted that these configuration qualifiers are not only valid for drawable, but also for other resource types (such as layout, etc.):
Mobile Country Code (MCC): mcc310, mcc310-mnc004, mcc208-mnc00
Languages and regions: en, fr, en-rUS, etc.
Layout direction: ldrtl (from right to left) ldltr (from left to right)
smallestWidth: sw<N>dp Such as: sw320dp, sw600dp, sw720dp, etc. The minimum size of the screen can be of height and width, and the "minimum possible size" of the screen.
Available width: w<N>dp For example: w720dp, w1024dp, etc. Specify the minimum available screen width that the resource should use, in units of dp, defined by the <N> value. When switching between landscape and portrait, this configuration value will also change accordingly in order to match the current actual width.
Available height: h<N>dp Such as: h720dp, h1024dp, etc., specify the minimum available screen height that the resource should use, in units of dp, defined by the <N> value. When switching between landscape and portrait, this configuration value will also change accordingly in order to match the current actual height.
Screen size: small, normal, large, xlarge
Screen aspect ratio: long widescreen, such as WQVGA, WVGA, FWVGA; notlong non-widescreen, such as QVGA, HVGA and VGA
Screen direction: the port device is in the vertical direction (vertical), the land device is in the horizontal direction (horizontal)
UI mode: car, desk, television, appliance, watch
Night mode: night, nontight daytime
Screen pixel density: ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi, nodpi, tvdpi
Touch screen type: notouch, finger
Keyboard availability: keysexposed, keyshidden, keyssoft
Main text input methods: nokeys, qwerty, 12key
Navigation key availability: navexposed navigation key is available for users, navhidden navigation key is not available
Main non-touch navigation methods: nonav, dpad, trackball, wheel
Platform version (API level): v3, v4, v7, etc., such as v1 corresponds to API level 1, v4 corresponds to API level 4
If you carefully study each configuration qualifier, you will realize that it is impossible to perfectly adapt to various situations. In fact, what we usually use most is the screen pixel density. Here it is necessary to talk about this parameter in detail:
ldpi: low-density screen; approximately 120dpi.
mdpi: Medium density (traditional HVGA) screen; approximately 160dpi.
hdpi: high-density screen; approximately 240dpi.
xhdpi: Ultra-high density screen; approximately 320dpi. New configuration in API level 8
xxhdpi: Ultra-high density screen; approximately 480dpi. New configuration in API level 16
xxxhdpi: Ultra-Ultra-HD screen usage (only for launcher icon, see the notes in "Support multiple screens"); approximately 640dpi. New configuration in API level 18
nodpi: It can be used for bitmap resources that you do not want to scale to match device density.
tvdpi: A screen with a density between mdpi and hdpi; about 213dpi. It is not a "main" density group, mainly used in TVs, and most applications do not require it. For most applications, providing mdpi and hdpi resources is sufficient and the system will scale them as needed. This qualifier is introduced in API level 13.
The scaling ratio between the six main densities is 3:4:6:8:12:16 (ignoring the tvdpi density). Therefore, the 9x9 (ldpi) bitmap is equivalent to the 12x12 (mdpi), 18x18 (hdpi), 24x24 (xhdpi) bitmap, and so on.
Qualifier naming rules
Multiple qualifiers can be specified for a single group of resources and separated by dash. For example, drawable-en-rUS-land is suitable for horizontally-rowed American English devices.
These qualifiers must follow the order listed above, so the list above is in order. For example: Error: drawable-hdpi-port/, correct: drawable-port-hdpi/
The alternate resource directory cannot be nested. For example, you cannot have res/drawable/drawable-en/.
Values are case-insensitive. Before processing, the resource compiler converts directory names to lowercase to avoid problems with case-insensitive file systems. Any capital letters used in the name are for ease of reading.
For each qualifier type, only one value is supported. For example, if you want to use the same drawable file for Spanish and French, you certainly cannot have a directory named drawable-rES-rFR/, but instead require two resource directories that contain the corresponding files.
Android matches the best drawable rules
If you only use one configuration qualifier, it is easy to match. Find the drawable that matches the configuration. However, when you use multiple configuration qualifiers at the same time and there are multiple drawable directories at the same time, matching the best drawable is not that simple. Here is an official example of Android Developer. For example: Now your application contains the following directories:
drawable/ drawable-en/ drawable-fr-rCA/ drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/
At the same time, assuming that the configuration of the target device is as follows:
Regional settings = en-GB Screen Orientation = port Screen pixel density = hdpi Touch screen type = notouch Main text input method = 12key
The specific matching process is as follows:
1. Eliminate resource files that conflict with device configuration: where the drawable-fr-rCA/ directory conflicts with the en-GB region settings, and is eliminated (with an exception, screen pixel density is the only qualifier that has not been eliminated due to conflict. Although the screen density of the device is hdpi, drawable-port-ldpi/ is not eliminated because each screen density is considered a match at this time)
2. Select the qualifier with the highest priority in the above qualifier list, start with MCC, and then move down to see if there is a resource directory that includes this qualifier. If not, look at the next qualifier. In this example, unless the language qualifier is reached, the answer is always "No".
3. If so, the resource directory without this qualifier will be eliminated. In this example, all directories that do not contain language qualifiers are eliminated. So to this point, there are still drawables that meet the requirements:
drawable-en/
drawable-en-port/
drawable-en-notouch-12key/
4. Select the next priority qualifier and repeat steps 2, 3, 4. Until there is only one directory left, in this example, it should be port, so after elimination, only:
drawable-en-port/
There are two points to be explained:
1. Screen pixel density is the only qualifier that has not been eliminated due to conflict. If the qualifier involved is screen pixel density, Android will select the option closest to the device's screen density. Usually Android tends to shrink large original images rather than enlarge the original images.
2. What if there is no drawable that meets the qualifier? What else can I do? Let’s collapse!
The difference and connection between drawable and mipmap
Now create a project through Android Studio, by default, a series of mipmap folders are created instead of the previous drawable folders. So what is the relationship between mipmap and drawable? Has mipmap replaced drawable? Let’s take a look at the official instructions:
drawable/
For bitmap files (PNG, JPEG, or GIF), 9-Patch image files, and XML files that describe Drawable shapes or Drawable objects that contain multiple states (normal, pressed, or focused). See the Drawable resource type.
mipmap/
For app launcher icons. The Android system retains the resources in this folder (and density-specific folders such as mipmap-xxxhdpi) regardless of the screen resolution of the device where your app is installed. This behavior allows launcher apps to pick the best resolution icon for your app to display on the home screen. For more information about using the mipmap folders, see Managing Launcher Icons as mipmap Resources.
Let’s talk about the conclusion first:In the mipmap folder, it is only recommended to place the startup icon (app launcher icon), that is, the icon that will be displayed on the desktop after the application is installed, while other image resources, etc. are still placed in the drawable folder in the previous way.
So why put Launcher Icon in the mipmap folder? The following is the official explanation:
Different home screen launcher apps on different devices show app launcher icons at various resolutions. When app resource optimization techniques remove resources for unused screen densities, launcher icons can wind up looking fuzzy because the launcher app has to upscale a lower-resolution icon for display. To avoid these display issues, apps should use the mipmap/ resource folders for launcher icons. The Android system preserves these resources regardless of density stripping, and ensures that launcher apps can pick icons with the best resolution for display.
Make sure launcher apps show a high-resolution icon for your app by moving all densities of your launcher icons to density-specific res/mipmap/ folders (for example res/mipmap-mdpi/ and res/mipmap-xxxhdpi/). The mipmap/ folders replace the drawable/ folders for launcher icons. For xxhpdi launcher icons, be sure to add the higher resolution xxxhdpi versions of the icons to enhance the visual experience of the icons on higher resolution devices.
Here is my understanding:The size of the Launcher Icons used by many different Launcher Apps is inconsistent. When the application is installed, Android resource optimization will delete unnecessary resolution resources in the drawable folder. For example, the resources under drawable-xxhdpi are deleted on the xhdpi device. Of course, the Launcher Icons inside will also be deleted. At this time, if the size of the Launcher Icons used by Launcher App is too large and the Icons under high-resolution xxhdpi is deleted, you can only enlarge and display the small size Icons under xhdpi, which will cause the display of the Launcher Icons to be blurred. In order to avoid the above problems, mipmap was introduced. Android will ensure that the resources under mipmap will not be deleted due to resource optimization, ensuring that large-sized Launcher Icons can find more suitable resolution icons. Therefore, mipmap is created for Launcher Icon, while other image resources are placed in the drawable folder, which helps Android resources optimize and delete useless resources and reduce application volume.
Summarize
The above is all about some rules that must be known about drawable in Android. The content of the article is very practical for Android developers, and I hope it will be helpful to you.