iOS底层之类的结构分析

从iOS底层之isa结构分析及关联类我们探究了类的实例对象的内存结构，对象指针的首地址存储了isa，其中存储了类的信息，那么同样道理，我们也可以打印这个类的内存地址。

类内存地址

图中的操作，用以打印出objc对象的类BKPerson的内存分布，及获取BKPerson类的类——元类。

可以看到BKPerson的地址是0x00000001000020e8，而它的isa指向的类的地址是0x00000001000020c0，这是明显不一样的。

问：那么为什么地址不一样，打印的结果却都是BKPerson类？

这里需要了解下元类：

对象的isa存储着对象的类的信息，而上图可以看出，类也有内存地址，类的isa存储着这个类对象的归属类信息，也就是元类。
元类是由系统定义的，由编译器完成创建。
元类是自定义类的创建过程中系统定义的，那么它的名字也是用同一个类名。

既然如此，那我们可以继续打印，查看这个元类的归属类，再看这个归属类的归属类。

NSObject根元类

可以看到，BKPerson类的元类的归属类，是NSObject类，而NSObject类的元类指向了自己。也就是说NSObject类是BKPerson类的根元类。

那么如果我打印NSObject类的地址：

根元类地址与NSObject类地址对比

可以看到，这个根元类NSObject的地址0x00000001003340f0和NSObject的地址0x0000000100334140并不一致。难道说NSObject类存在多个，类不是唯一的？？
那么我们来验证一下：

1. 第一种方式：元类地址对比

NSObject的元类

打印NSObject的isa指向的元类，可以看到打印出的元类也是NSObject，而且地址0x00000001003340f0和BKPerson的根元类地址是一致的。

2. 第二种方式：多种方式打印多个对象的类地址

    Class class1 = [BKPerson class];
    Class class2 = [BKPerson alloc].class;
    Class class3 = object_getClass([BKPerson alloc]);
    NSLog(@"\n%p\n%p\n%p",class1,class2,class3);

可以看到，以3种方式打印创建的3个对象的类地址，都是指向同一个地址。

由此得出结论：类的内存地址只有一份，类只存在一个，是唯一的。所有类的根元类都指向NSObject。

对象、类、元类的关系

关于实例对象、类、元类、根元类的归属，子类、父类的继承关系，实例对象之间的关系可通过下图帮助理解。

从图中可以理清他们的关系：

实例对象之间的并没有任何关系，无论他们的类是否有继承关系。
实例对象的isa指向类，类的isa指向元类、元类的isa指向根元类，根元类指向自身，形成闭环。根元类就是NSObject。
子类继承于父类，父类继承于根类，根类继承于nil，也就是根类没有父类。根类就是NSObect。
子类的元类继承于父类的元类，父类的元类继承于根元类，根元类继承于根类。

类的结构

为什么所有的对象、类、元类、根元类都有一个isa成员？
我们查看objc4-781版本的源码。

查看NSObject类的实现

@interface NSObject <NSObject> {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wobjc-interface-ivars"
    Class isa  OBJC_ISA_AVAILABILITY;
#pragma clang diagnostic pop
}

查看它的isa的类型Class的定义

typedef struct objc_class *Class;

再查找这个objc_class的定义，可以发现有两处定义:

第1处，runtime.h文件里

struct objc_class {
    Class _Nonnull isa  OBJC_ISA_AVAILABILITY;

#if !__OBJC2__
    Class _Nullable super_class                              OBJC2_UNAVAILABLE;
    const char * _Nonnull name                               OBJC2_UNAVAILABLE;
    long version                                             OBJC2_UNAVAILABLE;
    long info                                                OBJC2_UNAVAILABLE;
    long instance_size                                       OBJC2_UNAVAILABLE;
    struct objc_ivar_list * _Nullable ivars                  OBJC2_UNAVAILABLE;
    struct objc_method_list * _Nullable * _Nullable methodLists                    OBJC2_UNAVAILABLE;
    struct objc_cache * _Nonnull cache                       OBJC2_UNAVAILABLE;
    struct objc_protocol_list * _Nullable protocols          OBJC2_UNAVAILABLE;
#endif

} OBJC2_UNAVAILABLE;

要注意⚠️，OBJC2_UNAVAILABLE的修饰，这个struct定义在OBJC2已经被废除了。

第2处，在objc-runtime-new.h文件，也就是我们要找的定义。

objc_class的定义

首先，objc_class继承于objc_object，查看objc_object的定义

struct objc_object {
    Class _Nonnull isa  OBJC_ISA_AVAILABILITY;
};

可以得出结论：

objc_object里定义了成员isa，继承于objc_object的类和结构体对象，都会继承这个isa成员。证明了为什么对象、类、元类、根元类的首地址（第一个成员），都是isa。
OC的万物之源NSObject的底层C/C++实现就是这个objc_object，说明真正的万物之源其实是objc_object。

那么我们知道了，类的内存首地址存储着isa指针的地址，那么第二个地址存储的是什么呢？

superClass的地址

通过lldb调试命令打印，可以看到第二个地址存储着父类的地址。也就是NSObject，这跟我们直接获取NSObject类的地址打印结果是一致的。

那么后面的地址存储着什么呢？
我们重新看回objc_class的定义：

struct objc_class : objc_object {
    // Class ISA;
    Class superclass;
    cache_t cache;             // formerly cache pointer and vtable
    class_data_bits_t bits;    // class_rw_t * plus custom rr/alloc flags

// ======================== 以下是方法

    class_rw_t *data() const {
        return bits.data();
    }
    void setData(class_rw_t *newData) {
        bits.setData(newData);
    }
    ...

我们查看它的成员，可以看到，苹果为我们指明了objc_class还有一个继承的成员 Class ISA
成员：

Class ISA
Class superclass
cache_t cache
class_data_bits_t bits

这样验证了我们上面打印的类内存的第二个地址，存储的就是父类。但是这只是巧合，刚好我们打印的第二个地址，也就是父类信息，占用了8个字节，所以刚好可以打印出信息。而后面的成员我们并不知道它们的类型大小，没办法打印出具体信息。
解决这个问题，可以通过内存首地址，计算前面所有成员类型大小的和进行内存偏移后，就可以得到我们需要的成员的内存地址。所以我们得计算每个成员的类型大小。

isa和superclass都占用8个字节，查看cache_t cache结构体定义：

struct cache_t {
#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_OUTLINED
    explicit_atomic<struct bucket_t *> _buckets;
    explicit_atomic<mask_t> _mask;
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16
    explicit_atomic<uintptr_t> _maskAndBuckets;
    mask_t _mask_unused;
    
    //static修饰的静态变量存储在静态存储区，所以不需要算入
    // How much the mask is shifted by.
    static constexpr uintptr_t maskShift = 48;
      ...
#if __LP64__
    uint16_t _flags;
#endif
    uint16_t _occupied;
      ...

cache_t里包含了以上的成员，还有一些静态成员，由于静态成员存储在静态缓存区，所以无需计入。
开始计算条件：

#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_OUTLINED为true时，也就是macOS环境下的话：
可以看到_buckets的泛型是结构体指针，8个字节大小。
_mask的泛型是typedef uint32_t mask_t;，占用4个字节。
由于在64位系统下，所以包含了uint16_t _flags成员，占用2个字节，uint16_t _occupied;占用2个字节，总共8+4+2+2 = 16字节。
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16为true时，也就是真机64位架构下，泛型为typedef unsigned long uintptr_t占用8字节，mask_t _mask_unused占用4字节。而且64位环境下还包含了uint16_t _flags成员，占用2个字节，uint16_t _occupied，占用2个字节。总共8+4+2+2 = 16字节。

至此，得出cache_t成员为16字节大小。可以通过内存首地址偏移8+8+16=32个字节，取到bits的地址。
查看bits的data的类型，可以看到它的定义

struct class_rw_t {
    // Be warned that Symbolication knows the layout of this structure.
    uint32_t flags;
    uint16_t witness;
#if SUPPORT_INDEXED_ISA
    uint16_t index;
#endif

    explicit_atomic<uintptr_t> ro_or_rw_ext;

    Class firstSubclass;
    Class nextSiblingClass;

private:
    using ro_or_rw_ext_t = objc::PointerUnion<const class_ro_t *, class_rw_ext_t *>;

    const ro_or_rw_ext_t get_ro_or_rwe() const {
        return ro_or_rw_ext_t{ro_or_rw_ext};
    }

    void set_ro_or_rwe(const class_ro_t *ro) {
        ro_or_rw_ext_t{ro}.storeAt(ro_or_rw_ext, memory_order_relaxed);
    }

    void set_ro_or_rwe(class_rw_ext_t *rwe, const class_ro_t *ro) {
        // the release barrier is so that the class_rw_ext_t::ro initialization
        // is visible to lockless readers
        rwe->ro = ro;
        ro_or_rw_ext_t{rwe}.storeAt(ro_or_rw_ext, memory_order_release);
    }

    class_rw_ext_t *extAlloc(const class_ro_t *ro, bool deep = false);

public:
    void setFlags(uint32_t set)
    {
        __c11_atomic_fetch_or((_Atomic(uint32_t) *)&flags, set, __ATOMIC_RELAXED);
    }

    void clearFlags(uint32_t clear) 
    {
        __c11_atomic_fetch_and((_Atomic(uint32_t) *)&flags, ~clear, __ATOMIC_RELAXED);
    }

    // set and clear must not overlap
    void changeFlags(uint32_t set, uint32_t clear) 
    {
        ASSERT((set & clear) == 0);

        uint32_t oldf, newf;
        do {
            oldf = flags;
            newf = (oldf | set) & ~clear;
        } while (!OSAtomicCompareAndSwap32Barrier(oldf, newf, (volatile int32_t *)&flags));
    }

    class_rw_ext_t *ext() const {
        return get_ro_or_rwe().dyn_cast<class_rw_ext_t *>();
    }

    class_rw_ext_t *extAllocIfNeeded() {
        auto v = get_ro_or_rwe();
        if (fastpath(v.is<class_rw_ext_t *>())) {
            return v.get<class_rw_ext_t *>();
        } else {
            return extAlloc(v.get<const class_ro_t *>());
        }
    }

    class_rw_ext_t *deepCopy(const class_ro_t *ro) {
        return extAlloc(ro, true);
    }

    const class_ro_t *ro() const {
        auto v = get_ro_or_rwe();
        if (slowpath(v.is<class_rw_ext_t *>())) {
            return v.get<class_rw_ext_t *>()->ro;
        }
        return v.get<const class_ro_t *>();
    }

    void set_ro(const class_ro_t *ro) {
        auto v = get_ro_or_rwe();
        if (v.is<class_rw_ext_t *>()) {
            v.get<class_rw_ext_t *>()->ro = ro;
        } else {
            set_ro_or_rwe(ro);
        }
    }

    const method_array_t methods() const {
        auto v = get_ro_or_rwe();
        if (v.is<class_rw_ext_t *>()) {
            return v.get<class_rw_ext_t *>()->methods;
        } else {
            return method_array_t{v.get<const class_ro_t *>()->baseMethods()};
        }
    }

    const property_array_t properties() const {
        auto v = get_ro_or_rwe();
        if (v.is<class_rw_ext_t *>()) {
            return v.get<class_rw_ext_t *>()->properties;
        } else {
            return property_array_t{v.get<const class_ro_t *>()->baseProperties};
        }
    }

    const protocol_array_t protocols() const {
        auto v = get_ro_or_rwe();
        if (v.is<class_rw_ext_t *>()) {
            return v.get<class_rw_ext_t *>()->protocols;
        } else {
            return protocol_array_t{v.get<const class_ro_t *>()->baseProtocols};
        }
    }
};

可以看到这里面就是我们存储的就是我们想要的类的方法methods()、属性properties()、协议protocols()等信息。

给BKPerson添加属性和对象方法、类方法。

@interface BKPerson : NSObject
{
  NSString *sex；
}
@property (nonatomic, copy) NSString *name;

- (void)eat;
+ (void)say;

@end


@implementation BKPerson
- (void)eat{}
+ (void)say{}
@end

用lldb进行调试打印属性:

类bits里的属性信息

打印类的属性的步骤为：

打印BKPerson类的内存地址（首地址）
将首地址偏移32字节，打印出bits的地址。
根据bits的data方法

class_rw_t *data() const {
        return bits.data();
    }

打印data数据的地址。

打印bits的data数据，由于其类型是class_rw_t *指针，所以前面加*打印。
根据data的类型class_rw_t，找到其定义里的属性的方法properties()，打印属性的信息。
根据打印的属性信息知道，其有list的成员，打印list的地址。
由于list类型为指针类型property_list_t *const，所以加*打印属性列表信息。

我们还可以通过data的结构体类型class_rw_t的成员methods()，打印类的方法列表：

bits的方法列表信息

打印类的方法的步骤与属性类似：

在打印出data的信息之后，根据data的类型class_rw_t，找到其定义里的属性的方法methods()，打印方法的信息。
根据打印的方法信息知道，其有list的成员，打印list的地址。
由于list类型为指针类型method_list_t *const，所以加*打印方法列表信息。
根据list数组下标，以此打印每个元素，要注意，方法的列表count为4，如果越界打印，会提示错误。

从每一个元素的信息可以看到，第一个元素存储了eat的方法。
第二个存储了析构方法，由于C语言的结构体对象没有所谓的构造和析构的概念，在往结构体添加OC引用（指针）类型时，为了解决结构体中的OC引用类型成员的生命周期问题，编译器隐式的帮我们自动生成一个析构函数。当一个结构体对象实例被销毁时则会自动调用隐式的析构函数，隐式的析构函数的内部实现是会将其中的OC引用数据成员置为nil来减少引用计数。要注意的是我们这里的BKPerson的实例是在栈上的，所以对象结构体会帮我们调用析构函数，如果在堆上则需要我们手动管理。
第三个元素存储了name属性自动生成的get方法。
第四个元素存储了name属性自动生成的set方法。

可以发现，data里的属性列表里并没有类的成员变量sex，类方法+ (void)say;也并没有在类的方法列表里。那么它们是存储在哪里呢？这个答案等待下一篇分析。

以上，若有欠妥或疑惑之处，欢迎指出～