一、背景
好久没写文章了，看了掘金的年度报告，感觉还挺有意思，赶在春节前向各位大佬拜个早年前，聊聊我最近的做一个方案的思路。如有其它的更好的想法，还烦请不惜赐教。😀
安装包瘦身一直是老生常谈的问题，几乎每个大一点的项目都要经历。我们团队也做了很多关于安装包瘦身的事情，通过各种方案在不删减业务的情况下，累计安装包大小减少100M+，减少占总包体约38%+。
App每次迭代都会加入大量的本地图片，但是一些页面用户并不会用到，而不会用到的本地资源确会跟着一起打包进来，导致App包越来越大，我们也用过了各种办法去解决类似的问题，取得一定的效果，但作为一个有追求的人嘛，总得折腾折腾，突破自我。
为了处理这类图片资源问题，我做了一些比较有意思的图片管理尝试。即、开启云端图片资源管理方案。😺
二、实现基本思路
云端是啥意思呢？
其实就是通过一些埋点统计，找出可能未使用的资源，把可能未使用的图片通过脚本剔除出项目，在App启动后动态加载那些被剔除图片的zip包。下载完成后，放入iOS应用程序沙盒中，在app读取图片时，如在原本的App路径中查找不到图片，会自动去沙盒中找一次图片路径。
整套流程对于我们目前的项目情况来说，还是一如既往的做到业务方无改动且无感知，由底层框架和自动化脚本自行处理。
三、技术成果
云端图片资源管理方案，开启后，安装包减少了21.2M（总的IPA图片约40M），如果你胆子够肥，**减少75%+**也不是说不可能的，谋事在人，成事在天，事在人为嘛。
同时动态加载本地资源图片还能提供一些其他的功能，比如对于已上架的App，能动态替换、新增本地图片，我们曾经用了这个机制避免一次补丁包。
由于减少了项目的图片数量，也同时提升了每次Command+R Build的编译效率。更多编译优化请移步这里iOS编译速度如何稳定提高10倍以上
四、具体方案
一个成功男人的背后，总有一个默默支持他的女人。同样的，每个稳定的系统后面都需要许多个“女人”们在背后默默的支持。
对每个“女人”们，我们都是真心实意，披荆斩棘、下刀山过火海，闯过了各种各样的难关才让她成为“王的女人”
当时我在做这套体系时，也是遇到各种各样的难题。好在后面还是顺利的实现了，目前已经稳定运行了几个月了。
目前我们针对的是项目，不是针对某个模块或者组件在处理。如果是针对某个组件处理的，会使整套系统过于复杂，且不容易移植到其他项目。
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、其他
在具体的执行过程中，可能会遇到各种各样的问题，需要不同的策略与方案去帮助我们的系统更加稳健，这里就省略一万字。
五、注意事项
- 注意XIB和storyboard的图片引用方式，看是否有被统计到。
- 注意 initWithContentsOfFile的读取文件用户法，是否有对应的处理.
- 注意项目中是否包含了其他格式的图片，如JPG，WEBP格式
- 动态图片可分2x 、3x 降低下载包体大小
- 完善自动化流程，否则由于图片资源的变更，后续维护成本较大
- 每一环最好有对应的系统去规范与验证，更喜欢说这是一套系统体系，不是简单的脚本开发
六、总结
整体的设计方案思路相对清晰，但是在实现的过程中，会遇到诸多实施细节。并且需要结合各自项目的情况做出调整，需要一定的全局思考。
打个广告，厦门美柚急缺各类人才，欢迎加入我们。
内推简历发送至邮箱： suliangjin@xiaoyouzi.com 😀😀😀
最后祝各位看官，新年吉祥，升职加薪，大吉大利，财源广进。
