Swift語言未來的發展

標籤：程式設計語言   關鍵詞   運算式   表現力   開發人員   

1. Swift 容易閱讀

如你所能預計到的一門基於 C 構建的語言，Objective-C 身上所有的毒疣子都有。為了將關鍵詞和類型同C的類型作區分，Objective-C 使用@符號引入了新的關鍵詞。因為 Swift 不是基於C構建的，它同意了所有的關鍵詞，並將 Objective-C 類型和對象相關的關鍵詞前面大量的@符號移除了.

Swift 丟棄了遺留下來的約定。因而你不再需要行尾的分號，以及 if/else 語句中圍繞條件運算式的括弧。另外一個大變化就是方法的調用不再互相嵌套成中括弧的深坑 -- 再見吧，[[[ ]]]。Swift 中的方法和函數的調用使用行業內標準的在一對括弧內使用逗號分隔的參數列表。這樣做的結果就是一種帶有簡化了句法和文法的更加乾淨有表現力的語言。

除了其它當代流行的程式設計語言之外，Swift 更像是自然的英語了。這種可讀性是的其很容易能被其它來自 JavaScript，Java，Python，C#，以及 C++ 的開發人員納入到他們的工具鏈之中 -- 一點也不像 Objective-C 這隻笨笨的黃小鴨。

2. Swift 更易於維護

曆史遺留問題會讓 Objective-C 越來越倒退 -- C 沒有演化的話，這個語言也就跟著無法進行演化。C 需要程式員維護兩套代碼檔案，以最佳化構建的時間以及建立可執行 app 的效率, 這種需要延續到了 Objective-C 上。

Swift 丟掉了對著倆檔案的要求。Swift1.2 中 Xcode 和 LLVM 編譯器可以自動計算出以來並執行增量構建。如此，將內容清單 (標頭檔) 同內容主體（實現檔案）相分離。Swift 將 Objective-C 標頭檔(.h) 和實現檔案 (.m) 合并成了一個代碼檔案 (.swift）。

Objective-C 的兩份檔案系統存在強加給程式員的額外工作 -- 而這些工作會讓程式員難免分心而不能顧全大局. 在 Objective-C 中你不得不手動去同步檔案之間的方法名稱和注釋, 有時候要寄希望於一個約定好的標準，不過除非團隊的規矩和代碼審查制度到位，否則這是不會為你提供什麼保障的。

Xcode 和 LLVM 編譯器可以在幕後做一些工作來減輕程式員的工作負擔. 使用 Swift, 程式員可以少做些費腦力的記憶性工作，從而能在建立app邏輯的工作上面贏得更多的時間. Swift 為我們程式員裁掉了那些樣板式的工作，同時對代碼、注釋以及所要支援的特性的品質都有所提升。

3. Swift 更加安全 

Objective-C 有意思的一個方面是指標 -- 特別是 nil (null) 指標 -- 它們被處理的方式. 在Objective中-C, 如果你調用方法的是一個值為 nil (未初始化)的指標變數，什麼事情都會不發生. 運算式或者一行操作變成了一項空操作（no-operation (no-op)）, 而這就使得其看起來會有不會奔潰的好處, 但其實它已經變成了一個巨大的bug來源. no-op 會導致不可預測的行為, 這是程式員在嘗試找出並修複某種隨機的奔潰，或者要停止反常的行為時所要面對的敵人。

在Swift代碼中的可選類型使得一個nil可選值的可能性變得非常的明確, 這意味它能在你寫下一段糟糕的代碼時會產生一個編譯器錯誤. 這就建立了一種短程反饋的迴圈，可以讓程式員帶著目標去寫代碼. 問題在代碼被寫就時就可以被修複, 這大大節省了你要在修複有關來自 Objective-C 指標邏輯的bug時需要耗費的時間和金錢。

在Objective-C的傳統中, 如果某個值返回自一個方法, （使用注釋以及方法的命名規範來）說明指標變數被返回的行為是程式員的責任.在 Swift 中, 可選類型和實值型別使得方法定義中值是否存在，或者其有可能是可選的（即值可能存在也可能為nil），這些問題都是很明確清楚的。

為了提供對行為的預測，Swift會在nil可選值被使用時觸發一次運行時崩潰。 崩潰提供的就是一種一致的行為，它能減輕修複bug過程的壓力，因為它會直白地強制讓程式員修複好這個問題. Swift 運行時崩潰的時候會停在nil可選值被使用到的那行代碼處。這就意味著bug能更早的被修複，並能在Swift代碼中被完全的規避掉。

4. Swift 的記憶體管理是統一化的

Swift 以一種 Objective-C 從未有過的方式進行了統一。對自動引用計數 (ARC) 的支援是在整個過程化的和物件導向的代碼路徑上完成的。在。Objective-C。中, ARC 在 Cocoa API 和物件導向代碼中獲得支援；然而它並不支援過程式的 C 語言代碼和像 Core Graphics 這樣的 API。這意味著在使用 Core Graphics API 以及其它 iOS 上的底層 API 時，記憶體管控的處理都是程式員的責任。程式員在 Objective-C 上會遇到的大量記憶體溢出問題在 Swift 上是不可能的。

程式員不應該為他或她建立的數字對象去考慮記憶體的問題。因為 ARC 在編譯時間就處理了所有的記憶體管理事務, 記憶體管理所有消耗的腦力現在可以被用來專註於核心的應用邏輯以及新的功能特性。因為 Swift 中的 ARC 在過程式的和物件導向的代碼中都能起作用，它也就不再需要程式員進行心理上的環境切換了, 即使是他們在編寫要觸及底層API的代碼時也不需要 -- 這在目前版本的 Objective-C 中就是一個實實在在的問題。

自動和高效能的記憶體管理是一個已經被解決的問題，而蘋果公司已經證明了這個問題的解決可以提高生產力. 另外一個副作用就是 Objective-C 和 Swift 不會像 Java，Go 或者 C# 那樣遇到垃圾收集器針對沒有被使用的記憶體運行清理作業的情況. 這對於那些將會被用於相應圖形和使用者輸入的程式設計語言而言就是一個非常重要的要素, 特別是在諸如 iPhone、Apple Watch 以及 iPad 這樣的(如果響應滯後就會讓使用者感知上以為應用是壞的)觸控螢幕裝置上。

5.Swift代碼更少

Swift 減少了重複性語句和字串操作所需要的代碼量。在 Objective-C 中, 使用文本字串將兩塊資訊組合起來的操作非常繁瑣。Swift 採用當代程式設計語言的特性，比如使用“+”操作符將兩個字串加到一起，這在 Objective-C 中是沒有。像這樣支援對字元和字串的組合對於任何要在螢幕上向使用者展示文本的程式設計語言的基礎設施。

Swift中的類型系統減少了代碼語句的複雜性--作為編譯器可以理解的類型。比如，Objective-C要求程式員記住特殊字元標記（%s，%d，%@）並且提供了一個用逗號分隔的變數來代替每個標記。Swift支援字串插入，這就消除了需要記住的標記和允許程式員直接插入變數到面向使用者的字串中，比如標籤或者按鈕的標題。這類推理系統和字串插入減少錯誤來源在Objective-C中都是很常見的。

在Objective—C中，搞亂了順序或者使用了錯誤字串標記會造成app崩潰。這裡，Swift再次將你從反鎖的工作中解放出來，翻譯成更少要編寫的代碼（代碼現在已經不容易出錯）因為它的對處理文本字串和資料的內嵌支援。

6. Swift 更快

刪除遺留下來的C語言約定大大提升了引擎蓋之下Swift的效能. Swift代碼效能的基準測試一直都瞄向蘋果公司所致力於的Swift運行app邏輯的速度提升。

根據靈長類動物研究所（Primate Lab）——時下流行的 GeekBench 效能工具的創造者——的調查, 2014年12月中使用曼德爾布羅演算法（Mandelbrot algorithm）進行計算密集型任務的效能上，Swift已經逼近C++的表現了。

在2015年2月，靈長類動物研究所發現 Xcode 6.3 測試版提升了Swift在GEMM演算法上的效能 -- 這是一種受制於記憶體限制的演算法，需要對大型數組進行順序訪問 -- 有1.4倍. 初始的FFT實現 -- 這是一種會對大型數組進行隨機訪問的受限於記憶體的演算法-- 擁有2.6倍的效能提升。

通過應用最佳實務，可以觀察到更進一步的效能提升, 結果是 FFT 演算法上8.5倍的效能 (差上 C++ 1.1倍)。這些改進也使得 Swift 在曼德爾布羅演算法上實際超越了 C++ 1.03 倍。

Swift 在 FFT 和曼德爾布羅演算法上幾乎能與 C++ 比肩。根據 Primate Labs 的研究發現，GEMM 演算法的效能表現說明 Swift 編譯器還不能實現 C++ 編譯器支援的向量代碼 -- 所以 Swift 的下一個版本可能會比較容易的獲得一次效能提升。

7.開源項目中更少的名稱衝突 

Objective-C 代碼中一直令人很困擾的問題就是缺乏對命名空間的正式支援, 它是 C++ 處理檔案名稱衝突的解決方案。當名稱衝突發生在 Objective-C 中時，就會是一個連接器錯誤，會導致 app 無法運行。解決的辦法倒是有，可它們都有潛在的隱患。一般的約定是使用兩到三個字母首碼來區分編寫的 Objective-C 代碼, 比方說，通過 Facebook 來展現出你自己的代碼。

Swift 提供了隱含的命名空間，允許相同的代碼檔案存在於多重專案，而不會造成構建失敗，或者需要向 NSString (Next Step -- Steve Jobs 被 Apple 炒魷魚之後建立的公司) 或者 CGPoint (Core Graphics)這樣的名稱。最終，Swift 中的這一特性使得開發人員更加的有生產力，並且也意味著他們沒必要再做 Objective-C 需要的備忘式記憶工作。在簡單如 Array，Dictionary 以及 String 這樣的名字中你可以看到 Swift 的影響力，而不是脫胎於缺少命名空間的 Objective-C 中的 NSArray、NSDictionary 以及 NSString。

Swift的命名空間是基於一份代碼檔案所屬的目標位置。這就意味可以使用命名空間標識來區分出不同的類和值。Swift 中的這個改變很大，它極大的方便了將開發員項目、架構以及庫整合到你代碼中來的操作。命名空間使得在整合開源項目時，不用擔心來自不同軟體公司的同名代碼檔案會發生衝突。現在 Facebook 和蘋果公司可以同時使用一個叫做 FlyingCar.swift 的對象代碼檔案，不會有任何錯誤或者失敗。

8. Swift 支援動態庫

Swift 中沒有受到足夠重視的一個最大的問題是靜態庫向動態庫的切換，其在主要發布版（iOS8，iOS7等等）會被更新。動態庫是可以被連結到 app 的可執行代碼塊。這一特性可以讓現有的 Swift 應用可以連結到隨著時間推移所產生的更新版本的 Swift 語言。

開發人員將 app 連同庫檔案一併提交，它們都用開發人員認證打上了數位簽章，以確保完整性 (你好, NSA)。這就意味著 Swift 可以比 iOS 更快地進化，對於一種現代程式設計語言而言這是必要的。對庫檔案的修改可以被全部引入 AppStore 上某個 app 的最新更新中，一起運行起來都如此簡單。

動態庫在 iOS 上從未受到支援，直到 Swift 和 iOS 8 的發布，儘管已經在 Mac 獲得支援很久了。動態庫處在應用可執行檔之外，不過會被包含在從 AppStore 上下載的應用程式套件中。它減小了 app 被載入到記憶體中的初始大小，因為外部代碼只在被用到時才會被連結進來。

行動裝置 App程式或者是 Apple Watch 上的嵌入式應用所具有的消極式載入能力，將提升應用面向使用者的感知效能。這是使得 iOS 生態系統更具感官上的響應性的區別之一。蘋果公司原先只專註於運行時載入資料和資源，現在代碼的編譯和連結也可以在運行時進行。運行時載入減少的等待時間，直到資源需要被用於展示在螢幕上時，才會被載入進來。

Swift 中的動態庫讓程式設計語言的修改升級比以往更快的傳播出去成為了可能。使用者不在需要等待指定的iOS 版本發布才能享受到 Apple 引入 Swift 中的效能和可靠性改進。

9. Swift Playgrounds 鼓勵互動式編碼 

Swift 新引入的 Playgrounds 是有經驗的開發人員的福音。Playgrounds 的靈感來自於蘋果公司前僱員 Brett Victor 的工作。Playgrounds 可以讓程式員用比如說5到20行代碼來測試一種新的演算法或者圖形程式，不用去建立一個完整的 iPhone 應用。

蘋果公司已經將內聯代碼執行操作加入到了 Playgrounds 中，以協助程式員建立代碼塊或者編寫某種演算法時獲得反饋。這樣的反饋迴圈可以提升代碼編寫的速度，因為傳統程式員所需要的心智模型已經為 Playground 的資料視覺效果形式所替代。編程是一個反覆的過程，任何可能壓力上的減輕或者創造的補充都會使得開發人員更具生產力，並能釋放出他們的精力來解決更大的問題，而不是死盯著傳統編譯器來增加程式員的繁瑣細節。

注意：據我教授新手程式員的經驗，Playgrounds 對於入門者而言不會像對有經驗的程式員那麼有用。如果只是簡單的展示 Swift 中一個變數是如何工作的，Playggrounds 顯然不能對協助新手理解對於一個浮點指標變數與一個整型變數的需要。當你要展示一個能記憶你最後在 Facebook 新聞提要中的滾動位置時，這種需要才會變得明顯。對於新手而言，“為什麼”這個問題只能用一個可以運行樣本：也就是一個 iPhone 應用，來回答。

10. Swift是一個你可以影響的未來 

Objective-C 沒有任何出路，你將不會看到它發生改變，我們要感謝 Swift 的引入. 一些 Swift 特性可能會整合到 Objective-C, 但 Objective-C 的 C 語言遺留物還是註定了它只能吸收那麼點 Swift 的好東西。

Swift 向開發人員社區提供了一個直接的方式，去影響一門語言，它將會被用於應用的建立，嵌入式系統（如果蘋果公司向第三方的嵌入式架構和晶片進行了授權）以及像 Apple Watch 這樣的裝置。

蘋果公司專註於提供最佳的消費者體驗，而且只構建值得注意的功能特性. 隨著 Xcode6.3 中 Swfit1.2 的發布，蘋果公司已經利用流行的 Apple Bug Reporter 工具修複了數以千計的 bug。支撐 Swfit 開發和改進的團隊對於如何提升語言，以更好的支援那些使用 Swift 構建應用和系統的開發社區高度興趣。

Swift:更易上手，特性豐富的語言

從丟棄 Objective-C 賴以構建的傳統語言開始，一大堆變化讓 Swift 超越了 Objective-C。Apple 並沒有丟棄 Cocoa—— 這是他們的用於建立蘋果風格體驗的 API 和程式碼程式庫——而是提供了一個完整功能的等價物，使得同支援 Force Touch 或者 Taptic Feedback 這類特性的新 API 互動起來更加簡單。

許多舊的設計決定都旨在讓編譯器的設計更加容易。Swift 則專註於通過拋棄傳統的緊張心理和編碼實踐，來使得應用開發人員的工作更加輕鬆。隨著現代編譯器的發展，少量的代碼可以表示更多的資訊。

使用 Swift，程式員只要維護原來一半量的代碼檔案，手動的代碼同步工作為零，標點輸入出錯的機率也遠遠低於以前 -- 這樣就能騰出更多的時間寫高品質的代碼。通過使用可選類型 —— 一種針對返回或不傳回值的編譯時間安全機制，而傳回值是同步操作、網路失效時無效的使用者輸入以及資料驗證錯誤發生時普遍會遇到的問題。ARC 在 Swift 中對過程式 C 風格的代碼，還有蘋果公司 Cocoa 架構使用的物件導向代碼都進行了統一。

開發人員會發現他們寫的 Swift 比較少，而現代的程式設計語言特性則支援著他們行行代碼都保持更多的可讀性。隨著其不斷髮展，Swift 會保持整個蘋果公司的生態系統在編程領域的先進性，這都要感謝 iOS 和 Swift 中對動態庫的支援。開源項目、第三方 SDK 以及架構可以更容易的整合進家居自動化裝置以及社交服務中，不會有編譯時間的增長。Swift 在某些演算法的速度上幾乎與 C++ 一樣的快，而最新版的Xcode 6.3 和 Swift 1.2 則在這一起跑線上把目標指向更多的效能最佳化。

再加上 playgrounds 和 swift 允許用一個新的方法來開發視覺反饋協助使用內聯資料視覺效果演算法程式，讓一個較短的反饋迴路和圖形描述迭代解碼過程更容易開始。

最終，Swift 是一個平易近人的全功能的程式設計語言，未來將允許開發人員不僅構建 app 還支援嵌入式系統比如新的低功耗 apple watch。

7月29日扣丁學堂郭老師帶你掀起蘋果的手腕革命--Apple Watch！

本文出自 “扣丁學堂” 部落格，請務必保留此出處http://codingke.blog.51cto.com/10519550/1677460

Swift語言未來的發展