近期（指一个月前）终于有时间偿还前辈留下的技术债了，下面分享一下经验和心得。这次的优化主题是提高构建速度，在开始前自然是调研一下网上主流的构建提速方案：
- 依赖库二进制化：将依赖库打包成二进制文件，直接节省掉依赖库的编译时间
- 编译缓存器：把编译的中间产物缓存起来
这些方案都不错，但这次没有采用上述方案，因为综合对比下来有更值得先做的事：消除大量的警告。因为目前项目警告已经 65535+ 了，已经超过 Xcode 可以显示的警告数量上限了。
优化前现状
- 在 MacBook Pro (M1 Pro) 电脑配置上清除项目缓存，冷启动首次 Build 时间约为：320s
- 整个构建过程中 Xcode 无响应
- 在真机设备 Run 过程中，如果拔掉线（或线松动），Xcode 无响应 30s 以上
- 在真机设备 Run 过程中，修改代码，再次 Run，Xcode 无响应
- 在上述无响应状态下强制 Xcode 重启，启动后继续无响应，必须按住 Shift 启动
所以我觉得要根据实际情况，先解决掉警告的问题，之后再来考虑二进制化方案。经过几天的修改：
- 消除 ObjC 和 Swift 混编时产生的 nullability 警告（增加
NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END） - 把已经没有实现的方法声明删掉
- 有些警告是类型不匹配，修改成正确的类型
- 把已经过期的 API 修改成新版本的 API
- 删除重复的宏定义
没什么技术含量，都是些琐碎活，需要 QA 部门配合做细致的全量回归测试。
优化警告后
最终把警告数量降低到现在的不足 800 个，构建时间直接降低到 120s 以内。（同为清除缓存并冷启动后首次 Build 的测试结果）
- 现在构建过程中 Xcode 也能继续操作了，很少有无响应了
- 在真机设备 Run 过程中，直接拔掉线以及再次 Run 都不会出现无响应的情况
- 不清除缓存的情况下编译速度本身就很快，在优化前处于不可用的状态，现在终于可用了，视改动量大小，构建时间在十几秒到几十秒不等
总结与思考
优化不是一蹴而就的，这次把警告数降低到合理范围内之后日常构建效率和体验已经实现了质的飞跃，可以先告一段落了，如果下次再需要进一步提高构建速度的话，可以开始考虑二进制化方案了。
每家公司每个项目情况都不太一样，适合别人的方法未必适合你，曾经合适的方法现在未必合适，用一个专业术语来说，大概就是不要落入“教条主义”吧，总之要根据实际情况来具体分析，制定适合团队现状的方案。
许可协议
本文由 Mr. X 原创，采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
分享文章
