在前傳1中，我們分析瞭解了XNU核心所支援的二進位制檔案格式Mach-O。同時還留了一個小尾巴，就是Mach-O檔案中和Objective-C以及runtime相關的Segment section。今天，就來了解一下它們。

OC之源起

我們知道，程式的入口點在iOS中被稱之為main函式：

#import <UIKit/UIKit.h>
#import "AppDelegate.h"

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class
 
]));
    }
}

我們所寫的所有程式碼，它的執行的第一步，均是由main函式開始的。

但其實，在程式進入main函式之前，核心已經為我們的程式載入和執行做了許多的事情。

當我們設定符號斷點_objc_init，可以看到如下呼叫堆疊資訊，這些函式都是在main函式呼叫前，被系統呼叫的：

_objc_init 是Object-C runtime的入口函式，在這裡面主要功能是讀取Mach-O檔案OC對應的Segment seciton，並根據其中的資料程式碼資訊，完成為OC的記憶體佈局，以及初始化runtime相關的資料結構。

我們可以看到，_objc_init 是被_dyld_start

dyld是蘋果的動態載入器，用來載入image（注意這裡image不是指圖片，而是Mach
-O格式的二進位制檔案）。

當程式啟動時，系統核心首先會載入dyld， 而dyld會將我們APP所依賴的各種庫載入到記憶體空間中，其中就包括libobjc庫（OC和runtime）, 這些工作，是在APP的main函式執行前完成的。

在_objc_init 方法中，會註冊監聽來自dlyd的以下事件：

   // Register for unmap first, in case some +load unmaps something
    _dyld_register_func_for_remove_image(&unmap_image);
    dyld_register_image_state_change_handler(dyld_image_state_bound,
                                             1
 
/*batch*/, &map_2_images);
    dyld_register_image_state_change_handler(dyld_image_state_dependents_initialized, 0/*not batch*/, &load_images);

對應的事件說明：

• _dyld_register_func_for_remove_image ： dyld將image移除記憶體
• dyld_image_state_bound ：dyld綁定了新的image
• dyld_image_state_dependents_initialized ：image所依賴的各種庫都被初始化好了

由上面程式碼可以看到，當dyld綁定了新的image之後，runtime會執行map_2_images方法，在這個方法中，libobjc會讀取當前所載入的image的Mach-O檔案資訊，並利用和OC相關的Segment section中的資訊，對OC記憶體空間的各種底層資料結構進行初始化，包括class struct的填充，category繫結到對應class，填充class的method list，protocol list以及property list等。當這一切都做好後，我們就可以在程式中盡情的呼叫runtime的各種黑魔法啦~ 說到底，所謂的runtime黑魔法，只是基於OC各種底層資料結構上的應用。

所以，要想深入的瞭解runtime，需要了解OC底層的各種C語言實現，這在後續的章節中會逐步介紹。而OC底層結構的初始化，則是藉助於Mach-O檔案格式以及dyld。

對於dyld是如何載入Mach-O檔案的，我們這裡不做深入介紹，有興趣可以參見：iOS 程式 main 函式之前發生了什麼。

這裡，我們重點關注一下Mach-O檔案和OC相關的Segment section。

PS：不要將OC和runtime分開理解，其實在蘋果開原始碼中，OC和runtime是在一個工程中objc4的。我們平常所用到的OC語言，底層90%都是由C語言加一些彙編程式碼實現的。比如OC中的NSObject它唯一的例項變數型別Class，對應C語言結構體objc_class。

而所謂的runtime，則是在OC這些C語言底層實現的資料結構基礎上，進行的一些操作，比如交換Selector的實現，只需要交換method
list的IMP。獲取一個物件的說有屬性名稱，只需要輸出對應C語言結構property list即可。

Mach-O中OC相關的Segment Section

在上一篇文章中，我們可以看到，在__TEXT段和__DATA段中，都有如下以_objc_**形式命名的section，這些section，是和OC的記憶體佈局相關的。

__TEXT & OC

__TEXT段是程式的不可變常量部分，包括了字串常量，被const修飾的常量，同時也包括OC相關的一些seciton。

__objc_classname

這裡面以字串常量的形式，記錄了我們自定義以及所引用的系統class的名稱，同時也包括Category, protocol 的名稱：

__objc_methname

這個seciton中記錄了當前APP所呼叫的方法的名稱：

__objc_methtype

這個seciton與__objc_methname節對應，記錄了method的描述字串：

__DATA & OC

以下內容的結論，大部分來自於五子棋大神的深入理解Macho檔案（二）- 消失的__OBJC段與新生的__DATA段，裡面涉及到許多的彙編分析，本人對彙編功力欠佳，所以僅能總結下大神的結論。

__objc_imageinfo

__objc_imageinfo section 主要用來區分OC的版本1.0 或 2.0，在OC原始碼中是這樣定義的：

typedef struct {
    uint32_t version; // currently 0
    uint32_t flags;
} objc_image_info;

version 欄位總是為0，而flags欄位通過異或的方式，表面需要支援的特性。如是否需要/支援垃圾回收：

SupportsGC          = 1<<1,  // image supports GC
  RequiresGC          = 1<<2,  // image requires GC

if (ii.flags & (1<<1)) {
    // App wants GC. 
    // Don't return yet because we need to 
    // check the AppleScriptObjC exception.
    wantsGC = YES;
}

__objc_classlist

這個section列出了所有的class，包括meta class。

用MachOView檢視該節，是這樣的：

該節中儲存的是一個個的指標，指標指向的地址是class結構體所在的地址。class結構體在OC中用結構體objc_class 表示。

struct objc_class : objc_object {
    // Class ISA;
    Class superclass;
    cache_t cache;             // formerly cache pointer and vtable
    class_data_bits_t bits;    // class_rw_t * plus custom rr/alloc flags
}

__objc_catlist

該節中儲存了OC中定義的Catgory, 儲存了一個個指向__objc_category 型別的指標。

struct category_t {
    const char *name;
    classref_t cls;
    struct method_list_t *instanceMethods;
    struct method_list_t *classMethods;
    struct protocol_list_t *protocols;
    struct property_list_t *instanceProperties;
}

__objc_protolist

該節中記錄了所有的協議。 像上面一樣，也是儲存了指向protocol_t的指標。

struct protocol_t : objc_object {
    const char *mangledName;
    struct protocol_list_t *protocols;
    method_list_t *instanceMethods;
    method_list_t *classMethods;
    method_list_t *optionalInstanceMethods;
    method_list_t *optionalClassMethods;
    property_list_t *instanceProperties;
    uint32_t size;   // sizeof(protocol_t)
    uint32_t flags;
    // Fields below this point are not always present on disk.
    const char **extendedMethodTypes;
    const char *_demangledName;
  }

__objc_classrefs

該節記錄了那些class被引用了。因為有些類雖然被打包入APP中，但是在程式中並沒有被引用。所以，這裡記錄了那些類真正的被我們例項化了。（注意，這裡的AppDelegate 雖然在程式中沒有顯示的例項化，但系統似乎將其也標識為被引用的）

__objc_selrefs

這節告訴那些SEL對應的字串被引用了，有系統方法，也有自定義方法：

__objc_superrefs

這一個節記錄了呼叫super message的類。比如，在son方法中，我們呼叫了father的方法，就會將son class記錄在這裡。同理，在viewDidLoad中呼叫了super viewDidLoad, 因此view controller class也被記錄在這裡。

至於為什麼要單獨弄出一個section來記錄所有呼叫了super message的類，這應該和[super message]的底層實現相關，說實話，五子棋大神的解釋，我沒有看懂……

__objc_const

這一節用來記錄在OC記憶體初始化過程中的不可變內容。這裡所謂的不可變內容並不是我們在程式中所寫的const int k = 5這種常量資料（它存在__TEXT的const section中），而是在OC記憶體佈局中不可變得部分，包括但不限於：

struct class_ro_t {
    uint32_t flags;
    uint32_t instanceStart;
    uint32_t instanceSize;
#ifdef __LP64__
    uint32_t reserved;
#endif

    const uint8_t * ivarLayout;

    const char * name;
    method_list_t * baseMethodList;
    protocol_list_t * baseProtocols;
    const ivar_list_t * ivars;

    const uint8_t * weakIvarLayout;
    property_list_t *baseProperties;

    method_list_t *baseMethods() const {
        return baseMethodList;
    }
};

// 方法列表
// Two bits of entsize are used for fixup markers.
struct method_list_t : entsize_list_tt<method_t, method_list_t, 0x3> {
    bool isFixedUp() const;
    void setFixedUp();

    uint32_t indexOfMethod(const method_t *meth) const {
        uint32_t i = 
            (uint32_t)(((uintptr_t)meth - (uintptr_t)this) / entsize());
        assert(i < count);
        return i;
    }
};
// 方法實體
struct method_t {
    SEL name;
    const char *types;
    IMP imp;

    struct SortBySELAddress :
        public std::binary_function<const method_t&,
                                    const method_t&, bool>
    {
        bool operator() (const method_t& lhs,
                         const method_t& rhs)
        { return lhs.name < rhs.name; }
    };
};

總結

今天我們瞭解了Mach-O格式和OC的關係，並大致瞭解了各個section中的內容。

當dyld載入我們的APP的時候，會通知OC讀取對應seciton的內容，進而完成OC記憶體資料結構的初始化工作，為之後的程式執行及runtime黑魔法做好了準備。

注意，上面所說的工作，是在APP的main函式之前就已經結束了的。

到此為止，關於Mach-O格式，我們已經有了基本的瞭解了。接下來將會進入我們的正題：理解OC內部的各種資料結構，以及它們是如何被runtime所應用的。