iOS应用启动（三）：镜像文件的读取和加载

932 字

5 分钟

iOS应用启动（三）：镜像文件的读取和加载

2021-07-21

2026-10-12

iOS

底层知识梳理

本文基于 dyld-832.7.3 与 objc4-818.2 源码

前言#

在上一文iOS应用启动（二）：环境配置与runtime初始化我们提到了 _dyld_objc_notify_register，本文就将深入对镜像文件的读取map_images与加载loadClass进行解读。

一、 _dyld_objc_notify_register#

_dyld_objc_notify_register(&map_images, load_images, unmap_image);

_dyld_objc_notify_register

这里有两个重要的函数：
- map_images
  - 管理文件中和动态库中的所有符号：class protocol selector category
- load_images
  - 执行 +load 方法
进行了镜像文件的读取与加载

这里有个一个小细节

我们看到这里调用 &map_images 这里用了函数的地址，因为这里非常重要，为了保持整个过程的同步。

二、 map_images#

1
/***********************************************************************
2
* map_images
3
* Process the given images which are being mapped in by dyld.
4
* Calls ABI-agnostic code after taking ABI-specific locks.
5
*
6
* Locking: write-locks runtimeLock
7
**********************************************************************/
8
void
9
map_images(unsigned count, const char * const paths[],
10
           const struct mach_header * const mhdrs[])
11
{
12
    mutex_locker_t lock(runtimeLock);
13
    return map_images_nolock(count, paths, mhdrs);
14
}

2.1 map_images_nolock#

1
void
2
map_images_nolock(unsigned mhCount, const char * const mhPaths[],
3
                  const struct mach_header * const mhdrs[])
4
{
5
    ...
6

7
    if (hCount > 0) {
8
        _read_images(hList, hCount, totalClasses, unoptimizedTotalClasses);
9
    }
10

11
    ...
12

13
    // Call image load funcs after everything is set up.
14
    for (auto func : loadImageFuncs) {
15
        for (uint32_t i = 0; i < mhCount; i++) {
16
            func(mhdrs[i]);
17
        }
18
    }
19
}

2.2 _read_images#

这里的源码非常长，但是Apple贴心的加了Log我们可以从Log找下线索

1
ts.log("IMAGE TIMES: fix up selector references");
2

3
ts.log("IMAGE TIMES: discover classes");
4

5
ts.log("IMAGE TIMES: remap classes");
6

7
ts.log("IMAGE TIMES: fix up objc_msgSend_fixup");
8

9
ts.log("IMAGE TIMES: discover protocols");
10

11
ts.log("IMAGE TIMES: fix up @protocol references");
12

13
ts.log("IMAGE TIMES: discover categories");
14

15
ts.log("IMAGE TIMES: realize non-lazy classes");
16

17
ts.log("IMAGE TIMES: realize future classes");

整体流程：
- 条件控制进行第一次加载
- 修复预编译阶段的 @selector 混乱问题
- 错误混乱的类处理
- 修复重映射一些没有被镜像文件加再进来的类
- 修复一些消息
- 当类中有协议的时候，readProtocol
- 修复没有被加载的协议
- 处理分类
- 类的加载相关处理

修复：主要是指对地址进行修复，将MachO中的地址修复为dyld处理后的地址

2.3 循环调用 readClass 加载类#

在这里添加Log可以发现，自定义的类是最后加载的：

1
... // 一系列系统类加载
2
readClass -- RYModel
3
readClass -- RYSubModel

这里如果想过滤系统的可以参考下面的代码：

1
const char *myClassName = "RYModel";
2
const char *mangledName = cls->nonlazyMangledName();
3

4
if (strcmp(mangledName, myClassName) == 0) {
5
    printf("%s -- %s\n", __func__, myClassName);
6
}

2.4 readClass 源码中的坑#

下图中的代码，看似进行了Class的ro rw的操作但实际运行断点的时候根本不会执行，千万不要被源码误导了。

如图三个断点：

跳过了中间的断点

2.5 寻找类相关的流程#

在源码中找到了可能的地方，添加断点：

实现 非懒加载类（实现类+load方法或者静态实例）

Realize non-lazy classes (for +load methods and static instances)

Realize newly-resolved future classes

运行后只输出了：

1
Realize non-lazy classes _read_images -- RYModel

而在其中也发现来到了另一个重要的流程：realizeClassWithoutSwift

关于这部分内容之前在研究msgSend的过程中有顺便进行了探索，可以在类的实现与初始化一文中进行深入了解。

补充：懒加载类 & 非懒加载类#

在2.5中提到了 非懒加载类，那么什么是 非懒加载类，什么是 懒加载类？

懒加载类

数据加载推迟到第一次接收第一次消息的时候

非懒加载类

map_image 的时候加载所有类数据。

三、 load_images#

这里流程就比较简单了
- 加载分类
- 查找所有 load 方法
- 调用 load 方法

1
void
2
load_images(const char *path __unused, const struct mach_header *mh)
3
{
4
    if (!didInitialAttachCategories && didCallDyldNotifyRegister) {
5
        didInitialAttachCategories = true;
6
        // 加载分类
7
        loadAllCategories();
8
    }
9

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

13
    recursive_mutex_locker_t lock(loadMethodLock);
14

15
    // Discover load methods
16
    // 查找所有 load 方法
17
    {
18
        mutex_locker_t lock2(runtimeLock);
19
        prepare_load_methods((const headerType *)mh);
20
    }
21

22
    /// 调用 load 方法
23
    // Call +load methods (without runtimeLock - re-entrant)
24
    call_load_methods();
25
}