AI智能
改变未来

iOS的OC的方法缓存的源码分析

在日常开发中,我们调用方法的时候有没有想过一个问题,在我们频繁地调用方法,为了高效苹果会不会对使用过的方法做缓存起来?如果有做缓存的话,具体是怎样做的呢?为了了解这块的内容,本篇文章就对cache_t做源码分析。

1.cache_t
cache_t是在objc_class结构体中,占16个字节,cache_t的源码如下:

struct cache_t {struct bucket_t *_buckets;mask_t _mask;mask_t _occupied;...};struct bucket_t {private:// IMP-first is better for arm64e ptrauth and no worse for arm64.// SEL-first is better for armv7* and i386 and x86_64.#if __arm64__MethodCacheIMP _imp;cache_key_t _key;#elsecache_key_t _key;MethodCacheIMP _imp;#endif}using MethodListIMP = IMP;typedef uintptr_t cache_key_t;

从源码可以知道,通过将方法编号SEL和函数地址IMP缓存在bucket_t(又称哈希桶)中。 为了方便接下来的内容,定义了一个TestObject的类,具体的代码如下:

正在跳转(iOS高级开发技术交流裙 进裙密码:123)

#import <Foundation/Foundation.h>NS_ASSUME_NONNULL_BEGIN@interface TestObject : NSObject{NSString *nickName;}@property(nonatomic,copy) NSString *name;-(void)sayName;-(void)sayHello;-(void)sayTest;+(void)sayNickName;@endNS_ASSUME_NONNULL_END#import \"TestObject.h\"@implementation TestObject-(void)sayName{NSLog(@\"%p\",__func__);}-(void)sayHello{NSLog(@\"%p\",__func__);}-(void)sayTest{NSLog(@\"%p\",__func__);}+(void)sayNickName{NSLog(@\"%p\",__func__);}@end//实现的代码TestObject *testObject = [TestObject alloc];Class tClass = object_getClass(testObject);[testObject sayName];[testObject sayHello];NSLog(@\"%@\",testObject);

因为实例对象里面的方法是在类里面调用的,为了验证实例方法是不是存在cache_t里面,我们可以通过lldb的指令来找到cache_t然后深入进去查看,如下图所示

由上图可以知道,因为我们在调用了TestObject类的三个方法(包括了init方法),图中的_mask和_occupied都为3。那么我们再调用多一个方法,如下所示

正在跳转(iOS高级开发技术交流裙 进裙密码:123)

TestObject *testObject = [[TestObject alloc] init];Class tClass = object_getClass(testObject);[testObject sayName];[testObject sayHello];[testObject sayTest];NSLog(@\"%@\",testObject);

再次使用lldb的指令来查看,可以知道此时的_mask为7,但是_occupied为1,并且此时的buckets的数组里面只有一个sayTest方法,还是不是有序存放,此时其他的方法不存在了。所以由此可以知道,方法的缓存并不是有一个存一个的,里面是有对方法的缓存做一定的处理的。
1.1 cache_t的属性值
_buckets:是bucket_t结构体的数组,bucket_t是用来存放方法的SEL内存地址和IMP的。
_mask:是数组容量的大小用作掩码。(因为这里维护的数组大小都是2的整数次幂,所以_mask的二进制位000011,000111,001111)刚好可以用作hash取余数的掩码。刚好保证相与后不超过缓存大小。
_occupied:是当前已缓存的方法数,即数组中已使用了多少位置。
2.方法缓存的原理分析
OC方法的本质是消息发送(即objc_msgSend),底层是通过方法的 SEL 查找 IMP。读取cache_t缓存是通过objc_msgSend的查找,cache_t缓存的写首先是通过cache_fill函数,如下源码:

正在跳转(iOS高级开发技术交流裙 进裙密码:123)

* Cache readers (PC-checked by collecting_in_critical())* objc_msgSend** cache_getImp* Cache writers (hold cacheUpdateLock while reading or writing; not PC-checked)* cache_fill         (acquires lock)* cache_expand       (only called from cache_fill)* cache_create       (only called from cache_expand)* bcopy               (only called from instrumented cache_expand)* flush_caches        (acquires lock)* cache_flush        (only called from cache_fill and flush_caches)* cache_collect_free (only called from cache_expand and cache_flush)

2.1 cache_fill
方法的缓存首先是通过cache_fill函数,源码如下

正在跳转(iOS高级开发技术交流裙 进裙密码:123)

void cache_fill(Class cls, SEL sel, IMP imp, id receiver){#if !DEBUG_TASK_THREADSmutex_locker_t lock(cacheUpdateLock);cache_fill_nolock(cls, sel, imp, receiver);#else_collecting_in_critical();return;#endif}cache_fill方法传入cls类的Class和方法的SEL,IMP。

2.2 cache_fill_nolock

static void cache_fill_nolock(Class cls, SEL sel, IMP imp, id receiver){cacheUpdateLock.assertLocked();// Never cache before +initialize is doneif (!cls->isInitialized()) return;// Make sure the entry wasn\'t added to the cache by some other thread// before we grabbed the cacheUpdateLock.if (cache_getImp(cls, sel)) return;cache_t *cache = getCache(cls);cache_key_t key = getKey(sel);// Use the cache as-is if it is less than 3/4 fullmask_t newOccupied = cache->occupied() + 1;mask_t capacity = cache->capacity();if (cache->isConstantEmptyCache()) {// Cache is read-only. Replace it.cache->reallocate(capacity, capacity ?: INIT_CACHE_SIZE);}else if (newOccupied <= capacity / 4 * 3) {// Cache is less than 3/4 full. Use it as-is.}else {// Cache is too full. Expand it.cache->expand();}// Scan for the first unused slot and insert there.// There is guaranteed to be an empty slot because the// minimum size is 4 and we resized at 3/4 full.bucket_t *bucket = cache->find(key, receiver);if (bucket->key() == 0) cache->incrementOccupied();bucket->set(key, imp);}cache_t *getCache(Class cls){assert(cls);return &cls->cache;}cache_key_t getKey(SEL sel){assert(sel);return (cache_key_t)sel;}/* Initial cache bucket count. INIT_CACHE_SIZE must be a power of two. */enum {INIT_CACHE_SIZE_LOG2 = 2,INIT_CACHE_SIZE      = (1 << INIT_CACHE_SIZE_LOG2)};#if __LP64__typedef uint32_t mask_t;  // x86_64 & arm64 asm are less efficient with 16-bits#elsetypedef uint16_t mask_t;#endiftypedef uintptr_t cache_key_t;

从源码中各个方法来分析一下,其中的getCache(cls)通过cls来获取到类的cache_t。getKey(sel)将SEL转化为cache_key_t的类型。下面是 cache->occupied()和cache->capacity()的源码。

mask_t cache_t::occupied(){return _occupied;}mask_t cache_t::capacity(){return mask() ? mask()+1 : 0;}mask_t cache_t::mask(){return _mask;}

_occupied是方法的数量,默认是0,所以一开始进来的话newOccupied的值是1相当于占

用1个缓存的数量来做缓存,而capacity()是获取缓存的方法数量,默认也是0的,如果

mask()有值了就是在这个基础上加1,这就相当于获取方法的容量。接下来就是三个的条

件判断了,第一个判断isConstantEmptyCache()是判断是否有缓存,第二个判断是判断占

用的方法数量是否小于等于容量的3/4,如果是就什么都不做。否则就需要开始扩容

expand。如果没有缓存的话就需要执行reallocate函数。其中reallocate中的

INIT_CACHE_SIZE是4,所以一开始传进去的reallocate的值是0和4.

2.2.1 reallocate
从函数名的大概可以看出意思,就是重新初始化缓存的意思。这个函数的源码如下:

void cache_t::reallocate(mask_t oldCapacity, mask_t newCapacity){//判断是否可以释放旧的缓存的标示bool freeOld = canBeFreed();//获取旧的bucketsbucket_t *oldBuckets = buckets();//创建新的bucketsbucket_t *newBuckets = allocateBuckets(newCapacity);// Cache\'s old contents are not propagated.// This is thought to save cache memory at the cost of extra cache fills.// fixme re-measure thisassert(newCapacity > 0);assert((uintptr_t)(mask_t)(newCapacity-1) == newCapacity-1);//设置新的buckets和赋值masksetBucketsAndMask(newBuckets, newCapacity - 1);if (freeOld) {//释放旧的bucketscache_collect_free(oldBuckets, oldCapacity);cache_collect(false);}}bool cache_t::canBeFreed(){return !isConstantEmptyCache();}bucket_t *allocateBuckets(mask_t newCapacity){// Allocate one extra bucket to mark the end of the list.// This can\'t overflow mask_t because newCapacity is a power of 2.// fixme instead put the end mark inline when +1 is malloc-inefficientbucket_t *newBuckets = (bucket_t *)calloc(cache_t::bytesForCapacity(newCapacity), 1);bucket_t *end = cache_t::endMarker(newBuckets, newCapacity);#if __arm__// End marker\'s key is 1 and imp points BEFORE the first bucket.// This saves an instruction in objc_msgSend.end->setKey((cache_key_t)(uintptr_t)1);end->setImp((IMP)(newBuckets - 1));#else// End marker\'s key is 1 and imp points to the first bucket.end->setKey((cache_key_t)(uintptr_t)1);end->setImp((IMP)newBuckets);#endifif (PrintCaches) recordNewCache(newCapacity);return newBuckets;}void cache_t::setBucketsAndMask(struct bucket_t *newBuckets, mask_t newMask){// objc_msgSend uses mask and buckets with no locks.// It is safe for objc_msgSend to see new buckets but old mask.// (It will get a cache miss but not overrun the buckets\' bounds).// It is unsafe for objc_msgSend to see old buckets and new mask.// Therefore we write new buckets, wait a lot, then write new mask.// objc_msgSend reads mask first, then buckets.// ensure other threads see buckets contents before buckets pointermega_barrier();_buckets = newBuckets;// ensure other threads see new buckets before new maskmega_barrier();_mask = newMask;_occupied = 0;}

从源码中可以看到reallocate获取旧的buckets和创建新的buckets,因为旧的buckets在

判断可以释放的时候是需要抹掉的。创建新的buckets在allocateBuckets函数可以知道,

通过calloc函数来申请cache_t类型的内存空间,并且对key和imp都设置了默认值。

在setBucketsAndMask函数中对buckets和_mask赋值,因为一开始传进来的newMask为3,

_occupied为0之所以为0是因为此时还没有对方法做缓存只是初始化值。这就很好地说明了上

面第一次用lldb指令的时候得到的mask为3.

2.2.2 expand

在newOccupied的值大于capacity的3/4,这时候就需要扩容,这时候就需要执行expand()函数void cache_t::expand(){cacheUpdateLock.assertLocked();uint32_t oldCapacity = capacity();uint32_t newCapacity = oldCapacity ? oldCapacity*2 : INIT_CACHE_SIZE;if ((uint32_t)(mask_t)newCapacity != newCapacity) {// mask overflow - can\'t grow further// fixme this wastes one bit of masknewCapacity = oldCapacity;}reallocate(oldCapacity, newCapacity);}mask_t cache_t::capacity(){return mask() ? mask()+1 : 0;}

在需要扩容的时候,此时的capacity()值为4了,所以oldCapacity为4,newCapacity

为8,然后会继续执行reallocate函数,传进去的参数分别为4和8。根据上面的

reallocate函数的执行流程会将旧的buckets清空,修改mask的值为7,然后occupied的

值为0.但是为什么会在lldb的指令的时候看到的occupied为1呢?在这个流程走完之后,

执行完判断的流程之后,会执行到

// Scan for the first unused slot and insert there.// There is guaranteed to be an empty slot because the// minimum size is 4 and we resized at 3/4 full.bucket_t *bucket = cache->find(key, receiver);if (bucket->key() == 0) cache->incrementOccupied();bucket->set(key, imp);void cache_t::incrementOccupied(){_occupied++;}

其中find函数通过上面的key和receiver来查找bucket_t。如果key()为0的时候,这

时会对_occupied数量+1。并且对bucket的key和imp进行填充。

2.2.3 find函数

bucket_t * cache_t::find(cache_key_t k, id receiver){assert(k != 0);bucket_t *b = buckets();mask_t m = mask();// 通过cache_hash函数【begin  = k & m】计算出key值 k 对应的 index值 begin,用来记录查询起始索引mask_t begin = cache_hash(k, m);// begin 赋值给 i,用于切换索引mask_t i = begin;do {if (b[i].key() == 0  ||  b[i].key() == k) {//用这个i从散列表取值,如果取出来的bucket_t的 key = k,则查询成功,返回该bucket_t,//如果key = 0,说明在索引i的位置上还没有缓存过方法,同样需要返回该bucket_t,用于中止缓存查询。return &b[i];}} while ((i = cache_next(i, m)) != begin);// 这一步其实相当于 i = i-1,回到上面do循环里面,相当于查找散列表上一个单元格里面的元素,再次进行key值 k的比较,//当i=0时,也就i指向散列表最首个元素索引的时候重新将mask赋值给i,使其指向散列表最后一个元素,重新开始反向遍历散列表,//其实就相当于绕圈,把散列表头尾连起来,不就是一个圈嘛,从begin值开始,递减索引值,当走过一圈之后,必然会重新回到begin值,//如果此时还没有找到key对应的bucket_t,或者是空的bucket_t,则循环结束,说明查找失败,调用bad_cache方法。// hackClass cls = (Class)((uintptr_t)this - offsetof(objc_class, cache));cache_t::bad_cache(receiver, (SEL)k, cls);}static inline mask_t cache_hash(cache_key_t key, mask_t mask){return (mask_t)(key & mask);}

ind函数可以知道,通过mask的大小与获取的key用hash函数的形式得到begin下标来得到

bucket_t的地址进行返回,因为hash函数是无序的,所以在buckets里面存放的位置也是无

序的。

在类的cache_t中是找不到类方法的,因为类方法都是缓存在元类中,所以如果想通过lldb指令来查找类方法,可以先通过isa找到元类,可以根据上面的流程来验证元类中是不是存放类方法。

3.最后
OC方法的本质是消息发送(即objc_msgSend),底层是通过方法的 SEL 查找 IMP。
1.方法缓存在cache_t中,分别用buckets指针地址来存方法数组,mask来存放方法数组的容量大小,occupied来存放当前的方法占用数量。
2.在方法的newOccupied新的方法占用数量大于当前的方法数量capacity()的3/4就需要扩容。
3.在扩容的过程中,会设置mask为capacity() * 2 – 1即方法的数量的2倍减1,例如第一次为3,第二次为7。最后都会将旧的buckets列表清空。但是最后都会将执行到需要扩容的方法加入到buckets里面。

正在跳转(iOS高级开发技术交流裙 进裙密码:123)

赞(0) 打赏
未经允许不得转载:爱站程序员基地 » iOS的OC的方法缓存的源码分析