現(xiàn)在Swift和Objective C的競爭正在飛快加劇。 這是很容易理解的，因?yàn)樗麄兌加懈髯缘暮锰?，一些開發(fā)人員對對如何選擇一個適合項(xiàng)目的編程語言產(chǎn)生了困惑。

首先，這兩者之間的選擇是沒有嚴(yán)格的答案。在做出選擇之前，要考慮很多事情，包括各種因素和特征、各自缺點(diǎn)和優(yōu)點(diǎn)。 因此，這里做一個概述，以客觀展示雙方之間的差異和利弊，因?yàn)槲覀冋J(rèn)為明智的做法是選擇根據(jù)是否適合自己的開發(fā)團(tuán)隊和具體項(xiàng)目進(jìn)行選擇。

管理考慮

第一個考慮是根據(jù)特定團(tuán)隊選擇。即使Swift通常被稱為更簡單，更平滑的語法語言，它消除了更復(fù)雜的Objective-C的一些麻煩，但仍然有一些進(jìn)入門檻。這里正確的問題不是“如果團(tuán)隊能夠使用Swift / Objective-C構(gòu)建新項(xiàng)目會怎樣”，而是“現(xiàn)在的團(tuán)隊是否能使用它在截止日期之前完成任務(wù)？

與你的團(tuán)隊開會詢問他們，必須確保他們不僅能夠使用Swift實(shí)現(xiàn)，而且確保及時完成。如果團(tuán)隊是Objective-C專家，強(qiáng)制他們使用Swift并在一個有嚴(yán)格期限的項(xiàng)目上使用并不是一個好主意。反之亦然。 嚴(yán)格的截止日期決定了團(tuán)隊使用最舒適的語言（如果沒有被環(huán)境覆蓋）。

項(xiàng)目規(guī)模

下一個考慮可能是的項(xiàng)目的規(guī)模。 小型項(xiàng)目可以從Swift的簡單語法，文件結(jié)構(gòu)等功能中受益，而大型項(xiàng)目則可能會受到Swift這是一門年輕語言的影響。當(dāng)然會有Xcode轉(zhuǎn)換到新版本的手段，但他們不是完美的，隨著項(xiàng)目增長事情變得更糟。Swift因?yàn)槟贻p也帶來了一些缺點(diǎn)，比如錯誤和不穩(wěn)定性，以Swift的原生IDE - Xcode為例，經(jīng)常報告崩潰現(xiàn)象發(fā)生，Xcode語言的許多不兼容等問題也有報道，雖然Xcode中提升效率相當(dāng)快，許多錯誤已經(jīng)解決。 但是有些新錯誤還會來。

技術(shù)原因

這兩種語言之間有多種區(qū)別，但它們至少有一個重要的特征 -它們都是蘋果公司的主要編程語言，適用于所有蘋果平臺的應(yīng)用程序開發(fā)。 Objective-C早在八十年代早期就已經(jīng)開發(fā)出來，它屬于Generation X.原始的Cocoa是寫在其中的，雖然Swift的書面部分自2014年推出以來一直被添加到Cocoa和Cocoa Touch。

Objective-C是C的嚴(yán)格超集，從Xerox Smalltalk得到其面向?qū)ο蟮恼Z法。 它的性質(zhì)是高度動態(tài)的，具有動態(tài)綁定和動態(tài)類型，而Swift有靜態(tài)類型檢查。

現(xiàn)在讓我們看看這兩種語言的優(yōu)勢，一方優(yōu)勢可以被認(rèn)為是另一一方弊端。

為什么選擇Swift

使用方便

Swift的設(shè)計更容易使用，比Objective-C更容易閱讀理解。它的語法更接近自然的英語，放棄了一些傳統(tǒng)的約定 - 沒有更多的括號鏈，在任何對象相關(guān)的關(guān)鍵字或Objective-C特定類型之前沒有更多的“@”。 看起來更清晰; Swift有時被稱為“沒有C的Objective-C”。Swift不是基于C的，不僅簡化了語法，而且降低了Java，Python，C ++等程序員用于掌握Swift的門檻。

Swift也不那么冗長，特別是在字符串處理中，甚至支持使用簡單的“+”添加字符串。

內(nèi)存管理在整個代碼中是統(tǒng)一的，不同于以前的面向?qū)ο?，自動引用計?shù)（ARC）現(xiàn)在可以在代碼的面向?qū)ο蠛瓦^程兩部分中同時適用。 Objective-C會有大量的內(nèi)存泄漏，Swift使這點(diǎn)變得不可能了，并解放了程序員的開發(fā)時間。

此外，Swift不使用雙文件系統(tǒng)，沒有更多的.h頭文件+ .m實(shí)現(xiàn)文件，只有一個.swift代碼文件（感謝LLVM編譯器和Xcode IDE依賴處理）。

安全

Swift被設(shè)計成一種安全的語言。在這個世界上沒有不發(fā)生故障的安全語言，但是錯誤處理是非常好的考慮，類型系統(tǒng)是非常強(qiáng)大的。

不像Objective-C不會在nil指針調(diào)用上拋出異常，比如說，如果你試圖調(diào)用一個未初始化的指針變量的方法，它只是使這個表達(dá)式為無操作，在Swift的可選類型和值類型使得在nil指針調(diào)用上生成編譯器錯誤。這意味著無操作相關(guān)的不可預(yù)測的不穩(wěn)定行為消失了，它大大縮短了錯誤修復(fù)費(fèi)用。

動態(tài)庫

在iOS 8中，一個期待已久的新技術(shù)被帶到了移動平臺 - 支持動態(tài)庫。 從那時起，Swift應(yīng)用程序能夠與Swift的較新版本鏈接，允許Swift在演變上比iOS更快，這是現(xiàn)代語言必須的。 動態(tài)庫也是外部的應(yīng)用程序可執(zhí)行文件，允許較小的初始下載和差異化的移動和嵌入式應(yīng)用程序的負(fù)載。

未來

Swift可能只有兩年時間，但自2014年以來，它的流行度已經(jīng)迅速增長到所有開源Cocoa項(xiàng)目的30％左右。隨著蘋果明確瞄準(zhǔn)Swift取代Objective-C作為他們的主要語言，未來將轉(zhuǎn)向Swift。

但這不是一個明天就能達(dá)到的問題，這種過渡將需要一些時間，但它預(yù)計在5 - 10年左右，因此有開發(fā)人員適應(yīng)的時間。

頗為青睞的效率蘋果軟件缺陷報告工具顯示蘋果有多努力地為Swift推廣。蘋果還將適應(yīng)社區(qū)的想法，吸收其知識和經(jīng)驗(yàn)，并在未來版本中實(shí)施其解決方案。 完美的方式。

為什么選擇Objective-C

兼容性和支持

盡管Xcode團(tuán)隊的努力，但是IDE不是很好支持Swift，因?yàn)榭赡芩铝?。自動完成滯后了，語法突出幾乎是非基礎(chǔ)功能的，重構(gòu)工具會不工作。 使用Objective-C編程已經(jīng)有一段時間了（> 30年了！），它非常成熟，有非常輝煌的工具支持。

由于Swift是“無C語言”，C ++庫在這里不可用。 同樣的包括C ++跨平臺SDK和API的基礎(chǔ)（如的CoreFoundation ）。

有一些工具如橋接和包裝類，但這些努力通常不值得，堅持Objective-C最好的情況下是使用C ++和Foundation API。

Swift不僅年輕，而且與舊的操作系統(tǒng)不兼容，它的支持從iOS 7.0+和Mac OS 10.9+開始（tvOS和watchOS支持任何版本的Swift），因此Objective-C是老平臺的首選工具平臺。

專業(yè)

不僅一些團(tuán)隊在Objective-C上有更多的經(jīng)驗(yàn)，但是如果你有興趣外包你的項(xiàng)目的一些部分，更容易找到第三方專家。

動態(tài)

盡管Swift可以從靜態(tài)類型檢查中獲益于優(yōu)化，但是即時添加的方法不再可用，所有類型都在運(yùn)行時之前定義。 如果你絕對需要動態(tài)類型，那么Swift是不行的。

運(yùn)行

Objective-C是一個更加確定的平臺，因此它有一個更穩(wěn)定，更強(qiáng)硬和可靠的運(yùn)行時。 我們不想說Swift不能實(shí)現(xiàn)這個規(guī)模，但它需要時間。

結(jié)論

正如我們所看到的，兩種語言都有自己的優(yōu)勢和權(quán)衡，但他們確實(shí)有可能一起工作（在較小的項(xiàng)目中，但最好是）。