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

·  阅读 21596

20220117092009.jpg

一、背景

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

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

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

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

二、实现基本思路

云端是啥意思呢?

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

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

三、技术成果

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

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

由于减少了项目的图片数量,也同时提升了每次Command+R Build的编译效率。更多编译优化请移步这里iOS编译速度如何稳定提高10倍以上

image-20211129171639671.png

四、具体方案

image-20220112143418515.png

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

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

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

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

1、大致流程图

云端管理流程图.png 数据收集分析系统

  • 对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处理后的样子

20220114103952.jpg

3、怎么确保完整性,避免丢失图片?

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

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

20220114102202.jpg

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

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

20220114102338.jpg

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. 每一环最好有对应的系统去规范与验证,更喜欢说这是一套系统体系,不是简单的脚本开发

六、总结

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

打个广告,厦门美柚急缺各类人才,欢迎加入我们。

内推简历发送至邮箱: suliangjin@xiaoyouzi.com 😀😀😀

最后祝各位看官,新年吉祥,升职加薪,大吉大利,财源广进。

分类:
iOS
标签:
分类:
iOS
标签:
收藏成功!
已添加到「」, 点击更改