Mipmap drawables for icons
Since Android 4.3 (Jelly Bean) we can now make use of the res/mipmap folders to store "mipmap" images.
For example, Chrome for Android stores its icons in these folders instead of the more normal res/drawable folders.
How are these mipmap images different from the other familiar drawable images?
I see that in my manifest, we use the @mipmap/ qualifier, instead of @drawable/ , which makes sense given the resource folder name:
<activity
android:name=".MipmapDemp"
android:icon="@mipmap/ic_launcher" />
References:
The Android 4.3 APIs document has the following to say:
Using a mipmap as the source for your bitmap or drawable is a simple way to provide a quality image and various image scales, which can be particularly useful if you expect your image to be scaled during an animation.
Android 4.2 (API level 17) added support for mipmaps in the Bitmap class—Android swaps the mip images in your Bitmap when you've supplied a mipmap source and have enabled setHasMipMap(). Now in Android 4.3, you can enable mipmaps for a BitmapDrawable object as well, by providing a mipmap asset and setting the android:mipMap attribute in a bitmap resource file or by calling hasMipMap().
I don't see anything in there that helps me to understand.
XML Bitmap resources have an android:mipMap property:
Boolean. Enables or disables the mipmap hint. See setHasMipMap() for more information. Default value is false.
This does not apply to launcher icons as far as I can see.
The question was raised on Google Groups (The purpose of resource name "mipmap"?!), to which Romain Guy replied:
It's useful to provide an image at a larger resolution that would normally be computed (for instance, on an mdpi device, Launcher might want the larger hdpi icon to display large app shortcuts.)
I feel like this almost makes sense of it, but not quite.
I'm still inclined to go with Randy Sugianto's follow up:
What are the advantages of this? Is there any guide how to use mipmaps, probably for better launcher icons?
Of course, Wikipedia has a page for "Mipmap", which refers to an older technique invented in 1983, that I can't quite relate to the current Android implementation.
Should we be storing all our app icons in res/mipmap folders these days, and what are the guidelines for these mipmap images?
Update #1
Here's a blog post that tries to explain it a bit.
But the image used in that blog post shows what looks like one file with many logos in it. This is not what I see in Chrome's mipmap folder.
Chrome's mipmap-hdpi folder contains three images. One is the Chrome logo, on its own.
Strangely, it is 72x72, not 48x48 which I would expect to see.
Perhaps that is all there is to this - we just need to keep bigger icons in the mipmap folders?
Update #2
The Android Developers Blog post of 23/10/2014 again confirms the idea of using the mipmap folders for application icons:
When talking about the Nexus 6 screen density, the author writes:
It's best practice to place your app icons in mipmap- folders (not the drawable- folders) because they are used at resolutions different from the device's current density. For example, an xxxhdpi app icon can be used on the launcher for an xxhdpi device.
Update #3
Note that Android Studio creates the ic_launcher.png icons in the mipmap... folders rather than the drawable... folders that Eclipse used to create them in.
There are two distinct uses of mipmaps:
For launcher icons when building density specific APKs. Some developers build separate APKs for every density, to keep the APK size down. However some launchers (shipped with some devices, or available on the Play Store) use larger icon sizes than the standard 48dp. Launchers use getDrawableForDensity and scale down if needed, rather than up, so the icons are high quality. For example on an hdpi tablet the launcher might load the xhdpi icon. By placing your launcher icon in the mipmap-xhdpi directory, it will not be stripped the way a drawable-xhdpi directory is when building an APK for hdpi devices. If you're building a single APK for all devices, then this doesn't really matter as the launcher can access the drawable resources for the desired density.
The actual mipmap API from 4.3. I haven't used this and am not familiar with it. It's not used by the Android Open Source Project launchers and I'm not aware of any other launcher using.
It seems Google have updated their docs since all these answers, so hopefully this will help someone else in future :) Just came across this question myself, while creating a new (new new) project.
TL;DR: drawables may be stripped out as part of dp-specific resource optimisation. Mipmaps will not be stripped.
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.
(from http://developer.android.com/tools/projects/index.html#mipmap)
The Android implementation of mipmaps in 4.3 is exactly the technique from 1983 explained in the Wikipedia article :)
Each bitmap image of the mipmap set is a downsized duplicate of the main texture, but at a certain reduced level of detail. Although the main texture would still be used when the view is sufficient to render it in full detail, the renderer will switch to a suitable mipmap image (...) when the texture is viewed from a distance or at a small size.
Although this is described as a technique for 3D graphics (as it mentions "viewing from a distance"), it applies just as well to 2D (translated as "drawn is a smaller space", ie "downscaled").
For a concrete Android example, imagine you have a View with a certain background drawable (in particular, a BitmapDrawable ). You now use an animation to scale it to 0.15 of its original size. Normally, this would require downscaling the background bitmap for each frame. This "extreme" downscaling, however, may produce visual artifacts.
You can, however, provide a mipmap, which means that the image is already pre-rendered for a few specific scales (let's say 1.0, 0.5, and 0.25). Whenever the animation "crosses" the 0.5 threshold, instead of continuing to downscale the original, 1.0-sized image, it will switch to the 0.5 image and downscale it, which should provide a better result. And so forth as the animation continues.
This is a bit theoretical, since it's actually done by the renderer. According to the source of the Bitmap class, it's just a hint, and the renderer may or may not honor it.
/**
* Set a hint for the renderer responsible for drawing this bitmap
* indicating that it should attempt to use mipmaps when this bitmap
* is drawn scaled down.
*
* If you know that you are going to draw this bitmap at less than
* 50% of its original size, you may be able to obtain a higher
* quality by turning this property on.
*
* Note that if the renderer respects this hint it might have to
* allocate extra memory to hold the mipmap levels for this bitmap.
*
* This property is only a suggestion that can be ignored by the
* renderer. It is not guaranteed to have any effect.
*
* @param hasMipMap indicates whether the renderer should attempt
* to use mipmaps
*
* @see #hasMipMap()
*/
public final void setHasMipMap(boolean hasMipMap) {
nativeSetHasMipMap(mNativeBitmap, hasMipMap);
}
I'm not quite sure why this would be especially suitable for application icons, though. Although Android on tablets, as well as some launchers (eg GEL), request an icon "one density higher" to show it bigger, this is supposed to be done using the regular mechanism (ie drawable-xxxhdpi , &c).
上一篇: 相同的应用程序在不同的Android设备上使用不同的内存量
下一篇: Mipmap可绘制的图标