iOS减包实践-大图是否用Assets管理？
Asset Catalog优势
-
使用方面
- 对图片资源方便统一管理；
- 方便图片拉升；
- 方便适配暗黑模式；
-
性能方面
- xcassets目录下的所有图片最终被打包到Assets.car文件中，多张图片被整合为一张大图。App运行时根据索引从大图中获取单张小图片，可以减少文件IO次数，Performance会更好；
- Apple为了优化iPhone读取图片的速度，Xcode编译时，Asset Catalog中的png图片转换成CgBI格式（非标准的png格式），jpg格式图片会转为png.其他非Asset Catalog管理的图片资源，在编译时不会被优化；
- 使用Asset Catalog管理的图片能被App Store工具app thinning处理，处理后用户只会下载匹配其设备分辨率的图片资源，用户下载的包更小;
是否所有图片都适合用Assets管理？
先说结论
- Assets适合用来管理icon类会重复使用的小图；
- 背景图这类的大图不适合用Assets管理；
例子
image.png
图片大小：39524字节
未添加图片时Assets.car的大小：5,026,528字节
添加图片后Assets.car的大小: 5,083,664字节
添加图片后Assets.car大小增大了57136字节，比原图多了17612字节；
通过 assetutil 工具对Assets.car进行解析，查看图片在Assets.car中的大小：
image.png
图片放到Assets中，Xcode做了什么事情？
Xcode会执行iphoneos-optimize脚本对Assets中的图片进行优化
脚本路径：
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/iphoneos-optimize
通过查阅相关资料发现，Compress PNG Files做的并不是单纯的压缩数据，而是把文件格式也做了修改，Apple是将png图片转换成了一种CgBI格式：
These modifications cause the generated images to be invalid as per the current version of the PNG standard.
extra critical chunk (CgBI)
byteswapped (RGBA -> BGRA) pixel data, presumably for high-speed direct blitting to the framebuffer
zlib header, footer, and CRC removed from the IDAT chunk
premultiplied alpha (color' = color * alpha / 255)
明显的改动就是在IHDR块之前插入了CgBI块来表示这种格式，同时修改了IDAT块中的数据，原因就是在iPhone中，图像是以BGRA格式在内存中处理的，到这里就可以发现，其实这个所谓的Compress PNG Files，最主要的目的并不是压缩图片的大小，而是将图片转换成iPhone能更方便处理的格式，加快处理速度。
因为CgBI的IDAT是BGRA格式的，所以不管之前的IDAT是否有Alpha通道，在处理的时候，都会增加alpha通道，其次就是因为每一行数据的filter不同，apple处理的时候，默认每一行都使用相同的filter，而原始文件则可以通过更好的算法，对不同的数据行使用不同的filter，为后面的数据压缩提供更容易压缩的数据。
工具
-
assetutil
将Assets.car中一些信息资源解析成json格式；sudo xcrun — sdk iphoneos assetutil — info ./Assets.car > ./Assets.json
-
AssetCatalogTinkerer
查看Assets.car中所有图片的可视化工具，还可以导出图片；https://github.com/insidegui/AssetCatalogTinkerer
image.png
参考
iOS减包实战：Compress PNG Files作用分析
Assets.car解剖作弊条
iOS获取ipa及解压Assets.car，兼容M1
抖音品质建设 - iOS 安装包大小优化实践篇
iOS 优化 - 瘦身
