iOS load 方法详解

r囧r小猫 2022-02-03 00:07 466阅读 0赞

## load 方法的调用时机 ##

Objective-C 中绝大多数类都继承自 NSObject 根类，每个类都有两个初始化方法，其中之一就是+ (void)load方法。  
对于每一个 Class 和 Category 来说，必定会调用此方法，而且仅调用一次。当包含 Class 和 Category 的程序库载入系统时，就会执行此方法，并且此过程通常是在程序启动的时候执行。

不同的是，现在的 iOS 系统中已经加入了动态加载特性（Dynamic Loading），这是从 macOS 应用程序中迁移而来的特性，等应用程序启动好之后再去加载程序库。**如果 Class 和其 Category 中都重写了 load 方法，则先调用 Class 中的**。

我们通过 [RetVal 封装好的 debug 版][RetVal _ debug]最新源码进行断点调试，来追踪一下 load 方法的全部处理过程，以便于了解这个函数以及 Objective-C 强大的动态性。

创建一个 Class 文件 TestClassA.m，然后在其中增加 load 方法。在运行 proj 后，可以看见 load 方法的调用时机是在入口函数主程序之前。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lvdXNoYW9kdW8_size_16_color_FFFFFF_t_70]

在 load 方法下增加断点，查看其调用栈并跟踪函数执行时候的上层代码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lvdXNoYW9kdW8_size_16_color_FFFFFF_t_70 1]

很容易发现这里调用了如下方法：

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_The Dynamic Link Editor_ Apple]，系统内核做好启动程序的初始准备后，将其他事务交给 dyld 负责，dyld已经全部开源，关于dyld的分析将会抽空在以后的文章中写一下。

在研究 load\_images 方法之前，先来研究一下什么是 images。images表示的是二进制文件（可执行文件或者动态链接库.so文件）编译后的符号、代码等。所以 **load\_images** 的工作是传入处理过后的二进制文件并让 Runtime 进行处理，并且每一个文件对应一个抽象实例来负责加载，这里的实例是 ImageLoader，我们从调用栈的方法 4 可以清楚的看到参数类型：  
![在这里插入图片描述][20190508122008456.png]  
ImageLoader 处理二进制文件的时机是在 main 入口函数以前，它在加载文件时主要做两个工作：

1.  在程序运行时它先将动态链接的 image 递归加载 （也就是上面测试栈中一串的递归调用的时刻，这一步在之前介绍砸壳工具[dumpdecrypted][]时也提到了，可以看一下）
2.  从可执行文件 image 递归加载所有符号

## 什么是Image（镜像） ##

我们通过给load\_images方法加断点，查看镜像：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lvdXNoYW9kdW8_size_16_color_FFFFFF_t_70 2]

我们可以看到这里有个**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**的具体介绍，可以看[这篇文章][Link 1]，本文不再赘述：  
看一下控制台里的输出，发现这里面有很多的动态链接库，还有一些苹果为我们提供的框架，比如 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 方法的调用情况至此已经全部清晰。思路梳理如下三大流程：

1.  Load Images: 通过 dyld 载入 image 文件，引入 Class。
2.  Prepare Load Methods: 准备 load 方法。过滤无效类、无效方法，将 load 方法指针和所属 Class 指针收集至全局 Class 存储线性表 **loadable\_classes** 中，其中会涉及到自动扩展空间和父类优先的递归调用问题。
3.  Call Load Methods: 根据收集到的函数指针，对 load 方法进行动态调用。进一步过滤无效方法，并记录 log 日志。

load的调用顺序：

1.  父类先于子类调用
2.  类先于分类调用

[RetVal _ debug]: https://github.com/RetVal/objc-runtime
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lvdXNoYW9kdW8_size_16_color_FFFFFF_t_70]: /images/20220203/d0d455b4c76049dbb6eac3dcb5cdbc76.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lvdXNoYW9kdW8_size_16_color_FFFFFF_t_70 1]: /images/20220203/0bcd37fcb42b4e0dbd5fe2741a5f6a0b.png
[dyld_The Dynamic Link Editor_ Apple]: https://github.com/opensource-apple/dyld
[20190508122008456.png]: /images/20220203/fe0652d5cef94a549c90b7a47ca347f5.png
[dumpdecrypted]: https://blog.csdn.net/youshaoduo/article/details/89918243
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lvdXNoYW9kdW8_size_16_color_FFFFFF_t_70 2]: /images/20220203/7af869a5846f461fae5d6c6f56e9ab44.png
[Link 1]: https://blog.csdn.net/youshaoduo/article/details/81112107