各位親愛的iOS與OS X應用程序開發(fā)人員，如今正是將編程陣地轉移至更為親民、功能更為全面的Swift的最佳時機。

一般而言，編程語言往往不會輕易消亡，不過由相關廠商大力推動的更新換代舉措則不在此列。如果大家從事移動設備應用程序開發(fā)工作，但卻還沒體驗過Swift，那請注意啦：Swift不僅僅是一種希望在Mac、iPhone、iPad、Apple Watch以及其它未來設備上取代Objective-C的新型編程語言，它同時也將在蘋果平臺上一舉取代C語言對嵌入式編程的統治。

得益于自身的多項關鍵性特色，Swift正迅速成為我們在未來幾年中創(chuàng)建沉浸式、響應式、面向消費者的應用程序時不容忽視的優(yōu)先性編程語言選項。

蘋果公司似乎為Swift制定了一項宏偉的發(fā)展目標。該語言針對編譯器性能以及語言開發(fā)需求作出了諸多優(yōu)化，而且蘋果公司在Swift的說明文檔中暗示稱該語言“在設計思路上充分考慮到規(guī)模化需要，從‘你好，世界’到完整的操作系統皆可輕松應對”。盡管蘋果方面目前還沒有明確指出該語言的設計目標，但Xcode 6、Playgrounds再加上Swift的陸續(xù)出臺標志著蘋果公司希望讓應用程序開發(fā)工作變得更加輕松，同時這套體系與任意其它開發(fā)工具鏈的對接也將變得簡單便捷。

在今天的文章中，我們將立足于十大理由，了解選擇Swift作為首選編程方案所帶來的具體收益。

1. Swift代碼更易于閱讀

Objective-C幾乎讓大家對于一款以C為基礎建立起的編程語言所抱有的一切預期及希望都落了空。為了能夠將自身關鍵字與類型設置與C語言作出區(qū)分，Objective-C引入了@符號作為新的關鍵字標記。由于Swift并非以C語言為建立基礎，因此其能夠將所有關鍵字加以統一，同時取消了原本在每種Objective-C類型或者與對象相關的關鍵字中的@符號。

Swift徹底丟棄了其前身的大量遺留設定。因此，大家已經沒必要再保證每一行代碼以分號結尾，或者在if/else語句當中利用括號將條件表達式給括起來。另一大重要變更在于，Swift中的方法調用不再相互嵌套，這就讓我們從可怕的中括號地獄中解脫了出來——再也不見了，[[[ ]]]。Swift中的方法與函數調用采用了業(yè)界標準化的，在圓括號內以逗號分隔參數列表的作法。結果就是，我們如今擁有了一套更為簡潔、更富于表現力的編程語言，并能夠享受其中更為簡單的語法表達方式。

Swift的代碼內容與英語這一自然語言非常接近，或者說比目前其它主流現代編程語言相比更為接近。這種可讀性使原本使用Javascript、Java、Python、C#以及C++等語言的程序員能夠更輕松地將Swift納入其工具鏈當中——而不像當初的丑小鴨Objective-C那么難對付。

2. Swift代碼易于維護

這種繼承屬性正是Objective-C在發(fā)展中遭遇拖累的主要原因——如果C語言沒有進化，那么Objective-C也將無法進化。C語言要求程序員同時維護兩個代碼文件，從而改善構建時間并提高應用程序創(chuàng)始的執(zhí)行效果，而這一要求也被Objective-C原原本本地繼承了過來。

Swift語言則消除了這種雙文件要求。在Swift 1.2版本中，Xcode與LLVM編譯器已經能夠自動判斷出關聯性并執(zhí)行增量構建。如此一來，將內容表（也就是頭文件）從主體（也就是執(zhí)行文件）中剝離出來的任務已經徹底不復存在。Swift將Objective-C的頭文件（即.h文件）與執(zhí)行文件（即.m文件）整合成了單一代碼文件（即.swift文件）。

Objective-C的雙文件系統無疑給程序員帶來了額外的工作負擔——而這讓程序員們更難從大局角度出發(fā)完成開發(fā)任務。在Objective-C中，我們必須以手動方式在兩個文件之間進行方法名及注釋的同步工作，從而讓二者使用同一套標準表達，但除非開發(fā)團隊已經擁有現成的規(guī)則及代碼審查機制、否則這一目標根本得不到保障。

Xcode以及LLVM編譯器能夠在幕后起效以減少程序員的實際工作量。而在Swift當中，程序員幾乎用不著再為上述任務所煩惱，從而把更多精力及時間用于創(chuàng)建應用程序邏輯。Swift簡化了樣板工作、提升了代碼及注釋內容的質量，同時帶來更多功能支持能力。

3. Swift安全性更高

Objective-C語言的一大有趣之處在于對指針——特別是nil（也就是null）指針——的處理方式。在Objective-C當中，如果大家嘗試利用某個為nil（即未初始化）的指針變量調用一項方法，則不會起到任何效果。該表達式或者代碼行將因此變成無操作（no-op）內容，盡管其不至于導致意外崩潰狀況的出現，但卻一直是應用程序中各類bug的主要根源。一條no-op往往會導致不可預知的行為，而這正是程序員們在努力尋找并修正隨機崩潰或者中止意外狀況時所面臨的頭號大敵。

可靠類型的出現讓無操作值在Swift代碼中的可能后果變得非常明確，這意味著一旦大家編寫出糟糕的代碼、其將直接引發(fā)編譯器錯誤。Swift借此創(chuàng)建出一套簡短的反饋循環(huán)，并允許程序員根據自己的意圖進行編碼。在代碼編寫的過程中、相關問題就能夠同時得到解決，而這顯然會大大降低我們在bug修復工作中所投入的時間及精力——特別是與Objective-C指針邏輯相關的bug。

從傳統角度看，在Objective-C當中，如果某個值返回自某個方法，那么程序員就需要負責在文件中記錄下該指針返回變量的行為（利用注釋以及方法命名規(guī)則）。而在Swift中，可選類型及值類型的存在使我們能夠很輕松地通過方法定義了解到該值是否存在或者其是否屬于潛在的可選項（即該值可能存在或者可能為nil）。

為了提供具備可預測性的行為，如果某個nil可選變量被使用、Swift會觸發(fā)一項運行時崩潰。這一崩潰會帶來一致性行為，從而簡化了整個bug修復過程——因為這迫使程序員需要立即對該問題進行修復。此類Swift運行時崩潰將阻止對應代碼行在出現nil可選變量被使用后繼續(xù)運行的狀況。這意味著該bug必須盡快得到修復，或者被徹底被排除出Swift代碼。

4. Swift在內存管理方面擁有統一化特性

Swift能夠以Objective-C所無法達到的方式實現自身語言的高度統一。Swift對自動引用計數（即Automatic Reference Counting，簡稱ARC）的支持能力可以完全涵蓋面向過程與面向對象的代碼路徑。在Objective-C當中，ARC只能夠在Cocoa API以及面向對象代碼內部得到支持; 除此之外，其無法作用于C代碼過程以及Core Graphics等API當中。這意味著程序員在使用由iOS所提供的Core Graphics API以及其它低級API時，必須自行負責內存管理工作。有鑒于此，Swift徹底杜絕了程序員經常在Objective-C中所面臨的內存大規(guī)模泄漏問題。

程序員不應該從自己所創(chuàng)建的每個數字化對象角度考慮內存管理工作。由于ARC能夠在編譯的過程中處理所有內存管理事務，因此大家的腦力應該專注于應用程序的核心邏輯以及各類新功能。由于Swift中的ARC能夠跨越面向過程與面向對象的代碼起效，因此其不再要求程序員把太多精力浪費在上下文切換方面——我們甚至能夠直接編寫出觸及底層API的代碼，從而一舉解決Objective-C目前版本所面臨的最大難題。

通過解決自動化與高性能內存管理這一難題，蘋果公司用事實證明了Swift能夠切實幫助程序員提高生產效率。另一項附加作用在于，Objective-C與Swift都不會受到用于清理未使用內存的垃圾收集機制（即Garbage Collector）的影響，正如Java、Go或者C#一樣。這一點對于任何一種會被用于響應圖形及用戶輸入內容的編程語言都非常重要，特別是在像iPhone、Apple Watch或者iPad這樣的觸控設備之上（在這些平臺中，操作滯后會帶來令人難以忍受的糟糕體驗，并導致用戶認為應用程序的運行出現了問題）。

5. Swift所需要的代碼較少

Swift對于需要重復的語句以及字符串操作，Swift能夠大大降低所需代碼量。在Objective-C當中，處理文本字符串的過程非常繁瑣，而且需要采取一系列步驟來將兩組信息結合在一起。相比之下，Swift則具備多種現代編程語言特性，例如通過“+”運算符將兩條字符串直接合并在一起，這種能力是Objective-C所不具備的。對于此類字符與字符串結合方式的支持能力已經成為任何一種需要在屏幕上向用戶顯示文本內容的編程語言的必備要素。

Swift中的類型系統能夠降低代碼語句的復雜程度——因為編譯器能夠直接識別出這些類型。舉例來說，Objective-C要求程序員雇特殊的字符串標記（例如%s、%d以及%@），并提供一份由逗號分隔的變量列表來替代這些標記。Swift支持字符串插值，這就使程序員不必再死記硬背這些標記、而能夠直接將變量插入到面向用戶的字符串之內，例如標簽或者按鈕標題。相比之下，Objective-C中的類型推理系統與字符串插值則往往成為導致應用崩潰的誘因。

在Objective-C當中，弄亂字符串標記的順序或者使用了錯誤的字符串標記都有可能令應用程序發(fā)生崩潰。但現在，Swift能夠把程序員從這些繁瑣的規(guī)定當中解放出來，并憑借著其對文本字符串及數據操作的內聯支持能力保證翻譯得出的代碼成果更為精練（從而降低了代碼出現錯誤的機率）。

6. Swift代碼的執(zhí)行速度更快

從深層角度看，舍棄C語言遺留特性讓Swift在多個方面獲得了巨大提升。Swift代碼在性能基準測試中的出色表現也證明了，蘋果公司確實一直在切實改善Swift運行應用程序邏輯時的速度水平。

根據Primate實驗室——也就是高人氣性能工具GeekBench的開發(fā)方——所公布的結果，Swift在去年12月采用Mandelbrot算法的計算綁定任務測試中，其性能表現已經與C++非常接近。

2015年2月，Primate實驗室發(fā)現Xcode 6.3 Beta版本對Swift在GEMM算法——這是一項內存綁定型算法，面向大型數組進行連續(xù)訪問——中的性能表現作出了進一步改善，其提升指標為1.4。而在最初的FFT算法當中——這是一項內存綁定型算法，面向大型數組進行隨機訪問——其性能提升幅度可達2.6倍。

Swift所采用的一系列最佳實踐則讓這種改進效果變得更為突出，其FFT算法性能測試中的性能提升幅度達8.5倍（而使用C++時其測試結果僅為Swift的1.1倍）。這樣的增強效果同時也使得C++在Mandelbrot算法中僅僅獲得了1.03倍于Swift的得分。

Swift語言在FFT與Mandelbrot兩種算法中幾乎已經能夠與C++的性能水平相比肩。根據Primate實驗室的說法，GEMM算法性能測試結果證明，Swift編譯器無法像C++編譯器那樣實現代碼量化——而這種量化方式正是快速提升性能表現的便捷途徑，并將在下個版本中正式登陸Swift。

7.減少與開源項目之間的命名沖突

一直困擾著Objective-C代碼的一大問題在于，其缺乏對于命名空間的正式支持能力，而這正是C++在解決代碼文件名沖突時給出的辦法。當這種名稱沖突狀況發(fā)生在Objective-C當中時，其會表現為一項鏈接錯誤，而且應用程序將無法正常運行。解決的辦法雖然已經出現，但其卻有可能引發(fā)其它潛在問題。一般而言，程序員往往會利用一段由兩個或者三個字母組成的前綴來區(qū)分已經編寫完成的Objective-C代碼——換言之，就像是在Facebook上@了我們的代碼一下。

Swift語言提供隱含的命名空間，允許不同項目之間使用同樣的代碼文件名稱，且既不會導致build故障、亦不強制要求程序員使用NNString（即Next Step，是由喬布斯在離開蘋果后創(chuàng)建的公司）或者CGPoint（即Core Graphics）這類命名方式。最后，Swift中的這一特性使得程序員能夠進一步提高生產效率，且意味著他們無需再像使用Objective-C時那樣記錄大量文件名稱。在Swift項目中，大家可以看到由這一影響而產生的諸如Array、Dictionary以及String等簡單名稱，而不再像過去那樣被迫使用NSArray、NSDictionary以及NSString等Objective-C缺少命名空間所造成的畸形產物。

在Swift的幫助下，命名空間基于代碼文件歸屬的目標所存在。這意味著程序員們能夠利用命名空間標識符區(qū)分類或者值。Swift中的這項變更可謂意義重大。這極大地簡化了將開源項目、框架以及庫整合到自有代碼中的流程。該命名空間使得不同軟件廠商能夠創(chuàng)建出同樣的代碼文件名稱，而又無需擔心在將其與開源項目整合時出現命名沖突。總而言之，現在Facebook與蘋果都能夠使用名為FlyingCar.swift的對象伖雇傭兵，而不會導致任何錯誤或者build故障了。

8. Swift支持動態(tài)庫

Swift當中的最大變化——但同時又沒能受到足夠的重視——當數從以往的靜態(tài)庫經歷多次大版本更新（iOS 7、iOS 8以及更多后續(xù)版本）而最終迎來了動態(tài)庫支持。動態(tài)庫屬于可執(zhí)行代碼片段，且能夠被接入到應用程序當中。這一特性意味著，如今Swift應用程序可以隨著Swift語言的不斷發(fā)展隨時與其最新版本相對接。

開發(fā)者需要同時提交應用程序及其對應庫，而二者都利用開發(fā)證書進行了數字簽名，從而確保其完整性（聽起來美國安全局又能有所作為了）。這意味著Swift語言甚至能夠以高于iOS的速度得到更新，而這也正是現代編程語言的一項重要要求。指向庫的所有變更都能夠被包含在App Store當中應用程序的最新更新包內，而且整個過程的實現可謂非常簡單。

直到Swift與iOS 8面世之前，iOS系統一直無法支持動態(tài)庫機制——然而在桌面端，Mac早就已經開始對動態(tài)庫提供支持。動態(tài)庫存在于應用程序執(zhí)行文件外部，但卻會在用戶從App Store獲取應用程序時以綁定方式被一同下載。由于這部分內容會被載入到內存當中，因此其降低了應用程序的初始大小，而且這些外部代碼只會在被使用時才得到接入。

在Apple Watch平臺之上，這種在移動應用程序或者嵌入式應用當中實現延后載入的能力可以提高呈現在用戶使用過程中的性能表現。而這正是iOS生態(tài)系統的一大獨特之處，即使用體驗更為靈敏快捷。蘋果公司一直專注于讓應用程序在運行過程中僅僅載入所需的資產與資源，而如今經過編譯的接入代碼也被納入了這一范疇。這種運行過程中即時載入的方式能夠降低應用程序的初始等待時間，并保證其直到需要被顯示在屏幕上時才真正被載入。

動態(tài)庫支持能力的出現令Swift成為一款能夠以前所未有的速度實現變更與改進的編程語言。用戶不必再等等iOS的版本更新，即可即時享受到蘋果在Swift當中添加的任何性能提升或者可靠性改善效果。

9. Swift Playgrounds鼓勵程序員采取交互式編碼方式

Swift全新引入的Playgrounds正是經驗豐富的開發(fā)人員們的最大福音。Playgrounds的誕生受到了蘋果公司前任員工Brett Victor的啟發(fā)。Playgrounds能夠幫助程序員實時測試一種新算法或者圖形例程——例如包含五到二十行代碼——而且無需創(chuàng)建出整套iPhone應用程序。

蘋果公司還為Playgrounds添加了內聯代碼執(zhí)行能力，從而幫助程序員在創(chuàng)建一條代碼片段或者編寫一種算法的同時，從開發(fā)環(huán)境處獲得效果反饋。這一反饋循環(huán)能夠大大提高代碼的編寫效率，因為從傳統角度講，程序員需要用想法的方式來估計當前代碼的運行效果——而有了Playgrounds，一直皆以可視化方式進行。編程是一種迭代式過程，而其中任何可以減少或者用于補充創(chuàng)建流程的機制都能讓程序員們更具生產效率，并把他們的精力解放出來用于處理更為重要的問題——而非專注于解決傳統編譯器強加給程序員的那些惱人的細節(jié)調整工作。

備注：根據我個人在教授新人程序員時的感受，Playgrounds的實際效果對于剛入門的新手而言其實不像經驗豐富的老鳥們那么突出。單純在Swift Playgrounds當中顯示出某條變量的運行效果并不能幫助新人們理解這部分代碼到底是需要浮點變量還是整數變量——是的，如果打算開發(fā)一款能夠記住用戶上一次Facebook新聞內容訪問位置的應用，這種變量類型的需求將非常顯著。對新手們來說，關于“為什么”的問題只能在實現運行中的iPhone應用里找到答案——而不是Playgrounds上的片段運行效果。

10. Swift代表著我們能夠參與并對其產生影響的未來

Objective-C在相當長的一段時間里仍將繼續(xù)存在，但其已經不會再迎來任何重大改變，而這完全是因為Swift的出臺。Swift中的一部分功能可能會被遷移到Objective-C當中，但Objective-C脫胎于C語言的血統就注定了它也只能吸收這么一丁點新鮮血液。

Swift語言則給開發(fā)社區(qū)帶來了一種直接的途徑，允許我們每位參與者對其作出影響，并利用最終成果創(chuàng)建應用程序、嵌入式系統（如果蘋果未來發(fā)布嵌入式框架許可并向第三方提供芯片架構授權的話）以及像Apple Watch這樣的設備。

蘋果公司專注于提供最出色的消費者使用體驗，并正在著手構建那些真正值得認真關注的功能特性。隨著Swift 1.2版本在Xcode 6.3中的發(fā)布，蘋果方面已經修正了蘋果bug報告所收集到的數千個已知bug。負責支持Swift發(fā)展與演進的技術團隊對該語言的命運非常關注，他們期待著觀察Swift如何實現更出色的支持效果、從而幫助開發(fā)社區(qū)打造出優(yōu)秀的應用程序及系統成果。

Swift:更加平易近人且功能更為齊備的語言選項

前面提到的一系列變更讓Swift得以凌駕于Objective-C之上，同時徹底擺脫了后者作為衍生型語言所殘留的大量固癥頑疾。蘋果公司并不會放棄Cocoa，因為其正是創(chuàng)建出蘋果產品特殊使用體驗的核心API及代碼庫。相反，他們會推出功能齊全的校驗機制，并使Cocoa能夠輕松與其它可以支持Force Touch或者Taptic Feedback（即力度感應與力反饋）等功能的新型API實現交互。

過去的許多傳統設定從設計思路上看，完全是為了保障編譯器設計方案的易用性。Swift則將注意力集中在了摒棄傳統編碼實踐當中那些容易令人神經緊張的糟粕，從而幫助應用程序開發(fā)人員更輕松地完成工作。隨著現代編譯器方案的不斷改進，我們將能夠利用更少代碼表達出更多信息。

有了Swift語言，程序員們需要維護的代碼文件只相當于原先的一半、不必以手動方式進行代碼同步、產生標點錯誤的可能性也變得更低——這將保證他們將更多時間花在真正具有意義的高質量代碼編寫上。在Swift當中，代碼現在能夠實現自我記錄并提供更多可選類型：編譯時安全機制會返回某個值或者無值，這恰恰是異步操作、網絡故障、無效用戶輸入內容或者數據驗證錯誤等多發(fā)問題的根源。在Swift當中，ARC在C語言式過程代碼與采用蘋果Cocoa框架的面向對象代碼之間得到了統一。

開發(fā)人員會發(fā)現，他們在Swift中需要編寫的代碼量更少，而且能夠借助各類現代語言特性支持自己讓代碼行內容變得更為可靠。Swift自身在不斷演變的同時，將始終保證蘋果生態(tài)系統站在編程發(fā)展潮流的前沿，而這都要歸功于iOS與Swift當中提供的動態(tài)庫支持能力。與家庭自動化、設備以及社交服務相集成的開源項目、第三方SDK以及框架等都將更輕松地實現對接，而無需忍受由此帶來的額外構建時間。Swift在一部分算法測試中幾乎擁有可以與C++相媲美的速度表現，而最新發(fā)布的Xcode 6.3與Swift 1.2版本則標志著蘋果將進一步推動這一性能優(yōu)化步伐。

而且如今有了Playgrounds的加盟，Swift能夠以一種全新方式為程序員提供可視性反饋信息，從而幫助我們利用內聯數據可視化機制實現算法開發(fā)。由于反饋循環(huán)更短且提供圖形化描述，迭代編碼過程也要比原先更為簡便。

最后讓我們進行一番總結：Swift是一款平易近人且功能齊備的編程語言，不僅允許開發(fā)人員利用它構建應用程序、同時也將發(fā)展目標指向了未來多年內將陸續(xù)出現的Apple Watch等新型低功耗嵌入式系統平臺。

想學Swift語言？可查看：Swift語言教程