Apple重寫並開源了Foundation框架,網友:你用它做iOS應用嗎?

作者|核子可樂楚星娟

最近,Apple宣佈將使用Swift為所有平臺創建一個統一的開源Foundation框架實現。

使用Foundation的原生Swift實現,該項目通過消除在C和Swift之間切換框架的開銷來提高性能。

該項目為服務器端應用程序提供了更小、更詳細的模塊選項,並作為統一的Foundation實現的核心。

Swift應用程序的基礎

Foundation框架為應用程序和其他框架提供基本功能。

Foundation定義的類、協議和數據類型對於macOS、iOS、watchOS和tvOSSDK是通用的。

2016年,Swift-corelibs-Foundation項目推出了一個開源的Swift版本的Foundation,它在Foundation的開源C實現之上封裝了一個Swift層。

基金會項目組認為,隨著Swift的發展,框架開發策略也必須進行修改。

Swift是Apple開發的一種現代通用語言。

雖然它有很多用途,但主要用於iOS和Mac應用程序開發。

當前Apple工程師ChrisLattner於2010年開始構建Swift語言時,他將其作為副項目進行。

當時,Lattner對編程語言C++提出了挑戰。

『C++是一門復雜的語言,』拉特納艱難地說。

『C++和Objective-C都不錯,它們是環境的產物。

但我們可以做得更好』

Lattner從Objective-C、Rust、Haskell、Ruby、Python、C#、CLU等語言中汲取靈感,最終確定了基礎設施設計。

當Lattner意識到Swift可能是更好的選擇時,他申請了資金並與Apple組建了一個研究團隊。

隨後,他帶領開發團隊完成了語法設計、編譯器、運行時、框架、IDE和文檔。

經過多年的迭代,據官網介紹,Swift在編寫應用程序時比Objective-C快2.6倍,比Python2.7快8.4倍。

在Swift之前,構建iOS應用程序的主要語言是Objective-C,但越來越多的iOS項目是用Swift編寫的。

移動設備市場的持續增長也推動了Swift的不斷發展。

在TIOBE12月公佈的編程語言流行指數中,Swift排名第15,超越了Objective-C的第19位。

除了Apple,Lyft、Uber、Airbnb、Square等公司現在都在使用Swift。

隨著Swift開發需求的增加,Swift開發者的收入也隨之增加。

國外網站DevJobsScanner最近對全球超過1000萬個開發崗位進行了調查。

結果顯示,Swift在十大入門級編程語言中排名第七。

Swift開發人員的平均年薪為114,000美元,但上限為每年230,000美元。

今天,幾乎所有Swift項目都使用Foundation框架。

隨著越來越多的Swift應用,Foundation框架的重要性不言而喻。

Foundation框架在iOS上的位置

基金會的框架將如何發展?

Foundation框架開發願景的一個重要部分是為服務器端應用程序提供更小和更詳細的模塊選項。

基礎組也開始了模塊分類,並簡要介紹了下一階段的開發思路。

共享模塊

以下為官方模塊分發思路,並非最終版本,團隊也在征求社區反饋。

基礎要領

大多數應用程序都使用這些模塊類型,並且沒有額外的系統依賴性。

這個包可能依賴於重要的Swift包,例如Collections或Algorithms,但保證添加新的依賴項不會對Essentials的整體大小造成太大影響。

下面列出的每個類型都基於Foundation作為一個整體庫,它提供重要的實用程序類,提供設計模式的先例,並提供一些操作系統依賴性的自由以提高可移植性。

具體包括:

URL、Data、UUID、Date、DateInterval、PropertyListSerialization、JSONSerialization、PropertyListDecoder、JSONDekoeder和Encoder、NotificationCenter、AttributedString、SortDescriptor、Measurement、Dimension、Unit、ProcessInfo、UserDefaults《范圍可能有限》。

、文件句柄、進程、管道、捆綁包。

鑒於語言本身的進步,一些API也到了需要更新的地步。

例如,團隊認為像Process這樣的API應該使用async/await。

通過將其包含在Essentials包中,該團隊希望與社區合作推動API的迭代。

然而,在短期內,當前的API將繼續照常為依賴它們的項目提供服務。

基金會國際化

以下類型主要側重於更好地處理日期/時間或向用戶呈現格式化數據:FormatStyle協議和所有具體格式類型、Locale、Calendar、TimeZone、DateComponents、特定於Locale的String擴展、CharacterSet《此API可能會添加到未來重新設計或擴展以更好地適應SwiftString)、URLResource、LocalizedError、Morphology。

基金會網絡

FoundationNetworking模塊已經從Foundation中分離出來,並將繼續提供相同的網絡API。

團隊已經定義了必要的類型,尤其是URL,所以下一步就是統一Swift中的FoundationNetworking實現,主要包括URLSession、URLRequest、URLResponse等相關類型,HTTPCookie、HTTPURLResponse等相關類型。

基礎XML

FoundationXML模塊已經從Foundation中分離出來,並將繼續提供相同的XML解析API。

定義了Essential類型和FoundationNetworking之後,下一步就是在Swift中統一實現FoundationXML,主要包括:XMLDocument、XMLDTD、XMLDTDNode、XMLElement、XMLNode、XMLParser。

FoundationObjCC兼容性

以下類型主要用於與DarwinFoundation或遺留代碼的交叉編譯,主要包括:NSObject

NSValue、NSNumber、NSError、NSNull、幾何類型、NS/CGRect、NS/CGPoint、NSEdgeInsets等。

微模塊還是單片設計?

為什麼不將每種類型的Foundation拆分成一個單獨的包,以便它們可以隨時獨立導入?該團隊認為,最好的方法是在每個模塊一個包和所有模塊一個包之間取得最佳平衡。

如果每個組件都被視為一個單獨的模塊,模塊之間的關系數量會迅速增加,並且模塊之間的每個接口都必須是穩定和公共的。

發現一個隻應在『親密』模塊中使用的接口實際上正在其他地方使用,可能會無意中限制團隊未來改進整個API的空間。

因此,團隊決定拆分具有外部依賴的模塊。

外部依賴項通常會導致嚴重的二進制文件膨脹,並且如果依賴項傳遞沒有得到適當控制,可能會導致與下遊客戶端發生沖突。

刪除類型

在Darwin平臺上,團隊必須保持與所有現有API的兼容性。

但該團隊將新的統一實施重點放在最有用的SwiftAPI上。

『這代表了思想上的一個重要轉變,尤其是與swift-corelibs基金會最初的100%源兼容性目標相比,』該團隊在一篇博文中表示。

Foundation的很多功能都直接包含在語言支持中,所以以下類型暫時不考慮在新包中實現:

RunLoop、Lock、OperationQueue、Stream、Port、Timer等被結構化並發替代。

NS前綴的集合類型——最初是為了兼容性,但實用性有限

NSCoding、NSKeyedArchiver-替換為Codable

進展-沒有外部依賴,但與尚未完全設計的結構化並發重疊

在Darwin中,Foundation框架繼續使用C、Objective-C和Swift的組合來維護單一類型的實現。

結論

消息公佈後,不少社區開發者表示很高興看到這樣的變化。

開發者Joakim_Hassila評論道:『作為一個專門回避基礎的人,我隻想做一個簡短的正面說明——這似乎是一種非常實用的方法,基於可能的外部依賴關系構建模塊非常有用。

意義』

然而,這僅僅是開始。

Foundation團隊還需要為開發者解決更多的技術細節,以及回答有關項目進一步發展的問題,例如由哪個基金會負責,iOS/macOS應用程序是否會使用這個新的SwiftFoundation。

推薦鏈接: