前两篇文章中，我们对类结构进行了分析，objc_class里面有isa、superclass、cache、和bits， 在上两篇文章中我们主要分析了bits，那么今天我们来看看cache 这个玩意
首先老规矩，要想分析先点到cache源码里面瞧一瞧
看到这个源码，相信大家此时此刻心情跟我一样，心里一万个超泥马在沸腾。其实也不必太惊慌失措，仔细看一下就会发现里面很多东西是唬人的。接下来我给大家分析一波， 希望大家看多了我的文章后，分析源码的能力越来越强
把源码分析了一遍，用注释写出来了，相信大家这下就不懵逼了吧。其实说白了，我们需要用到的就是buckets里面的sel和imp。明白了这个点之后，我再来一张图让大家看的更加清晰明了
这张图一看，整个cache_t的结构就很清楚了， 接下来我们来玩一下：
首先，在LGPerson里面定义一些属性和方法
@interface LGPerson : NSObject
@property (nonatomic, copy) NSString *lgName;
@property (nonatomic, strong) NSString *nickName;
- (void)sayHello;
- (void)sayCode;
- (void)sayMaster;
- (void)sayNB;
+ (void)sayHappy;
@end
@implementation LGPerson
- (void)sayHello{
NSLog(@"LGPerson say : %s",__func__);
}
- (void)sayCode{
NSLog(@"LGPerson say : %s",__func__);
}
- (void)sayMaster{
NSLog(@"LGPerson say : %s",__func__);
}
- (void)sayNB{
NSLog(@"LGPerson say : %s",__func__);
}
+ (void)sayHappy{
NSLog(@"LGPerson say : %s",__func__);
}
@end
然后在main里面进行调用
// cache_t
int main(int argc, const char * argv[]) {
@autoreleasepool {
// insert code here...
LGPerson *p = [LGPerson alloc];
Class pClass = [LGPerson class];
[p sayHello];
[p sayCode];
[p sayMaster];
NSLog(@"%@",pClass);
}
return 0;
}
运行程序，将断点打在sayHello上面
这个步骤跟之前分析bits的时候一摸一样，看过的应该轻车熟路了，这里就不做多的介绍，接下来我们观察一下,_occupied为0,sel为空,imp 也为0, 注意，这个断点是打在sayHello上的,没有任何调用方法
接下来我们调用两个方法之后再来看一下：
看到没有，跟之前不一样了，由此可见，由于执行了方法，所以cache_t里面就会缓存这个方法，导致打印结果有变化，接下来我们就可以把cache_t里面的sayHello打印出来
这个地方要注意，我直接打印sel打印不出来，这个时候我们一般去源码里面看一看sel在哪里，点进去一看是在buckets里面，所以我们先获取buckets，然后把buckets里面的方法打印出来,还可以把里面的imp也打印出来
用MachOView也可以查看二进制文件中的方法地址和这里打印的是一致的，都是0x0000000100000c30：
补充一种牛逼方式，直接脱离源码环境，在项目查找
按照我图上的三大步骤就能把源码环境自己搭建了，这样以后就非常方便了。 需要注意的是 Class ISA;本来是在objc_object里的，这里我们没有继承objc_object,所以需要在我们自己的环境上加上。 明白了这点之后我们再来玩一下这个环境
int main(int argc, const char * argv[]) {
@autoreleasepool {
LGPerson *p = [LGPerson alloc];
Class pClass = [LGPerson class]; // objc_clas
[p say1];
[p say2];
// 初始化 lg_objc_class
struct lg_objc_class *lg_pClass = (__bridge struct lg_objc_class *)(pClass);
// 打印LGPerson里面cache的_occupied和_mask
NSLog(@"%hu - %u",lg_pClass->cache._occupied,lg_pClass->cache._mask);
for (mask_t i = 0; icache._mask; i++) {
// 打印获取bucket里面的sel和imp
struct lg_bucket_t bucket = lg_pClass->cache._buckets[I];
NSLog(@"%@ - %p",NSStringFromSelector(bucket._sel),bucket._imp);
}
NSLog(@"Hello, World!");
}
return 0;
}
代码里面该注释的都注释了，相信大家都能看懂。 运行看结果：
看到没有，有了这个代码就可以非常方便的查看类里面的cache_t，而且还不需要源码环境，爽的一批。
很多人以为这就完了，惊喜往往在后面，接下来我们多调用几个方法，把say3，say4 也调用了，我们来运行一下：
此时此刻，看到这里我不知道各位有啥想法，反正我是挺疑惑的，
1、为什么由2-3 变成 2-7，
2、为什么只打印了say3和say4，没有say1和say2，
3、为什么say4在say3的顺序不对
带着这几个问题，我们继续来探索
首先我们先想一想为什么mask会变化，它究竟经历了什么，我们打开源码来瞧一瞧
因为属性只是用来存储的， 真正改变值的是函数，所以看到incrementOccupied()这个函数是不是有点小激动，点进去一看_occupied++;，那么接下来我们搜索一下incrementOccupied()这个函数在哪里调用的
就在这，也只在cache_t里的insert方法有调用，先给大家看一下擦他里面的内容
看到这个内容是不是有点头皮发麻，没关系，我给大家一一分析，也希望我们以后分析源码的能力越来越强
解释的应该还算清晰吧，有啥好的建议或者问题欢迎在下方留言，看到我会及时回复。
那么经过一番分析之后，上面三个问题就很容易回答了：
第一个问题： 2-3 变成 2-7 是因为capacity - 1 capacity开始为4，两倍扩容之后是8，所以4减1，8减1，就是3和7了
第二个问题： 为什么只打印了say3和say4 是因为扩容的时候，将原有的内存全部清除了，再重新申请了内存导致的
第三个问题： 为什么say4在say3的顺序不对 是因为在得到新下标的时候是通过哈希计算的，哈希本身就是无序的，大家伙可以打断点试一试，一切都明白了。
最后再附上一张整个cache_t的流程分析图,让大家更加清晰cache_t缓存流程
对于今天的分析，我觉得大家伙还是自己打个断点实战一下，理论再多都没有自己实战一番来的明白。感谢大伙的观看！
iOS 底层原理 文章汇总