iOS 多線程之內的那些事情（上）

眾所周知，蘋果的 MAC OS X 系統以及 iOS 系統是基於三個部分的。BSD Unix，MACH 以及蘋果自己開發的 IOKit 等構成了作業系統的主體，也就是 Darwin 架構。其中 MACH 主要負責的部分是 CPU 管理，記憶體保護以及處理序間通訊等等。而從 BSD Unix 那邊承接過來的，基本上就是網路效能，運行效率，以及標準化的 POSIX API 這一套東西了。大多數情況下，對於 Unix 使用者或者開發人員來說，POSIX API 基本上提供了多線程編程所需要的一切東西。按照 POSIX API 編寫出來的多線程程式往往是最標準，而且是最容易移植的。特別是對於需要從其他平台將代碼移植到 iOS 的開發人員來說，將其他多線程代碼翻譯到 POSIX 是最方便的。這主要也是因為 POSIX API 在事實上已經形成了一種標準，只要有多線程程式，就一定有 POSIX 的影子。

當然，對於跨平台的開發人員來說，它確實是最方便的。但是對於 iOS 的原生開發人員來說，僅僅使用 POSIX API 就顯得有些單薄了。特別是，當開發人員把這一套固定的多線程編程的思路帶到 iOS 開發中來的時候，就會遇到一些小小的問題。在這篇文章（以及今後的幾篇當中）我會與大家共同探討一下這個問題，並且對這一問題提供一些自己的看法。

事實上，在實際工作中，大多數情況下並不是特別需要用到多執行緒，這是第一個結論。一般來說，在我們的層次上，使用多線程主要還是為瞭解決一些使用者介面互動之類的問題，比如網路之類的耗時操作，大多數時候我們會用把這種操作移到另一個線程上，以避免主介面卡住。其實歸根結底以上的這些都是屬於平行處理這一類，在嚴格的意義上說，並不是平行處理就一定是多線程。最簡單的例子就要數大家都在使用的一個開源庫：CocoaSocket 提供了基於 GCD 的以及基於 Runloop 的兩種並行 Socket，而後者就不是安全執行緒的。當然，這麼說或許不夠準確，準確的來說，就好像大多數 Foundation 類一樣，它們可以在任何線程上使用，但是如果在另外的線程上進行了訪問的話就會產生錯誤（基本上都是 NSMutable 這一首碼的類）。事實上，基於 Runloop 的 Socket 也能很好的提供平行處理的解決方案（CFSocket 本身也是基於 Runloop 的）。NSRunloop 和 CFRunloop 是基於線程的，然而它們並不是多線程所特有的屬性（請注意即便是單線程也是線程），而且有它獨特的行為模式。估計我會在下一篇文章中講到這些。

當然，對於 iOS 中多線程程式來說，最難的部分也就是 Runloop 這裡。簡單情況下，一個背景工作執行緒可以無限迴圈自己，這樣就能夠保證一直處在工作狀態，而把時間調度之類的問題全部拋給作業系統去做。而在 iOS 環境下，這麼做對系統資源的利用還不是最完美的。事實上，Runloop 相當於蘋果所整合的一個關於線程睡眠與喚醒的庫，每一個線程可以擁有一個 Runloop，在這種工作模式下，線程所佔用的 CPU 時間最少，因為作業系統可以根據你的代碼來選擇何時將這個 Runloop 送入休眠狀態：這個在以後會講到。

在使用中，Foundation 類裡有很多東西都與 Runloop 相關。最經常見到的就是 NSTimer 這一個類。因為在很多系統中，基於時間間隔來進行觸發的事件一般都工作於一個單獨的進程（大多數是系統管理的進程）上，所以大多數時候我們會誤認為 NSTimer 也會與主線程達到並行的效果。而實際上，由於 NSTimer 是基於 Runloop 的，更準確的說，Timer 就是 Runloop Source 的一種。所以在同一個線程上的 NSTimer 不能達到並行的效果。這就意味著以下的一點：第一個 Timer 的代碼執行完畢之前，第二個 Timer 不會被觸發。這點可以很簡單的通過一個內容為死迴圈的 Timer 進行驗證。而這也等同於，在 NSTimer 的代碼裡添加對於多線程的同步或者說保護措施，其實是沒有必要的。這樣的情況只有可能在兩個 Timer 被分別添加到不同的線程上才會遇到。

對於 NSTimer 來講，還有很多有趣的其他特性。比如說要重新規劃一個 NSTimer 是一件非常耗時的工作，這底下的原因也和 NSTimer 是基於 Runloop 而不是系統的線程有關。在接下來的文章裡，我們就會詳細的探討一下 Runloop 這個東西，以及它的各種注意事項。