Swift 會不會取代 Objective-C?

說到 Swift 會不會完全取代 Objective-C,目前看起來是,在 iOS 8 推出之後,應該不少應用程式會使用 Swift 開發,但是 Framework 這一層還是要用 Objective-C 來寫。

我們還是要回來看 Objective-C 與 Swift 的 run time 是怎麼實作的。無論是在 Objective-C 或 Swift 中,一個 class 有哪些 method,都是儲存在 virtual method table (以下簡稱 vtable)中,但是實作方式不一樣。

Objective-C 的 vtable 是個像是 dictionary 的實作,table 中每一筆資料都是 C 字串當 key(又稱 selector),對應到相對的 C Function pointer,所以每次呼叫某個 Objective-C 物件的某個 method,就是透過一個叫做 objc_msgSend 的 function,在表格中根據字串當 key,尋找對應該執行的 function—如果找不到,還會去問這個 Class 是否有實作 forwardInvocation: 這個 method,還是沒有的話,就會丟出找不到 method 的 exception,這部份可以參考蘋果自己的官方文件

至於 Swift 的 vtable 則是一個 array,對某個物件呼叫某個 method 時,相當於要求執行這個 function array 當中的第幾個 function(參見 Mike Ash 的文章)。

如此就會造成以下影響:在 Swift 中,尋找要呼叫的 method 的速度,理論上就會比 Objective-C 來得快,因此同樣功能的程式,用 Swfit 寫,整體上應該會比用 Objective-C 來得快。但同時,Swift 的 vtable 中每個 function 的順序就不能改變,在編譯的時候,vatble 裡頭是什麼順序,在執行的時候就得要是什麼順序,如果是執行的時候載入了不同的 runtime,順序不對,那就會呼叫到錯誤的 function。

蘋果是怎麼確保 compile 時用到的 runtime 與執行時的 runtime 是同一份呢?就是,在編譯應用程式的時候,Xcode 會自動把一份 Swift runtime 複製到應用程式的 bundle 中;所以,你的裝置中有多少個 Swift 應用程式,就會有多少份 Swift runtime。Swift 的 runtime 本身不大,這麼做還沒什麼問題,但是你寫一個 iOS 應用程式還會用到 Foundation、UIKit…一大堆的 Framework,如果要把每個 Framework 都複製一份,聽起來就很不對,照裡說不會換成 Swift 才對,Objective-C 當初用字串當 key,某方面來看,也就是為了處理像 DLL Hell 這樣的問題。

外部開發者比較沒有機會寫到比較底層的 Framework,如果只是寫一個 iOS 應用程式的話,按照蘋果的宣稱,全都用 Swift 寫看來不是什麼問題。

而在 iOS 8 之後,蘋果也終於開放在應用程式 bundle 中,放置自己寫的、或別人包好的 Framework(Mac OS X 從一開始就開放了)。如果是自己寫的 Framework,而且這個 Framework 與主要應用程式的 Target 是在同一個 Xcode project 中,跟著主應用程式 Target 一起編譯,那應該還不會有什麼問題,但如果用的是別人已經編譯好的 Framrwork,那就相當危險—你不能夠保證別人的這個 Framework,與你現在的開發環境用的是同一個版本的 Swift runtime。

iOS 8 同時也開放了一些系統 extension,這些 extension 感覺起來原理就是 Mac OS X 上的 plug-in bundle,透過 dynamic loading 讀入外部的 library。感覺起來 extension 用 Swift 寫似乎也頂危險的—一個應用程式載入一堆 plug-in,每個 plug-in 可能相依於不同的 Swift runtime,看起來就會出亂子。不過目前還沒看到蘋果自己在這方面有什麼文件。

Be Sociable, Share!

Leave a Reply