iOS底层原理 objc_class 中 cache 原理分析

2022-04-30  本文已影响0人  Mr木子李

objc_class中cache存储的是什么？

首先，我们需要知道cache中存储的到底是什么？

struct cache_t {
#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_OUTLINED//macOS、模拟器 -- 主要是架构区分
    // explicit_atomic 显示原子性，目的是为了能够 保证 增删改查时 线程的安全性
    //等价于 struct bucket_t * _buckets;
    //_buckets 中放的是 sel imp
    //_buckets的读取 有提供相应名称的方法 buckets()
    explicit_atomic<struct bucket_t *> _buckets;
    explicit_atomic<mask_t> _mask;
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16 //64位真机
    explicit_atomic<uintptr_t> _maskAndBuckets;//写在一起的目的是为了优化
    mask_t _mask_unused;

    //以下都是掩码，即面具 -- 类似于isa的掩码，即位域
    // 掩码省略....
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_LOW_4 //非64位 真机
    explicit_atomic<uintptr_t> _maskAndBuckets;
    mask_t _mask_unused;

    //以下都是掩码，即面具 -- 类似于isa的掩码，即位域
    // 掩码省略....
#else
#error Unknown cache mask storage type.
#endif

#if __LP64__
    uint16_t _flags;
#endif
    uint16_t _occupied;

    //方法省略.....
}


struct bucket_t {
private:
#if __arm64__ //真机
    //explicit_atomic 是加了原子性的保护
    explicit_atomic<uintptr_t> _imp;
    explicit_atomic<SEL> _sel;
#else //非真机
    explicit_atomic<SEL> _sel;
    explicit_atomic<uintptr_t> _imp;
#endif
    //方法等其他部分省略
}

所以通过上面两个结构体源码可知，cache中缓存的是sel-imp

整体的结构如下图所示

image

在cache中查找sel-imp

cache_t中查找存储的sel-imp，有以下两种方式

准备工作

通过源码查找

由上图可知，在没有执行方法调用时，此时的cache是没有缓存的，执行了一次方法调用，cache中就有了一个缓存，即调用一次方法就会缓存一次方法。

我们现在了解了如何获取cache中sel-imp，如何验证打印的sel和imp就是我们调用的呢？可以通过machoView打开target的可执行文件，在方法列表中查看其imp的值是否是一致的，如下所示，发现是一致的，所以打印的这个sel-imp就是LGPerson的实例方法

image

脱离源码通过项目查找

脱离源码环境，就是将所需的源码的部分拷贝至项目中，其完整代码如下

typedef uint32_t mask_t;  // x86_64 & arm64 asm are less efficient with 16-bits

struct lg_bucket_t {
    SEL _sel;
    IMP _imp;
};

struct lg_cache_t {
    struct lg_bucket_t * _buckets;
    mask_t _mask;
    uint16_t _flags;
    uint16_t _occupied;
};

struct lg_class_data_bits_t {
    uintptr_t bits;
};

struct lg_objc_class {
    Class ISA;
    Class superclass;
    struct lg_cache_t cache;             // formerly cache pointer and vtable
    struct lg_class_data_bits_t bits;    // class_rw_t * plus custom rr/alloc flags
};

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        LGPerson *p  = [LGPerson alloc];
        Class pClass = [LGPerson class];  // objc_clas
        [p say1];
        [p say2];
        //[p say3];
        //[p say4];

        struct lg_objc_class *lg_pClass = (__bridge struct lg_objc_class *)(pClass);
        NSLog(@"%hu - %u",lg_pClass->cache._occupied,lg_pClass->cache._mask);
        for (mask_t i = 0; i<lg_pClass->cache._mask; i++) {
            // 打印获取的 bucket
            struct lg_bucket_t bucket = lg_pClass->cache._buckets[I];
            NSLog(@"%@ - %p",NSStringFromSelector(bucket._sel),bucket._imp);
        }

        NSLog(@"Hello, World!");
    }
    return 0;
}

针对上面的打印结果，有以下几点疑问

带着上述的这些疑问，下面来进行cache底层原理的探索

cache_t底层原理分析

void incrementOccupied(); //Occupied自增

//👇具体实现
void cache_t::incrementOccupied() 
{
    _occupied++;
}

但本文的重点还是分析cache存储的原理，接下来根据cache_t写入的流程图，着重分析insert方法

insert方法分析

在insert方法中，其源码实现如下

image

主要分为以下几部分

其中，第一步，根据occupied的值计算出当前的缓存占用量，当属性未赋值及无方法调用时，此时的occupied()为0，而newOccupied为1，如下所示

mask_t newOccupied = occupied() + 1;

关于缓存占用量的计算，有以下几点说明：

【第二步】根据缓存占用量判断执行的操作

if (slowpath(isConstantEmptyCache())) { //小概率发生的 即当 occupied() = 0时，即创建缓存，创建属于小概率事件
    // Cache is read-only. Replace it.
    if (!capacity) capacity = INIT_CACHE_SIZE; //初始化时，capacity = 4（1<<2 -- 100）
    reallocate(oldCapacity, capacity, /* freeOld */false); //开辟空间
    //到目前为止，if的流程的操作都是初始化创建
}


else if (fastpath(newOccupied + CACHE_END_MARKER <= capacity / 4 * 3)) { 
    // Cache is less than 3/4 full. Use it as-is.
}


else {//如果超出了3/4，则需要扩容（两倍扩容）
    //扩容算法： 有cap时，扩容两倍，没有cap就初始化为4
    capacity = capacity ? capacity * 2 : INIT_CACHE_SIZE;  // 扩容两倍 2*4 = 8
    if (capacity > MAX_CACHE_SIZE) {
        capacity = MAX_CACHE_SIZE;
    }
    // 走到这里表示 曾经有，但是已经满了，需要重新梳理
    reallocate(oldCapacity, capacity, true);
    // 内存 扩容完毕
}

realloc方法：开辟空间

该方法，在第一次创建以及两倍扩容时，都会使用，其源码实现如图所示

image

主要有以下几步

【第三步】针对需要存储的bucket进行内部imp和sel赋值

这部分主要是根据cache_hash方法，即哈希算法 ，计算sel-imp存储的哈希下标，分为以下三种情况：

其中涉及的两种哈希算法，其源码如下

static inline mask_t cache_hash(SEL sel, mask_t mask) 
{
    return (mask_t)(uintptr_t)sel & mask; // 通过sel & mask（mask = cap -1）
}


#if __arm__  ||  __x86_64__  ||  __i386__
// objc_msgSend has few registers available.
// Cache scan increments and wraps at special end-marking bucket.
#define CACHE_END_MARKER 1
static inline mask_t cache_next(mask_t i, mask_t mask) {
    return (i+1) & mask; //（将当前的哈希下标 +1） & mask，重新进行哈希计算，得到一个新的下标
}

#elif __arm64__
// objc_msgSend has lots of registers available.
// Cache scan decrements. No end marker needed.
#define CACHE_END_MARKER 0
static inline mask_t cache_next(mask_t i, mask_t mask) {
    return i ? i-1 : mask; //如果i是空，则为mask，mask = cap -1，如果不为空，则 i-1，向前插入sel-imp
}

到此，cache_t的原理基本分析完成了，然后前文提及的几个问题，我们现在就有答案了

疑问解答

1、_mask是什么？

_mask是指掩码数据，用于在哈希算法或者哈希冲突算法中计算哈希下标，其中mask 等于capacity - 1

2、_occupied 是什么？

_occupied表示哈希表中 sel-imp 的占用大小 (即可以理解为分配的内存中已经存储了sel-imp的的个数)，

3、为什么随着方法调用的增多，其打印的occupied 和 mask会变化？

因为在cache初始化时，分配的空间是4个，随着方法调用的增多，当存储的sel-imp个数，即newOccupied + CACHE_END_MARKER（等于1）的和 超过 总容量的3/4,例如有4个时，当occupied等于2时，就需要对cache的内存进行两倍扩容

4、bucket数据为什么会有丢失的情况？，例如2-7中，只有say3、say4方法有函数指针

原因是在扩容时，是将原有的内存全部清除了，再重新申请了内存导致的

5、2-7中say3、say4的打印顺序为什么是say4先打印，say3后打印，且还是挨着的，即 顺序有问题 ？

因为sel-imp的存储是通过哈希算法计算下标的，其计算的下标有可能已经存储了sel，所以又需要通过哈希冲突算法重新计算哈希下标，所以导致下标是随机的，并不是固定的

6、打印的 cache_t 中的 ocupied 为什么是从 2 开始？

这里是因为LGPerson通过alloc创建的对象，并对其两个属性赋值的原因，属性赋值，会隐式调用set方法，set方法的调用也会导致occupied变化

上一篇 下一篇

猜你喜欢

热点阅读