OC底层原理17-类的加载

前面研究了dyld的加载流程和dyld与objc的关联，我们已经知道，代码会被编译成macho文件，那怎么把macho里面的数据格式加载到内存的呢?

上一篇 OC底层原理16-objc_init初探 & dyld和objc关联 中，我们已经知道，dyld会调用objc注册的回调方法map_images、load_images、unmap_image

所以我们从map_images入手研究

一、map_images源码初探

1.1 进入 map_images

void
map_images(unsigned count, const char * const paths[],
           const struct mach_header * const mhdrs[])
{
    mutex_locker_t lock(runtimeLock);
    return map_images_nolock(count, paths, mhdrs);
}

• map_images中调用了map_images_nolock
• map_images：管理文件中和动态库中的所有符号（class protocol selector category）

1.2 进入 map_images_nolock

map_images_nolock()

• map_images_nolock方法中，会进行首次初始化。

• 调用关键方法_read_images读取镜像文件。

1.3 进入 _read_images

由于代码量过大，只显示关键代码，请自行查阅

_read_images

• _read_images中做了以下操作，即是对（selector class protocol category ）的处理

1. 条件控制进行一次加载
2. 修复预编译阶段的 @selector 的混乱问题
3. 检测类，修复现在不处理的，将来需要处理的类，标记bundle类
4. 修复重映射一些没有被镜像文件加载进来的类
5. 修复旧的objc_msgSend_fixup调用站点
6. 检测协议，修复协议，当我们类里面有协议的时候调用readProtocol
7. 修复没有被加载的协议
8. 分类处理，启动时的类别初始化完成后才走if里面，被推迟到对_dyld_objc_notify_register的调用完成后的第一个load_images调用为止
9. 非懒加载类处理，实现了+load方法的类叫非懒加载类
10. 没有被处理的类，优化那些被侵犯的类

1.4 进入 readClass

在_read_images流程中的第三步，我们找到了关键方法readClass

image.png

进入readClass

readClass

• addNamedClass：把cls绑定上插入到内存中存类的数据表中
• addClassTableEntry：把cls加入到需要开辟内存的类的表

既然我们已经把类存到了内存中，那我们类中的方法，属性，协议又是什么时候存进入的呢？是怎么从maho的data中拿到rw，rwe的呢？我们还不得而知。

现在我们的研究对象是类，而_read_images与类相关的只有第三步，第九步和第十步，而第三步我们已经探索过，即是把类绑定名字加入到内存的两张表中，一张存类的表，一张存需要开辟内存的类的表，接着研究第九步和第十步

1.5 探索与类相关的第九步和第十步

首先在第九步中添加自定义条件，定位到研究对象GomuPerson，并加上2个断点，如下图所示

第九步 & 第十步.png

• 经过断点调试，发现2个断点都不会走，但是我们又根据命名推断出了关键方法realizeClassWithoutSwift，但是没有调用

于是我们推测，第九步没有走的原因，是不是因为判断条件不满足，非懒加载类才会走进if，接着我们探索一个拓展非懒加载类 & 懒加载类

1.6 非懒加载类 & 懒加载类

懒加载类：数据加载推迟到第一次发送消息的时候
非懒加载类：map_images 的时候 加载所有类数据
区分方法：当前类是否实现了 load 方法，实现则未非懒加载类

懒加载类加载情况：GomuPerson中未实现load方法，在方法慢速查询lookUpImpOrForward（由于是第一次发送消息，缓存中没有数据，所以会进入到慢查询流程）中，插入以下代码，运行

lookUpImpOrForward中自定义条件

打印结果

• 懒加载类不会调用_read_images第九步中的realizeClassWithoutSwift，而是在main函数中实例GomuPerson调用alloc方法发送消息的时候加载类
• lookUpImpOrForward -> realizeClassMaybeSwiftMaybeRelock -> realizeClassWithoutSwift

非懒加载类加载情况：GomuPerson中实现load方法，会调用第九步中的realizeClassWithoutSwift

GomuPerson添加load

打印

• 非懒加载类会调用_read_images第九步中的realizeClassWithoutSwift，在map_images中加载类
• _getObjc2NonlazyClassList -> realizeClassWithoutSwift

在GomuPerson中实现load方法，继续探索realizeClassWithoutSwift流程

1.7 进入 realizeClassWithoutSwift

调用realizeClassWithoutSwift之前，cls只是一个地址+name，ro，rw，rwe还没有，下面开始研究是否在realizeClassWithoutSwift对它们进行了操作

realizeClassWithoutSwift1

realizeClassWithoutSwift2

• ro是干净的类，realizeClassWithoutSwift中会把macho中的ro取出来，赋值给rw，然后把rw赋值给cls
• 递归实现父类和元类
• 处理继承链中所有类的isa
• 对父类和元类进行重新映射
• 设置实例大小
• 设置c++函数
• 设置flag
• 关联类和父类，确认继承链关系
• 处理分类，修复cls的方法列表，协议列表和属性列表
• rw->set_ro(ro)不管有没有实现分类，都不会set到rwe中，都是直接set给rw

特别说明：

1. ro是干净内存，由于ios有运行时机制（会进行增删查改），对内存的操作比较严重，为了防止对原始数据的修改，所以把ro copy了一份放到了rw中
2. 为什么有了rw，还要有rwe呢，因为并不是所有的类都会进行动态操作，为了节省内存，只有你动态处理过，才会生成相应的rwe
3. rw/rwe都是脏内存

在realizeClassWithoutSwift中，找到了取ro，把ro赋值给rw，rw赋值给cls，但是依然没有找到rwe在哪里赋值的，索性继续研究methodizeClass，看看后面会不会有眉目

1.8 进入 methodizeClass

修复cls的方法列表，协议列表和属性列表，附加类别

methodizeClass

• 经过断点调试，rwe都是空的
• prepareMethodLists会对所有方法进行排序
• 最后会进入attachToClass方法

1.9 进入 attachToClass

attachToClass

• 找到关键方法attachCategories，里面调用了extAllocIfNeeded对rwe进行了初始化或赋值
• 但是，经过各种调试，发现attachCategories不会调用

1.10 总结：类的加载过程

• 类的加载流程：map_images -> map_images_nolock -> map_images_nolock -> _read_images

• 进入_read_images后，调用readClass，把类绑定上mangledName插入到内存中存类的数据表中，并且加入到需要开辟内存的类的表

• 接着会对重写了load方法的类进行加载，即对非懒加载类进行加载

• 而懒加载类的加载则会推迟到第一次发送消息的时候

• 非懒加载类和懒加载类都会调用同样一个实现类的方法realizeClassWithoutSwift

• realizeClassWithoutSwift里面会进行递归加载父类和元类，并关联他们，也会从macho中读取ro，赋值给新开辟的rw，然后把rw和cls绑定

• 接着进入methodizeClass，该方法会对rw中的method_list_t（方法列表）根据方法的sel地址进行重新排序，注意该方法中rwe一直为空，最后会调用attachToClass

• attachToClass中调用了为rwe赋值的关键方法attachCategories，但是却没有触发调用，原因还不得而知，留给下期分类的加载再探讨