iOS原理分析之怎么從源碼看load與initialize方法

這篇文章主要介紹“iOS原理分析之怎么從源碼看load與initialize方法”，在日常操作中，相信很多人在iOS原理分析之怎么從源碼看load與initialize方法問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”iOS原理分析之怎么從源碼看load與initialize方法”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

一、引言

    在iOS開發(fā)中，NSObject類是萬事萬物的基類，其在Objective-C的整理類架構(gòu)中非常重要，其中有兩個很有名的方法：load方法與initialize方法。

+ (void)load;
+ (void)initialize;

說起這兩個方法，你的第一反應(yīng)一定是覺得太老套了，這兩個方法的調(diào)用時機(jī)及作用幾乎成為了iOS面試的必考題。其本身調(diào)用時機(jī)也非常簡單：

1. load方法在pre-main階段被調(diào)用，每個類都會調(diào)用且只會調(diào)用一次。

2. initialize方法在類或子類第一次進(jìn)行方法調(diào)用前會調(diào)用。

上面的兩點(diǎn)說明本身是正確的，但是除此之外，還有許多問題值得我們深究，例如：

1. 子類與父類的load方法的調(diào)用順序是怎樣的？

2. 類與分類的load方法調(diào)用順序是怎樣的？

3. 子類未實(shí)現(xiàn)load方法，會調(diào)用父類的么？

4. 當(dāng)有多個分類都實(shí)現(xiàn)了load方法時，會怎么樣？

5. 每個類的load方法的調(diào)用順序是怎樣的？

6. 父類與子類的initialize的方法調(diào)用順序是怎樣的？

7. 子類實(shí)現(xiàn)initialize方法后，還會調(diào)用父類的initialize方法么？

8. 多個分類都實(shí)現(xiàn)了initialize方法后，會怎么樣？

9. ...

如上所提到的問題，你現(xiàn)在都能給出明確的答案么？其實(shí)，load與initialize方法本身還有許多非常有意思的特點(diǎn)，本篇博客，我們將結(jié)合Objective-C源碼，對這兩個方法的實(shí)現(xiàn)原理做深入的分析，相信，如果你對load與initialize還不夠了解，不能完全明白上面所提出的問題，那么本篇博客將會使其收獲滿滿。無論在以后的面試中，還是工作中使用到load和initialize方法時，都可能幫助你從源碼上理解其執(zhí)行原理。

二、實(shí)踐出真知 - 先看load方法

    在開始分析之前，我們首先可以先創(chuàng)建一個測試工程，對load方法的執(zhí)行時機(jī)先做一個簡單的測試。首先，我們創(chuàng)建一個Xcode的命令行程序工程，在其中創(chuàng)建一些類、子類和分類，方便我們測試，目錄結(jié)構(gòu)如下圖所示：

其中，MyObjectOne和MyObjectTwo都是繼承自NSObject的類，MySubObjectOne是MyObjectOne的子類，MySubObjectTwo是MyObjectTwo的子類，同時我們還創(chuàng)建了3個分類，在類中實(shí)現(xiàn)load方法，并做打印處理，如下：

+ (void)load {
    NSLog(@"load:%@", [self className]);
}

同樣，類似的也在分類中做實(shí)現(xiàn)：

+ (void)load {
    NSLog(@"load-category:%@", [self className]);
}

最后我們在main函數(shù)中添加一個Log：

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        NSLog(@"Main");
    }
    return 0;
}

運(yùn)行工程，打印結(jié)果如下：

2021-02-18 14:33:46.773294+0800 KCObjc[21400:23090040] load:MyObjectOne
2021-02-18 14:33:46.773867+0800 KCObjc[21400:23090040] load:MySubObjectOne
2021-02-18 14:33:46.773959+0800 KCObjc[21400:23090040] load:MyObjectTwo
2021-02-18 14:33:46.774008+0800 KCObjc[21400:23090040] load:MySubObjectTwo
2021-02-18 14:33:46.774052+0800 KCObjc[21400:23090040] load-category:MyObjectTwo
2021-02-18 14:33:46.774090+0800 KCObjc[21400:23090040] load-category:MyObjectOne
2021-02-18 14:33:46.774127+0800 KCObjc[21400:23090040] load-category:MyObjectOne
2021-02-18 14:33:46.774231+0800 KCObjc[21400:23090040] Main

從打印結(jié)果可以看出，load方法在main方法開始之前被調(diào)用，執(zhí)行順序上來說，先調(diào)用類的load方法，再調(diào)用分類的load方法，從父子類的關(guān)系上看來，先調(diào)用父類的load方法，再調(diào)用子類的load方法。

    下面，我們就從源碼上來分析下，系統(tǒng)如此調(diào)用load方法，是源自于什么樣的奧妙。

三、從源碼分析load方法的調(diào)用

    要深入的研究load方法，我們首先需要從Objective-C的初始化函數(shù)說起：

void _objc_init(void)
{
    static bool initialized = false;
    if (initialized) return;
    initialized = true;
    
    // fixme defer initialization until an objc-using image is found?
    environ_init();
    tls_init();
    static_init();
    runtime_init();
    exception_init();
    cache_init();
    _imp_implementationWithBlock_init();

    // 其他的我們都不需要關(guān)注，只需要關(guān)注這行代碼
    _dyld_objc_notify_register(&map_images, load_images, unmap_image);

#if __OBJC2__
    didCallDyldNotifyRegister = true;
#endif
}

_objc_init函數(shù)定義在objc-os.mm文件中，這個函數(shù)用來做Objective-C程序的初始化，由引導(dǎo)程序進(jìn)行調(diào)用，其調(diào)用實(shí)際會非常的早，并且是操作系統(tǒng)引導(dǎo)程序復(fù)雜調(diào)用驅(qū)動，對開發(fā)者無感。在_objc_init函數(shù)中，會進(jìn)行環(huán)境的初始化，runtime的初始化以及緩存的初始化等等操作，其中很重要的一步操作是執(zhí)行_dyld_objc_notify_register函數(shù)，這個函數(shù)會調(diào)用load_images函數(shù)來進(jìn)行鏡像的加載。

    load方法的調(diào)用，其實(shí)就是類加載過程中的一步，首先，我們先來看一個load_images函數(shù)的實(shí)現(xiàn)：

void
load_images(const char *path __unused, const struct mach_header *mh)
{
    if (!didInitialAttachCategories && didCallDyldNotifyRegister) {
        didInitialAttachCategories = true;
        loadAllCategories();
    }

    // Return without taking locks if there are no +load methods here.
    if (!hasLoadMethods((const headerType *)mh)) return;

    recursive_mutex_locker_t lock(loadMethodLock);

    // Discover load methods
    {
        mutex_locker_t lock2(runtimeLock);
        prepare_load_methods((const headerType *)mh);
    }

    // Call +load methods (without runtimeLock - re-entrant)
    call_load_methods();
}

濾掉其中我們不關(guān)心的部分，與load方法調(diào)用相關(guān)的核心如下：

void
load_images(const char *path __unused, const struct mach_header *mh)
{
    // 鏡像中沒有l(wèi)oad方法，直接返回
    if (!hasLoadMethods((const headerType *)mh)) return;
    {
        // 準(zhǔn)備load方法
        prepare_load_methods((const headerType *)mh);
    }
    // 進(jìn)行l(wèi)oad方法的調(diào)用
    call_load_methods();
}

最核心的部分在于load方法的準(zhǔn)備與laod方法的調(diào)用，我們一步一步看，先來看load方法的準(zhǔn)備(我們?nèi)サ袅藷o關(guān)緊要的部分)：

void prepare_load_methods(const headerType *mhdr)
{
    size_t count, i;
    // 獲取所有類 組成列表
    classref_t const *classlist = 
        _getObjc2NonlazyClassList(mhdr, &count);
    for (i = 0; i < count; i++) {
        // 將所有類的load方法進(jìn)行整理
        schedule_class_load(remapClass(classlist[i]));
    }
    // 獲取所有的分類 組成列表
    category_t * const *categorylist = _getObjc2NonlazyCategoryList(mhdr, &count);
    for (i = 0; i < count; i++) {
        category_t *cat = categorylist[i];
        // 將分類的load方法進(jìn)行整理
        add_category_to_loadable_list(cat);
    }
}

看到這里，我們基本就有頭緒了，load方法的調(diào)用順序，基本可以確定是由整理過程所決定的，并且我們可以發(fā)現(xiàn)，類的load方法整理與分類的load方法整理是互相獨(dú)立的，因此也可以推斷其調(diào)用的時機(jī)也是獨(dú)立的。首先我們先來看類的load方法整理函數(shù)schedule_class_load(去掉無關(guān)代碼后)：

static void schedule_class_load(Class cls)
{
    // 類不存在或者已經(jīng)加載過load，則return
    if (!cls) return;
    if (cls->data()->flags & RW_LOADED) return;

    // 保證加載順序，遞歸進(jìn)行父類加載
    schedule_class_load(cls->superclass);
    // 將當(dāng)前類的load方法加載進(jìn)load方法列表中
    add_class_to_loadable_list(cls);
    // 將當(dāng)前類設(shè)置為已經(jīng)加載過laod
    cls->setInfo(RW_LOADED); 
}

可以看到，schedule_class_load函數(shù)中使用了遞歸的方式演著繼承鏈逐層向上，保證在加載load方法時，先加載父類，再加載子類。add_class_to_loadable_list是核心的load方法整理函數(shù)，如下(去掉了無關(guān)代碼)：

void add_class_to_loadable_list(Class cls)
{
    IMP method;
    // 讀取類中的load方法
    method = cls->getLoadMethod();
    if (!method) return; // 類中沒有實(shí)現(xiàn)load方法，直接返回
    // 構(gòu)建存儲列表及擴(kuò)容邏輯
    if (loadable_classes_used == loadable_classes_allocated) {
        loadable_classes_allocated = loadable_classes_allocated*2 + 16;
        loadable_classes = (struct loadable_class *)
            realloc(loadable_classes,
                              loadable_classes_allocated *
                              sizeof(struct loadable_class));
    }
    // 向列表中添加 loadable_class 結(jié)構(gòu)體，這個結(jié)構(gòu)體中存儲了類與對應(yīng)的laod方法
    loadable_classes[loadable_classes_used].cls = cls;
    loadable_classes[loadable_classes_used].method = method;
    // 標(biāo)記列表index的指針移動
    loadable_classes_used++;
}

loadable_clas結(jié)構(gòu)體的定義如下：

struct loadable_class {
    Class cls;  // may be nil
    IMP method;
};

getLoadMetho函數(shù)的實(shí)現(xiàn)主要是從類中獲取到load方法的實(shí)現(xiàn)，如下：

IMP 
objc_class::getLoadMethod()
{
    // 獲取方法列表
    const method_list_t *mlist;
    mlist = ISA()->data()->ro()->baseMethods();
    if (mlist) {
        // 遍歷，找到load方法返回
        for (const auto& meth : *mlist) {
            const char *name = sel_cname(meth.name);
            if (0 == strcmp(name, "load")) {
                return meth.imp;
            }
        }
    }
    return nil;
}

現(xiàn)在，關(guān)于類的load方法的準(zhǔn)備邏輯已經(jīng)非常清晰了，最終會按照先父類后子類的順序?qū)⑺蓄惖膌oad方法添加進(jìn)名為loadable_classes的列表中，loadable_classes這個名字你要注意一下，后面我們還會遇到它。

    我們再來看分類的laod方法準(zhǔn)備過程，其與我們上面介紹的類非常相似，add_category_to_loadable_list函數(shù)簡化后如下：

void add_category_to_loadable_list(Category cat)
{
    IMP method;
    // 獲取當(dāng)前分類的load方法
    method = _category_getLoadMethod(cat);
    if (!method) return;
    // 列表創(chuàng)建與擴(kuò)容邏輯
    if (loadable_categories_used == loadable_categories_allocated) {
        loadable_categories_allocated = loadable_categories_allocated*2 + 16;
        loadable_categories = (struct loadable_category *)
            realloc(loadable_categories,
                              loadable_categories_allocated *
                              sizeof(struct loadable_category));
    }
    // 將分類與load方法進(jìn)行存儲
    loadable_categories[loadable_categories_used].cat = cat;
    loadable_categories[loadable_categories_used].method = method;
    loadable_categories_used++;
}

可以看到，最終分類的load方法是存儲在了loadable_categories列表中。

    準(zhǔn)備好了load方法，我們再來分析下load方法的執(zhí)行過程，call_load_methods函數(shù)的核心實(shí)現(xiàn)如下：

void call_load_methods(void)
{
    bool more_categories;
    do {
        // 先對 loadable_classes 進(jìn)行遍歷，loadable_classes_used這個字段可以理解為列表的元素個數(shù)
        while (loadable_classes_used > 0) {
            call_class_loads();
        }

        // 再對類別進(jìn)行遍歷調(diào)用
        more_categories = call_category_loads();
       
    } while (loadable_classes_used > 0  ||  more_categories);
 
}

call_class_loads函數(shù)實(shí)現(xiàn)簡化后如下：

static void call_class_loads(void)
{
    int i;
    // loadable_classes列表
    struct loadable_class *classes = loadable_classes;
    // 需要執(zhí)行l(wèi)oad方法個數(shù)
    int used = loadable_classes_used;
    // 清理數(shù)據(jù)
    loadable_classes = nil;
    loadable_classes_allocated = 0;
    loadable_classes_used = 0;
    // 循環(huán)進(jìn)行執(zhí)行 循環(huán)的循序是從前到后
    for (i = 0; i < used; i++) {
        // 獲取類
        Class cls = classes[i].cls;
        // 獲取對應(yīng)load方法
        load_method_t load_method = (load_method_t)classes[i].method;
        if (!cls) continue; 
        // 執(zhí)行l(wèi)oad方法
        (*load_method)(cls, @selector(load));
    }
}

call_category_loads函數(shù)的實(shí)現(xiàn)要復(fù)雜一些，簡化后如下：

static bool call_category_loads(void)
{
    int i, shift;
    bool new_categories_added = NO;
    
    // 獲取loadable_categories分類load方法列表
    struct loadable_category *cats = loadable_categories;
    int used = loadable_categories_used;
    int allocated = loadable_categories_allocated;
    loadable_categories = nil;
    loadable_categories_allocated = 0;
    loadable_categories_used = 0;

    // 從前往后遍歷進(jìn)行l(wèi)oad方法的調(diào)用
    for (i = 0; i < used; i++) {
        Category cat = cats[i].cat;
        load_method_t load_method = (load_method_t)cats[i].method;
        Class cls;
        if (!cat) continue;
        cls = _category_getClass(cat);
        if (cls  &&  cls->isLoadable()) {
            (*load_method)(cls, @selector(load));
            cats[i].cat = nil;
        }
    }
    return new_categories_added;
}

現(xiàn)在，我相信你已經(jīng)對load方法為何類先調(diào)用，分類后調(diào)用，并且為何父類先調(diào)用，子類后調(diào)用。但是還有一點(diǎn)，我們不甚明了，即類之間或分類之間的調(diào)用順序是怎么確定的，從源碼中可以看到，類列表是通過_getObjc2NonlazyClassList函數(shù)獲取的，同樣分類的列表是通過_getObjc2NonlazyCategoryList函數(shù)獲取的。這兩個函數(shù)獲取到的類或分類的順序?qū)嶋H上是與類源文件的編譯順序有關(guān)的，如下圖所示：

可以看到，打印的load方法的執(zhí)行順序與源代碼的編譯順序是一直的。

四、initialize方法分析

    我們可以采用和分析load方法時一樣的策略來對initialize方法的執(zhí)行情況，進(jìn)行測試，首先將測試工程中所有類中添加initialize方法的實(shí)現(xiàn)。此時如果直接運(yùn)行工程，你會發(fā)現(xiàn)控制臺沒有任何輸出，這是由于只有第一次調(diào)用類的方法時，才會執(zhí)行initialize方法，在main函數(shù)中編寫如下測試代碼：

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        [MySubObjectOne new];
        [MyObjectOne new];
        [MyObjectTwo new];
        NSLog(@"------------");
        [MySubObjectOne new];
        [MyObjectOne new];
        [MyObjectTwo new];
    }
    return 0;
}

運(yùn)行代碼控制臺打印效果如下：

2021-02-18 21:29:55.761897+0800 KCObjc[43834:23521232] initialize-cateOne:MyObjectOne
2021-02-18 21:29:55.762526+0800 KCObjc[43834:23521232] initialize:MySubObjectOne
2021-02-18 21:29:55.762622+0800 KCObjc[43834:23521232] initialize-cate:MyObjectTwo
2021-02-18 21:29:55.762665+0800 KCObjc[43834:23521232] ------------

可以看到，打印數(shù)據(jù)都出現(xiàn)在分割線前，說明一旦一個類的initialize方法被調(diào)用后，后續(xù)再向這個類發(fā)送消息，也不會在調(diào)用initialize方法，還有一點(diǎn)需要注意，需要注意，如果對子類發(fā)送消息，父類的initialize會先調(diào)用，再調(diào)用子類的initialize，同時，分類中如果實(shí)現(xiàn)了initialize方法則會覆蓋類本身的，并且分類的加載順序靠后的會覆蓋之前的。下面我們就通過源碼來分析下initialize方法的這種調(diào)用特點(diǎn)。

    首先，在調(diào)用類的類方法時，會執(zhí)行runtime中的class_getClassMethod方法來尋找實(shí)現(xiàn)函數(shù)，這個方法在源碼中的實(shí)現(xiàn)如下：

Method class_getClassMethod(Class cls, SEL sel)
{
    if (!cls  ||  !sel) return nil;
    return class_getInstanceMethod(cls->getMeta(), sel);
}

通過源碼可以看到，調(diào)用一個類的類方法，實(shí)際上是調(diào)用其元類的示例方法，getMeta函數(shù)用來獲取類的元類，關(guān)于類和元類的相關(guān)組織原理，我們這里先不擴(kuò)展。我們需要關(guān)注的是class_getInstanceMethod這個函數(shù)，這個函數(shù)的實(shí)現(xiàn)也非常簡單，如下：

Method class_getInstanceMethod(Class cls, SEL sel)
{
    if (!cls  ||  !sel) return nil;

    // 做查詢方法列表，嘗試方法解析相關(guān)工作
    lookUpImpOrForward(nil, sel, cls, LOOKUP_RESOLVER);

    // 從類對象中獲取方法
    return _class_getMethod(cls, sel);
}

在class_getInstanceMethod方法的實(shí)現(xiàn)中，_class_getMethod是最終獲取要調(diào)用的方法的函數(shù)，在這之前，lookUpImpOrForward函數(shù)會做一些前置操作，其中就有initialize函數(shù)的調(diào)用邏輯，我們?nèi)サ魺o關(guān)的邏輯，lookUpImpOrForward中核心的實(shí)現(xiàn)如下：

IMP lookUpImpOrForward(id inst, SEL sel, Class cls, int behavior)
{
    IMP imp = nil;
    // 核心在于!cls->isInitialized() 如果當(dāng)前類未初始化過，會執(zhí)行initializeAndLeaveLocked函數(shù)
    if (slowpath((behavior & LOOKUP_INITIALIZE) && !cls->isInitialized())) {
        cls = initializeAndLeaveLocked(cls, inst, runtimeLock);
    }

    return imp;
}

initializeAndLeaveLocked會直接調(diào)用initializeAndMaybeRelock函數(shù)，如下：

static Class initializeAndLeaveLocked(Class cls, id obj, mutex_t& lock)
{
    return initializeAndMaybeRelock(cls, obj, lock, true);
}

initializeAndMaybeRelock函數(shù)中會做類的初始化邏輯，這個過程是線程安全的，其核心相關(guān)代碼如下：

static Class initializeAndMaybeRelock(Class cls, id inst,
                                      mutex_t& lock, bool leaveLocked)
{
    // 如果已經(jīng)初始化過，直接返回
    if (cls->isInitialized()) {
        return cls;
    }
    // 找到當(dāng)前類的非元類
    Class nonmeta = getMaybeUnrealizedNonMetaClass(cls, inst);
    // 進(jìn)行初始化操作
    initializeNonMetaClass(nonmeta);

    return cls;
}

initializeNonMetaClass函數(shù)會采用遞歸的方式沿著繼承鏈向上查詢，找到所有未初始化過的父類進(jìn)行初始化，核心實(shí)現(xiàn)簡化如下：

void initializeNonMetaClass(Class cls)
{
    Class supercls;
    // 標(biāo)記是否需要初始化
    bool reallyInitialize = NO;
    // 父類如果存在，并且沒有初始化過，則遞歸進(jìn)行父類的初始化
    supercls = cls->superclass;
    if (supercls  &&  !supercls->isInitialized()) {
        initializeNonMetaClass(supercls);
    }
    
    SmallVector<_objc_willInitializeClassCallback, 1> localWillInitializeFuncs;
    {
        // 如果當(dāng)前不是正在初始化，并且當(dāng)前類沒有初始化過
        if (!cls->isInitialized() && !cls->isInitializing()) {
            // 設(shè)置初始化標(biāo)志，此類標(biāo)記為初始化過
            cls->setInitializing();
            // 標(biāo)記需要進(jìn)行初始化
            reallyInitialize = YES;
        }
    }
    // 是否需要進(jìn)行初始化
    if (reallyInitialize) {
        @try
        {
            // 調(diào)用初始化函數(shù)
            callInitialize(cls);
        }
        @catch (...) {
            @throw;
        }
        return;
    }
}

callInitialize函數(shù)最終會調(diào)用objc_msgSend函數(shù)來向類發(fā)送initialize初始化消息，如下：

void callInitialize(Class cls)
{
    ((void(*)(Class, SEL))objc_msgSend)(cls, @selector(initialize));
    asm("");
}

需要注意，initialize方法與load方法最大的區(qū)別在于其最終是通過objc_msgSend來實(shí)現(xiàn)的，每個類如果未初始化過，都會通過objc_msgSend來向類發(fā)送一次initialize消息，因此，如果子類沒有對initialize實(shí)現(xiàn)，按照objc_msgSend的消息機(jī)制，其是會沿著繼承鏈一路向上找到父類的實(shí)現(xiàn)進(jìn)行調(diào)用的，所有initialize方法并不是只會被調(diào)用一次，假如父類中實(shí)現(xiàn)了這個方法，并且它有多個未實(shí)現(xiàn)此方法的子類，則當(dāng)每個子類第一次接受消息時，都會調(diào)用一遍父類的initialize方法，這點(diǎn)非常重要，在實(shí)際開發(fā)中一定要牢記。

到此，關(guān)于“iOS原理分析之怎么從源碼看load與initialize方法”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！