现在的项目是接受别人写的，而且项目时间比较旧。一直不断的开发新功能，造成现在项目体积很大。现在的用户不像14、15年那时候，愿意装各种app，用户现在会考虑是否有必要，是否占内存，app有多大等等一些。所以，缩小ipa的大小就非常有必要了。
优化要从两个方面来处理：
1 资源的优化
1.1资源的压缩
其实资源的压缩，主要体现在图片的压缩。一般在项目中使用到的图片都是png无损压缩的，即使经过Xcode压缩后图片资源依然会很大。=但是由于 PNG 是无损压缩，经过 Xcode 压缩后的图片资源，依然很大。这个时候，我们可以把明明在UI界面上显示很小的一个图片进行压缩。因为一个很小的视图显示很大图片，根本没有必要。即使我们对显示图片进行了压缩，难道显示效果就会发生巨大的变化吗？显然不会。所以，资源的压缩说白了就是把这种UI显示很小但是图片却很大的情况进行优化。
1.2 未使用、重复使用资源的删除。
随着版本的不断迭代，一些功能可能下线，这个时候要及时的删除这些。有时候由于不同的人员开发，也做造成资源的重复，随着时间的推移这部分会慢慢的积累。所以，遇到这种情况的时候要及时的删除。可能有的人会担心，那我后期如果又让变回原来的需求怎么办，大兄弟啊，有个东西叫git，我相信不使用代码管理的应该没多少吧。
重复资源的情况一般会发生在一些按钮、或者背景图由同一个 UI 同事生成，发给了不同功能的开发人员。这部分图片的判定一般可以通过图片大小相同或相近（大小在 5% 范围内）、分辨率相同进行初筛，然后再通过 magick compare 工具进行图片的对比，提取出相似度极大的即可。
1.3 资源上云
这个我没实践过，只能百度一下了。资源上云可以有效减少包内资源，唯一要注意的是这些资源由于是 lazy load，所以比较适合层级较深的页面使用。图片逻辑可以封装为工具类，前端使用只是调用一个方法，具体哪些图片取本地、哪些图片走云的策略可以自由配置。此外，资源上云的另一个好处是可以很方便地实现动态换肤。
2.二进制文件的优化
1.1配置编译选项 Generate Debug Symbols 设置为 NO；
1.2 舍弃架构，如：armv7，根据实际选择。一般现在估计使用到iphone4s的估计没几个人了。所以可以舍弃。
1.3编译的版本必须是 release 版本，一般情况下我们都会区分debug和release，这为什么发布时候要release呢？是因为release跳过了项目中断点和一些打印输出。
1.4 查找内部使用到的第三方库，一方面可以进行删减代码，用不到的类，直接删除，还有第三方库中的图片资源统统删除掉，如果能够自己手写实现的，那费功夫自己写吧。因为一般第三方的库功能都比较全面，但是在项目中我们仅仅使用它的具体某一个功能的话，在不影响功能性的情况下，是可以对其进行一些删除的，以便缩小项目体积。
1.5 图片的压缩。这部分我们在之前资源配置部分已经介绍
1.6 音频
压缩音频，尽可能使用 AAC 或者 MP3 格式，并且使用一个较低的码率。通常 44.1khz 的码率有点浪费，降低一定的码率也不会丢失多少音质。
1.7视频
视频也可以使用类似于音频的处理方法，音视频的压缩可以很大程度的压缩，但是要注意压缩的格式，是不是会增加编解码的负担，这要权衡考虑。
网友评论