Xcode 的編譯器 LLVM 背后有怎樣的故事？

Swift 誕生的前世今生，封閉的蘋(píng)果為何要擁抱開(kāi)源？

說(shuō)好的 ABI 穩(wěn)定性何時(shí)能推出？

教育背景

伊利諾伊大學(xué) PHD

2005年 - 2017年供職蘋(píng)果，前開(kāi)發(fā)部高級(jí)總監(jiān)，架構(gòu)師

2017年開(kāi)始，擔(dān)任特斯拉副總裁，負(fù)責(zé)自動(dòng)駕駛

Swift 之父，主要作者

LLVM 之父，主要作者

Clang 主要貢獻(xiàn)者

2016年被評(píng)為“創(chuàng)造未來(lái)的25位當(dāng)世天才”

2013年獲得 ACM 系統(tǒng)設(shè)計(jì)大獎(jiǎng)

1. 你怎么看待自己？

我是個(gè)程序員。我喜歡寫(xiě)代碼。我編程有很長(zhǎng)時(shí)間了。

我在讀博的時(shí)候就開(kāi)始寫(xiě) LLVM 了。當(dāng)時(shí) LLVM 是我的博士研究項(xiàng)目，我想把它做成工業(yè)界中顛覆性的產(chǎn)品。當(dāng)時(shí)我異想天開(kāi)，嘗試了各種架構(gòu)設(shè)計(jì)，想解決以往編譯器所有的弊端 -- 結(jié)果當(dāng)然沒(méi)有如愿。我畢業(yè)后，就希望能接著搞 LLVM ，當(dāng)時(shí)只有蘋(píng)果允許我入職之后繼續(xù)設(shè)計(jì)并實(shí)現(xiàn) LLVM 。我想都沒(méi)想就加入了蘋(píng)果。

LLVM

2. 說(shuō)說(shuō) LLVM（Low Level Virtual Machine）到底是什么吧

先說(shuō)編譯器：編譯器是把程序員的代碼翻譯成機(jī)器可以理解的語(yǔ)言的工具；

再談LLVM：一個(gè)模塊化和可重用的編譯器和工具鏈技術(shù)的集合，Clang 是 LLVM 的子項(xiàng)目，是 C，C++ 和 Objective-C 編譯器，因?yàn)槎嗄K的復(fù)用，所以提供了驚人的快速編譯，比 GCC 快3倍。

3. LLVM 是一開(kāi)始就作為一個(gè)完整的編譯工具來(lái)使用的嗎？還是有什么其他故事

LLVM 當(dāng)時(shí)是為了解決一個(gè)小問(wèn)題而開(kāi)發(fā)的：當(dāng)使用OpenGL 函數(shù)庫(kù)的時(shí)候（Mac OS 10.4 和 10.5環(huán)境下），比如你要調(diào)用這個(gè)函數(shù)，glVertex3f()，編譯器必須將其轉(zhuǎn)化為特定的GPU可以理解的數(shù)據(jù)。但是這帶來(lái)一個(gè)問(wèn)題：市面上有海量的GPU，每個(gè)GPU的性能和參數(shù)也不盡相同，所要求的數(shù)據(jù)格式也不同。這時(shí) LLVM 可以產(chǎn)生很小的一部分代碼去解決這個(gè)問(wèn)題，這是 LLVM 誕生的初衷。

4. LLVM 的 bytecode 和 Apple 現(xiàn)在的 bitcode 有什么不同？

這是歷史遺留問(wèn)題。一開(kāi)始 LLVM 是開(kāi)源的，所有代碼在轉(zhuǎn)成二進(jìn)制時(shí)就叫做 bytecode -- 因?yàn)?java 當(dāng)年就是這么叫的。當(dāng)時(shí)這一部分有很多問(wèn)題：比如不能擴(kuò)展，無(wú)法兼容，非常脆弱。

然后就到了 LLVM 2.0，當(dāng)時(shí)我重新設(shè)計(jì)了架構(gòu)，采用的就是 Bitcode 機(jī)制。LLVM 2.0 將所有代碼以比特流(bit stream)而不是字節(jié)流(byte stream)的形式來(lái)編碼。這就是 bitcode 這一術(shù)語(yǔ)的由來(lái)。

主要的工作流程就是現(xiàn)將代碼轉(zhuǎn)成比特流，然后相應(yīng)處理。處理完后再將編碼傳到其他地方去。

5. Bitcode 這個(gè)機(jī)制比直接傳輸二進(jìn)制有什么好處

好處那是多了去了。首先 編譯器工作起來(lái)會(huì)越來(lái)越好。因?yàn)橥ㄟ^(guò)Bitcode機(jī)制，它可以通過(guò)編譯不同代碼來(lái)存儲(chǔ)各種優(yōu)化方法，這樣下次碰到類(lèi)似代碼，它就會(huì)自動(dòng)啟動(dòng)相關(guān)優(yōu)化機(jī)制，使得效率提升。還有個(gè)好處是 LLVM 可以讓芯片的兼容性變得很好。因?yàn)?Apple 每年都在芯片上推陳出新，它們轉(zhuǎn)化為二進(jìn)制的規(guī)則都不盡相同，LLVM 只要每次重新編碼并傳輸成比特流就好了。

當(dāng)然 Bitcode 也不是萬(wàn)能的。比如它不能解決 32位的 APP 在64位機(jī)器上的兼容問(wèn)題。這個(gè)問(wèn)題其實(shí)應(yīng)該依靠代碼邏輯。

談管理

6. 在職業(yè)生涯中，你在 LLVM 上鞠躬盡瘁，但我們發(fā)現(xiàn)這幾年你更多的工作是在管理上，你自己怎么看這種轉(zhuǎn)變的？

我雖然做管理了，但是我依然喜歡寫(xiě)代碼，而且我每天都寫(xiě)，因?yàn)槲揖褪莻€(gè)極客嘛。而且，其實(shí)我很早就開(kāi)始做管理的工作了。不過(guò)我一直是作為技術(shù)領(lǐng)導(dǎo)人的角色帶 2 到 3 個(gè)人的，我只是在寫(xiě)代碼方面把把關(guān)，給他們提提建議這樣。

后來(lái)帶的人多了，隊(duì)伍也大了。我不僅管程序員，還管小組經(jīng)理和其他技術(shù)領(lǐng)導(dǎo)人。雖然我一直喜歡寫(xiě)代碼，但是管理對(duì)我來(lái)說(shuō)是一個(gè)必須要去做的事。現(xiàn)在回過(guò)頭來(lái)，我覺(jué)得干得還不錯(cuò)。跟大家一起工作之后我知道很多事協(xié)同工作效果更好，和同事交流你就會(huì)理解他們的想法，這樣我就可以制定更好的計(jì)劃路線。

其實(shí)我沒(méi)感覺(jué)整個(gè)過(guò)程有什么不同。直到今天我還夜以繼日、廢寢忘食得寫(xiě)代碼，我并不是坐那邊動(dòng)動(dòng)嘴皮子，指揮別人干活的老板。我其實(shí)每個(gè)周末都在寫(xiě)代碼，我很忙的。

Swift

7. Swift 是如何誕生的？在蘋(píng)果這樣一個(gè)大廠，決定做出如此巨大的變革，同時(shí)還是在封閉的環(huán)境下，你是如何一步步實(shí)現(xiàn)的？

首先，蘋(píng)果內(nèi)部所有的項(xiàng)目都不盡相同 -- 工作流程、戰(zhàn)略規(guī)劃、實(shí)施細(xì)節(jié)，到最后發(fā)布。Swift 也一樣，沒(méi)有可比性。因?yàn)樘O(píng)果本身就是小組單兵作戰(zhàn)模式 -- 每個(gè)組負(fù)責(zé)不同的大方向，組里自己計(jì)劃和工作，甚至招人都是各自招。

言歸正傳，契機(jī)發(fā)生在2010年了。當(dāng)時(shí)好像是我們剛剛完成了 Clang 對(duì) C++的支持。你也知道 C++ 寫(xiě)起來(lái)有多丑，但是做個(gè)編輯器支持 C++，完善 C++ 這門(mén)語(yǔ)言就是另一回事了，我們當(dāng)時(shí)搞了好久終于完成的時(shí)候特別有成就感。當(dāng)然 Clang 遠(yuǎn)沒(méi)有到達(dá)完美的地步。

我又扯遠(yuǎn)了。除了做 Clang 以外，無(wú)論是 C語(yǔ)言，C++，還是 Objective-C，都有一些我不是很滿(mǎn)意的地方。所以我就想要不我們搞個(gè)新的語(yǔ)言來(lái)吧。新的語(yǔ)言要越簡(jiǎn)單越好。一開(kāi)始大家都沒(méi)認(rèn)真，后來(lái)我跟很多同事聊了之后覺(jué)得新語(yǔ)言的計(jì)劃可行，而且大家都很亦可賽艇。于是我們就用業(yè)余時(shí)間開(kāi)始頂層設(shè)計(jì)和寫(xiě)代碼。

現(xiàn)在問(wèn)題來(lái)了，因?yàn)槲覀円呀?jīng)有 Objective-C 了。雖然它有幾個(gè)地方很丑，比如老是用 "@"，每句結(jié)束了還要打分號(hào)，但是這些并不妨礙它是一門(mén)偉大的語(yǔ)言。所以，我們?yōu)槭裁匆_(kāi)發(fā)新語(yǔ)言，而不是把精力花在優(yōu)化 Objective - C 上？

原因有三。

第一，如果我們大幅優(yōu)化 Objective - C，把很多 Swift 的特性加進(jìn)去，這對(duì)開(kāi)發(fā)者來(lái)說(shuō)是災(zāi)難性的，因?yàn)樗麄円獙?duì)原來(lái)的 APP 要進(jìn)行大幅修改；

第二，Objective - C 很多特性積重難返，比如它安全性上的問(wèn)題；

第三，Objective - C 是基于 C 開(kāi)發(fā)的語(yǔ)言，所以你無(wú)論怎么優(yōu)化，它必然有 C 語(yǔ)言自身的缺陷。

于是我們就動(dòng)手做 Swift 了，它的背后有著數(shù)百人的努力: 支持 Xcode，開(kāi)發(fā) Playground，兼容調(diào)試器和編譯器。我個(gè)人感到最驕傲的一點(diǎn)是，我們并不打算自己內(nèi)部把它做到完美 -- 我們開(kāi)源、我們依靠社區(qū)，這樣一門(mén)語(yǔ)言才能在無(wú)數(shù)開(kāi)發(fā)者的實(shí)戰(zhàn)中得到檢驗(yàn)和改進(jìn)，我想這才是 Swift 最棒的地方。

8. 你之前在優(yōu)化 Objective-C 的時(shí)候，有沒(méi)有想到什么地方是未來(lái) Swift 可以用得到的？

ARC。我們其實(shí)一直都在爭(zhēng)論是用垃圾回收機(jī)制（garbage collection）還是 ARC，后來(lái)決定了是 ARC。

另一個(gè)是模塊化，我們也將這一部分的經(jīng)驗(yàn)帶到了 Swift 開(kāi)發(fā)中。

其實(shí)，很多數(shù)組和字典方面的語(yǔ)法優(yōu)化本來(lái)是計(jì)劃在 Objective - C 上面的。但是后來(lái)我們開(kāi)發(fā)了 Swift，于是這些改進(jìn)被直接用在了新語(yǔ)言上，所以大家會(huì)在寫(xiě) Swift 的時(shí)候覺(jué)得似曾相識(shí)，因?yàn)楸緛?lái)這些就是 Objective-C 的升級(jí)版本嘛。

我可以透露一個(gè)有意思的事情。我們?cè)谧?Swift 的時(shí)候，很多 iOS 開(kāi)發(fā)者，包括蘋(píng)果內(nèi)部的工程師，都在吐槽我們這幾年在 Objective - C 上毫無(wú)建樹(shù)，都在說(shuō)你們?yōu)槭裁床蛔鲞@個(gè)那個(gè)。我們當(dāng)然不能告訴他們我們?cè)谌﹂_(kāi)發(fā) Swift，而他們所要的語(yǔ)法功能我們都會(huì)給。

9. 蘋(píng)果內(nèi)部對(duì)于 Swift 的使用情況和開(kāi)發(fā)是怎么看得？

Swift 團(tuán)隊(duì)對(duì)于開(kāi)發(fā)上有明確的目標(biāo)和計(jì)劃，應(yīng)用二進(jìn)制接口（ABI）的穩(wěn)定性一直是我們的首要目標(biāo)。很多人很喜歡我們開(kāi)源的 Swift Playground。同時(shí) iOS 系統(tǒng)內(nèi)置的 Music App 也是 Swift 寫(xiě)的。其實(shí)用不用 Swift 主要是技術(shù)和開(kāi)發(fā)方面的考量，蘋(píng)果內(nèi)部同時(shí)得兼顧穩(wěn)定性和開(kāi)發(fā)效率，這不是說(shuō)大家喜不喜歡這個(gè)語(yǔ)言的問(wèn)題。

Swift 剛發(fā)布的時(shí)候，內(nèi)部很多組都很驚訝：我們已經(jīng)有了 Objective-C，為什么還要搞新的 Swift？而且 Objective-C 本身就很不錯(cuò)，開(kāi)發(fā)起來(lái)也很順手。后來(lái)漸漸 Swift 成熟了，大家也愛(ài)上了這個(gè)新生兒。

內(nèi)部其實(shí)對(duì)于 Swift 一個(gè)很大的顧慮在于，蘋(píng)果的所有開(kāi)發(fā)必須兼容32位機(jī)器，而32位的應(yīng)用都采用了 Objective-C 的 runtime 機(jī)制。這就要求 Swift 團(tuán)隊(duì)也弄出個(gè)類(lèi)似的機(jī)制，或者弄個(gè)兼容的方案，否則 Swift 無(wú)法與 AppKit 適配。

10. 開(kāi)源后的 Swift 發(fā)展態(tài)勢(shì)喜人，你對(duì)此有什么看法？

開(kāi)源之后，Swift 發(fā)展之好讓我咋舌，然而這也是問(wèn)題所在。

當(dāng)年我們開(kāi)源了 LLVM 和 Clang，它們也發(fā)展喜人。我們的對(duì)手 AMD 們完全跟不上我們。但是跟 Swift 比起來(lái)，它們的發(fā)展也太慢了，LLVM 和 Clang 開(kāi)源后完全沒(méi)有 Swift 這么火。

Swift 就不同了，開(kāi)源一年之后，我們就有了上百萬(wàn)的開(kāi)發(fā)者在使用這門(mén)語(yǔ)言 -- 我和很多有豐富開(kāi)源經(jīng)驗(yàn)的老工程師都嚇了一跳，這簡(jiǎn)直了！然后我們每天收到無(wú)數(shù)的郵件和 pull requests，要求更新這個(gè)、要求優(yōu)化那個(gè)，我們的節(jié)奏完全被打亂了。我們?nèi)绾我?guī)劃開(kāi)發(fā)？我們?nèi)绾伟?Swift 的開(kāi)發(fā)導(dǎo)向一個(gè)正確的方向？這些問(wèn)題隨著時(shí)間的推移和經(jīng)驗(yàn)的積累，慢慢找到了解決之道。

我現(xiàn)在覺(jué)得開(kāi)源這個(gè)決定至關(guān)重要。一來(lái)大家會(huì)幫著優(yōu)化；二來(lái)我們有個(gè)巨大的論壇，在那里大家可以暢所欲言，全世界的人都在幫著 Swift 進(jìn)步，這真的很棒。我們雖然沒(méi)有一開(kāi)始就具體計(jì)劃要開(kāi)源，但是蘋(píng)果內(nèi)部當(dāng)時(shí)都覺(jué)得 Swift 肯定有一天要開(kāi)源。

蘋(píng)果與特斯拉

11. 蘋(píng)果好像一直是個(gè)封閉的公司，你們內(nèi)部對(duì)于開(kāi)源怎么看？

蘋(píng)果其實(shí)有開(kāi)源的傳統(tǒng)。LLVM 雖然不是始于蘋(píng)果，但是最終是蘋(píng)果完成并將其開(kāi)源。Clang 則完完全全是生于斯開(kāi)源于斯。還有其他工具，比如 LLDB，libc+，以及compiler-rt 都是如此。

所以對(duì)于 Swift 來(lái)說(shuō)，開(kāi)源只是時(shí)間問(wèn)題。當(dāng)年從 Swift 1.0 到 Swift 2.0，一切都亂七八糟。當(dāng)時(shí)我們重點(diǎn)在開(kāi)發(fā)錯(cuò)誤處理機(jī)制，還有協(xié)議、拓展等一系列重要的功能。所以開(kāi)源 Swift 1.0，并不是一個(gè)好選擇，因?yàn)檫@些重要的東西都沒(méi)有，而這些開(kāi)發(fā)是當(dāng)務(wù)之急。當(dāng) Swift 2.0 到來(lái)的時(shí)候，我們才有空去開(kāi)源、去做社區(qū)拓展和論壇搭建。開(kāi)源社區(qū)可以幫我們修復(fù)細(xì)節(jié)，我們這時(shí)候可以更多的投入在架構(gòu)設(shè)計(jì)上。

12. 蘋(píng)果最讓你懷念的是什么？

蘋(píng)果是這樣一個(gè)公司，你可以選擇你喜歡的東西，然后努力工作去實(shí)現(xiàn)它，最終你的工作會(huì)落實(shí)在產(chǎn)品上，影響億萬(wàn)計(jì)的人。

有很多公司，你可以努力工作，但是不一定能做你喜歡的東西；你做出來(lái)東西，可能會(huì)被束之高閣；你做的產(chǎn)品，也許最后很幸運(yùn)的發(fā)布，但是并不一定有很多人會(huì)用。在蘋(píng)果，你的工作可以真正改變世界，很有成就感。

13. 你覺(jué)得到特斯拉之后，還會(huì)努力為 Swift 做出貢獻(xiàn)嗎？

特斯拉的工作非常有挑戰(zhàn)性，這是我最開(kāi)心的地方。我現(xiàn)在還沒(méi)入職，所以也不知道我之后對(duì) Swift 能做多少工作。也許我還會(huì)夜以繼日的發(fā) Pull Request，也許我就周末寫(xiě)寫(xiě) Swift 代碼。我應(yīng)該會(huì)從各個(gè)方面 -- 無(wú)論是頂層設(shè)計(jì)還是具體代碼實(shí)現(xiàn)，與蘋(píng)果的核心團(tuán)隊(duì)合作，為這個(gè)語(yǔ)言做貢獻(xiàn)。

其實(shí)我一直想說(shuō)，Swift 只是我在蘋(píng)果工作的一小部分，我花了大量的時(shí)間在其他事情上。實(shí)際上在蘋(píng)果我也就晚上或者周末有空寫(xiě)寫(xiě) Swift。我希望到了特斯拉之后我還能花同樣的精力和時(shí)間在 Swift 上，畢竟我對(duì)這門(mén)語(yǔ)言統(tǒng)治世界充滿(mǎn)期待。

ABI 穩(wěn)定性

14. 現(xiàn)在 Swift 已經(jīng)到了第3個(gè)版本了。我們也知道ABI穩(wěn)定性的追求一直是你們的目標(biāo)，但是它也一直被各種事情拖延。你對(duì)此有什么計(jì)劃嗎？或者說(shuō)你從拖延中學(xué)到了什么經(jīng)驗(yàn)教訓(xùn)嗎？

ABI 推遲有兩個(gè)原因。

第一是因?yàn)?Swift 的開(kāi)發(fā)進(jìn)程中有很多不確定性。當(dāng) Swift 開(kāi)源之時(shí)，一堆人對(duì)我們提 pull request，提各種各樣的 issue。這樣我們就不得不去花大量的時(shí)間去維護(hù)開(kāi)源社區(qū)，而不是專(zhuān)心去做計(jì)劃內(nèi)的工作。

第二個(gè)原因是，盡管穩(wěn)定的 ABI 很重要，但是對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，穩(wěn)定的 ABI 對(duì)他們來(lái)說(shuō)沒(méi)有明顯的好處，他們更關(guān)心是語(yǔ)法和兼容上的穩(wěn)定和優(yōu)化。所以我們后來(lái)修改了計(jì)劃，語(yǔ)法和兼容上的穩(wěn)定性被定為是最先要實(shí)現(xiàn)的目標(biāo)。這樣當(dāng) Swift 3.1 或者 Swift 4.0 出來(lái)的時(shí)候，大家不用擔(dān)心語(yǔ)言上的轉(zhuǎn)化會(huì)讓 Xcode 崩潰，或是需要大家整個(gè)重構(gòu) APP。Swift 3.0 主要就是實(shí)現(xiàn)這個(gè)目標(biāo)。

15. 穩(wěn)定的 ABI 什么時(shí)候推出？他會(huì)趕在異步和并發(fā)模型之前嗎？

Swift 現(xiàn)有的內(nèi)存管理機(jī)制對(duì) ABI 穩(wěn)定性造成了不小的影響。有些底層邏輯還需要調(diào)整，比如 getter 和 setter 的生成以及屬性的內(nèi)存分配問(wèn)題，蘋(píng)果內(nèi)部正在做這件事，這之后我們才能完成 ABI。至于并發(fā)模型啥的就跟 ABI 沒(méi)有關(guān)系了。

很多人擔(dān)心 Swift 4.0 的時(shí)候蘋(píng)果能不能推出穩(wěn)定的 ABI，因?yàn)楫吘构ぷ髁刻蟆BI 的工作正在井然有序得進(jìn)行，而且對(duì)于開(kāi)源社區(qū)來(lái)講推出穩(wěn)定的 ABI 至關(guān)重要。Ted （Chris Lattner 之后的 Swift 領(lǐng)導(dǎo)人）有一件事說(shuō)對(duì)了，現(xiàn)在 Swift 當(dāng)務(wù)之急就是讓編譯器更穩(wěn)定，讓錯(cuò)誤處理更方便，提高編譯速度，并且將 Swift 拓展到大規(guī)模系統(tǒng)中。

我在想 Swift 4.0 的時(shí)候究竟能看到什么。也許沒(méi)有穩(wěn)定的 ABI，但是一定會(huì)有重要的新功能加入。

ABI 將允許未來(lái) Swift 版本開(kāi)發(fā)的應(yīng)用程序和編譯庫(kù)可以在二進(jìn)制層次上與 Swift 3.0 版本的應(yīng)用程序和編譯庫(kù)相互調(diào)用。這樣，ABI的穩(wěn)定性將保證一定程度的二進(jìn)制兼容性，并且第三方更容易發(fā)布二進(jìn)制庫(kù)。另外，ABI 將允許刪除需要的 Swift 標(biāo)準(zhǔn)庫(kù)和二進(jìn)制文件，就像目前情況下通過(guò)Xcode創(chuàng)建的 iOS 和 OS X 應(yīng)用程序一樣。

補(bǔ)充

LLVM

補(bǔ)充：LLVM的三層結(jié)構(gòu)

第一層：Clang 編譯器，負(fù)責(zé)編譯各種語(yǔ)言

第二層：代碼優(yōu)化器，通過(guò)模塊化操作優(yōu)化代碼，是 Bitcode 邏輯的主要部分

第三層：代碼翻譯器，針對(duì)不同平臺(tái)和 GPU 將代碼翻譯成機(jī)器語(yǔ)言

補(bǔ)充：LLDB，llbc++，compile rt

LLDB: 一個(gè)有著 REPL 的特性和 C++ ,Python 插件的開(kāi)源調(diào)試器。LLDB 綁定在 Xcode 內(nèi)部，存在于主窗口底部的控制臺(tái)中；

libc++，libc++ ABI: 高性能 C++ 標(biāo)準(zhǔn)庫(kù)實(shí)現(xiàn)，支持 C++ 11

compiler-rt：為 LLVM 和 Clang 設(shè)計(jì)的編譯器擴(kuò)展函數(shù)庫(kù)。針對(duì) __fixunsdfdi 和其他目標(biāo)機(jī)器上沒(méi)有一個(gè)核心 IR (intermediate representation) 對(duì)應(yīng)的短原生指令序列時(shí)，提供高度調(diào)優(yōu)過(guò)的底層代碼生成支持。

ABI 是什么？

Application Binary Interface，中文名：應(yīng)用二進(jìn)制接口。是 APP 和 操作系統(tǒng)、其他應(yīng)用之間的二進(jìn)制接口。它包括以下細(xì)節(jié)：

數(shù)據(jù)類(lèi)型的大小、布局和對(duì)齊;

調(diào)用約定（控制著函數(shù)的參數(shù)如何傳送以及如何接受返回值），例如，是所有的參數(shù)都通過(guò)棧傳遞，還是部分參數(shù)通過(guò)寄存器傳遞；哪個(gè)寄存器用于哪個(gè)函數(shù)參數(shù)；通過(guò)棧傳遞的第一個(gè)函數(shù)參數(shù)是最先push到棧上還是最后；

系統(tǒng)調(diào)用的編碼和一個(gè)應(yīng)用如何向操作系統(tǒng)進(jìn)行系統(tǒng)調(diào)用；

以及在一個(gè)完整的操作系統(tǒng)ABI中，目標(biāo)文件的二進(jìn)制格式、程序庫(kù)等等。

16. Swift 在服務(wù)器，或者 Linux 上可以說(shuō)運(yùn)行得不錯(cuò)。你們是一開(kāi)始就計(jì)劃在服務(wù)器或者系統(tǒng)端運(yùn)行 Swift，還是說(shuō)你們更希望 Swift 專(zhuān)注于 iOS 開(kāi)發(fā)，而不是去與 python 或 Rails 競(jìng)爭(zhēng)？

你如果去看蘋(píng)果官方的 Swift 書(shū)，里面有這樣一句：“Swift 的目標(biāo)是，上能寫(xiě)應(yīng)用程序，下能寫(xiě)操作系統(tǒng)（Swift was designed to scale from hello world to an entire operating system）”。所以我們一開(kāi)始，就是要將它創(chuàng)作成為一門(mén)一統(tǒng)天下的語(yǔ)言。

這也許有點(diǎn)癡人說(shuō)夢(mèng)，但是大家等著，過(guò)幾年就知道了。無(wú)論是我還是蘋(píng)果的其他人，都把 Swift 當(dāng)成是未來(lái)世界的主流語(yǔ)言來(lái)看的，它將會(huì)超越 Python，甚至有一天取代 C。那么我們是怎么實(shí)現(xiàn)這一步的呢？

開(kāi)源是重要的一環(huán)。你不開(kāi)源，別的平臺(tái)就不大想用這個(gè)語(yǔ)言。當(dāng)各種各樣的開(kāi)發(fā)都采用 Swift ，Swift 一統(tǒng)天下的目標(biāo)也就越來(lái)越現(xiàn)實(shí)?，F(xiàn)在很多學(xué)校的計(jì)算機(jī)基礎(chǔ)教育就在教 Swift，它越來(lái)越流行了。

所以嘛，第一步我們就是讓這個(gè)語(yǔ)言流行起來(lái)，讓大家使用它。我對(duì)“流行”的定義是，Swift 必須要有一個(gè)殺手級(jí)的產(chǎn)品，這樣大家就會(huì)知道 Swift 有多好，大家都會(huì)使用它?，F(xiàn)在 iOS 平臺(tái)和 Mac OS 平臺(tái)有很多非常棒的 Swift 應(yīng)用。這樣我們開(kāi)始第二步，開(kāi)源。第三步，我們要走得更遠(yuǎn)。

什么叫走得更遠(yuǎn)？我覺(jué)得現(xiàn)在我們要做的就是把 Swift 應(yīng)用到服務(wù)器端。其實(shí)服務(wù)器和移動(dòng)應(yīng)用開(kāi)發(fā)頗有類(lèi)似，比如架構(gòu)設(shè)計(jì)和函數(shù)庫(kù)調(diào)用上。但是，唯一的麻煩就是我們得讓 Swift 能在 Lunix 上流暢運(yùn)行。同時(shí)構(gòu)建大量服務(wù)器端的庫(kù)函數(shù)。現(xiàn)在 Swift.org 上已經(jīng)有專(zhuān)門(mén)的版塊討論服務(wù)器端上的開(kāi)發(fā)了，大家集思廣益的感覺(jué)非常好。

再接下來(lái)，Swift 要取代 Java，無(wú)論是腳本語(yǔ)言還是底層的系統(tǒng)設(shè)計(jì)，Swift 最終都應(yīng)該能應(yīng)付自如。

腳本語(yǔ)言上，開(kāi)源社區(qū)和我們蘋(píng)果內(nèi)部都在嘗試將正則表達(dá)式、多行字符串等腳本語(yǔ)言的特征都加入到 Swift 當(dāng)中，雖然工作量很大，但我認(rèn)為它們最終都將成為 Swift 的一個(gè)部分。

系統(tǒng)開(kāi)發(fā)方面，我覺(jué)得取代 Java 最重要的一點(diǎn)就是 Swift 一定要有自己的特色。我覺(jué)得 Rust 是一個(gè)不錯(cuò)的語(yǔ)言，雖然現(xiàn)在沒(méi)多少人用。Swift 在某些頂層開(kāi)發(fā)上要明顯優(yōu)于 Rust。再等過(guò)些年，當(dāng) Swift 在系統(tǒng)開(kāi)發(fā)上真正流行起來(lái)之時(shí)，Swift 就離一統(tǒng)天下不遠(yuǎn)了。

17. 對(duì)于 Swift 在服務(wù)器上的發(fā)展，你覺(jué)得交給開(kāi)源社區(qū)去做就足夠了嗎？蘋(píng)果自己會(huì)不會(huì)推出面向服務(wù)器端的 Swift 函數(shù)庫(kù)？

首先我覺(jué)得若要成為服務(wù)器端的流行語(yǔ)言，這幾個(gè)部分 Swift 必須具備：編碼和解碼，網(wǎng)絡(luò)傳輸協(xié)議，HTTP。這些部分我覺(jué)得要成為標(biāo)準(zhǔn)函數(shù)庫(kù)，因?yàn)樗鼈兪亲罨镜臇|西，蘋(píng)果內(nèi)部自己來(lái)做也許更好，因?yàn)槟艽_保質(zhì)量。對(duì)于具體的網(wǎng)絡(luò)應(yīng)用函數(shù)庫(kù)，我覺(jué)得短期內(nèi)沒(méi)必要。這是因?yàn)闃I(yè)界內(nèi)部對(duì)此就爭(zhēng)議很大，如同 Ruby on Rails 那樣的王者框架還沒(méi)有出現(xiàn)。

我覺(jué)得對(duì)開(kāi)源社區(qū)而言，最重要是兩個(gè)工作。第一，是 Swift 的包管理器（Package Manager）。這個(gè)可以讓我們?cè)诙鄠€(gè)平臺(tái)、不同函數(shù)庫(kù)之間協(xié)同工作，大幅提高兼容性和效率；第二，是并發(fā)模型（Concurrency Model）。Go 語(yǔ)言之所以在服務(wù)器和云端開(kāi)發(fā)這么受歡迎，就是因?yàn)椴l(fā)模型做得好。并發(fā)模型應(yīng)該會(huì)集成在 Swift 5 中。

18. 現(xiàn)在 Swift 在服務(wù)器端還不是那么成熟。有人說(shuō) Swift 不過(guò)是寫(xiě) App 的一門(mén)語(yǔ)言。現(xiàn)在已經(jīng) 3.0 版本了，大家貌似都還只是將 Swift 用來(lái)寫(xiě)寫(xiě) iOS 應(yīng)用。你怎么看？

我現(xiàn)在根本不擔(dān)心 Swift 在服務(wù)器端最后不會(huì)成功。很多人寫(xiě)了幾年 Swift，自以為很懂這門(mén)語(yǔ)言。當(dāng) Swift 具備服務(wù)器端特性的時(shí)候，蘋(píng)果一定會(huì)跟大家說(shuō)，你看 Swift 能做這個(gè)那個(gè)，你用其他語(yǔ)言來(lái)寫(xiě)就要麻煩得多。

現(xiàn)在最大的問(wèn)題是大家還覺(jué)得 Swift 只是蘋(píng)果自己搞出來(lái)的東西。他們覺(jué)得 Swift 不過(guò)是蘋(píng)果自己的玩具，只能用在蘋(píng)果自己的 iOS 系統(tǒng)和 Mac OS 系統(tǒng)上。所以我們應(yīng)該加大開(kāi)源和構(gòu)建社區(qū)的力度?，F(xiàn)在外行對(duì)于 Swift 的態(tài)度還可以接受，慢慢地 Swift 就會(huì)在系統(tǒng)開(kāi)發(fā)領(lǐng)域追上來(lái)。

19. 大家似乎都在期待 Swift 能在網(wǎng)頁(yè)開(kāi)發(fā)上有所建樹(shù)?，F(xiàn)在網(wǎng)頁(yè)或者網(wǎng)絡(luò)程序開(kāi)發(fā)方面，一般是多種語(yǔ)言混用，前端和后端可能語(yǔ)言邏輯完全不一樣，你對(duì)此怎么看？

這可能要花很長(zhǎng)時(shí)間，要是能取代 Java 那就簡(jiǎn)直了。現(xiàn)在 Dart 在網(wǎng)頁(yè)開(kāi)發(fā)上做的不錯(cuò)。我個(gè)人看好 asm.js 和 WebAssembly，它們都是通過(guò) LLVM 編譯的，跟 Swift 一樣。如果這兩個(gè)今后做得足夠好，也許就沒(méi) Swift 什么事了。未來(lái)之事，都很難說(shuō)。

而且我現(xiàn)在發(fā)現(xiàn)，Java 已經(jīng)變成一門(mén)基礎(chǔ)語(yǔ)言了。我看很多腳本語(yǔ)言現(xiàn)在都直接編譯成 Java，Java 就像比特一樣成為一個(gè)最基本的表達(dá)方式。我覺(jué)得五年之后，很有可能 asm.js 會(huì)一統(tǒng)網(wǎng)頁(yè)端。雖然大家說(shuō) Java 不好 debug，但其實(shí)就算你寫(xiě) C 這么成熟的語(yǔ)言，debug 起來(lái)依然很頭疼。這也是我們?yōu)槭裁床辉?Swift 中加入宏定義，因?yàn)槟莻€(gè)給編譯和 debug 增加了難度。

Swift 語(yǔ)言設(shè)計(jì)

20. Swift 好像一開(kāi)始就設(shè)計(jì)得簡(jiǎn)單易懂、而同時(shí)又有很多高階的復(fù)雜操作。經(jīng)驗(yàn)豐富的程序員可以寫(xiě)出漂亮的語(yǔ)法糖，對(duì)編程一竅不通的小孩也可以玩轉(zhuǎn) Playground。你認(rèn)為 Swift 是一門(mén)將復(fù)雜和簡(jiǎn)易融為一體的語(yǔ)言嗎？

Swift 在這點(diǎn)上目前做得還不錯(cuò)。但我擔(dān)心開(kāi)源之后大量的新功能添加進(jìn)來(lái)，使得 Swift 不再簡(jiǎn)單。我一直致力于讓 Swift 成為一門(mén)簡(jiǎn)單易學(xué)的語(yǔ)言，同時(shí)又足夠強(qiáng)大。你想我們?yōu)槭裁床恢С謨?nèi)聯(lián)匯編 (inline assembly support) 這樣的功能，就是只有極少數(shù)極客會(huì)喜歡。以后我們也要秉持這個(gè)原則。

一個(gè)不會(huì)寫(xiě) Swift 的人。打開(kāi) Playground，敲下 “print("Hello World")”，旁邊就會(huì)顯示出來(lái)，這點(diǎn)跟 python 很像，你不用去打"n"這樣的換行符號(hào)。也就是說(shuō) Swift 對(duì)于新手來(lái)說(shuō)非常友好，我們可以從 Hello World 開(kāi)始逐步深入，從簡(jiǎn)單慢慢過(guò)渡到復(fù)雜。

對(duì)于系統(tǒng)開(kāi)發(fā)而言，Swift 相比 Rust，會(huì)更好的自動(dòng)控制內(nèi)存分配，因?yàn)槲覀兛梢越梃b開(kāi)發(fā) ARC 時(shí)的經(jīng)驗(yàn)。你想內(nèi)存分配這種底層的東西，也只有少數(shù)大牛能精通。那為什么不把 ARC 引入到底層來(lái)簡(jiǎn)化開(kāi)發(fā)呢？我覺(jué)得這是 Swift 開(kāi)發(fā)的另一個(gè)方向。

21. 有人說(shuō) Swift 是大雜燴，一部分借鑒 C#，一部分借鑒 Java，一部分借鑒 Objective-C，你是怎么看的？

Swift 確實(shí)是大雜燴。但是它并不是簡(jiǎn)單的模仿其他語(yǔ)言，而是借鑒，然后創(chuàng)造出一個(gè)偉大的語(yǔ)言。我們確實(shí)參考了大量其他的語(yǔ)言設(shè)計(jì)。比如 Haskell 很多概念就被引入到 Swift 中。Swift 中的 Protocol，就是從 Haskell 的 construct 中得到啟發(fā)的。

還有其他部分長(zhǎng)得像 Dart，亦或是借鑒了 Go 和 C#。這樣做也有另一個(gè)好處，開(kāi)發(fā)者拿到 Swift 的時(shí)候會(huì)有種似曾相識(shí)的感覺(jué)，這樣大家也更愿意用 Swift 開(kāi)發(fā)。

Swift vs. Objective-C

22. 給我個(gè)現(xiàn)在就學(xué)習(xí) Swift 的理由？

這個(gè)其實(shí)無(wú)所謂。我個(gè)人不覺(jué)得 Objective-C 會(huì)短期內(nèi)被取代，蘋(píng)果依然支持 C 和 C++，而且放棄 Objective-C 對(duì)蘋(píng)果來(lái)說(shuō)有百害而無(wú)一利。你不必一定要學(xué)習(xí) Swift，Swift 只是一門(mén)更好的語(yǔ)言。

說(shuō)到 Swift，我們給它取這個(gè)名字就意味著我們希望這門(mén)語(yǔ)言非常得高效。它本身設(shè)計(jì)的目的不是讓你短時(shí)間內(nèi)寫(xiě)大量代碼，而是用最少的時(shí)間、最簡(jiǎn)潔的代碼來(lái)完成工作。

編程其實(shí)包括方方面面，不僅僅是寫(xiě)代碼，還有 debug，給各種系統(tǒng)適配，以及其他各種事情。其實(shí)開(kāi)發(fā)的時(shí)間短，找 bug 的時(shí)間一般都會(huì)很長(zhǎng)。比如在 Objective-C 中，你會(huì)花不少時(shí)間修 unrecognized-selector error，但是 Swift 從頂層設(shè)計(jì)中就排除了這類(lèi) bug。

Swift 還有其他一些好處。比如可以對(duì)字符串使用 switch...case...語(yǔ)句；可以使用 functional programming；可以用 enum 和 protocol。Swift 其實(shí)是一門(mén)包羅萬(wàn)象的語(yǔ)言，菜鳥(niǎo)和老手寫(xiě)出來(lái)的 Swift 可以完全不一樣，這取決于經(jīng)驗(yàn)。

我最近發(fā)現(xiàn)，很多 iOS 開(kāi)發(fā)者會(huì)把 Swift 當(dāng) Objective-C 來(lái)寫(xiě)，邏輯結(jié)構(gòu)完全一樣，只是換個(gè)語(yǔ)法。其實(shí)這就意味著他們沒(méi)有意識(shí)到 Swift 的價(jià)值 -- 認(rèn)為 Swift 不過(guò)是 Objective-C 的替代品。當(dāng)開(kāi)發(fā)者深究 Swift 的語(yǔ)法后，他們才會(huì)意識(shí)到這是一門(mén)多么高效的語(yǔ)言。

23. 會(huì)不會(huì)像 Objective-C 一樣，在未來(lái) Swift 添加一些動(dòng)態(tài)特性？

Swift 目前沒(méi)有加入動(dòng)態(tài)特性的計(jì)劃。很多人問(wèn)為什么 Swift 不能有響應(yīng)，reflection這些特性。甚至有人寫(xiě)博客說(shuō)，“遲早有一天，蘋(píng)果要重寫(xiě) Swift 的所有架構(gòu)”，我每次在 WWDC 前看到這些博客都會(huì)呵呵。很多人不明白什么叫動(dòng)態(tài)性，也不關(guān)心我們發(fā)布的 Swift 計(jì)劃表，只是不停的寫(xiě)博客，預(yù)測(cè)這個(gè)吐槽那個(gè)。

我個(gè)人可以明確表示，Swift 近期內(nèi)沒(méi)有加入動(dòng)態(tài)特性的計(jì)劃。凡事有輕重緩急，我們得先處理其他事情，比如并發(fā)模型，比如在系統(tǒng)端上的優(yōu)化，比如腳本的適配。不過(guò)以后如果有時(shí)間，Swift 會(huì)加入動(dòng)態(tài)特性的，前提是我們計(jì)劃表里的事情都做完了。

24. 你不擔(dān)心沒(méi)有動(dòng)態(tài)特性，很多 Objective-C 的程序員會(huì)各種不適應(yīng) Swift，然后就放棄用 Swift 了嗎？

我不擔(dān)心啊。Swift 本身支持 Objective-C 上的所有特性，你只需要那部分代碼使用 Objective-C 兼容，然后把它們加入到 runtime 中即可。

雖然有很多人說(shuō)，我就是想寫(xiě)純粹的 Swift 代碼，但其實(shí)我不覺(jué)得這是一種倒退。你可以使用 reflection 模型，要用這個(gè)功能你用就是了，自己設(shè)計(jì)的代碼結(jié)構(gòu)自己負(fù)責(zé)。在寫(xiě)代碼這事上，從來(lái)沒(méi)有非黑即白一說(shuō)，我們要做最重要的事，而不是天天在推特上開(kāi)聽(tīng)證會(huì)。Swift 核心組做的工作就是把關(guān) Swift 開(kāi)發(fā)，把這門(mén)語(yǔ)言導(dǎo)向一個(gè)正確的方向。

Swift 編程規(guī)范

25. Swift 現(xiàn)在好多語(yǔ)法糖。怎樣避免寫(xiě)出奇怪和低效的 Swift 代碼？你覺(jué)得現(xiàn)在 Swift 可以稱(chēng)得上成熟嗎？

現(xiàn)在正是 Swift 成熟之時(shí)。Swift 1 和 Swift 2 的時(shí)候，確實(shí)語(yǔ)言的變化很大，大家很頭疼。但是 Swift 3.0 是一個(gè)穩(wěn)定成熟的版本，它真的不錯(cuò)。之后的工作是在 Swift 3.0 的基礎(chǔ)上增加新的函數(shù)庫(kù)或者功能，而不是修改現(xiàn)有的架構(gòu)。

其實(shí) Swift 開(kāi)發(fā)者也在糾結(jié)語(yǔ)法糖太多的問(wèn)題。我聽(tīng)說(shuō)一些人出了一些 Swift 的書(shū)籍，這很好。其實(shí)我們?cè)谠O(shè)計(jì) Swift 的時(shí)候，就考慮到語(yǔ)法糖的問(wèn)題了。比如你寫(xiě)代碼，把所有變量都用 var，這時(shí)候編譯器會(huì)提醒你對(duì)常量使用 let。這說(shuō)明一點(diǎn)，Swift 是鼓勵(lì) immutable 數(shù)據(jù)類(lèi)型的，并且 Xcode 也會(huì)自動(dòng)督促你寫(xiě)出更規(guī)范的代碼。不過(guò)目前對(duì)于“是該用 class 還是 struct？”這類(lèi)比較困難的問(wèn)題，編譯器還沒(méi)智能到能自動(dòng)檢測(cè)并糾正。

26. 有些語(yǔ)言一開(kāi)始就有設(shè)定好的語(yǔ)法糖和規(guī)范。為什么 Swift 沒(méi)有這樣，而是讓開(kāi)源社區(qū)去討論？你個(gè)人對(duì) Swift 有沒(méi)有一些編程規(guī)范？

作為一個(gè)程序員，我骨子里流淌著編程規(guī)范的血液。但在 Swift 的開(kāi)發(fā)過(guò)程中，我還是改變了一些固有觀念。比如說(shuō)，我認(rèn)為所有代碼代碼段都應(yīng)該是一個(gè)地方輸入，一個(gè)地方輸出。但我后來(lái)發(fā)現(xiàn)這樣設(shè)計(jì)語(yǔ)言很難維護(hù)，可讀性也不佳。 比如說(shuō)我們?cè)O(shè)計(jì)的 guard else 語(yǔ)句，你一定要在末尾寫(xiě)上 return 之類(lèi)的結(jié)束語(yǔ)。這就導(dǎo)致了一個(gè)函數(shù)有多個(gè)地方輸出：你在 guard else 里 return，在其他地方也 return，不符合我原來(lái)的設(shè)想。但是如此設(shè)計(jì)會(huì)令安全性提高，因?yàn)槲覀儼岩恍┨厥馇闆r給提前處理掉了。

對(duì)于空格這種格式問(wèn)題，我個(gè)人傾向于空 2 格。我知道有些人喜歡空 4 格，還有人喜歡 3 格（因?yàn)樗麄冇X(jué)得文件中不應(yīng)該有 tab）。這完全是蘿卜青菜各有所愛(ài)，大家對(duì)此爭(zhēng)論不休，哪一種都有一定道理。所以我們最后也沒(méi)有對(duì) Swift 提出固定的格式要求，大家寫(xiě)出自己喜歡的代碼就行。但是這也造成了一定程度的混亂 -- 你寫(xiě)的代碼格式會(huì)與同事的完全不同。但是我覺(jué)得這并不會(huì)影響語(yǔ)言的多樣性。

Go 當(dāng)年強(qiáng)行推廣了一套編程規(guī)范，結(jié)果到現(xiàn)在仍有爭(zhēng)議。我們現(xiàn)在的工作不是做語(yǔ)法上面的規(guī)范，而且我們也不希望推出一套規(guī)范后大家好不買(mǎi)賬。開(kāi)源的另一個(gè)好處是，大家可以自行決定什么是好的語(yǔ)法規(guī)范。就算有時(shí)間我個(gè)人或者 Apple 也不會(huì)去寫(xiě) Swift Style Guide。比起規(guī)范我更愿意去回答理論和語(yǔ)言設(shè)計(jì)上的問(wèn)題。

有一件趣事我想分享，我一直擔(dān)心別人會(huì)問(wèn)，為什么 Swift 的函數(shù)名叫 func？而不叫 function 或者 fn？這其實(shí)頗有爭(zhēng)議。不過(guò)現(xiàn)在已經(jīng)是 Swift 3.0 時(shí)代了，大家這樣用得很順，我們也不會(huì)去更改了，所以爭(zhēng)論于此沒(méi)有意義。

RxSwift 以及響應(yīng)式編程

27.很多開(kāi)發(fā)者用 RxSwift 或者其他響應(yīng)式編程。你在開(kāi)發(fā) Swift 過(guò)程中有沒(méi)有仔細(xì)研究過(guò)響應(yīng)式編程這些？

我已經(jīng)開(kāi)始關(guān)注 RxSwift 了。但是我自己沒(méi)用響應(yīng)式編程來(lái)開(kāi)發(fā)過(guò)產(chǎn)品，所以我對(duì)它們的理解來(lái)自于博客。RxSwift 看起來(lái)很棒，你可以少寫(xiě)很多代碼，而且似乎開(kāi)發(fā)效率也會(huì)更高。但聽(tīng)說(shuō)維護(hù)和測(cè)試起來(lái)也很難，有優(yōu)點(diǎn)也有缺點(diǎn)。

如果我有空寫(xiě)一個(gè) App 的話，我肯定回去試試 RxSwift，然后再過(guò)來(lái)發(fā)表觀點(diǎn)。我現(xiàn)在不敢說(shuō)”強(qiáng)烈推薦”，或者“強(qiáng)烈不推薦”之類(lèi)的話。

Garbage Collection vs. ARC

28. 我們都知道 Garbage Collection 和 ARC 各有千秋。Objective-C 有 Garbage Collection，后來(lái)加入了 ARC 的機(jī)制。Swift 則是完全 ARC。你能說(shuō)說(shuō)為什么你們那么看好 ARC 嗎？

Objective-C 最開(kāi)始是基于 Libauto 系統(tǒng)開(kāi)發(fā)的，而 Libauto 本身就有諸多限制，所以我們當(dāng)時(shí)采用了 Garbage Collection。我個(gè)人覺(jué)得 ARC 完全要優(yōu)于 Garbage Collection，因?yàn)楹笳呓?jīng)常在內(nèi)存上回收一下我們不想回收的變量。所以我們?cè)?Objective-C 上采用了引用計(jì)數(shù)和 ARC。

ARC 最重要的一個(gè)優(yōu)勢(shì)就是，它很好的處理了 final 這類(lèi)參數(shù)。如果你用 Garbage Collection，比如 java 吧，final 參數(shù)就是那些不被回收一直在跑的東西，這樣展開(kāi)講問(wèn)題是一籮筐。我舉個(gè)最簡(jiǎn)單的例子，當(dāng)有個(gè) final 變量運(yùn)行在一個(gè)錯(cuò)誤的線程上時(shí)，它會(huì)多次重跑，導(dǎo)致實(shí)例被不停的創(chuàng)建。ARC 則是從根本上解決了這個(gè)問(wèn)題。

目前反對(duì) ARC 的理由主要有兩個(gè)，一是人們覺(jué)得 ARC 引入了額外的開(kāi)銷(xiāo)，因?yàn)槟阋S護(hù)引用計(jì)數(shù)嘛。另一個(gè)是 ARC 容易造成循環(huán)引用。

我個(gè)人要強(qiáng)調(diào)的是，這些毛病 Garbage Collection 也有。除此之外 Garbage Collection 還不能終止所有的線程，或者在特定的一個(gè)時(shí)間點(diǎn)終止一個(gè)線程。這是因?yàn)?Garbage Collection 引入了安全指針（safepoint），這同樣也是一筆額外的開(kāi)銷(xiāo)。

ARC 中引用計(jì)數(shù)的開(kāi)銷(xiāo)在實(shí)際開(kāi)發(fā)中影響不大。而且我們對(duì)對(duì)象的整個(gè)生命流程都有掌控，而這是 Garbage Collection 不具備的。實(shí)際上我覺(jué)得 ARC 中有些額外開(kāi)銷(xiāo)是必須的，那些不必須的開(kāi)銷(xiāo)以后也會(huì)慢慢改進(jìn)的。

至于循環(huán)引用的問(wèn)題。相比于你必須在具體的一行說(shuō)明，retain/malloc 這個(gè)變量，然后再在后面某一行說(shuō)明，release/free這個(gè)變量這種麻煩事，你只需要用 strong 或者 weak 表示你對(duì)對(duì)象的所有權(quán)，你省去了大量思考內(nèi)存分配的擔(dān)憂和操作，這難道不是一個(gè)巨大的進(jìn)步嗎？

身后之事

29.把 Swift 交給 Ted 你放心嗎？

完全不用擔(dān)心。

Ted 這人實(shí)力非常強(qiáng)。斯坦佛的博士生畢業(yè)，蘋(píng)果十年工作經(jīng)驗(yàn)，曾經(jīng)以一己之力完成了 Clang 的靜態(tài)分析器。Ted 在管理方面也很優(yōu)秀。我有時(shí)候會(huì)突發(fā)奇想，讓手下一個(gè)人或者一個(gè)組去做“我認(rèn)為有意義”的項(xiàng)目。Ted 則是非常穩(wěn)健的管理者，他總會(huì)領(lǐng)導(dǎo)組員去做最重要的事情，這就是我跟他的不同。

另外我們的小組也很強(qiáng)，核心團(tuán)隊(duì)的幾個(gè)人：Doug Gregor, John McCall, Joe Groff, Dave Abrahams。這幾個(gè)人都是極其優(yōu)秀的極客。Swift 其他團(tuán)隊(duì)的工程師也很給力。有他們?cè)冢瑳](méi)有任何理由 Swift 不會(huì)成功。

30. 你為什么去做電動(dòng)車(chē)？

首先我個(gè)人非常喜歡車(chē)。但我又懶得自己老是去加油啊、開(kāi)車(chē)，我更喜歡一種更可靠的方式，最好我自己啥也不用做，車(chē)子就可以把我送到目的地。我也不需要擔(dān)心維護(hù)啊什么的。我其實(shí)是特斯拉最早的一批客戶(hù)，我覺(jué)得特斯拉駕駛起來(lái)很開(kāi)心。

不過(guò)我重來(lái)沒(méi)想過(guò)我會(huì)去一家汽車(chē)公司任職，因?yàn)槲矣X(jué)得我是個(gè)程序員，這跟汽車(chē)有啥關(guān)系？不過(guò)特斯拉讓我去做自動(dòng)駕駛系統(tǒng)，這個(gè)就很對(duì)我胃口了。因?yàn)檫@也是世界級(jí)的難題，我想嘗試挑戰(zhàn)一下。