+load和+initialize

那么还有一个问题, Category中也有load方法吗?
答案是肯定的

image.png

发现类, 以及每一个分类中的调用了load方法, 这里要提一点的是,

load方法的调用时机是在类和分类加载到内存的时候调用, 每个类和分类的load方法只调用一次

按照类方法的调用原理, 类方法都存放在元类方法列表里, 如果元类列表里面找到了方法, 就不会再调用, 那么这个每一个类方法都调用, 又是什么原因呢?

系统会调用_objc_init方法:

image.png

那么load_images又做了些什么呢?

image.png

可以看到的是:
call_load_methods这个方法是调用了+load方法, 我们先不看这个方法, 在调用call_load_methods之前,
先调用了loadAllCategoriesIfNeeded把所有分类加到内存里, 然后prepare_load_methods, 即: 准备调用+load方法(还没调用), 最后才是刚刚提到的调用call_load_methods方法.

那我们来看看prepare_load_methods里做了些什么

image.png

主要有两步

  • 先从类列表里取出类, 调用schedule_class_load
  • 然后从分类列表里取出分类, 加到可加载分类列表中去

schedule_class_load其实是调用的add_class_to_loadable_list

image.png

但是很重要的一点是, 这里有一个递归调用:

schedule_class_load(cls->getSuperclass());

也就是说, 如果有父类的话, 是先将父类加到列表里.
看注释:

// Ensure superclass-first ordering

确保父类优先被加入列表, 也就是说, 最后是父类的+load方法先被调用

但是: add_category_to_loadable_list, 这个是直接加入到分类列表中, 没有调用父类的那一个环节, 所以分类的+load方法是谁先编译, 就先调用谁的的+load方法

所以归纳一下就是

  • 把类加到可加载类列表add_class_to_loadable_list
  • 把分类加到可加载分类列表add_category_to_loadable_list

add_class_to_loadable_list究竟做了些什么呢?

image.png

创建一个loadable_classes数组, 这个数组里面放什么呢? 放struct loadable_class结构体, 这个结构体里面放两样东西:

  • 类对象
  • load方法
method = cls->getLoadMethod();

load方法是通过getLoadMethod方法获取的, getLoadMethod方法里面又做了什么呢?

image.png

ALWAYS_INLINE static IMP
_getLoadMethod(const method_list_t *mlist)
{
    if (!mlist)
        return nil;

    if (auto meth = search_method_list_inline(mlist, @selector(load))) {
        return meth->imp(false);
    }

    return nil;
}

从上面可以看出, load方法是在方法列表里面找到load方法, 然后再返回出去:
最终是调用findMethodInSortedMethodList这个方法, 或者findMethodInUnsortedMethodList, 我们就看前面那个方法.

image.png

这个方法的本质就是以方法名为key, 去找对应的方法.
同理, add_category_to_loadable_list做的事情是:
创建一个loadable_categories数组, 这个数组里面放什么呢? 放struct loadable_category结构体, 这个结构体里面放两样东西:

  • 分类
  • load方法

此时loadable_classes_used这个静态变量的值就是可加载的类的数量

这是prepare_load_methods做的事情, 那么紧接着, 就开始调用call_load_methods, 这是真正的调用+load方法.
首先, 我们来看一下call_load_methods的方法注释

* call_load_methods
* Call all pending class and category +load methods.
* Class +load methods are called superclass-first. 
* Category +load methods are not called until after the parent class's +load.
* 
* This method must be RE-ENTRANT, because a +load could trigger 
* more image mapping. In addition, the superclass-first ordering 
* must be preserved in the face of re-entrant calls. Therefore, 
* only the OUTERMOST call of this function will do anything, and 
* that call will handle all loadable classes, even those generated 
* while it was running.
*
* The sequence below preserves +load ordering in the face of 
* image loading during a +load, and make sure that no 
* +load method is forgotten because it was added during 
* a +load call.
* Sequence:
* 1. Repeatedly call class +loads until there aren't any more
* 2. Call category +loads ONCE.
* 3. Run more +loads if:
*    (a) there are more classes to load, OR
*    (b) there are some potential category +loads that have 
*        still never been attempted.
* Category +loads are only run once to ensure "parent class first" 
* ordering, even if a category +load triggers a new loadable class 
* and a new loadable category attached to that class. 
*
* Locking: loadMethodLock must be held by the caller 
*   All other locks must not be held.

翻译一下:

  • 这个方法要调用所有待定的类和分类的+load方法.
  • 类的+load方法, 要先调用父类
  • 分类的+load方法要等到其主类的+load方法调用之后才会被调用

让我们看看代码究竟是怎么实现的:


image.png

进来之后, 先循环调用所有类的+load方法, 即call_class_loads.

image.png

从这里可以看到
这是遍历loadable_classes, 拿到结构体里的method, 然后直接调用

(*load_method)(cls, @selector(load));

请注意, 这是拿到函数指针, 直接调用, 而不是objc_msgSend(非消息发送机制)

先循环调用所有类的+load方法, 即call_class_loads
然后call_category_loads的调用和call_class_loads类似

    // Call all +loads for the detached list.
    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()) {
            if (PrintLoading) {
                _objc_inform("LOAD: +[%s(%s) load]\n", 
                             cls->nameForLogging(), 
                             _category_getName(cat));
            }
            (*load_method)(cls, @selector(load));
            cats[i].cat = nil;
        }
    }

所以总结起来就是:
先调用类的+load方法
再调用类的+load方法的时候, 又先调用父类的+load方法, 然后再调用子类的
类的+load方法调用结束后, 再调用分类的+load方法, 按照谁先编译, 先调用谁的顺序
看下图, 就是按照这个顺序:

image.png

+load方法类似的, 还有一个方法, 就是+initialize方法.
那么, +initialize是什么时候调用呢?

它是在类对象第一次收到消息时调用.

image.png

如上图所示, +load方法都是调用了的, 但是+initialize一次都没调用, 为什么呢, 因为我并没有给PersonStudent的类对象发消息
现在, 我给Person类对象发一个alloc消息:

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        [Person alloc];
    }
    return 0;
}

发现:

image.png

Person分类调用了+initialize, 而且是调用的后编译的Person分类的+initialize, 这从侧面验证了+initialize+load的不同点在于, +initialize是典型的消息发送机制.

但这里有一点不同的是, 假设我调用子类的+initialize, 但此时父类还一次都没有+initialize的时候, 会先调用父类的+initialize, 再调用子类的+initialize
image.png

如果在给子类发消息的时候, 发现父类的+initialize没调, 然后调用父类的+initialize, 接下来如果再给父类发消息, 这时候, 父类也不会再调用+initialize了.

但是有这么一个现象:

image.png

我只给Student发消息(此时, Student类和Teacher类都没有实现+initialize方法), 却调用了Person+initialize三次, 这是为什么呢?
情况是这样的

  • 我现在给Student发消息alloc,
  • 结果发现Student的父类也没调用+initialize,
  • 然后就给Student的父类Teacher类对象发消息+initialize,
  • 结果发现Teacher类的父类Person类也没有+initialize,
  • 于是就给Person类发消息+initialize
  • 如果Person类实现了+initialize, 那么此时, Person类的+initialize调用1次
  • 上面, 给Teacher类发+initialize, Teacher类没有实现+initialize, 找到Person类的+initialize, 再调用1次, 一共2次.
  • 同理, 给Student类发+initialize, Student类没有实现+initialize, 找到Person类的+initialize, 再调用1次, 一共3次.
    所以, 上面的3次调用就是这么来的
总结一下:
+load方法会在runtime加载类, 分类的时候调用
每个类, 分类的+load, 在程序运行过程中只调用一次
调用顺序:
1. 先调用类的+load
  • 按照编译的先后顺序调用(先编译, 先调用)
  • 调用子类的+load之前会先调用父类的+load
2. 再调用分类的+load
  • 按照编译的先后顺序调用(先编译, 先调用)
+initialize方法会在类第一次接收到消息的时候调用
调用顺序:
  • 先调用父类的+initialize, 再调用子类的+initialize
  • 先初始化父类, 再初始化子类, 每个类只会初始化1次
+initialize+load的很大区别是, +initialize是通过objc_msgSend进行调用的, 所以有以下特点:
  • 如果子类没有实现+initialize, 会调用父类的+initialize(所以父类的+initialize可能会被调用多次)
  • 如果分类实现了+initialize, 会覆盖类本身的+initialize调用
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,884评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,347评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,435评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,509评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,611评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,837评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,987评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,730评论 0 267
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,194评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,525评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,664评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,334评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,944评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,764评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,997评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,389评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,554评论 2 349

推荐阅读更多精彩内容