iOS得层探索 --- 类的结构探索（下）
image
在iOS底层探索 --- 类的结构探索（上）中我们分析了cache_t的大小。今天我们来探索一下cache_t里面到底存放了些什么。
1、cache_t源码查看
1.1 源码简单分析
首先我们要从源码中寻找，看看cache_t到底长什么样子。
在这里首先要跟打下确认几点内容：
-
CACHE_MASK_STORAGE_HIGH_16_BIG_ADDRS：表示运行的环境是MacOS，或者是模拟器。。 -
CACHE_MASK_STORAGE_HIGH_16：表示运行的环境是64位的真机，一般是指ARM64架构的。 -
CACHE_MASK_STORAGE_LOW_4：表示非64位的真机，一般指32位的。 -
CACHE_MASK_STORAGE_OUTLINED：表示未识别的设备。
image
我们在阅读cache_t源码的时候，里面有很多内容，一时间也看不出来到底有什么用。同样的，探索的过程终究是比较枯燥的。在漫长的探索过程中，发现了这个：bucket_t
image
为什么是bucket_t呢？因为我在bucket_t的定义中发现了我想要的东西：
image
正常的缓存，一定要存储方法的。既然在bucket_t里面找到了imp和sel；那么说明这条思路是对的，我们顺着这条思路继续探索。
1.2 LLDB打印缓存方法
既然我们大致滤清了cache_t中方法的存储形式，那么我们就通过控制台去打印一下。
我们沿用之前的代码：
image
我们的初次LLDB运行到下面阶段的时候，遇到了问题。究竟cache_t里的缓存方法存在哪里呢？（注意：这里指针平移16字节）
image
上图中$3的结构，对应的就是源码中的数据结构：
image
这里我猜测应该是_originalPreoptCache，存储着缓存方法。但是在继续探索的时候，发现并没有缓存方法。过程如下：
image
此时应该换一个思路，看一看cache_t中有没有一些对应的方法，于是发现了buckets()：
image
这个时候，我们执行以下buckets()：
image
到这里我们终于找到了sel和imp。但是会发现，里面并没有数据，这是因为我们并没有调用方法，所以没有缓存数据。
既然没有缓存数据，那么我们就执行以下方法func，创造缓存数据。但是当我们执行了方法func之后，发现还是没有数据，不过maybeMask产生了变化：
image
这里主要是因为缓存方法的存储是根据哈希值来计算下标的。我这边从新执行了，然后得到了需要的数据。（哈希值的内容，我们文章结尾再探讨）
image
此时我们可以通过sel()和imp(UNUSED_WITHOUT_PTRAUTH bucket_t *base, Class cls)这两函数来获得具体的sel和imp：
image
-
sel:
image
-
imp:
image
2 非源码查看缓存
正常情况下，我们从官网获取的源码是不能够编译的。有些情况下，我们去配置源码的时候，也不一定能够成功让其编译通过。（我这边使用的是命令行工程）
这个时候我们可以采取另外一种方式，让我们可以继续进行源码的探索。那就是，举个例子如下：
- 拷贝
obj_class
举个例子，我们在探索源码的时候，都要经过obj_class，所以我们将obj_class的部分代码拷贝出来，修改成我们自己的名字，拷贝的内容也是一些属性等关键信息。
struct jax_objc_class {
Class isa;
Class superclass;
struct jax_cache_t cache;
struct jax_class_data_bit_t bits;
};
- 整个拷贝之后的代码如下：
typedef uint32_t mask_t; // x86_64 & arm64 asm are less efficient with 16-bits
struct jax_bucket_t {
SEL _sel;
IMP _imp;
};
struct jax_cache_t {
struct jax_bucket_t *_bukets; // 8
mask_t _maybeMask; // 4
uint16_t _flags; // 2
uint16_t _occupied; // 2
};
struct jax_class_data_bit_t {
uintptr_t bits;
};
struct jax_objc_class {
Class isa;
Class superclass;
struct jax_cache_t cache;
struct jax_class_data_bit_t bits;
};
- 创建
Person类，并实现一些测试方法：
image
- 接下来我们在
main函数里面检测一下我们拷贝出来的代码是否可用。这里我们随便打印一下cache里面的信息：
image
-
由于我们有很多的方法，所以我们可以循环打印一下
image
-
增加方法调用，再次循环打印；但是当我们再次循环打印的时候，发现输出的打印信息不正常：
image
3 cache_t 底层原理探索
在上面我们调用多个对象方法的时候，我们的循环打印发生了异常。
并且还发现_occupied和_maybeMask也发生了变化。
这究竟是为什么呢？我们还是需要从源码中寻找答案。
3.1 occupied
首先关于occupied的变化，我们发现了这个函数：void incrementOccupied();
image
image
也就是说incrementOccupied()会让_occupied进行自加操作。
那么我们就要知道它在哪里别调用。
通过搜索发现，它在cache_t的insert方法里面被调用：
image
3.2 insert
其实在看到insert方法的时候，我们就应该有所感觉了。对应缓存，肯定是要有插入方法的。cache_t的insert正是其插入方法。
image
接下来我们分析以下insert源码:
image
上面这部分内容，描述了缓存空间的开辟，其中有一个方法reallocate值得我们去研究一下。
因为，初始化和扩容的时候，都用到了这个方法，但是，传入的参数却不相同。
-
reallocate
image
可以看到，开启缓存空间的方法很简单，首先是根据传入的值开辟新的缓存空间；然后判断是否有旧的缓存，如果有就释放旧的缓存。
既然缓存空间已经开辟完毕了，那接下来就应该是sel和imp相关的操作了。
image
cache_hask
这个是计算哈希值的函数：
// Class points to cache. SEL is key. Cache buckets store SEL+IMP.
// Caches are never built in the dyld shared cache.
static inline mask_t cache_hash(SEL sel, mask_t mask)
{
uintptr_t value = (uintptr_t)sel;
#if CONFIG_USE_PREOPT_CACHES
value ^= value >> 7;
#endif
return (mask_t)(value & mask);
}
cache_nest
这个是计算哈希冲突的函数：
#if CACHE_END_MARKER
static inline mask_t cache_next(mask_t i, mask_t mask) {
return (i+1) & mask;
}
#elif __arm64__
static inline mask_t cache_next(mask_t i, mask_t mask) {
return i ? i-1 : mask;
}
#else
#error unexpected configuration
#endif
3.3 上面问题解答
我们在上面，调用多个对象方法的时候，循环打印出错了。接着我们探究了源码中的insert方法。现在我们可以对这个现象做出解释了。
-
对象方法调用的增加，
_occupied和_maybeMask都变化了
这是因为在cache初始化的时候，分配的空间是4个(INIT_CACHE_SIZE == 4)；随着方法调用的增加，缓存空间不够用了，根据源码中的扩容算法，对缓存空间进行了两倍扩容。 -
mask
在哈希相关的函数中，我们看到了这个参数；这是掩码，mask = capacity -1capacity`是容量的意思。 -
_occupied
字面意思理解是占据，占位的意思，可以理解为缓存中已经存在的sel-imp的个数。
导致_occupied变化的因素有以下几个：init- 属性赋值
- 方法调用
-
上面的循环打印，出现
空值是怎么回事？
这个是缓存空间重新分配造成的，旧的空间被释放，新的空间`重新分配。 -
sel-imp在缓存中的存储顺序
这一点大家要注意，由于下标是通过哈希计算出来的，所以顺序是不固定的，没有先后之分。这一点大家可以参考cache_t::insert函数的后半部分。
