iOS 瘦身！一个让 50% 本地图片消失的方案

一、背景

好久没写文章了，看了掘金的年度报告，感觉还挺有意思，赶在春节前向各位大佬拜个早年前，聊聊我最近的做一个方案的思路。如有其它的更好的想法，还烦请不惜赐教。😀

安装包瘦身一直是老生常谈的问题，几乎每个大一点的项目都要经历。我们团队也做了很多关于安装包瘦身的事情，通过各种方案在不删减业务的情况下，累计安装包大小减少100M+，减少占总包体约38%+。

App每次迭代都会加入大量的本地图片，但是一些页面用户并不会用到，而不会用到的本地资源确会跟着一起打包进来，导致App包越来越大，我们也用过了各种办法去解决类似的问题，取得一定的效果，但作为一个有追求的人嘛，总得折腾折腾，突破自我。

为了处理这类图片资源问题，我做了一些比较有意思的图片管理尝试。即、开启云端图片资源管理方案。😺

二、实现基本思路

云端是啥意思呢？

其实就是通过一些埋点统计，找出可能未使用的资源，把可能未使用的图片通过脚本剔除出项目，在App启动后动态加载那些被剔除图片的zip包。下载完成后，放入iOS应用程序沙盒中，在app读取图片时，如在原本的App路径中查找不到图片，会自动去沙盒中找一次图片路径。

整套流程对于我们目前的项目情况来说，还是一如既往的做到业务方无改动且无感知，由底层框架和自动化脚本自行处理。

三、技术成果

云端图片资源管理方案，开启后，安装包减少了21.2M（总的IPA图片约40M），如果你胆子够肥，**减少75%+**也不是说不可能的，谋事在人，成事在天，事在人为嘛。

同时动态加载本地资源图片还能提供一些其他的功能，比如对于已上架的App，能动态替换、新增本地图片，我们曾经用了这个机制避免一次补丁包。

由于减少了项目的图片数量，也同时提升了每次Command+R Build的编译效率。

四、具体方案

一个成功男人的背后，总有一个默默支持他的女人。同样的，每个稳定的系统后面都需要许多个“女人”们在背后默默的支持。

对每个“女人”们，我们都是真心实意，披荆斩棘、下刀山过火海，闯过了各种各样的难关才让她成为“王的女人”

当时我在做这套体系时，也是遇到各种各样的难题。好在后面还是顺利的实现了，目前已经稳定运行了几个月了。

目前我们针对的是项目，不是针对某个模块或者组件在处理。如果是针对某个组件处理的，会使整套系统过于复杂，且不容易移植到其他项目。

1、大致流程图

数据收集分析系统

• 对IPA中的本地资源图片进行使用统计，如某个图片name key使用次数、版本、所在展示页面的层级数、调用时间与距离首次打开APP时间差等，上报到数据收集系统，给我们提供数据支撑
• 获取IPA中所有相关图片key列表数据库，把每张图片的使用情况写入相关的数据库保存起来。
• 用IPA所有key集合 - 线上统计到的数据集合 = 我们可能要删除的图片集合
• 对于一些数吊车尾的，使用层级较深的，通过一定的数据分析放入被删除的黑名单中
• 黑名单机制：指统计到的key，经过一定的算法筛选，需要从IPA包中删除的图片的集合
• 白名单机制：不能被移除的图片集合
• 未统计到列表集合
• 最终会被移除的图片集合是 remove_image_list + black_list - white_list

自动化制作系统

• 非Xcassets模式的图片，在利用pod钩子去删除要被移除集合
• Xcassets模式：由于Xcassets并没有像非Xcassets那样，在Pods_Project_resources.sh有独立的install_resource Action，所以只能通过一定的算法规则移除了实体文件。
• 在CI制作完成后，提取对应的包资源做diff，验证是否误伤“友军”

监控系统

• 线下监控：可追踪系统跟踪，确保每一张丢失的图片都会有人及时处理
• 线上监控：埋点追踪与预警

通过相关的配置信息，我们在post_install执行脚本，自动去修改了Pod-xx_resources的中相关资源的拷贝动作，既图片不会被拷贝在IPA安装包中。

2、Pods_project_resources.sh处理后的样子

3、怎么确保完整性，避免丢失图片？

1、埋点统计丢失情况，来避免一些误操作导致界面异常，同时对于一些较高的数据，我们也可以通过及时发布zip包修正。

2、在测试环境下，如果找不到图片，我们会自动触发创建钉钉消息通知和 tapd 追踪问题，确保丢失的问题有人处理。

4、发生替换图片怎么处理？

在CI每次打包时，对项目中所有的图片资源进行云端管理，会有一套系统对新增和有修改的记录发送对应的跟踪消息处理。

5、云端Zip包下载失败，怎么办？

可能有各种情况导致云端zip包下载失败，即使失败了也不会影响到我们项目的正常使用，因为我们放入云端图片都是经过大数据统计的，基本使用不到或者使用频率很低的那种，所以安心。

同时我们把项目中所有的资源图片都放入云端，在处理查找本地IPA图片都失败的情况下，拼接对应的URL去请求云端的图片（发生这种情况概率极低）

在请求云端的图片时，需要注意类似的写法

UImage *image = [UIImage imageNamed:iconName];
self.iconImageView.image = image；
//替换成这种会更稳妥
[self.iconImageView imy_setImage:iconName]
复制代码

6、上线后如何动态替换IPA包的图片

动态获取配置文件，对于需要替换的本地图片资源，提升本地图片加载优先级。

用了此方案后，我们还怕漏删图片、丢失图片的问题吗？这无疑给了我们做图片优化的提供了强大的后盾，不再需要害怕前有狼后有虎。

7、其他

在具体的执行过程中，可能会遇到各种各样的问题，需要不同的策略与方案去帮助我们的系统更加稳健，这里就省略一万字。

五、注意事项

1. 注意XIB和storyboard的图片引用方式，看是否有被统计到。
2. 注意 initWithContentsOfFile的读取文件用户法，是否有对应的处理.
3. 注意项目中是否包含了其他格式的图片，如JPG，WEBP格式
4. 动态图片可分2x 、3x 降低下载包体大小
5. 完善自动化流程，否则由于图片资源的变更，后续维护成本较大
6. 每一环最好有对应的系统去规范与验证，更喜欢说这是一套系统体系，不是简单的脚本开发

六、总结

整体的设计方案思路相对清晰，但是在实现的过程中，会遇到诸多实施细节。并且需要结合各自项目的情况做出调整，需要一定的全局思考。