本文翻译自：Mipmap drawables for icons
Since Android 4.3 (Jelly Bean) we can now make use of the res/mipmap folders to store "mipmap" images. 从Android 4.3（Jelly Bean）开始，我们现在可以使用res/mipmap文件夹来存储“mipmap”图像。
For example, Chrome for Android stores its icons in these folders instead of the more normal res/drawable folders. 例如， Chrome for Android将其图标存储在这些文件夹中，而不是更常规的res/drawable文件夹中。
How are these mipmap images different from the other familiar drawable images? 这些mipmap图像与其他熟悉的可绘制图像有何不同？
I see that in my manifest, we use the @mipmap/ qualifier, instead of @drawable/ , which makes sense given the resource folder name: 我看到在我的清单中，我们使用@mipmap/限定符，而不是@drawable/ ，这对于资源文件夹名称是有意义的：
<activity
android:name=".MipmapDemp"
android:icon="@mipmap/ic_launcher" />
References: 参考文献：
The Android 4.3 APIs document has the following to say: Android 4.3 API文档包含以下内容：
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. 使用mipmap作为位图或drawable的源是提供高质量图像和各种图像比例的简单方法，如果您希望在动画期间缩放图像，这可能特别有用。
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(). Android 4.2（API级别17）在Bitmap类中添加了对mipmap的支持 - 当您提供了mipmap源并启用了setHasMipMap（）时，Android会在您的Bitmap中交换mip图像。 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(). 现在在Android 4.3中，您还可以通过提供mipmap资源并在位图资源文件中设置android：mipMap属性或通过调用hasMipMap（）来为BitmapDrawable对象启用mipmaps。
I don't see anything in there that helps me to understand. 我没有看到任何有助于我理解的东西。
XML Bitmap resources have an android:mipMap property: XML Bitmap资源有一个android:mipMap属性：
Boolean. 布尔。 Enables or disables the mipmap hint. 启用或禁用mipmap提示。 See setHasMipMap() for more information. 有关更多信息，请参见setHasMipMap（）。 Default value is false. 默认值为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: 问题出现在Google网上论坛（ 资源名称“mipmap”的目的？！ ）上，Romain Guy回复道：
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.) 提供通常可以计算的更大分辨率的图像很有用（例如，在mdpi设备上，Launcher可能希望更大的hdpi图标显示大型应用程序快捷方式。）
I feel like this almost makes sense of it, but not quite. 我觉得这几乎是有意义的，但并不完全。
I'm still inclined to go with Randy Sugianto's follow up: 我仍然倾向于选择Randy Sugianto的跟进：
What are the advantages of this? 这有什么好处？ Is there any guide how to use mipmaps, probably for better launcher icons? 是否有任何指南如何使用mipmap，可能是为了更好的启动器图标？
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. 当然， 维基百科有一个“Mipmap”页面 ，它指的是一种1983年发明的旧技术，我无法与当前的Android实现相关联。
Should we be storing all our app icons in res/mipmap folders these days, and what are the guidelines for these mipmap images? 我们现在应该将所有应用程序图标存储在res/mipmap文件夹中吗？这些mipmap图像的准则是什么？
Update #1 更新＃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的mipmap文件夹中看到的。
Chrome's mipmap-hdpi folder contains three images. Chrome的mipmap-hdpi文件夹包含三张图片。 One is the Chrome logo, on its own. 一个是Chrome徽标，单独使用。
Strangely, it is 72x72, not 48x48 which I would expect to see. 奇怪的是，它是72x72，而不是48x48，我希望看到。
Perhaps that is all there is to this - we just need to keep bigger icons in the mipmap folders? 也许这就是全部 - 我们只需要在mipmap文件夹中保留更大的图标？
Update #2 更新＃2
The Android Developers Blog post of 23/10/2014 again confirms the idea of using the mipmap folders for application icons: 2014年10月23日的Android开发者博客文章再次证实了将mipmap文件夹用于应用程序图标的想法：
When talking about the Nexus 6 screen density, the author writes: 在谈到Nexus 6屏幕密度时，作者写道：
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. 最好将应用程序图标放在mipmap文件夹（而不是drawable文件夹）中，因为它们的分辨率与设备的当前密度不同。 For example, an xxxhdpi app icon can be used on the launcher for an xxhdpi device. 例如，可以在启动器上为xxhdpi设备使用xxxhdpi应用程序图标。
Update #3 更新＃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. 请注意，Android Studio会在mipmap...文件夹中创建ic_launcher.png图标，而不是Eclipse用于创建它们的drawable...文件夹。
#1楼
参考：https://stackoom.com/question/1cQnS/Mipmap-drawables图标
#2楼
There are two distinct uses of mipmaps: mipmap有两种不同的用途：
For launcher icons when building density specific APKs. 用于构建密度特定APK时的启动器图标。 Some developers build separate APKs for every density, to keep the APK size down. 一些开发人员为每个密度构建单独的APK，以保持APK大小。 However some launchers (shipped with some devices, or available on the Play Store) use larger icon sizes than the standard 48dp. 但是，某些发射器（随某些设备一起提供，或在Play商店中提供）使用比标准48dp更大的图标尺寸。 Launchers use getDrawableForDensity and scale down if needed, rather than up, so the icons are high quality. 启动器使用getDrawableForDensity并在需要时缩小，而不是向上缩小，因此图标质量很高。 For example on an hdpi tablet the launcher might load the xhdpi icon. 例如，在hdpi平板电脑上，启动器可能会加载xhdpi图标。 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. 通过将启动器图标放在mipmap-xhdpi目录中，在为hdpi设备构建APK时，它不会像drawable-xhdpi目录那样被剥离。 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. 如果您正在为所有设备构建单个APK，那么这并不重要，因为启动程序可以访问可绘制资源以获得所需的密度。
The actual mipmap API from 4.3. 4.3的实际mipmap API。 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. 它没有被Android开源项目启动器使用，我也不知道有任何其他启动器使用。
#3楼
The understanding I have about mipmap is more or less like this: 我对mipmap的理解或多或少是这样的：
When an image needs to be drawn, given we have different screen sizes are resolutions, some scaling will have to take part. 当需要绘制图像时，假设我们有不同的屏幕尺寸是分辨率，则必须进行一些缩放。
If you have an image that is ok for a low end cell phone, when you scale it to the size of a 10" tablet you have to "invent" pixels that don't actually exist. This is done with some interpolation algorithm. The more amount of pixels that have to be invented, the longer the process takes and quality starts to fail. Best quality is obtained with more complex algorithms that take longer (average of surrounding pixles vs copy the nearest pixel for example). 如果您的图像适用于低端手机，当您将其缩放到10英寸平板电脑的大小时，您必须“发明”实际上不存在的像素。这是通过一些插值算法完成的。必须发明的像素数量越多，过程所需的时间越长，质量开始失败。使用更复杂的算法需要更长的时间（周围像素的平均值与复制最近的像素）获得最佳质量。
To reduce the number of pixels that have to be invented, with mipmap you provide different sizes/rsolutions of the same image, and the system will choose the nearest image to the resolution that has to be rendered and do the scaling from there. 为了减少必须发明的像素数量，使用mipmap可以提供相同图像的不同尺寸/分辨率，系统将选择最接近必须渲染的分辨率的图像并从那里进行缩放。 This should reduce the number of invented pixels saving resources to be used in calculating these pixels to provide a good quality image. 这应该减少发明像素的数量，节省用于计算这些像素的资源以提供高质量的图像。
I read about this in an article explaining a performance problem in libgdx when scaling images: 我在一篇文章中解释了这一点，解释了在缩放图像时libgdx中的性能问题：
http://www.badlogicgames.com/wordpress/?p=1403 http://www.badlogicgames.com/wordpress/?p=1403
#4楼
The Android implementation of mipmaps in 4.3 is exactly the technique from 1983 explained in the Wikipedia article :) 4.3中的mipmaps的Android实现正是1983年维基百科文章中解释的技术:)
Each bitmap image of the mipmap set is a downsized duplicate of the main texture, but at a certain reduced level of detail. mipmap集的每个位图图像是主纹理的缩小副本，但是在某个降低的细节水平上。 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. 虽然当视图足以以完整细节渲染时仍然会使用主纹理，但是当从远处或小尺寸查看纹理时，渲染器将切换到合适的mipmap图像（...）。
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"). 虽然这被描述为用于3D图形的技术（因为它提到“从远处观看”），但它也适用于2D（翻译为“绘制的是较小的空间”，即“缩小的”）。
For a concrete Android example, imagine you have a View with a certain background drawable (in particular, a BitmapDrawable ). 对于具体的Android示例，假设您有一个具有特定背景可绘制的视图（特别是BitmapDrawable ）。 You now use an animation to scale it to 0.15 of its original size. 您现在使用动画将其缩放到原始大小的0.15。 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). 但是，您可以提供一个mipmap，这意味着图像已经预先渲染了几个特定的比例（比方说1.0,0.5和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. 每当动画“越过”0.5阈值时，不是继续缩小原始的1.0大小的图像，而是切换到0.5图像并缩小它，这应该提供更好的结果。 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. 根据Bitmap类的来源，它只是一个提示，渲染器可能会也可能不会尊重它。
/**
* 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以及一些发射器（例如GEL）请求“更高密度”的图标以显示更大，但这应该使用常规机制（即drawable-xxxhdpi ，＆c）来完成。
#5楼
One thing I mentioned in another thread that is worth pointing out -- if you are building different versions of your app for different densities, you should know about the "mipmap" resource directory. 我在另一个线程中提到的一件值得注意的事情 - 如果你为不同的密度构建不同版本的应用程序，你应该知道“mipmap”资源目录。 This is exactly like "drawable" resources, except it does not participate in density stripping when creating the different apk targets. 这与“可绘制”资源完全相同，只是在创建不同的apk目标时不参与密度剥离。
https://plus.google.com/105051985738280261832/posts/QTA9McYan1L https://plus.google.com/105051985738280261832/posts/QTA9McYan1L
#6楼
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. TL; DR：drawables可以作为dp特定资源优化的一部分被剥离。 Mipmaps will not be stripped. Mipmap不会被剥离。
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. 为避免出现这些显示问题，应用程序应使用mipmap/resource文件夹作为启动器图标。 The Android system preserves these resources regardless of density stripping, and ensures that launcher apps can pick icons with the best resolution for display. 无论密度剥离如何，Android系统都会保留这些资源，并确保启动器应用程序可以选择具有最佳分辨率的图标进行显示。
(from http://developer.android.com/tools/projects/index.html#mipmap ) （来自http://developer.android.com/tools/projects/index.html#mipmap ）
146
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
