Asset catalogs:图像管理的最佳选择

72 阅读6分钟

摘要: iOS工程中,对资源文件的管理可以划分为2种,一种是直接将资源文件放入工程主bundle,还是一种是使用Asset Catalogs对资源文件进行管理;主bundle中的资源文件,会被原样引入到app构建产物,而对于Asset Catalogs中的资源文件,在XCode编译过程中,会有Asset Catalogs的编译管道对资源进行优化,本文主要介绍相关优化内容。 阅读本文,希望具备图像的相关基础知识,会更容易理解。

1.app精简功能

在app包构建完毕后,会根据Asset编辑器中尽可能提供的变量内容,app精简会确保变量应用到最终分割出的设备上,比如说2x图片只会应用到2倍屏设备,不会应用到3倍屏设备。

2.自动图像打包

图像文件放入项目主bundle劣势:

  1. 额外的存储空间,传统的图像容器格式,会使用额外的空间来存储元数据和图像对应的其它属性,如果应用有大量的图像文件,而且他们有相似的元数据,那么相同的信息就会无意义的在磁盘上反复复制,如果应用的绝大多数资源都很小,也不能最大程度发挥图像压缩的优势

  2. 组织上的开销,处理如此多的零散的图像文件是很困难的,会产生大量的检索消耗

  3. 需要处理图像格式的不一致性,还有其它图像属性

Asset Catalogs优化:

  1. 通过识别共享相似色域配置的图像,并将其分成一组,来生成更大的图像地图集来解决重复存储问题,这样就不需要为你所有的图像插图重复存储相同的元数据

  2. 资源集中到Assets,避免多余的检索消耗

  3. 在编译过程中,提前对图像格式,图像属性进行兼容处理

3.图像压缩

图像压缩是Asset Catalogs编辑器的核心内容,也是Asset Catalogs编译管道的最后一步;

默认会选择优化最好的压缩类型,了解其它的压缩类型,做对应的取舍还是很有必要的。

3.1有损压缩

建议在短时间在屏幕上显示的图像使用有损压缩

  1. app启动画面中的图像

  2. 过场动画

  3. 特效

asset catalogs 编辑器引入 High Efficiency Image File Format(在拥有和JPEG同样画质的情况下:体积更小、效率更高;),并将HFIF与asset catalogs的有损压缩整合在一起:

  1. 可以提供更高的压缩比

  2. 支持透明度

  3. 可以自动将其它格式转换成HEIF格式(只要被标记为有损压缩,在编译管道中自动完成)

3.2无损压缩(默认)

引入全新压缩算法:Apple Deep Pixel Image Compression,

1.与当前的压缩算法对比,提供15-20%大小优化

2.缩减20%的解码时间

4.色彩管理

色彩管理可确保资源的实际颜色匹配合适在不同的显示屏上及缩放时比较得当,这是个计算过程,它可以由cpu完成,有时候是在gpu上;

编译管道优化:

  1. 对Asset Catalogs中的图像在编译过程中提前进行颜色匹配,节约计算量,避免在设备上渲染时才进行计算,而且此时资源在设备上已经准备好被加载,准备好被显示,不会有任何麻烦;

举个例子:display P3的图片

  1. 放在Assets中,默认会在asset编译管道中被转化为兼容模式(extended srgb),可以毫无障碍的加载和渲染
  2. 放在主Bundle中,GPU不支持的image: dispaly P3的格式,所以需要CPU进行转换,这个操作在主线程中进行,影响主线程性能,可用debug中的color copied images检测,颜色展示为青绿色
  1. 消除了原色彩配置文件,取而代之一种更高效的方法来注释颜色空间及磁盘上的像素

5.可拉伸图像

在Asset 编辑器中提供slicing功能

对于单个图像,提供表面其拉伸部分的拉伸元数据,这会带来对可变尺寸图像来说最优的,最流畅的gpu动画,同时可被重复的部分资源将不再被需要,因为可以用剩余的3个部分来表示所有可能的大小,所以设计师可以已原始尺寸送达资源,不需要预处理;另外分割后的图片大小也会有明显的缩减。

6.大型项目中图片集的组织方式

  1. 使用bundle来组织模块插图,xcode为bundle生成唯一的资源目录部署目标,bundle会生成唯一的命名空间,但是会丢失asset编译管道的优化

  2. 使用Asset编辑器的命名空间功能,图片集文件夹勾选Provides Namespace

7.以性能类来调整资源

可以通过设备相关性能,配置相应的图片资源

内存:1G,2G,3G,4G

图形:Metal

内存,图形混合的资源矩阵,已搜索内存结果优先

举例场景:使用NSDataSet提供可变容器,结合性能类,在高性能设备上使用视频,低性能设备上使用图片

8.Asset建议:

  1. 资源文件最好使用Assets Catalogs管理,如果图片过大,会导致内存爆增,可放入主bundle中,但是不要同时提供x2,x3多个版本资源文件

  2. Assets中文件夹使用命名空间,避免文件名重复

  3. Assets中要求提供完整的2x,3x图片,方便精简到对应设备

  4. 短时间在屏幕上显示的图像使用有损压缩,如动画,特效等

  5. Assets中对可拉伸图片进行分割处理,优化体积

  6. 对于有损压缩图片,不要自行压缩,由Assets Catalogs编译管道来处理(选择有损压缩),app可以保证图片质量的情况下,提供体积更小,解码更快的压缩方案

  7. 尽可能完整的提供内容变量,以便精简app的时候合适资源被应用到对应设备

  8. 对于pod库中的资源文件,建议同样使用Asset

  9. 对于其余json,html,xml,音视频等文件建议先压缩处理