Apollo iOS 项目依赖解析性能优化探讨

背景概述

在现代iOS应用开发中，Swift Package Manager(SPM)已成为主流的依赖管理工具。然而，当项目依赖较多时，某些大型库的解析过程会显著影响开发效率。Apollo iOS作为GraphQL客户端框架，其仓库由于历史积累导致克隆时间较长，这在包含40-50个SPM依赖的项目中尤为明显。

问题本质分析

SPM的默认行为会完整克隆仓库的所有分支和提交历史，这对于历史悠久且包含大型二进制文件的仓库尤为不利。Apollo iOS仓库中存在一个6年前的提交包含了40MB的node二进制文件，虽然这些内容已被移除，但仍保留在历史记录中，增加了克隆时的数据传输量。

解决方案探讨

1. 独立框架仓库方案

部分大型项目采用的解决方案是创建专门的SPM仓库，仅包含预编译的XCFramework。这种方案的优势在于：

• 仓库体积大幅减小
• 解析速度显著提升
• 避免下载不必要的提交历史

但维护团队对此方案存在顾虑：

• 需要额外维护一个仓库
• 增加了发布流程的复杂性

2. 历史记录优化方案

另一种思路是对仓库历史进行优化：

• 使用git gc清理无效对象
• 考虑压缩老旧提交(如超过3年的历史)
• 移除不再需要的大型二进制提交

这种方案的挑战在于：

• 会强制所有贡献者重新克隆仓库
• 可能影响依赖该仓库的其他项目
• 需要评估对现有用户的影响

3. 二进制分发方案

维护团队更倾向于的解决方案是：

• 在每个版本发布时附带预编译的二进制包
• 允许用户根据需要自行创建轻量级SPM包
• 保持主仓库的完整性

这种折中方案既解决了克隆速度问题，又避免了维护多个仓库的负担。

技术决策与未来方向

经过深入讨论，Apollo iOS团队最终决定：

1. 不创建单独的SPM专用仓库
2. 保持现有仓库结构不变
3. 探索在版本发布时附带预编译二进制
4. 建议有特殊需求的用户自行设置artifact仓库

对于使用Swift 5.7.1及更高版本的用户，可以利用Swift Package Registry功能建立自己的artifact仓库，这可能是目前最灵活的解决方案。

开发者建议

对于遇到SPM解析性能问题的开发者，可以考虑：

• 升级Xcode至最新版本(已知15.4版本有显著改进)
• 评估是否真正需要所有历史提交
• 考虑fork仓库并自行优化历史记录
• 探索Swift Package Registry等新特性

Apollo iOS团队将持续关注社区反馈，如果此问题对大量用户造成困扰，可能会重新评估更激进的解决方案。