返回目录：文件问题
概述
Swift Package Manager（简称SPM），是Apple官方提供的软件包管理器，类比如Ruby的RubyGems, Python的pip。开源框架里知名度较高的SwiftyJSON、SQLite.swift等都已支持SPM集成。
WWDC18专门开了一个Session介绍了SPM的内部结构、基本使用及设计理念，并介绍了之后即将支持的一些新特性。
为什么要使用SPM
最重要的一点：官方支持
官方支持，保证了所有Swift软件包的可信来源和通用标准。同时，SPM作为Swift项目的一部分，Apple在Swift工具链中提供了更强大的原生支持。
跨平台构建
SPM是一个跨平台方案，SPM提供了完整的构建环境，能在不同平台上来构建和分发Swift软件包。
和Swift更紧密的关系
SPM采用Swift编写，可以使用Swift自身的强大特性，并且与Swift的核心库紧密联系。
SPM有更先进的设计
这个我们在后面章节展开。
SPM的社区影响范围日益增长
作为Swift开源项目的一部分，社区的热度不断升温，CocoaPods的众多核心成员也参与架构设计，影响力越来越大。
SPM基本用法
SPM的基本概念可参见官网描述。
常用命令
- swift build: 编译Package。
- swift run: 编译Package里的可执行文件并运行。
- swift test: 运行Package里的单元测试。
- swift package: 这个命令的用法很多，Package的初始化、修改、更新、resolve检查、编译选项指定等。
内部结构
对于一个Package来说，主要分为三部分，Target、Products、Dependencies
Products
Products可以理解为Package输出的形态。对比与Cocoapods只能以静态库/动态库形式，SPM还可以输出为可执行文件。
Target
Target理解为包含多个文件的一个模块，target之间是可以有依赖关系，同时，输出的Products也会依赖一个或多个target。
Dependencies
Dependencies描述了当前的package需要依赖其他package。
一个典型的Package目录如下：
其中Package.swift的定义：
Sources目录下的文件不需要显示声明，SPM会自动导入，Dependencies依赖了两个外部Package， 其中Target的依赖既有Package内部Target的依赖也有外部Target的依赖。
Package.resolved被放在顶层包的一个文件中，类似于许多软件管理器lock的实现，swift使用该文件来做依赖关系解析。在执行swift build swift test swift package generate-xcodeproj命令时，默认会隐式调用swift package resolve检查依赖版本是否正确。
Package.resolved的详细设计思路可以参考提案。
SPM的设计思想
SPM的设计思想也遵循了Swift的一些设计思想：
安全: SPM的编译环境是在一个独立的沙盒里，无法任意执行命令和脚本。
快速: 得益于新的llbuild构建系统，SPM可以支持数百万节点的关系依赖图。
表现力: 采用Swift作为SPM的配置描述语言。
下图描述了Apple对SPM的大体思想
Configuration
相对于Cocoapods等笨重啰嗦的DSL语法，SPM采用了Swift来作为SPM的配置描述语言，大大降低了开发人员的学习成本同时保留的Swift强大的语言特性，并可以得到 Swift相关工具的支持。
Dependencies
SPM使用git tag来做版本依赖，格式上遵循Semantic Versioning.
Semantic Versioning（Semver）: 是为了解决软件包管理器中著名的Dependency hell问题而设计的一套简单的规则和条件来约束版本号配置的解决方案。
Semver规定格式里分为：主版本号.次版本号.修订号，版本号递增规则如下：
1. 主版本号：当你做了不兼容的 API 修改。
2. 次版本号：当你做了向下兼容的功能性新增。
3. 修订号：当你做了向下兼容的问题修正。
Semver同时支持语义化关键字来实现版本控制，需要对Semver更深入了解的读者可参考官网介绍。下图就是一个采用Semver版本控制的Package依赖树结构。
Building
SPM采用了swift-llbuild ,一个并行、高效、增量编译的构建系统作为其构建引擎。目前Xcode9也已集成，用作对LLVM、Clang及Swift的构建。同时，因为独立沙盒的构建环境，SPM提供了很强的安全性。
Workflow Features
如果你的某个软件包还处于开发模式下，tag的集成方式很不方便，类似于Cocoapods的做法，SPM也会提供分支依赖和本地依赖做法。
Tools Evolution
和Cocoapods一样，当我们的软件包需要依赖特定的swift版本，需要在配置描述里显示声明。声明的枚举类型如下
例如指定版本为4.0
SPM的未来新特性
- 与其他工具的更好的集成
- 使用libSwiftPM和libSyntax对SPM做更灵活的扩展实现。
- 发布和部署
- 目前的发布流程依赖于手动建立git tag, git push origin [tag name] 的做法，之后会有更自动化的工具实现。
- 支持复杂的Packages
- 对资源文件的支持，更复杂的编译设置，和扩展的编译工具等
- 更好的管理Package生态
- 跨平台的沙盒隔离、更安全的校验方案，支持fork操作和搜索索引等。
预见到等到合适的时机，SPM成为Swift Package的标准管理工具是大势所趋。
参考：
https://developer.apple.com/videos/play/wwdc2018/411/
https://swift.org/blog/swift-package-manager-manifest-api-redesign/
https://medium.com/xcblog/apple-swift-package-manager-a-deep-dive-ebe6909a5284