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
方法中,会进行首次初始化。 -
调用关键方法
_read_images
读取镜像文件。
1.3 进入 _read_images
由于代码量过大,只显示关键代码,请自行查阅
_read_images
-
_read_images
中做了以下操作,即是对(selector class protocol category )的处理
- 条件控制
进行一次加载
- 修复
预编译阶段
的@selector
的混乱问题
- 检测类,修复现在不处理的,
将来需要处理
的类,标记bundle
类 - 修复
重映射
一些没有被镜像文件
加载进来的类 - 修复旧的
objc_msgSend_fixup
调用站点 - 检测
协议
,修复协议
,当我们类里面有协议的时候调用readProtocol
- 修复没有
被加载
的协议
-
分类
处理,启动时的类别初始化完成后才走if
里面,被推迟到对_dyld_objc_notify_register
的调用完成后的第一个load_images
调用为止 -
非懒加载类
处理,实现了+load
方法的类叫非懒加载类
- 没有被处理的类,
优化
那些被侵犯的类
1.4 进入 readClass
在_read_images
流程中的第三步,我们找到了关键方法readClass
进入readClass
-
addNamedClass
:把cls绑定上插入到内存中存类的数据表中 -
addClassTableEntry
:把cls加入到需要开辟内存的类的表
既然我们已经把类
存到了内存中
,那我们类
中的方法
,属性
,协议
又是什么时候存进入的呢?是怎么从maho
的data
中拿到rw
,rwe
的呢?我们还不得而知。
现在我们的研究对象是类
,而_read_images
与类相关的只有第三步,第九步和第十步,而第三步我们已经探索过,即是把类绑定名字
加入到内存的两张表
中,一张存类的表
,一张存需要开辟内存的类的表
,接着研究第九步和第十步
1.5 探索与类相关的第九步和第十步
首先在第九步中添加自定义条件,定位到研究对象GomuPerson
,并加上2个断点,如下图所示
- 经过断点调试,发现2个断点都不会走,但是我们又根据命名推断出了关键方法
realizeClassWithoutSwift
,但是没有调用
于是我们推测,第九步没有走的原因,是不是因为判断条件不满足,非懒加载类才会走进if,接着我们探索一个拓展非懒加载类 & 懒加载类
1.6 非懒加载类 & 懒加载类
懒加载类:数据加载推迟到第一次发送消息的时候
非懒加载类:map_images 的时候 加载所有类数据
区分方法:当前类是否实现了 load 方法,实现则未非懒加载类
懒加载类加载情况:GomuPerson
中未实现load
方法,在方法慢速查询lookUpImpOrForward
(由于是第一次发送消息,缓存中没有数据,所以会进入到慢查询流程)中,插入以下代码,运行
- 懒加载类不会调用
_read_images
第九步中的realizeClassWithoutSwift
,而是在main
函数中实例GomuPerson
调用alloc
方法发送消息
的时候加载类
-
lookUpImpOrForward
->realizeClassMaybeSwiftMaybeRelock
->realizeClassWithoutSwift
非懒加载类加载情况:GomuPerson
中实现load
方法,会调用第九步中的realizeClassWithoutSwift
打印
- 非懒加载类会调用
_read_images
第九步中的realizeClassWithoutSwift
,在map_images
中加载类
-
_getObjc2NonlazyClassList
->realizeClassWithoutSwift
在GomuPerson
中实现load
方法,继续探索realizeClassWithoutSwift
流程
1.7 进入 realizeClassWithoutSwift
调用realizeClassWithoutSwift
之前,cls
只是一个地址+name
,ro,rw,rwe还没有,下面开始研究是否在realizeClassWithoutSwift
对它们进行了操作
realizeClassWithoutSwift2
-
ro
是干净的类,realizeClassWithoutSwift
中会把macho
中的ro
取出来,赋值给rw
,然后把rw
赋值给cls
- 递归实现
父类
和元类
- 处理
继承链
中所有类的isa
- 对
父类
和元类
进行重新映射
- 设置实例大小
- 设置
c++
函数 - 设置
flag
- 关联
类
和父类
,确认继承链
关系 - 处理
分类
,修复cls的方法列表,协议列表和属性列表 -
rw->set_ro(ro)
不管有没有实现分类
,都不会set
到rwe
中,都是直接set
给rw
特别说明:
- ro是干净内存,由于ios有运行时机制(会进行增删查改),对内存的操作比较严重,为了防止对原始数据的修改,所以把ro copy了一份放到了rw中
- 为什么有了rw,还要有rwe呢,因为并不是所有的类都会进行动态操作,为了节省内存,只有你动态处理过,才会生成相应的rwe
- rw/rwe都是脏内存
在realizeClassWithoutSwift
中,找到了取ro,把ro赋值给rw,rw赋值给cls,但是依然没有找到rwe
在哪里赋值的,索性继续研究methodizeClass
,看看后面会不会有眉目
1.8 进入 methodizeClass
修复cls的方法列表,协议列表和属性列表,附加类别
methodizeClass
- 经过断点调试,
rwe
都是空的 -
prepareMethodLists
会对所有方法
进行排序
- 最后会进入
attachToClass
方法
1.9 进入 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
,但是却没有触发调用,原因还不得而知,留给下期分类的加载
再探讨