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里面找到了impsel;那么说明这条思路是对的,我们顺着这条思路继续探索。


1.2 LLDB打印缓存方法

既然我们大致滤清了cache_t中方法的存储形式,那么我们就通过控制台去打印一下。

我们沿用之前的代码:


image

我们的初次LLDB运行到下面阶段的时候,遇到了问题。究竟cache_t里的缓存方法存在哪里呢?(注意:这里指针平移16字节

image

上图中$3的结构,对应的就是源码中的数据结构:

image

这里我猜测应该是_originalPreoptCache,存储着缓存方法。但是在继续探索的时候,发现并没有缓存方法。过程如下:

image

此时应该换一个思路,看一看cache_t中有没有一些对应的方法,于是发现了buckets()

image

这个时候,我们执行以下buckets()

image

到这里我们终于找到了selimp。但是会发现,里面并没有数据,这是因为我们并没有调用方法,所以没有缓存数据。

既然没有缓存数据,那么我们就执行以下方法func,创造缓存数据。但是当我们执行了方法func之后,发现还是没有数据,不过maybeMask产生了变化:

image

这里主要是因为缓存方法的存储是根据哈希值来计算下标的。我这边从新执行了,然后得到了需要的数据。(哈希值的内容,我们文章结尾再探讨)

image

此时我们可以通过sel()imp(UNUSED_WITHOUT_PTRAUTH bucket_t *base, Class cls)这两函数来获得具体的selimp

image
  • sel:

    image

  • imp:

    image


2 非源码查看缓存

正常情况下,我们从官网获取的源码是不能够编译的。有些情况下,我们去配置源码的时候,也不一定能够成功让其编译通过。(我这边使用的是命令行工程)

这个时候我们可以采取另外一种方式,让我们可以继续进行源码的探索。那就是\color{red}{将源码,部分拷贝到我们自己的项目中(注意,不是全部拷贝)},举个例子如下:

  • 拷贝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_tinsert方法里面被调用:

image

3.2 insert

其实在看到insert方法的时候,我们就应该有所感觉了。对应缓存,肯定是要有插入方法的。cache_tinsert正是其插入方法。

image

接下来我们分析以下insert源码:

image

上面这部分内容,描述了缓存空间的开辟,其中有一个方法reallocate值得我们去研究一下。

因为,初始化扩容的时候,都用到了这个方法,但是,传入的参数却不相同。

  • reallocate
    image

可以看到,开启缓存空间的方法很简单,首先是根据传入的值开辟新的缓存空间;然后判断是否有旧的缓存,如果有就释放旧的缓存

既然缓存空间已经开辟完毕了,那接下来就应该是selimp相关的操作了。

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函数的后半部分。

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容