一、背景
随着项目需求变化，那些没有用的图片、视频或者冗余的代码逻辑就垃圾存在在我们的工程里，趁着这两天需求没有堆积过来，想着赶紧跟我们项目除除草，以免后面包体积不断变化，导致用户流失，通过APP下载报告分析，大的APP下载时间变长，用户多数会选择抛弃。由于我研究这方面刚开始，接下来从以下几个纬度去做优化。
二、删除无用的图片、音频
使用工具检测用于的图片或者重复图片统计工具，为了以防误删，建议再仔细看下
[检测工具][https://github.com/tinymind/LSUnusedResources] 如果404，直接复制在浏览器里搜索
三、删除没有用到的类、第三方库、动态库
我们应用都是一个可执行文件，可以从可执行文件的内存布局方式上入手：
推荐一篇介绍mach-o文件内存 具体地址[https://www.jianshu.com/p/221894fcb5d0]
mach-o文件主要组成：header (大小、支持的CPU、支持的架构) ，common command (处理指令),Segment
重点看下Segment的细分，如下图：
Mach-O 文件中的 (__DATA,__objc_classlist) 段表示所有定义的类， (__DATA.__objc_classrefs) 段表示所有引用的类(继承关系是在 __DATA.__objc_superrefs 中)；使用的方法和引用的方法也是类似原理。因此我们使用 otool 等命令逆向可执行文件中引用到的类/方法和所有定义的类/方法，然后计算差集。具体参考iOS微信安装包瘦身，目前只有思路没有现成的工具。
主要我们无用的类、分类、方法尽量将一些可以复用的代码抽离
这里分享一个检测无用代码的工具，肯定有误差，具体可以作为我们的参考 APPCode
appcode，用起来特别爽，可以当成xcode 使用，优点还是大于xcode,这里只介绍对无用代码的检测，其实它的功能远远不止这些，比如错误、警告语法的搜集，很多好的开发模版以及工具等等
检测步骤：code->inspect code->可以设置检测选项（我只设置了无用代码检测）,检测完它会分类甚至可以直接设置每一个的路径，可以检测到无用的类、方法声音、无用头文件导入等具体如下图，粗糙点，更多的功能自己去体验下😄
四、编译器层面做优化
通过调节xcode在release环境下优化等级来优化
简单翻译如下，英文水平有限，有错误的地方望指出：
指定被编译代码的执行速度和二进制文件大小的优化程度：
- None[-O0]: 不优化。在这种设置下， 编译器的目标是降低编译消耗，保证调试时输出期望的结果。程序的语句之间是独立的：如果在程序的停在某一行的断点出，我们可以给任何变量赋新值抑或是将程序计数器指向方法中的任何一个语句，并且能得到一个和源码完全一致的运行结果。
- Fast[-O1]: 大函数所需的编译时间和内存消耗都会稍微增加。在这种设置下，编译器会尝试减小代码文件的大小，减少执行时间，但并不执行需要大量编译时间的优化。在苹果的编译器中，在优化过程中，严格别名，块重排和块间的调度都会被默认禁止掉。
- Faster[-O2]: 编译器执行所有不涉及时间空间交换的所有的支持的优化选项。在这种设置下，编译器不会进行循环展开、函数内联或寄存器重命名。和‘Fast[-O1]’项相比，此设置会增加编译时间和生成代码的性能。
- Fastest[-O3]: 在开启‘Fast[-O1]’项支持的所有优化项的同时，开启函数内联和寄存器重命名选项。这个设置有可能会导致二进制文件变大。
- Fastest, Smallest[-Os]: 优化大小。这个设置开启了‘Fast[-O1]’项中的所有不增加代码大小的优化选项，并会进一步的执行可以减小代码大小的优化。
- Fastest, Aggressive Optimizations[-Ofast]: 这个设置开启了“Fastest[-O3]”中的所有优化选项，同时也开启了可能会打破严格编译标准的积极优化，但并不会影响运行良好的代码。
在Xcode中，为了方便调试，通常Debug模式默认为None[-O0]，Release模式默认为Fastest, Smallest[-Os]，在实际的项目中，可以根据项目的情况设置优化级别。我的是xcode11,基本上xcode的默认配置就是最小最小限度对编译速度造成影响的配置。
如果你的swift 项目 ，可以参考如下
No optimization[-Onone]：不进行优化，能保证较快的编译速度。
Optimize for Speed[-O]：编译器将会对代码的执行效率进行优化，一定程度上会增加包大小。
Optimize for Size[-Osize]：编译器会尽可能减少包的大小并且最小限度影响代码的执行效率
五、去除无用的符号化文件
目前没有尝试，因为我们线上没有crash无法保证，所以还是得需要滴
五、一些音频，图片文件可以考虑放到后台，等进入app后下载：
目前没有尝试
六、与混合开发结合，
比如一些静态页面或者是简单的监护页面交给h5做，目前的方式很多，比如结合cordova的方式用web内核渲染开发，但是注意内存泄漏，或者用reactnative方法交给app渲染，然是中间多了一层转换层，或者用google的flutter，自制渲染内核，目前说是性能特别好，但是本身没有在工程里实践过。但是都是一些简单交互的页面，性能没有太大差别，在者我们的h5团队更熟悉cordova，我们最终还是结合cordova与原声结合的方式减少一部分代码。
七、总结：
其实优化最高层级就是图源文件，无用代码的删除，编译层面目前由于对clang、LLVM的了解不够深入，所以没有做很多优化，但是很多技术B类公司已经做了很多，但是都没有开源的很完整，所以，还是得努力研究，越学习越无知！
京公网安备 11010502036488号