mipmap到底有啥作用

Posted 2023-05-09

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了mipmap到底有啥作用相关的知识，希望对你有一定的参考价值。

mipmap作用：纹理图像的较小的预滤波变体，表示纹理的不同细节层次（LOD）。通过使用mipmap的缩小过滤器模式，Graphics Core可以设置为自动计算哪个LOD最接近将mipmap的纹理元素映射到渲染目标中的像素，并使用正确的mipmap 进行纹理化。

mipmapping 的单一限制是每个图像需要大约三分之一的纹理内存。根据情况，与渲染速度和图像质量方面的好处相比，这个成本可能很小。

原理分析

理想情况下，应该使用诸如PVRTexTool之类的工具离线创建mipmap，该工具可作为PowerVR图形SDK的一部分提供。可以在运行时生成mipmap，这对于更新渲染纹理目标的mipmap非常有用。

在OpenGL ES中，可以使用函数glGenerateMipmap来实现。在Vulkan中没有这样的内置函数，开发人员必须手动生成它们。

参考技术A mipmap指的是平面纹理的清晰程度。它是方块经过渲染之后显示的清晰程度。在同样的材质包，同样的显示器分辨率的情况下，mipmap等级越高，渲染后景物就越清晰。同时mipmap等级的高低还决定了电脑负担（主要是显卡、显存等）的大小；等级越高，...

Android中drawable和mipmap到底有什么区别

老项目代码中发现有的图片放到了drawable中, 有的图片放到了mipmap中, 开发时秉承哪个目录下文件多放哪里的原则, 偶尔有疑惑搜一搜文章, 看到了结论也就这么使用了, 不过今日有时间, 依次检验了一下文章中的内容, 发现和实际的表现出入甚远.

常见的几种结论

Case 1 drawable会剔除其它密度, mipmap会保留全部(实际上最终的结论和这个有关联)

当xhdpi密度的手机在加载apk的时候Google是有一个优化的，是会剔除drawable其他密度的文件，只保留一个基本的drawable和drawable-xhdpi的文件，而mipmap是会全部保留的。

检测方法也比较简单, 在drawable和mipmap不同密度的问价夹下分别放入同一类图片(图片标文字用于检查), 分别打包并检查其大小

Case1.1 安装包与应用大小

	安装包大小	应用大小
drawable	13.3 MB (14,016,841 字节)	14.04MB
mipmap	13.3 MB (14,017,191 字节)	14.04MB
###### 结论1.1
由此可见, 虽然两个安装包大小略有差异, 考虑到图片本身的大小(每张图片都在1Mb作用), 可以认为放入`drawable`和`mipmap`文件夹中的图片在安装包和应用安装后没有差异

Case1.2 应用内表现

排除安装包的情况, 我们看一下在应用内的表现情况(通过adb shell wm density保证只修改手机的dpi信息)

	100	420	800
drawable

mipmap

结论1.2

由此可见, 文件不论放在哪个目录下, 在手机中都会正确的显示为其匹配的图片资源

Case 1.3 应用内缩放

如果一个 imageView 有缩放动画，使用 drawable 下的图片，会一直使用一张来缩放图片实现 imageView 缩放动画。如果使用 mipmap 下的图片，会根据缩放程度自动选择比当前分辨率大而又最接近当前分辨率的图片来做缩放处理。

这个可能大家见得不是很多, 不过既然有这种说法, 那就来测试一下

drawable

小缩放比例	大缩放比例

mipmap

小缩放比例	大缩放比例

结论1.3

可以看到在缩放动画的过程中, 一直显示的都是同一个动画

Case 2 应用内性能

Google对mipmap的图片进行了性能优化, 使其可以表现的更好

drawable

性能检查一览	MEMORY	10次图片加载平均时间
		146

mipmap

性能检查一览	MEMORY	10次图片加载平均时间
		151

结论2

可以看到, 加载单张图片的情况下其性能基本一致,不排除图片太小/太少性能优化不明显的情况, 不过尝试单证图片重复加载的情况下依旧表现为性能相近的情况, 或许时只针对特殊类型有优化? 如各位知道的更详细, 欢迎和我进行交流。

Case3 启动图标

在查阅资料的时候, 发现多次提及minmap应用只放入应用的启动图标, 使其可以得到优化.

	100dpi	420dpi	800dpi

结论3

可以看到, 不同dpi的情况下应用图标的显示情况都是一致的. 其应用图标切换的边界值也是一致的. 关于420dpi和800dpi显示效果一样的情况, 因为种种原因, 应用图片在选择图片资源的时候, 需要将密度扩大25%左右¹.

看到这里大家应该和我有着一样的疑惑, 既然drawable和mipmap下图片的表现不论是安装包还是应用内, 甚至连官方文档都这么说了, 为什么各种测试结果下来, 两者的表现基本的一致呢?

罪魁祸首 Bundle(.aab)

提到Bundle(.aab)国内的开发者可能都比较陌生, 甚至不少之前做过Google Play上架应用的都不是很熟悉. 这个其实在我们每次手动打包的时候都会出现。

简单来说.aab包一般用于Google Play商店使用, 在你从Google Play商店下载应用时, 它会根据你手机的实际使用情况来下载不同drawable中的资源. 以期望达到减少安装包大小的目的. (一般情况下手机dpi不会改变, 其它密度下的资源文件直到应用卸载时都不会被使用).

下面的测试使用到的工具为bundletool², 简单来说, 就是模拟从Google Play下载应用和安装应用的过程.

安装包比较

	安装包(apks)大小	应用大小
drawable	5.91 MB (6,201,543 字节)	6.22MB
mipmap	12.6 MB (13,230,670 字节)	13.26MB

应用内表现

	100	420
drawable

mipmap

可以看到, 当图片放到`drawable`相关文件夹下的时候, 通过.aab包安装的应用会比放到`minmap`的下的应用小许多, 并且应用内更改dpi的时候页可以看到其不再能自动根据当前dpi选择对应的图片了。

结论

那么通过以上的测试, 我们可以得到以下结论了 以下结论均不涉及mipmap的性能优化相关(主要是暂未能设计好一个比较明确的测试对比) 以下测试机型为pixel 7, 测试Android版本为13

当应用构建为.apk的情况下, drawable和mipmap文件夹下的资源表现无差异, 不论是应用内表现还是在启动器(应用图标)中表现.
当应用构建为.aab的情况下, drawable文件夹下的资源会寻找匹配的设备密度保留, 不匹配的资源会被删除已保证apk的大小.而mipmap文件夹下的资源文件会全部被保留.