近日，苹果宣布将用 Swift 为所有平台创建一个统一的开源 Foundation 框架实现。通过 Foundation 的原生 Swift 实现，该项目将消除框架在 C 和 Swift 之间的转换成本，从而提高性能。该项目会为服务器端应用程序提供体量更小、细化程度更高的模块选项，同时将作为统一规范的 Foundation 实现的核心。
Swift 应用的基础
Foundation 框架为 App 和其他框架提供了基础的能力，Foundation 定义的类、协议和数据类型等在整个 macOS、iOS、watchOS 和 tvOS SDK 中通用。
2016 年，Swift -corelibs- Foundation 项目启动了 Foundation 的开源 Swift 版本，即在 Foundation 开源的 C 实现上封装了一个 Swift 层。Foundation 项目团队认为，随着 Swift 的发展，该框架发展战略也需要进行调整。Swift 是由苹果开发的现代通用语言。虽然用途颇多，但最主要还是用在 iOS 和 Mac 应用程序开发上。
前苹果工程师 Chris Lattner 在 2010 年开始构建 Swift 语言时，只是作为一个业余项目去做。当时，Lattner 在使用编程语言 C++ 时遇到了挑战。“C++ 是一种复杂的语言，”Lattner 为此花费了很大力气。“C++ 和 Objective-C 都不坏，它们是环境的产物。但我们可以做得更好。”
Lattner 从 Objective-C、Rust、Haskell、Ruby、Python、C#、CLU 等语言中汲取灵感，并完成了基础架构设计。当 Lattner 意识到 Swift 可能是更好的选择时，他开始寻求资金并在苹果内组建了一个团队进行研究。之后，他便带领开发小组陆续完成语法设计、编译器、运行时、框架、IDE 和文档等相关工作。
经过多年迭代，现在根据官网数据，在编写应用程序时，Swift 相较 Objective-C 快 2.6 倍，相较 Python 2.7 要快 8.4 倍。
在 Swift 之前，构建 iOS 应用程序的主要语言是 Objective-C，但越来越多的 iOS 项目都开始用 Swift 编写。移动设备市场的持续增长也为 Swift 的持续发展提供了助力。TIOBE公布的 12 月编程语言流行指数排名中，Swift 排名 15，超过 Objective-C 的第 19 名。
除苹果外，现在 Lyft、Uber、Airbnb、Square 等公司都在使用 Swift。随着 Swift 开发需求的提升，Swift 开发者的收入也在提高。国外网站 DevJobsScanner 最近对全球超 1000 万个开发岗进行了调研，结果显示，Swift 入选了前十大高收入编程语言，排名第七。Swift 开发者的平均年薪为 11.4 万美元，但上限报价也能达到每年 23 万美元水平。
如今，几乎所有的 Swift 项目都使用了 Foundation 框架。随着 Swift 应用的更多，Foundation 框架的重要性也不言而喻。
Foundation 框架在 iOS 系统中的位置
Foundation 框架将如何发展？
Foundation 框架发展愿景中的一大重要部分，就是为服务器端应用程序提供体量更小、细化程度更高的模块选项。Foundation 团队也从模块分类开始，简单介绍了下阶段的发展思路。
模块拆分
以下是官方初步整理的模块划分思路，并非最终版本，团队也正在征求社区的反馈意见。
FoundationEssentials
这些模块类型在大多数应用程序中都有所使用，而且不存在额外的系统依赖性。此包可能依赖于 Collections 或 Algorithms 等关键 Swift 包，但后续出现的新依赖项保证会在不过多影响 Essentials 整体大小的前提下添加。
以下列出的各个类型都是在将 Foundation 打造成一个整体库，进而提供基本实用程序类、为设计模式提供先例，并在一定程度上摆脱操作系统依赖以增强可移植性。具体包括：
URL，Data，UUID，Date、DateInterval，PropertyListSerialization，JSONSerialization，PropertyListDecoder，JSONDecoder 及编码器，NotificationCenter，AttributedString，SortDescriptor，Measurement，Dimension，Unit，ProcessInfo，UserDefaults (范围可能受限，例如某些类型的域)，FileManager，FileHandle，Process，Pipe，Bundle。
考虑到语言本身的进步，部分 API 也到了需要更新升级的时候。比如，团队认为 Process 这类 API 应该使用 async/await。通过将其包含在 Essentials 包中，团队希望与社区共同推进 API 迭代。不过在短期之内，现有 API 仍将正常服务于依赖它们的项目。
FoundationInternationalization
以下类型主要强调更好地处理日期/时间，或者为用户呈现格式化数据：FormatStyle 协议和所有具体格式样式类型，Locale、Calendar、TimeZone、DateComponents，Locale-specific String extensions，CharacterSet（此 API 未来可能会重新设计或扩充，以更好地适应 Swift String），URLResource，LocalizedError，Morphology。
FoundationNetworking
FoundationNetworking 模块已经从 Foundation 中分离出来，并将继续提供相同的网络 API。团队已经确定了 Essential 类型、特别是 URL，因此下一步就是在 Swift 当中统一 FoundationNetworking 实现，主要包括 URLSession、URLRequest、URLResponse 及其他关联类型，HTTPCookie、HTTPURLResponse 及其他关联类型。
FoundationXML
FoundationXML 模块已经从 Foundation 中分离出来，并将继续提供相同的 XML 解析 API。在确定了 Essential 类型和 FoundationNetworking 之后，下一步就是在 Swift 中统一 FoundationXML 的实现，主要包括：XMLDocument、XMLDTD、XMLDTDNode、XMLElement、XMLNode、XMLParser。
FoundationObjCCompatibility
以下类型主要用于同 Darwin Foundation 或遗留代码的交叉编译，主要包括：NSObject
NSValue、NSNumber、NSError、NSNull、Geometry types、NS/CGRect、NS/CGPoint、NSEdgeInsets 等。
微模块还是单体设计？
为什么不把 Foundation 中的每个类型都拆分成单独的包，以便随时可以独立导入？团队认为最好的办法应该是，在每个模块一个包跟所有模块一个包之间达到最佳平衡。
如果将每个组件都当作单独的模块，那模块间的关系数量就会迅速增长，而且要求确保各模块间每个接口都必须稳定且公开。一旦发现本应只用于“亲密”模块的接口实际也被用在其他地方时，可能会不经意间限制团队对整体 API 接口的未来改进空间。
因此，团队决定用外部依赖项来划分模块。外部依赖项通常是二进制文件显著膨胀的根源，如果对依赖项的传递控制不当，可能导致下游客户端发生冲突。
移除的类型
在 Darwin 平台上，团队需要保持全部现有 API 接口的兼容性。但团队将新的统一实现重点放在了实用性最强的那些 Swift API 上。“这代表着一种重要的思路转变，特别是对 swift-corelibs-foundation 当初提出的 100%源兼容目标的颠覆。”团队在博客中说道。Foundation 的很多功能都被包含在了语言的直接支持内，所以新包暂时不考虑引入以下类型：
RunLoop、Lock、OperationQueue、Stream、Port、Timer 等，由结构化并发替代。
NS 前缀集合类型- 最初是出于兼容性考虑而提供，但实用性一直不大
NSCoding, NSKeyedArchiver – 由 Codable 替代
Progress - 不存在外部依赖，但与结构化并发的重合还没有完全设计好
在 Darwin 上，Foundation 框架将继续通过 C、Objective-C 和 Swift 的组合维护各个类型的实现。
结束语
该消息发布后，社区很多开发者表示很开心看到这样的变化。开发者 Joakim_Hassila 留言道：“作为一个明确表示避免使用 Foundation 的人，我只想发表一个简短的正面说明——这看起来是一种非常实用的方法，并且基于可能的外部依赖关系构建模块很有意义。”
但是，这只是一个开始。Foundation 团队还需要为开发者解决更多技术细节上的问题，还有解答诸如哪个基金会负责、iOS/macOS 应用程序是否会使用这个新的 Swift Foundation 等项目后续发展上的疑问。
参考链接：
https://www.swift.org/blog/future-of-foundation/
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论