iOS虛擬機器對於Cocoa編程是必然的嗎？

免責聲明：整篇文章或者是我的推測與願望，或者是一篇控告。

介紹：批評Objective-C

程式員，旁觀者和學者已經批評Objective-C好長時間了。

關於語言和API的抱怨包括缺少多元組，子串(slices)，散列表或者在文法層級類似的結構;缺少編程模板;缺少命名空間;方法缺少預設參數;缺少運算子多載;不成熟的記憶體回收行程(iOS上就沒有記憶體回收機制);冗長的命名轉換;缺少包管理;對商用API比如REST、SOAP、SQL等待缺少原生的支援。即使是最經常被嘲笑的方法的方括弧格式也應該改變(或者修正)。

這些孤立的批評都不是代替Objective-C的理由。你可能會說如果Objective-C需要改變這麼多方面，那麼也許最好的方式就是替換掉整個語言。

但是代替主要的開發語言對於Team Dev來說是不悅的。蘋果也不會為了美學或者極小的特色來做這個事情。代替某一語言的理由必須是更實用和更功能化的。

更為中肯的是一個Objective-C不能修改的特性：關於C本身的抱怨，特別是C中的指標。

如果說與C在代碼層相容是Objective-C最好的特性，直接記憶體模型就是Objective-C的最不受歡迎的特性。

直接存取記憶體模式在正在逐漸消亡

直接存取記憶體模式，特別是使用C語言的項目正在變得越來越不受歡迎。

根據下面的表單20個最流行的程式設計語言(不完全是一個科學資源，但是也具有說服力)，僅僅32%的人仍然使用直接儲存模式的語言(C,C++,Objective-C，Pascal，Delphi)。在10年的時間裡，你可能不會在除核心、驅動、遊戲和底層嵌入式軟體之外的項目中看到直接存取記憶體的語言。

這意味著無論蘋果是否反對直接存取記憶體的APIs(很可能他們不會)，無論他們是否引入一個新的語言，蘋果的官方程式環境會具有虛擬儲存模式(an abstracted memory model)。

在儲存虛擬化中的程式虛擬機器的作用

技術上看，當前Objective-C的記憶體回收行程是一個虛擬儲存模式。但是我把它排除在外因為它不是完全的虛擬儲存模式，而且只要Objective-C包含C指標，那麼它就永遠不會是。

僅僅因為你不需要釋放記憶體，並不意味著不會有其他記憶體問題。你仍然有指標，這些指標仍然可能指向某些東西。你仍然可能數組越界。你仍然可能使緩衝區溢位。你仍然可能碰巧重寫了某一個記憶體地區。甚至可能你使記憶體回收行程回收了正在使用的資源。

這是相當抽象的漏洞。

不用一個真正意義上的虛擬機器來建立一個虛擬儲存模型是可能的(可以參見下面一個不同方式)但是虛擬機器允許你鎖住虛擬部分因此不會有任何意外的漏洞。你不再需要指標。你不會輕易地覆蓋記憶體。你無法使數組越界。你無法是緩衝區溢位。

虛擬機器通過移去提供直接擷取記憶體的指令而實現上述功能。相反，虛擬機器上的指令只與對象、屬性和值相關聯—你不能擷取記憶體的錯誤區塊，而且記憶體回收機制相對傳統方式也會是更有效，因為所有儲存的引用是完全確定的。

關於我提到的“虛擬機器”的定義：“虛擬機器”描述一台沒有直接依附於某一特定機器的電腦，而是映射到某一確定的機器。這種映射正常情況可以通過運行解釋(比如指令碼語言)，運行模擬(比如電腦模擬器)或者Just-In-Time 編譯為原始機器語言(比如java的JVM)來實現。無論該“虛擬機器”的運行方式如何，關鍵是程式員只需處理虛擬方案而目標機器的確切結構和行為不會直接涉及到。

平台獨立性

第二個關於虛擬機器的討論與語言關係不大：平台獨立性。

蘋果在17年中兩次改變CPU架構。不久又將發生一次。雖然向intel CPUs的改變難以置信的順利(我對它的無縫轉變感到震驚)，但還需要相當長的時間來等待大部分程式的intel版本以及其他的開發人員來完成全部的轉換工作。

考慮到蘋果在iOS裝置上的額外努力，設想一系列不同的CPUs可以在一套裝置上使用是可能的，fat binaries只能為少量CPUs提供便利。如果蘋果打算使用一系列不同的CPUs，那麼單獨的位元組碼運行是唯一的方式。

好的編程應該避免代碼只能適用於某一特定的硬體裝置。將CPU和平台從程式中獨立出來是一個符合邏輯的步驟。

在不同CPUs上運行這個主題，一個有趣的點是蘋果最近確實引入了一個新的平台獨立的語言：OpenCL，該語言在JIT編譯虛擬機器上運行。我無法預見是否有趨勢要利用OpenCL重新實現Cocoa(這個方式比Objective-C更加神秘)但是實現它的技術當然是存在的。

不利用新語言的虛擬機器

需要注意的一點就是在新語言之前可以先引入虛擬機器。

如果蘋果判斷對互動儲存管理的恐懼使開發人員望而止步，但是又不準備一步完成到新語言的轉變，先轉換到虛擬機器(獲得虛擬儲存模式的好處)是可能的，而同時使得代碼層的變動相對更小。

雖然這看起來是個奇怪的事物，但確實有兩項好處。

第一個是在虛擬機器內啟動並執行Objective-C可以更簡單地與虛擬機器外的原始Objective-C建立橋接。如果你記得蘋果曾經放棄橋接Java和Objective-C，當時最大的技術痛點是Java看待一個對象的動態執行性不如Objective-C，而且Java不能跟蹤在Objective-C這一端方法和指標的改變。橋接一個虛擬機器中的語言到虛擬機器外的語言在這個模型裡是相對簡單的。

第二個是當前Cocoa是適合Objective-C特點設定的。僅使用虛擬機器可以保持Cocoa本質的相似性，使得蘋果的開發工作更簡單。

更新：Jesper曾經指出這一點而且解釋為什麼虛擬化Objective-C同時保持與非虛擬化的Objective-C的相容性可能不是一個好注意。

簡而言之：，一個虛擬化版本的Objective-C(比如它之前的C++.NET)需要移去大量的語言特性或者它需要拋出運行異常如果你的代碼違反了一系列的規則(相當於沒有解決虛擬儲存問題)。

一個不同的方式

當然，僅僅因為上面所提到的優點，並不意味這虛擬機器肯定就是Mac 開發改善下一個步驟。

確實存在可編譯，記憶體回收，儲存安全的不需要虛擬機器的語言，該語言完全滿足虛擬儲存模式的要求，：Google’s Go language就是一個例子。

讓蘋果接受Go是不可能的。不要提Go還在開發，一個問題就是Go不能與Objective-C橋接。實際上，Go目前還不能輕易地與C或者C++橋接。

確實轉移到一個類似Go的語言上來需要一個空白間斷，即會有向前的相容性的問題。這個間斷是可能的(Carbon引入到Cocoa就是這樣一個間斷)，我認為更可能的方式是蘋果會選擇通過使用自訂語言或者某一已存語言中的自訂變數來保持一定的互用性。我這樣懷疑的原因是蘋果曾經有機會來代替Cocoa(在iOS上)，但是它選擇保持原有設計。我懷疑他們已經決定在未來Mac上繼續使用Cocoa，即使語言和環境已經改變了。

虛擬機器能夠提供的更好的向前相容性，橋接性和可移植性在加上現代JIT出色的運行能力，導致我認為非虛擬機器的選擇不能提供足夠的靈活性而且非虛擬機器的方式帶來的優點並不足以抵消語言改變而帶來不便。

結論

顯然，我熱愛Objective-C和Cocoa;我確信從我的部落格和關於它的特點的辯論文章可以明了我的觀點。我並不同意上面所列出的大部分的批評。我認為這些批評是淺薄，或者他們太哲學化了而且技術上被誤導。

但是Mac開發人員無法對抗一個勢不可擋的完全虛擬化儲存模型的趨勢，這個趨勢已經在Mac相關開發之外大範圍的展開。

更進一步，我不認為朝向虛擬機器的趨勢是值得去反抗的。當前Cocoa和Mac編程的主要特色：關注細節，widget運行方式，方法，類和APIs都不會改變。實際上，大部分Cocoa仍然可以保持原樣。

最終我確信Apple會轉向一個新的語言;

現在真得不用著急做這些。當然iOS裝置目前不需要這些。甚至是在Mac上，我認為在某些事情發生之前，還會有幾年的警示和準備，當最終發生時不需要強制的轉變。

當我說目前不用著急，我意味著：我認為在10年之內，你仍然可以為Mac發布新的，非虛擬機器的，Cocoa/Objective-C開發的程式(同時，如果你願意你仍然可以寫Carbon程式)。我只是不認為Carbon會是最普遍的選擇。