Swift vs. Objective-C：將來看好 Swift 的十個理由

是時候使用易入手又全面的Swif語言爲iOS和mac OS X作應用開發了。

雖然編程語言不會那麼容易消逝,但堅持衰落範例的開發小組正在這麼作。若是你正爲移動設備開發應用程序,而且你尚未研究Swift，那麼注意:當Swift涉及到Mac、iPhone、ipad、Apple Watch和將來設備的應用開發時，它不只會排擠掉Objective-C，並且還會取代在Apple平臺中作嵌入式開發的C語言。

因爲幾個關鍵特性,在將來幾年，Swift有很大潛力成爲創造身臨其境的、響應迅速的、面向用戶的應用程序的實際編程語言。

蘋果公司彷佛在Swift上還有更大的目標。它的編譯器性能和開發語言都被優化了，蘋果公司在Swift的文檔中暗示Swift被設計成小能（顯示）「hello,world」，大能（完成）整個操做系統。蘋果公司還沒把這門語言的目標說全，Xcode6，Playgrounds和Swift的推出就一塊兒揭露蘋果的意圖：更簡單的應用開發，更易用的開發工具鏈。

這是從如今起使用Swift工做，並走在比賽前列的10個緣由。

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 被加載到內存中的初始大小，由於外部代碼只在被用到時纔會被連接進來。

移動應用程序或者是 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。

英文出處：PC Advisor

英文鏈接：http://www.pcadvisor.co.uk/news/software/3611295/swift-vs-objective-c-10-reasons-the-future-favors-swift/

譯文出處：oschina

譯文連接：http://www.oschina.net/translate/swift-vs-objective-c-10-reasons-the-future-favors-swift