在上一篇文章iOS类的加载（上）中，我们知道了类是如何从Mach-O中加载到内存，这篇文章我们来分析分类是如何加载到类里面的，以及分类和类的搭配使用情况
前提
在main函数中定义LGPerson的分类LG
#pragma mark -- LGPerson的分类
@interface LGPerson (LG)
@property (nonatomic, copy) NSString *cate_name;
@property (nonatomic, assign) int cat_age;
- (void)cate_instanceMethod1;
- (void)cate_instanceMethod2;
- (void)cate_instanceMethod3;
- (void)cate_instanceMethod;
@end
@implementation LGPerson (LG)
- (void)cate_instanceMethod1{
NSLog(@"%s",__func__);
}
- (void)cate_instanceMethod2{
NSLog(@"%s",__func__);
}
- (void)cate_instanceMethod3{
NSLog(@"%s",__func__);
}
- (void)cate_instanceMethod{
NSLog(@"%s",__func__);
}
@end
下面我们将通过三种方式来探索分类的本质
- 【方式一】
clang - 【方式二】
Xcode文档搜索Category - 【方式三】
objc源码搜索category_t
【方式一】clang
clang -rewrite-objc main.m -o main.cpp命令查看底层编译
-
分类的类型是
_category_t -
分类的倒数第二个0，表示的是
没有协议，所以赋值为0
image.png
-
搜索
struct _category_t，如下所示- 其中有两个
method_list_t，代表实例方法和类方法
方法列表
- 其中有两个
-
搜索
_CATEGORY_INSTANCE_METHODS_LGPerson_，
image.png
其中有3个方法，格式为：sel+签名+地址，是method_t结构体的属性即key
image.png
-
搜索
method_t，其中对应关系如下- name == sel
- type == 方法签名
-
imp == 函数地址
image.png
-
查看
_prop_list_t，我们发现在分类中定义了的属性，但是在底层编译中并没有看到属性，如下图所示，这是因为分类中定义的属性没有对应的set、get方法，但是我们可以通过关联对象来进行设置
image.png
【方式二】Xcode文档搜索Category
command + shift + O打开Xcode文档搜索Category
Xcode文档搜索
【方式三】通过objc源码搜索category_t
category_t
分类的加载
前提
创建两个分类LGA、LGB
image.png
上一篇文章iOS类的加载（上）中提到了分类的加载顺序是越晚加进来，越在前面
查看methodizeClass的源码实现，可以发现类的数据和分类的数据是分开处理的，是因为在编译阶段就已经确定好了方法的归属位置(实例方法在类中，类方法在元类中)，而分类是后面才加进来的
methodizeClass
其中分类是需要通过attatchToClass方法添加到类里面，分为下面三步
- 分类数据
加载时机：根据类和分类是否实现load方法来区分 -
attachCategories准备分类数据 -
attachLists将分类数据添加到主类中
load_images
load_images方法的主要作用是加载镜像文件，其中最重要的有两个方法：prepare_load_methods（加载） 和 call_load_methods（调用）
load_images原理图
- 从所有的
非懒加载类和分类中的+load分别添加到表中 - 调用
类和分类的+load方法
load_images原理图
load_images调用过程
调用过程
分类的加载时机
我们在LGPerson和LGA、LGB中均实现+load方法
我们通过第二步数据反推第一步加载时机
在上一篇文章中我们知道，在attachCategories方法时，必然有分类数据的加载，因此我们可以反过来查看什么时候调用了attachCategories，全局搜索发现有两个方法调用
-
load_categories_nolock方法
load_categories_nolock
-
addToClass方法中，这里经过调试发现，从来不会进到if流程中，除非加载两次，一般的类一般只会加载一次
addToClass
-
运行objc代码，打印日志，通过日志可以发现
addToClass方法的下一步就是load_categories_nolock方法就是加载分类数据
image.png
-
全局搜索
load_categories_nolock的调用，有两次调用- 一次在
loadAllCategories方法中
image.png
- 一次在
-
一次在
_read_images方法中
image.png
-
但是经过调试发现，是不会走
_read_images方法中的if流程的，而是走的loadAllCategories方法中的
image.png
-
全局搜索查看
loadAllCategories的调用，发现是在load_images时调用的
image.png
通过堆栈信息分析
- 在
attachCategories中加自定义逻辑的断点，bt查看堆栈信息
image.png
所以综上所述，该情况下的分类的数据加载时机的反推路径为：attachCategories -> load_categories_nolock -> loadAllCategories -> load_images
而我们的分类加载正常的流程的路径为：realizeClassWithoutSwift -> methodizeClass -> attachToClass ->attachCategories
分类加载时机
LGPerson+分类LGA实现+load，分类LGB不实现+load方法
-
断点定在
attachCategories中加自定义逻辑部分，一步步往下执行
image.png
-
继续往下执行，会再次来到
attachCategories方法中断住
image.png
总结：只要有一个分类是非懒加载分类，那么所有的分类都会被标记位非懒加载分类，意思就是加载一次 已经开辟了rwe，就不会再次懒加载，重新去处理 主类
分类和类的搭配使用
通过上面的两个例子，我们可以大致将类 和 分类 是否实现+load的情况分为4种
-
【情况1】非懒加载类 + 非懒加载分类
-
【情况2】非懒加载类 + 懒加载分类
-
【情况3】懒加载类 + 懒加载分类
-
【情况4】懒加载类 + 非懒加载分类
非懒加载类 与 非懒加载分类
主类和分类都实现了+load方法，综合前面的分析可以得出下面结论
-
类是通过
_getObjc2NonlazyClassList加载数据的，即ro、rw的操作，对rwe初始化赋值是在extAlloc方法中- 调用路径为：
map_images -> map_images_nolock -> _read_images -> readClass -> _getObjc2NonlazyClassList -> realizeClassWithoutSwift -> methodizeClass -> attachToClass,此时的mlists是一维数组，然后走到load_images部分
- 调用路径为：
-
分类的数据加载是通过
load_images加载到类中的-
load_images --> loadAllCategories -> load_categories_nolock -> load_categories_nolock -> attachCategories -> attachLists，此时的mlists是二维数组
-
下面为源码中调试的打印日志
image.png
非懒加载类 与 懒加载分类
主类实现了+load方法，分类未实现+load方法
-
打开
realizeClassWithoutSwift中的自定义断点，看一下ro-
查看kc_ro
image.png
-
p
kc_ro->baseMethodList
image.png
-
p
$1.get(0) 、$1.get(1) 、$1.get(2) 、$1.get(3) 、$1.get(4)
image.png
-
p
$1.get(5)、$1.get(10)
image.png
-
-
来到
prepareMethodLists的for循环部分
image.png
-
来到
fixupMethodList方法中的if (sort) {部分- 其中
SortBySELAddress的源码实现如下：根据名字的地址进行排序
image.png
- 其中
-
走到
mlist->setFixedUp();，在读取list
image.png
image.png
通过打印发现，仅对同名方法进行了排序，而分类中的其他方法是不需要排序的，其中imp地址是有序的（从小到大） -- fixupMethodList中的排序只针对 name 地址进行排序
-
不加任何断点，运行程序，获取打印日志
image.png
非懒加载类 与 懒加载分类的数据加载 总结：
- 类 和 分类的加载是在
read_images就加载数据了 - 其中data数据在
编译时期就已经完成了
懒加载类 与 懒加载分类
主类和分类均未实现+load方法
-
不加任何断点，运行程序，获取打印日志
image.png
其中realizeClassMaybeSwiftMaybeRelock是消息流程中慢速查找中有的函数，即在第一次调用消息时才有的函数
- 在
readClass断住,然后读取kc_ro，即读取整个data
image.png
此时的baseMethodList的count还是16，说明也是从data中读取出来的，所以不需要经过一层缓慢的load_images加载进来
总结：懒加载类 与 懒加载分类的数据加载是在消息第一次调用时加载
懒加载类 与 非懒加载分类
主类未实现+load方法， 分类实现了+load方法
-
不加任何断点，运行程序，获取打印日志
image.png
-
在打印的日志中没有看到
load_categories_nolock方法，查看attachCategories -- extAlloc -- attachToClass -- attachCategories，在attachToClass中加断点
image.png
-
在
readClass方法中断住，查看kc_ro
image.png
其中baseMethodList的count是8个，打印看看：对象方法3个+属性的setget方法共4个+1个cxx方法 ，即 现在只有主类的数据
image.png
-
查看kc_ro结构
image.png
-
打印日志
image.png
-
为了调试分类的数据加载， 继续往下执行，
bt查看堆栈：load_images -> loadAllCategories -> load_categories_nolock
image.png
总结： 懒加载类 + 非懒加载分类的数据加载，只要分类实现了load，会迫使主类提前加载,即 主类 强行转换为 非懒加载类
总结
通过上面的分析可知：分类的本质是_category_t
- 有两个属性：
name(类名)和cls(类对象) - 有两个
method_list_t方法列表：分类中实现的类方法和实例方法 - 一个
protocol_list_t协议列表：分类中实现的协议 - 一个
prop_list_t属性列表：分类中定义的属性，一般通过关联对象实现 - 分类中的属性是没有
set、get方法
类和分类搭配使用，其数据的加载时机总结如下：
- 【情况1】
非懒加载类 + 非懒加载分类，其数据的加载在load_images方法中，首先对类进行加载，然后把分类的信息贴到类中
-【情况2】非懒加载类 + 懒加载分类，其数据加载在read_image就加载数据，数据来自data，data在编译时期就已经完成，即data中除了类的数据，还有分类的数据，与类绑定在一起
-【情况3】懒加载类 + 懒加载分类 ，其数据加载推迟到 第一次消息时，数据同样来自data，data在编译时期就已经完成
-【情况4】懒加载类 + 非懒加载分类 ，只要分类实现了load，会迫使主类提前加载，即在_read_images中不会对类做实现操作，需要在load_images方法中触发类的数据加载，即rwe初始化，同时加载分类数据
image.png
网友评论