一般而言，archive之后，所有的文件都会缩小，当然包括图片。可奇葩的是，在最近对app进行瘦身的过程中，在ipa里发现几张1~2M的png图片。（如图）
起初判定为开发人员导入图片的时候，没注意看图片的大小，忘记对图片进行必要的压缩。后来，在工程中找到图片后，笑了。工程里的图片最大也才1M，但是ipa里却显示2.4M。
着实被惊叹了。
知道Xcode会对png进行优化，但是优化的这么夸张，搞大了应用安装包，是让人万万没想到的。马上做了测试，问题要么出在Xcode上，要么出在图片上。
检查了下工程中其他png的压缩情况，多数的大小并未改变。如果是Xcode的问题，那么所有png应该都会出问题，因此重心转移到这个图片和其他的png有什么区别的探寻。把推断的情况大致和UI妹子讲了一遍，妹子一脸茫然的表示：听不懂，此png和彼png都是png,没啥区别。经过仔细的引导，妹子想到一条很重要的线索，此（会变大）png压缩过，彼（正常）png木有压过。
接着提出问题：原图是不是就有2M的大小呢？
妹子回复：原图1.9M，可能是系统不同，对图片大小计算的算法不一样。（mac Vs Windows）
向UI妹子要了原图，导入工程，继续archive，图片木有被放大。喜！
问妹子，这个原图是1688*1125的，可否给张720*530的呢？
答：可以。113k
archive，113k,图片木有放大，继续喜！
此时，问题已经比较明朗了。jpg->png->压缩—>png —>archive。Xcode对已经压缩过的png进行archive时，为保证用户体验，进行了解压缩和还原的逻辑（猜想）。在app看来，图片变大了，实则是图片被还原了。
为了验证这一猜想，又选择了一个被放大的图片，将工程中的png发给妹子，妹子转为jpg后进行压缩处理发给我；
继续archive，83k。
喜不胜收！为UI妹子的鼎力支持点赞~
在app图片瘦身的路上，从盲目压缩，适得其反，走向了合理索图，合理加载，顺利瘦身的方向；
tips：直接将图片文件放在工程目录中，如果是jpg格式的，使用imageNamed加载时，是需要带上后缀名；
如果放在Assert里，就不需要。
当然，为了app瘦身，果断放到Assert里呗，既方便调用，还可以不加后缀呢，一举两得。
Asset目录将会根据需求选取其中的资源,并且按照运行时更有效率的访问的方式排列.处理方式中包含将PNG文件转化为一种合法但是部分图形应用却无法查看的格式.如果你翻一番iOS的.app包,当看到无法查看的PNG文件的时候,不要惊讶!(之前将2.4M的那张PNG发给UI妹子,妹子表示,打不开,为黑色,哈哈哈,搞笑的IDE)
希望能帮到遇到同样问题其他小伙伴。动动小手，鼓励下达若，点下小心心吧❤️ ~
