在Objective-C中, 如果向某對象傳遞消息, 那就會使用動態綁定機制來決定需要調用的方法. 在底層, 所有方法都是普通的C語言函數, 然而對象收到消息之后, 究竟該調用哪個方法則完全于運行期決定, 甚至可以在程序運行時改變, 這些特性使得Objective-C 成為一門真正的動態語言.
id returnValue = [someObject messageName:parameter];
在本例中, someObject叫做"接收者"(receiver), messageName叫做"選擇子"(selector). 選擇子與參數合起來稱為"消息"(messge). 編譯器看到此消息后, 將其轉換為一條標準的C語言函數調用, 所調用的函數乃是消息傳遞機制中的核心函數, 叫做 objc_msgSend, 其"原型"(prototype) 如下:
void objc_msgSend(id self, SEL cmd, ...)
第一個參數代表接收者, 第二個參數代表選擇子(SEL 是選擇子的類型), 后續參數就是消息中的那些參數, 其順序不變
id returnValue = objc_msgSend(someObject, @selector(messageName:), parameter);
objc_msgSend函數會依據接收者與選擇子的類型來調用適當的方法. 為了完成此操作, 該方法需要在接收者所屬的類中搜尋其"方法列表" (list of methods), 如果能找到與選擇子名稱相符的方法, 就跳至其實現代碼. 若是找不到, 那就沿著繼承體系繼續向上查找, 等找到合適的方法之后再跳轉. 如果最終還是找不到相符的方法, 那就執行"消息轉發" (message forwarding) 操作.
調用一個方法需要很多步驟. objc_msgSend 會將匹配結果緩存在"快速映射表" (fast map) 里面, 每個類都有這樣一塊緩存, 若是稍后還向該類發送與選擇子相同的消息, 那么執行起來就很快了.這種"快速執行路徑" (fast path) 還是不如"靜態綁定的函數調用操作" (statically bound function call) 那樣迅速
objc_msgSend_stret. 如果待發送的消息要返回結構體, 那么可交由此函數處理. 只有當CPU的寄存器能夠容納得下消息返回類型時, 這個函數才能處理此消息. 若是返回值無法容納于CPU 寄存器中 (比如說返回的結構體太大了) , 那么就由另一個函數執行派發. 此時, 那個函數會通過分配在棧上的某個變量來處理消息所返回的結構體.
objc_msgSend_fpret. 如果消息返回的是浮點數, 那么可交由此函數處理. 在某些架構的CPU 中調用函數時, 需要對"浮點數寄存器" (floating-point register) 做特殊處理, 也就是說, 通常所用的 objc_msgSend 在這種情況下并不合適. 這個函數是為了處理x86等架構CPU中某些令人稍覺驚訝的奇怪狀況.
objc_msgSendSuper. 如果要給超類發消息, 例如[super message:parameter], 那么就交由此函數處理. 也有別外兩個與objc_msgSend_stret和 objc_msgSend_fpret 等效的函數, 用于處理發給super 的相應消息
每個類里都有一張表格, 其中的指針都會指向這種函數, 而選擇子的名稱則是查表時所用的"鍵". objc_msgSend 等函數正是通過這張表格來尋找應該執行的方法并跳至其實現的.
尾調用優化
如果某函數的最后一項操作是調用別外一個函數, 那么就可以運用"尾調用優化"技術. 編譯器會生成調轉至另一函數所需的指令碼, 而且不會向調用堆棧中推入新的"棧幀" (frame stack). 只有當某函數的最后一個操作僅僅是調用其他函數而不會將其返回值另作他用時, 才能執行"尾調用優化". 這項優化對 objc_msgSend 非常關鍵, 如果不這么做的話, 那么每次調用 Objective-C 方法之前, 都需要為調用 objc_msgSend 函數準備 "棧幀", 大家在"棧蹤跡" (stack trace) 中可以看到這種"棧幀". 此外, 若是不優化, 還會過早地發生"棧溢出" (stack overflow) 現象
