记得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尺寸小于原图的一半,那么把hasMipMap
set为true的话,图片质量会更好一点,但会消耗更多内存。不过不保证100%有效(不知道它是由哪些规则去判定的)。我用各种方法测试过了,手动把它设为true,完全没效果,跟使用res/drawable
下的图片对比,一点区别都没有。缩放的性能,内存占用都试过,跟
硬件加不加速、属性动画之类的都试过,没区别。res/drawable
没区别(我还特意拿了张20多m的超大图来测试对比)。反正就是,完全没感觉出来把图片放在
res/mipmap
下的特殊效果。。。难道Launcher在显示这些app icons的时候,会用特别的加载方式?
我不信,况且那么多手机厂商,怎么会一一遵循你谷歌订下的规范,估计大都是使用常规的方式加载的。