记得mipmap刚出来的时候，出现过很多言论，XXX类型图片放mipmap更好。
如今的观念基本停留在，仅将app icon放置到mipmap，其他的图片都放到drawable。
那么我们想想：
- google 为啥要搞个mipmap，或者mipmap有什么特殊的能力？
- 从源码上能做出相关分析吗？
更多问答 >>
-
2021-04-08 00:25
-
每日一问 | 听说你做过内存优化 之 Bitmap内存占用到底在哪？
2021-04-19 23:40 -
2021-05-06 00:16
-
每日一问 | view.requestLayout如果在灭屏或者切home之后调用会怎么样？
2021-05-06 00:16 -
每日一问 | 已经有了 Intent，那为啥还要 PendingIntent?
2021-05-28 00:29 -
每日一问 | onDraw 里面调用 invalidate 做动画，有什么问题？
2021-04-13 00:31 -
每日一问 | 在做性能优化的时候，常常看到 Thread(Cpu) Time，Wall clock Time?
2021-03-15 00:43 -
2021-03-18 23:20
-
每日一问 | 今天还探索一个 View 的方法 hasOverlappingRendering()
2021-02-21 20:16 -
每日一问 | 类要先加载、链接、初始化才能实例化，有特殊Case吗？
2021-02-21 20:15
当你适配了所有密度的设备，drawable-hdpi、drawable-xhdpi、drawable-xxhdpi等等，如果设备显示密度属于xhdpi，apk安装到设备的时候除了drawable-xhdpi文件夹以外，其他密度文件夹里的切图是不会随着apk的安装拷贝到设备里，mipmap的话则都会一起拷贝到设备。
至于剔除和设备不对应的切图没毛病，mipmap保留所有密度切图是为了给启动器使用，要知道很多启动器是可以设置桌面显示应用图标大小的，小的放大了会失真，大的压缩以后显示效果也不如点对点。
文档里也是这么个意思1.mipmap可以优化内存，在屏幕介于两个dpi之间，mipmap会取高的dpi图片进行缩放处理，比用drawable的减少一点内存。
2.分析不了，我找了大概2秒钟，没在aosp11上找到相关源码，我怀疑没适配(可能是我没找到)。我们简单做个实验能看出来到底适配了没有。
从理论上来说，把同样的png(尺寸很大，假装1000x1000)分别放到mipmap和drawable下，通过 Resources.getDrawable 获取返回如果大小不一样说明系统内做了适配，去找源码是有意义的，一样的话，那mipmap和drawable目前看算是个噱头。我测试过了，用getDrwable方法分别加载mipmap和drawbale下的同一张图片，内存占用是一样的，还有画质也一样，播放动画的性能一样
再说了，如果真的是要用特别的方式才能让这个特性生效，那官方又没告诉我们具体要怎么做，就算我们把图片放到了res/mipmap下，也发挥不了作用啊。。。
mipmap 文件夹存放应用启动图标，而其他类型的图片资源（如位图、点 9 图、矢量图）都应该存放在 drawable 文件夹。Launcher（桌面）在显示应用图标时，可以选择显示比当前屏幕更高密度的图片，以获取更高的清晰度和质量。
mipmap 和 drawable 的另一个区别体现在发布应用时的优化差异：在发布应用时，开发者可以向 Google Play 上传 App Bundle，Google Play 会创建优化的 Apk。比如对于 xhdpi 的设备，它会删除所有其他密度的 drawable 文件夹，只保留 xhdpi 的 drawable 文件夹和通用的 drawable 文件夹。因此用户下载的 Apk 包体积更小。mipmap 文件夹不同，优化 Apk 时所有的 mipmap 文件夹都会保留。
那么问题来了，如果我有个资源只在hdpi里有，xhdpi的设备会删这个资源吗？应该不会的吧
以前mipmap也是按照Xh XXh来区分子文件夹的，相同图片，原来放到drawable-xxhdpide , 需要放到mipmap-xhdpi
后来mipmap存放结构调整，如下：
mipmap的文件夹是按文件名称来划分子文件夹的，每个文件名称里再单独放置所有的尺寸；
drawable的文件夹是先按照尺寸来划分子文件夹，mipmap的组织结构更容易查询渲染上的区别吧，之前瞄了一眼，之前有人提过
external/skia/gm/drawable.cppexternal/skia/gm/mipmap.cppmipmap有什么特殊能力？
全局搜"mipmap"，发现在BitmapDrawable、Bitmap等类有这个关键词：setHasMipMap和hasMipMap方法上。难道使用res/mipmap下的图片，会跟这两个方法有关？debug了一下，发现无论是直接在xml中引用res/mipmap，还是用代码创建res/mipmap图片的Bitmap或BitmapDrawable对象，其内部加载流程是完全一样的，都不会牵涉到setHasMipMap和hasMipMap。这就奇怪了。Bitmap.setHasMipMap方法的文档注释说，如果bitmap的实际draw尺寸小于原图的一半，那么把hasMipMapset为true的话，图片质量会更好一点，但会消耗更多内存。不过不保证100%有效（不知道它是由哪些规则去判定的）。我用各种方法测试过了，手动把它设为true，完全没效果，跟使用res/drawable下的图片对比，一点区别都没有。缩放的性能，内存占用都试过，跟
硬件加不加速、属性动画之类的都试过，没区别。res/drawable没区别（我还特意拿了张20多m的超大图来测试对比）。反正就是，完全没感觉出来把图片放在
res/mipmap下的特殊效果。。。难道Launcher在显示这些app icons的时候，会用特别的加载方式？
我不信，况且那么多手机厂商，怎么会一一遵循你谷歌订下的规范，估计大都是使用常规的方式加载的。