那么还有一个问题, 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一次都没调用, 为什么呢, 因为我并没有给Person和Student的类对象发消息现在, 我给
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调用






网友评论