文中提到的优化措施，编写了python自动化脚本，适用于iOS项目。
地址：GitHub - dongzhixuanyuan/imagesOptimize: Optimize images to decrease the App package size.
目录
进行iOS App包体积优化工作时，图片处理的可优化空间最高，投入产出比最高。主要有如下几个优化方向：
图片复用
App架构模式
????????采用模块化设计模式，独立功能的代码放在一个Pod中，代码层面做到了分层设计，但是因为历史遗留问题，图片资源是未完全模块化的。存在2个问题：
?1. Pod A引用到的图片资源绝大部分在自身的Pod中，但是小部分分布在Common库，App壳工程。
?2. Pod A和Pod B可能存在完全相同的两份图片，因为彼此之间是资源不互通的。
????????为了解决这2个问题，有必要建立公共图片库，作为基础模块被其他Pod引用。重构工程，接入公共图片库需要解决2个问题：
?1. 如何让现有的UIImageView访问到公共库中的图片资源
?2. 如何找出项目中的重复图片?
UIImageView的图片资源访问方式
- 图片picture_1放在App壳工程目录下，获取image的方式：
let?image1 = UIImage.init(named:?"picture_1", in: Bundle.main, compatibleWith:? nil)
let?image2 = UIImage(named:"picture_1")
image1 == image2
2种方式都能获取到image，并且获取到的是同一个image对象。
- 图片picture_2放在Pod?A中，获取image的方式：
| let?searchBundle = Bundle(for: ClassInPod_A.self) if?let?path = searchBundle.path(forResource: "Pod A", ofType: "bundle") { if?let?podBundle = Bundle(path: path) { ? ? let?image = UIImage(named: "picture_2", in: podBundle, compatibleWith: nil) } } 如果直接使用let image = UIImage(named:"picture_2")，那么image=nil |
鉴于以上的图片访问规则，设计出公共图片库的访问逻辑，如下
相似图片检测：
?????使用"感知哈希算法"（Perceptual hash algorithm），对每张图片生成一个"指纹"（fingerprint）字符串，然后比较不同图片的指纹。结果越接近，就说明图片越相似。具体可参考相似图片搜索的原理 - 腾讯云开发者社区-腾讯云.通过对项目内的图片进行比较，找出所有相似的图片。
这2个问题都有了对应的解决方案，只需要将相似图片迁移到公共库中，各Pod都引用公共库的图片即可。当然，这里面涉及到项目中现有UIImage的访问方式修改，可以通过脚本来进行自动化处理。
无用图片清理
????????字符串搜索匹配工具，推荐使用Silver Searcher，其作者介绍，该搜索工具比Unix的ack工具搜索速度快34倍。对图片名称进行全局字符串匹配查找，高性能的工具至关重要。经过此项，通用包体积下降24.5M。
图片压缩
????????Asset?Catalog是Apple早在2015引入的图片、颜色管理工具，引入的最初目的是为了让图片能自动适配不同尺寸的设备。后来引入的黑暗模式，也是通过Asset?Catalog，让开发者能简单地适配。
Asset?Catalog有如下3项优势
- xcassets目录下的所有图片最终被打包到Assets.car文件中，多张图片被整合为一张大图。App运行时根据索引从大图中获取单张小图片，可以减少文件IO次数，Performance会更好。
- Apple为了优化iPhone读取图片的速度，Xcode编译时，Asset Catalog中的png图片转换成CgBI格式（非标准的png格式），jpg格式图片会转为png.其他非Asset?Catalog管理的图片资源，在编译时不会被优化。
- 使用Asset?Catalog管理的图片能被App?Store工具app?thinning处理，处理后用户只会下载匹配其设备分辨率的图片资源，用户下载的包更小。
????????对于Asset?Catalog管理的图片，如果仅仅对图片做无损压缩，虽然能减小原始图片的大小，但是会发现最终的ipa包体积并不会减小。这是因为Xcode编译时，会对图片再次处理，处理成CgBI格式，导致之前针对图片做的无损压缩工作全部失效。最终，只能通过有损压缩的方式，才能最终实现ipa包中的图片占用体积下降。
????????经过调研，把压缩率、自动化程度、压缩质量作为评估标准，选择了ImageOptim作为压缩工具。各项压缩工具的压缩指标，可参考评估报告。
使用ImageOptim工具，有损压缩质量80%，压缩率测试结果如下：
| 图片数量 | 图片总大小（MB） | Assets.car大小（MB） | |
| 压缩前 | 56 | 7.5 | 21.4 |
| 压缩后 | 56 | 2.99 | 12.3 |
| 压缩率 | 40% | 57% |
对比测试2款图片压缩工具（ImageOptim和pngquant），结果如下：
| pngquant | imageOptim | |
| 压缩前图片大小（Kb） | 1945 | 1945 |
| 有损质量 | 80 | 80 |
| 压缩后大小（Kb） | 757 | 836 |
| 压缩率 | 38% | 42% |
结论是，在选择相同压缩质量的条件下，pngquant压缩率更好，但是最终的图片质量imageOptim更好，最终选择了ImageOptim作为压缩工具。
图 7左边为ImageOptim处理后的图片，右边是pngquant处理后的图片。
ImageOptim集成介绍：
- ImageOptim工具需要单独安装，并且需要对一些压缩选项进行配置。依据压缩速度和压缩质量评估，较为合理的配置如下。建议去掉“Zopfil”和“PNGOUT”压缩算法，如果打开的话，对压缩比例的影响不到2%，但是压缩时长将增长好几倍。
- 可重复压缩。保持同样的压缩质量，多次压缩对图片大小影响只有1%以下。所以可以周期性地对项目内的所有图片进行压缩。
针对这三项优化点，用python编写了自动化脚本，可用于项目迭代以及其他项目。地址：https://github.com/dongzhixuanyuan/imagesOptimize