AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

iOS-底层原理 11：objc_class 中 cache 原理分析

2022-05-17 117
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： iOS-底层原理 11：objc_class 中 cache 原理分析

本文的主要目的是理解cache_t以及sel-imp的缓存原理


整体分析

在之前的iOS-底层原理 07：isa与类关联的原理和iOS-底层原理 08：类 & 类结构分析中，分析了objc_class中isa和bits，这次主要是分析objc_calss中的cache属性


cache中存储的是什么？

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


  • 查看cache_t的源码，发现分成了3个架构的处理，其中真机的架构中，mask和bucket是写在一起，目的是为了优化，可以通过各自的掩码来获取相应的数据


  • CACHE_MASK_STORAGE_OUTLINED 表示运行的环境 模拟器 或者 macOS
  • CACHE_MASK_STORAGE_HIGH_16 表示运行环境是 64位的真机
  • CACHE_MASK_STORAGE_LOW_4 表示运行环境是 非64位 的真机
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;
    //方法省略.....
}
  • 查看bucket_t的源码，同样分为两个版本，真机 和 非真机，不同的区别在于sel 和 imp的顺序不一致
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.png

整体类型关系结构图


在cache中查找sel-imp

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

  • 通过源码查找
  • 脱离源码在项目中查找


准备工作

  • 定义一个LGPerson类，并定义两个属性及5个实例方法及其实现

image.png

image.png

定义LGPerson类-2


  • 在main中定义LGPerson类的对象p，并调用其中的3个实例方法，在p调用第一个方法处加一个断点

image.png


通过源码查找

  • 运行执行，断在[p sayHello];部分，此时执行以下lldb调试流程

image.png

仅一个方法调用的sel-imp查找流程


  • cache属性的获取，需要通过pclass的首地址平移16字节，即首地址+0x10获取cache的地址
  • 从源码的分析中，我们知道sel-imp是在cache_t的_buckets属性中（目前处于macOS环境），而在cache_t结构体中提供了获取_buckets属性的方法buckets()
  • 获取了_buckets属性，就可以获取sel-imp了，这两个的获取在bucket_t结构体中同样提供了相应的获取方法sel() 以及 imp(pClass)


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


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

image.png

接着上面的步骤，我们再次调用一个方法，这次我们想要获取第二个sel，其调试的lldb如下

image.png

多个方法调用的sel-imp查找


  • 第一个调用方法的存储获取很简单，直接通过_buckets的首地址调用对应的方法即可，那么获取第二个呢？在之前的iOS-底层原理 08：类 & 类结构分析文章中，曾提及过一个概念 指针偏移，所以我们这里可以通过_buckets属性的首地址偏移，即 p *($9+1)即可获取第二个方法的sel 和imp
    如果有多个方法需要获取，以此类推，例如p *($9+i)


脱离源码通过项目查找

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

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;
}

这里有个问题需要注意，在源码中，objc_class的ISA属性是继承自objc_object的，但在我们将其拷贝过来时，去掉了objc_class的继承关系，需要将这个属性明确，否则打印的结果是有问题，如下图所示，


image.png

加上ISA属性后，增加两个方法的调用，其正确的打印结果应该是这样的

image.png

在增加两个方法的调用，即解开say3、say4的注释，其打印结果如下

image.png

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


  • 1、_mask是什么？
  • 2、_occupied 是什么？
  • 3、为什么随着方法调用的增多，其打印的occupied 和 mask会变化？
  • 4、bucket数据为什么会有丢失的情况？，例如2-7中，只有say3、say4方法有函数指针
  • 5、2-7中say3、say4的打印顺序为什么是say4先打印，say3后打印，且还是挨着的，即顺序有问题？
  • 6、打印的cache_t中的_ocupied为什么是从2开始？


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


cache_t底层原理分析

  • 首先，从cache_t中的_mask属性开始分析，找cache_t中引起变化的函数，发现了incrementOccupied()函数

image.png该函数的具体实现为

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

源码中，全局搜索incrementOccupied()函数，发现只在cache_t的insert方法有调用

image.png

insert方法，理解为cache_t的插入，而cache中存储的就是sel-imp，所以cache的原理从insert方法开始分析，以下是cache原理分析的流程图

image.png

全局搜索insert(方法，发现只有cache_fill方法中的调用符合

image.png

全局搜索cache_fill，发现在写入之前，还有一步操作，即cache读取，即查找sel-imp，如下所示

image.png

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


insert方法分析

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

image.png

主要分为以下几部分


  • 【第一步】计算出当前的缓存占用量
  • 【第二步】根据缓存占用量``判断执行的操作
  • 【第三步】针对需要存储的bucket进行内部imp和sel赋值


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

mask_t newOccupied = occupied() + 1;

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


  • alloc申请空间时，此时的对象已经创建，如果再调用init方法，occupied也会+1
  • 当有属性赋值时，会隐式调用set方法，occupied也会增加，即有几个属性赋值，occupied就会在原有的基础上加几个
  • 当有方法调用时，occupied也会增加，即有几次调用，occupied就会在原有的基础上加几个


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

  • 如果是第一次创建，则默认开辟4个
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的流程的操作都是初始化创建
}
  • 如果缓存占用量小于等于3/4，则不作任何处理
else if (fastpath(newOccupied + CACHE_END_MARKER <= capacity / 4 * 3)) { 
    // Cache is less than 3/4 full. Use it as-is.
}
  • 如果缓存占用量超过3/4，则需要进行两倍扩容以及重新开辟空间
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.png

主要有以下几步


  • allocateBuckets方法：向系统申请开辟内存，即开辟bucket，此时的bucket只是一个临时变量
  • setBucketsAndMask方法：将临时的bucket存入缓存中，此时的存储分为两种情况：
  • 如果是真机，根据bucket和mask的位置存储，并将occupied占用设置为0

image.png

如果不是真机，正常存储bucket和mask，并将occupied占用设置为0

image.png

如果有旧的buckets，需要清理之前的缓存，即调用cache_collect_free方法，其源码实现如下

image.png

该方法的实现主要有以下几步：


  • _garbage_make_room方法：创建垃圾回收空间
    image.png


  • 如果是第一次，需要分配回收空间
  • 如果不是第一次，则将内存段加大，即原有内存*2
  • 记录存储这次的bucket
  • cache_collect方法：垃圾回收，清理旧的bucket

image.png


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

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


  • 如果哈希下标的位置未存储sel，即该下标位置获取sel等于0，此时将sel-imp存储进去，并将occupied占用大小加1
  • 如果当前哈希下标存储的sel 等于 即将插入的sel，则直接返回
  • 如果当前哈希下标存储的sel 不等于 即将插入的sel，则重新经过cache_next方法 即哈希冲突算法，重新进行哈希计算，得到新的下标，再去对比进行存储

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

  • cache_hash：哈希算法


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


  • cache_next：哈希冲突算法
#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的的个数)，


  • init会导致occupied变化
  • 属性赋值，也会隐式调用，导致occupied变化
  • 方法调用，导致occupied变化


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变化


文章标签：
Java
iOS开发
MacOS
算法
缓存
存储
关键词：
iOS分析
iOS原理
iOS底层原理
iOS原理分析
iOS cache
5na6pyt44b2ti
目录
相关文章
游客sjjs6jgz4gp7m1
|
7天前
|
安全 Android开发 数据安全/隐私保护
深入探讨iOS与Android系统安全性对比分析
在移动操作系统领域，iOS和Android无疑是两大巨头。本文从技术角度出发，对这两个系统的架构、安全机制以及用户隐私保护等方面进行了详细的比较分析。通过深入探讨，我们旨在揭示两个系统在安全性方面的差异，并为用户提供一些实用的安全建议。
游客sjjs6jgz4gp7m1
29 3
帅政的oss
|
2月前
|
开发工具 Android开发 Swift
安卓与iOS开发环境对比分析
在移动应用开发的广阔舞台上，安卓和iOS这两大操作系统无疑是主角。它们各自拥有独特的特点和优势，为开发者提供了不同的开发环境和工具。本文将深入浅出地探讨安卓和iOS开发环境的主要差异，包括开发工具、编程语言、用户界面设计、性能优化以及市场覆盖等方面，旨在帮助初学者更好地理解两大平台的开发特点，并为他们选择合适的开发路径提供参考。通过比较分析，我们将揭示不同环境下的开发实践，以及如何根据项目需求和目标受众来选择最合适的开发平台。
帅政的oss
46 2
131王
|
2月前
|
安全 Android开发 数据安全/隐私保护
探索安卓与iOS的安全性差异：技术深度分析与实践建议
本文旨在深入探讨并比较Android和iOS两大移动操作系统在安全性方面的不同之处。通过详细的技术分析，揭示两者在架构设计、权限管理、应用生态及更新机制等方面的安全特性。同时，针对这些差异提出针对性的实践建议，旨在为开发者和用户提供增强移动设备安全性的参考。
131王
125 3
ShaFaChuang-36210
|
29天前
|
开发工具 Android开发 Swift
安卓与iOS开发环境的差异性分析
【10月更文挑战第8天】 本文旨在探讨Android和iOS两大移动操作系统在开发环境上的不同，包括开发语言、工具、平台特性等方面。通过对这些差异性的分析，帮助开发者更好地理解两大平台，以便在项目开发中做出更合适的技术选择。
ShaFaChuang-36210
37 0
叫个什么名字
|
2月前
|
安全 Linux Android开发
探索安卓与iOS的安全性差异：技术深度分析
本文深入探讨了安卓（Android）和iOS两个主流操作系统平台在安全性方面的不同之处。通过比较它们在架构设计、系统更新机制、应用程序生态和隐私保护策略等方面的差异，揭示了每个平台独特的安全优势及潜在风险。此外，文章还讨论了用户在使用这些设备时可以采取的一些最佳实践，以增强个人数据的安全。
叫个什么名字
82 2
肥猪肥猪-17824
|
3月前
|
Java 开发工具 Android开发
安卓与iOS开发环境对比分析
【8月更文挑战第20天】在移动应用开发的广阔天地中，Android和iOS两大平台各自占据着重要的位置。本文将深入探讨这两种操作系统的开发环境，从编程语言到开发工具，从用户界面设计到性能优化，以及市场趋势对开发者选择的影响。我们旨在为读者提供一个全面的比较视角，帮助理解不同平台的优势与挑战，并为那些站在选择十字路口的开发者提供有价值的参考信息。
肥猪肥猪-17824
98 17
萝卜带泥
|
2月前
|
IDE 开发工具 Android开发
安卓与iOS开发环境对比分析
本文将探讨安卓和iOS这两大移动操作系统在开发环境上的差异，从工具、语言、框架到生态系统等多个角度进行比较。我们将深入了解各自的优势和劣势，并尝试为开发者提供一些实用的建议，以帮助他们根据自己的需求选择最适合的开发平台。
萝卜带泥
44 1
游客moiomvrp3vyac2
|
3月前
|
开发框架 Android开发 Swift
安卓与iOS应用开发对比分析
【8月更文挑战第20天】在移动应用开发的广阔天地中，安卓和iOS两大平台各占半壁江山。本文将深入探讨这两大操作系统在开发环境、编程语言、用户界面设计、性能优化及市场分布等方面的差异和特点。通过比较分析，旨在为开发者提供一个宏观的视角，帮助他们根据项目需求和目标受众选择最合适的开发平台。同时，文章还将讨论跨平台开发框架的利与弊，以及它们如何影响着移动应用的开发趋势。
游客moiomvrp3vyac2
53 2
shuj
|
3月前
|
安全 搜索推荐 Android开发
安卓与iOS应用开发的对比分析
【8月更文挑战第20天】在移动应用开发领域，安卓和iOS两大平台各领风骚。本文通过深入探讨两者的开发环境、编程语言、用户界面设计、应用市场及分发机制等方面的差异，揭示了各自的优势和挑战。旨在为开发者提供决策支持，同时帮助理解为何某些应用可能优先选择在一个平台上发布。
shuj
41 2
jiashufen
|
3月前
|
开发工具 Android开发 Swift
安卓与iOS开发环境对比分析
在移动应用开发的大舞台上，安卓与iOS两大操作系统各占半壁江山。本文将深入浅出地比较两者的开发环境，从开发工具、编程语言到用户界面设计等多个维度进行剖析，旨在为初入行的开发者们提供一盏明灯，帮助他们选择适合自己的开发路径。通过实例分析和数据支持，我们将揭示这两个平台的独特优势和潜在挑战，以及它们如何影响应用的性能和用户体验。
jiashufen
67 1