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

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

管理考慮

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

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

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

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

技術(shù)原因

這兩種語言之間有多種區(qū)別，但它們至少有一個(gè)重要的特征 -它們都是蘋果公司的主要編程語言，適用于所有蘋果平臺(tái)的應(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ì)是高度動(dòng)態(tài)的，具有動(dòng)態(tài)綁定和動(dòng)態(tài)類型，而Swift有靜態(tài)類型檢查。

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

為什么選擇Swift

使用方便

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

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

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

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

安全

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

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

動(dòng)態(tài)庫

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

未來

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

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

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

為什么選擇Objective-C

兼容性和支持

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

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

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

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

專業(yè)

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

動(dòng)態(tài)

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

運(yùn)行

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

結(jié)論

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

最新評(píng)論