load 方法的调用时机
Objective-C 中绝大多数类都继承自 NSObject 根类，每个类都有两个初始化方法，其中之一就是+ (void)load方法。
对于每一个 Class 和 Category 来说，必定会调用此方法，而且仅调用一次。当包含 Class 和 Category 的程序库载入系统时，就会执行此方法，并且此过程通常是在程序启动的时候执行。
不同的是，现在的 iOS 系统中已经加入了动态加载特性（Dynamic Loading），这是从 macOS 应用程序中迁移而来的特性，等应用程序启动好之后再去加载程序库。如果 Class 和其 Category 中都重写了 load 方法，则先调用 Class 中的。
我们通过 RetVal 封装好的 debug 版最新源码进行断点调试，来追踪一下 load 方法的全部处理过程，以便于了解这个函数以及 Objective-C 强大的动态性。
创建一个 Class 文件 TestClassA.m，然后在其中增加 load 方法。在运行 proj 后，可以看见 load 方法的调用时机是在入口函数主程序之前。
在 load 方法下增加断点，查看其调用栈并跟踪函数执行时候的上层代码：
很容易发现这里调用了如下方法：
0 +[TestClassA load]
1 call_class_loads()
2 call_load_methods
3 load_images
4 dyld::notifySingle(dyld_image_states, ImageLoader const*,ImageLoader::InitializerTimingList*)
11 _dyld_start
追其源头，从 _dyld_start 开始探究。dyld(The Dynamic Link Editor)是 Apple 的动态链接库，系统内核做好启动程序的初始准备后，将其他事务交给 dyld 负责，dyld已经全部开源，关于dyld的分析将会抽空在以后的文章中写一下。
在研究 load_images 方法之前，先来研究一下什么是 images。images表示的是二进制文件（可执行文件或者动态链接库.so文件）编译后的符号、代码等。所以 load_images 的工作是传入处理过后的二进制文件并让 Runtime 进行处理，并且每一个文件对应一个抽象实例来负责加载，这里的实例是 ImageLoader，我们从调用栈的方法 4 可以清楚的看到参数类型：
ImageLoader 处理二进制文件的时机是在 main 入口函数以前，它在加载文件时主要做两个工作：
- 在程序运行时它先将动态链接的 image 递归加载 （也就是上面测试栈中一串的递归调用的时刻，这一步在之前介绍砸壳工具dumpdecrypted时也提到了，可以看一下）
- 从可执行文件 image 递归加载所有符号
什么是Image（镜像）
我们通过给load_images方法加断点，查看镜像：
我们可以看到这里有个mach_header的结构体，看一下他是啥：
/*
* The 32-bit mach header appears at the very beginning of the object file for
* 32-bit architectures.
*/
struct mach_header {
uint32_t magic; /* mach magic number identifier */
cpu_type_t cputype; /* cpu specifier */
cpu_subtype_t cpusubtype; /* machine specifier */
uint32_t filetype; /* type of file */
uint32_t ncmds; /* number of load commands */
uint32_t sizeofcmds; /* the size of all the load commands */
uint32_t flags; /* flags */
};
关于mach_header的具体介绍，可以看这篇文章，本文不再赘述：
看一下控制台里的输出，发现这里面有很多的动态链接库，还有一些苹果为我们提供的框架，比如 Foundation、 CoreServices 等等，都是在这个 load_images 中加载进来的，而这些 imageFilePath 都是对应的二进制文件的地址。
"/usr/lib/system/introspection/libdispatch.dylib"
(const mach_header *) $1 = 0x0000000100ce8000
"/usr/lib/system/libsystem_trace.dylib"
(const mach_header *) $3 = 0x00007fff5fe11000
"/usr/lib/system/libxpc.dylib"
(const mach_header *) $5 = 0x00007fff5fe2e000
"/Users/youssef/Library/Developer/Xcode/DerivedData/objc-fpslisaqyykeagafmyuymmagigfw/Build/Products/Debug/libobjc.A.dylib"
(const mach_header *) $7 = 0x000000010033e000
"/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation"
(const mach_header *) $9 = 0x00007fff3375a000
"/System/Library/Frameworks/Security.framework/Versions/A/Security"
(const mach_header *) $11 = 0x00007fff3ec54000
"/usr/lib/libnetwork.dylib"
(const mach_header *) $13 = 0x00007fff5dfe9000
"/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork"
(const mach_header *) $15 = 0x00007fff326bb000
......此处省略so many
开始研究load_images
原始代码和注释：
/***********************************************************************
* load_images
* Process +load in the given images which are being mapped in by dyld.
*
* Locking: write-locks runtimeLock and loadMethodLock
**********************************************************************/
extern bool hasLoadMethods(const headerType *mhdr);
extern void prepare_load_methods(const headerType *mhdr);
void
load_images(const char *path __unused, const struct mach_header *mh)
{
// 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();
}
给大家翻译之后的注释加代码：
// load_images
// 执行 dyld 提供的并且已被 map_images 处理后的 image 中的 +load
// 锁定状态：runtimeLock写操作和 loadMethodLock 方法，保证线程安全
extern bool hasLoadMethods(const headerType *mhdr);
extern void prepare_load_methods(const headerType *mhdr);
void
load_images(const char *path __unused, const struct mach_header *mh) {
// 没有查询到传入 Class 中的 load 方法，视为锁定状态
// 则无需给其加载权限，直接返回
if (!hasLoadMethods((const headerType *)mh)) return;
// 定义可递归锁对象
// 由于 load_images 方法由 dyld 进行回调，所以数据需上锁才能保证线程安全
// 为了防止多次加锁造成的死锁情况，使用可递归锁解决
recursive_mutex_locker_t lock(loadMethodLock);
// 收集所有的 +load 方法
{
// 对 Darwin 提供的线程写锁的封装类
rwlock_writer_t lock2(runtimeLock);
// 提前准备好满足 +load 方法调用条件的 Class
prepare_load_methods((const headerType *)mh);
}
// 调用 +load 方法 (without runtimeLock - re-entrant)
call_load_methods();
}
一行一行的分析代码
首先映入眼帘的是hasLoadMethods 函数，我们要分析一下它干了什么，毕竟这里if不过下面都是白写。
他的作用其实是为了查询 load 函数列表，会分别查询该函数在内存数据段上指定 section 区域是否有所记录。
来看一下源码：
// Quick scan for +load methods that doesn't take a lock.快速查询是否存在 +load 函数列表
bool hasLoadMethods(const headerType *mhdr)
{
size_t count;
if (_getObjc2NonlazyClassList(mhdr, &count) && count > 0) return true;
if (_getObjc2NonlazyCategoryList(mhdr, &count) && count > 0) return true;
return false;
}
我们发现这里有俩奇怪的东西 _getObjc2NonlazyClassList 和 _getObjc2NonlazyCategoryList ，在 objc-file.mm 文件中找到了他们的定义：
#define GETSECT(name, type, sectname) \
type *name(const headerType *mhdr, size_t *outCount) { \
return getDataSection<type>(mhdr, sectname, nil, outCount); \
} \
type *name(const header_info *hi, size_t *outCount) { \
return getDataSection<type>(hi->mhdr(), sectname, nil, outCount); \
}
// function name content type section name
GETSECT(_getObjc2NonlazyClassList, classref_t, "__objc_nlclslist");
GETSECT(_getObjc2CategoryList, category_t *, "__objc_catlist");
在 Apple 的官方文档中，我们可以在 __DATA 段中查询到 __objc_classlist 的用途，主要是用在访问 Objective-C 的类列表，而 __objc_nlcatlist 用于访问 Objective-C 的 +load 函数列表，比 __mod_init_func 更早被执行。这一块对类信息的解析是由 dyld 处理时期完成的，也就是我们上文提到的 map_images 方法的解析工作。而且从侧面可以看出，Objective-C 的强大动态性，与 dyld 前期处理密不可分。
继续往下走
走过了if之后，看到这里有个加锁的操作，里面放了一个全局的变量loadMethodLock：
recursive_mutex_locker_t lock(loadMethodLock);
声明在这里(xcode的代码追踪功能要好好利用哇)：
/***********************************************************************
* Lock management
**********************************************************************/
mutex_t runtimeLock;
mutex_t selLock;
mutex_t cacheUpdateLock;
recursive_mutex_t loadMethodLock; //就是我了！！！
void lock_init(void)
{
}
全局 loadMethodLock 是一个 recursive_mutex_t 类型的变量。这个是苹果公司通过 C 实现的一个互斥递归锁 Class，来解决多次上锁而不会发生死锁的问题，其作用与 NSRecursiveLock 相同，但不是由 NSLock 再封装，而是通过 C 为 Runtime 的使用场景而写的一个 Class。
继续走
{
// 对 Darwin 提供的线程写锁的封装类，我们先不关心这个
rwlock_writer_t lock2(runtimeLock);
// 提前准备好满足 +load 方法调用条件的 Class
prepare_load_methods((const headerType *)mh);
}
关于加锁这个我们先不管了，毕竟跟文章的主题相关性不大，所以我们直接看prepare_load_methods这个方法，这里的schedule_class_load方法在prepare_load_methods里调用了，而且源码也是写在一起的，所以就一并看一下：
/***********************************************************************
* prepare_load_methods
* Schedule +load for classes in this image, any un-+load-ed
* superclasses in other images, and any categories in this image.
**********************************************************************/
// Recursively schedule +load for cls and any un-+load-ed superclasses.
// cls must already be connected.
// 用来规划执行 Class 的 load 方法，包括父类
// 递归调用 +load 方法通过 cls 指针以及
// 要求是 cls 指针的 Class 必须已经进行链接操作
static void schedule_class_load(Class cls)
{
if (!cls) return;
// 查看 RW_REALIZED 是否被标记
assert(cls->isRealized()); // _read_images should realize
// 查看 RW_LOADED 是否被标记
if (cls->data()->flags & RW_LOADED) return;
// Ensure superclass-first ordering，递归到深层（超类）运行，总是能够保证没有调用 load 方法的父类先于子类加入 loadable_classes 数组，从而确保其调用顺序的正确性。
schedule_class_load(cls->superclass);
// 将需要执行 load 的 Class 添加到一个全局列表中
add_class_to_loadable_list(cls);
// 标记 RW_LOADED 符号
cls->setInfo(RW_LOADED);
}
void prepare_load_methods(const headerType *mhdr)
{
size_t count, i;
runtimeLock.assertLocked();
// 先去找class的load
// 收集 Class 中的 +load 方法
// 获取所有的类的列表
classref_t *classlist =
_getObjc2NonlazyClassList(mhdr, &count);
for (i = 0; i < count; i++) {
// 通过 remapClass 获取类指针
// schedul_class_load 递归到父类逐层载入
schedule_class_load(remapClass(classlist[i]));
}
//再去找category的load
category_t **categorylist = _getObjc2NonlazyCategoryList(mhdr, &count);
for (i = 0; i < count; i++) {
category_t *cat = categorylist[i];
// 通过 remapClass 获取 Category 对象存有的 Class 对象
Class cls = remapClass(cat->cls);
if (!cls) continue; // category for ignored weak-linked class
// 对类进行第一次初始化，主要用来分配可读写数据空间并返回真正的类结构
realizeClass(cls);
assert(cls->ISA()->isRealized());
// 将需要执行 load 的 Category 添加到一个全局列表中
add_category_to_loadable_list(cat);
}
}
prepare_load_methods 作用是为 load 方法做准备，从代码中可以看出 Class 的 load 方法是优先于 Category。其中在收集 Class 的 load 方法中，因为需要对 Class 关系树的根节点逐层遍历运行，在 schedule_class_load 方法中使用深层递归的方式递归到根节点，优先进行收集。
在 schedule_class_load 中，Class 的读取方式是用 cls 指针方式，其中有很多内存符号位用来记录状态。isRealized() 查看的就是 RW_REALIZED 位，该位记录的是当前 Class 是否初始化一个类的指标。而之后查看的 RW_LOADED 是记录当前类的 +load 方法是否被被调用。
在存储静态表的方法中，方法对象会以指针的方式作为参数传递，然后用名为 loadable_classes 的静态类数组对即将运行的 load 方法进行存储，其下标索引 loadable_classes_used 为（从零开始的）全局量，并在每次录入方法后做自加操作实现索引的偏移。
由此可以看到，在 prepare_load_methods 方法中，Runtime 方法进行了 Class 和 Category 的筛选过滤工作，并且将即将执行的 load 方法以指针的形式组织成了一个线性表结构，为之后执行操作中打下基础。
终于走到了最后一步
call_load_methods()
这个函数的定义在objc-loadmethod.mm文件里，找到 call_load_methods() 方法：
void call_load_methods(void)
{
static bool loading = NO;// 是否已经录入
bool more_categories;// 是否有关联的 Category
loadMethodLock.assertLocked();
// Re-entrant calls do nothing; the outermost call will finish the job.
if (loading) return; // 由于 loading 是全局静态布尔量，如果已经录入方法则直接退出
loading = YES;
// 声明一个 autoreleasePool 对象
// 使用 push 操作其目的是为了创建一个新的 autoreleasePool 对象
void *pool = objc_autoreleasePoolPush();
do {
// 1. Repeatedly call class +loads until there aren't any more，重复调用 load 方法，直到没有
while (loadable_classes_used > 0) {
call_class_loads();
}
// 2. Call category +loads ONCE，调用 Category 中的 load 方法，这个只要调用一次，毕竟category没有父类这东西
//这里可以在一定程度上确保类的 load 方法会先于分类调用。
//但是这里不能完全保证调用顺序的正确。如果分类的镜像在类的镜像之前加载到运行时，这里的代码就没法保证顺序的正确了
more_categories = call_category_loads();
// 3. Run more +loads if there are classes OR more untried categories，继续调用，直到所有 Class 全部完成
} while (loadable_classes_used > 0 || more_categories);
// 将创建的 autoreleasePool 对象释放
objc_autoreleasePoolPop(pool);
// 更改全局标记，表示已经录入
loading = NO;
}
我们来看看方法 call_class_loads 是如何从待加载的类列表 loadable_classes 中寻找对应的类，然后找到 @selector(load) 的实现并执行：
static void call_class_loads(void) {
// 声明下标偏移
int i;
// 分离加载的 Class 列表
struct loadable_class *classes = loadable_classes;
// 调用标记
int used = loadable_classes_used;
loadable_classes = nil;
loadable_classes_allocated = 0;
loadable_classes_used = 0;
// 调用列表中的 Class 类的 load 方法
for (i = 0; i < used; i++) {
// 获取 Class 指针
Class cls = classes[i].cls;
// 获取方法对象
load_method_t load_method = (load_method_t)classes[i].method;
if (!cls) continue;
if (PrintLoading) {
_objc_inform("LOAD: +[%s load]\n", cls->nameForLogging());
}
// 方法调用
(*load_method)(cls, SEL_load);
}
// 释放 Class 列表
if (classes) free(classes);
}
我们来看一下上面提到的loadable_classes是个什么东西：
typedef void(*load_method_t)(id, SEL);
struct loadable_class {
Class cls; // may be nil
IMP method;
};
struct loadable_category {
Category cat; // may be nil
IMP method;
};
// List of classes that need +load called (pending superclass +load)
// This list always has superclasses first because of the way it is constructed
static struct loadable_class *loadable_classes = nil;
static int loadable_classes_used = 0;
static int loadable_classes_allocated = 0;
// List of categories that need +load called (pending parent class +load)
static struct loadable_category *loadable_categories = nil;
static int loadable_categories_used = 0;
static int loadable_categories_allocated = 0;
看完定义发现，这就是个链表啊。。挑其中一个操作方法add_class_to_loadable_list看一下实现(像remove啥的都是常规的链表操作，category的链表一样的道理)：
void add_class_to_loadable_list(Class cls) {
// 定义方法指针
// 目的是构造函数指针
IMP method;
loadMethodLock.assertLocked();
// 通过 cls 中的 getLoadMethod 方法，直接获得 load 方法体存储地址
method = cls->getLoadMethod();
// 没有 load 方法直接返回
if (!method) return;
if (PrintLoading) {
_objc_inform("LOAD: class '%s' scheduled for +load",
cls->nameForLogging());
}
// 判断数组是否已满
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));
}
// 将 Class 指针和方法指针记录
loadable_classes[loadable_classes_used].cls = cls;
loadable_classes[loadable_classes_used].method = method;
// 游标自加偏移
loadable_classes_used++;
}
看完了简单all_class_loads方法，我们再来看一下更复杂的call_category_loads方法：
static bool call_category_loads(void)
{
int i, shift;
bool new_categories_added = NO;
// 1. 获取当前可以加载的分类列表
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;
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);
// 这里，检查了类是否存在并且是否可以加载，如果都为真，那么就可以调用分类的 load 方法了。
//综合call_load_methods中的代码，确保了类先于分类调用load方法
if (cls && cls->isLoadable()) {
// 2. 如果当前类是可加载的 `cls && cls->isLoadable()` 就会调用分类的 load 方法
(*load_method)(cls, SEL_load);
cats[i].cat = nil;
}
}
// 3. 将所有加载过的分类移除 `loadable_categories` 列表
shift = 0;
for (i = 0; i < used; i++) {
if (cats[i].cat) {
cats[i-shift] = cats[i];
} else {
shift++;
}
}
used -= shift;
// 4. 为 `loadable_categories` 重新分配内存，并重新设置它的值
new_categories_added = (loadable_categories_used > 0);
for (i = 0; i < loadable_categories_used; i++) {
if (used == allocated) {
allocated = allocated*2 + 16;
cats = (struct loadable_category *)
realloc(cats, allocated *
sizeof(struct loadable_category));
}
cats[used++] = loadable_categories[i];
}
if (loadable_categories) free(loadable_categories);
if (used) {
loadable_categories = cats;
loadable_categories_used = used;
loadable_categories_allocated = allocated;
} else {
if (cats) free(cats);
loadable_categories = nil;
loadable_categories_used = 0;
loadable_categories_allocated = 0;
}
return new_categories_added;
}
总结一下
load 方法的调用情况至此已经全部清晰。思路梳理如下三大流程：
- Load Images: 通过 dyld 载入 image 文件，引入 Class。
- Prepare Load Methods: 准备 load 方法。过滤无效类、无效方法，将 load 方法指针和所属 Class 指针收集至全局 Class 存储线性表 loadable_classes 中，其中会涉及到自动扩展空间和父类优先的递归调用问题。
- Call Load Methods: 根据收集到的函数指针，对 load 方法进行动态调用。进一步过滤无效方法，并记录 log 日志。
load的调用顺序：
- 父类先于子类调用
- 类先于分类调用
