如果把类的实例看成一个C语言的结构体（struct）

首先包含的是一个 isa 指针

类的其它成员变量依次排列在结构体中

对象在内存中的排布可以看成一个结构体，该结构体的大小并不能动态变化。所以无法在运行时动态给对象增加成员变量。

需要特别说明一下，通过 objc_setAssociatedObject 和 objc_getAssociatedObject方法可以变相地给对象增加成员变量，但由于实现机制不一样，所以并不是真正改变了对象的内存结构。

这些成员变量是基本类型和指针类型，指针类型的个数决定了结构体的大小，也就是实例变量决定着对象的内存结构，而运行时改变指针指向的结构体是不受影响的（如添加方法）

Non Fragile ivars（强壮的成员变量）

在C++中，成员变量的访问会被编译器转成一条指令，用“对象地址”加“成员变量偏移值”即可访问到成员变量的值，或许Objective-C2.0之前也是这样的。

上面说了类实例的结构，父类的成员变量在前，子类的在后。我们编译后上传到AppStore，用户下载到手机。当苹果发布新版本OSX SDK后。

例如，NSObject增加了两个成员变量。如果没有Non Fragile ivars特性，我们的代码将无法正常运行。我们的类继承自NSObject，编译时，类成员变量的已经确定。当根类增添成员变量，我们的类的成员变量和基类的内存区域重叠了。此时，我们只能重新编译我们的代码，程序才能在新版本系统上运行。

如果更悲催一点，如果我们使用了第三方提供的静态库，我们就只能眼巴巴等着库作者更新版本了。

Non Fragile ivars特性出场了。在程序启动后，runtime加载MyObject类的时候，通过计算基类的大小，runtime动态调整了我们自定义类成员变量布局，把自定义类成员变量的位置向后移动若干字节。于是我们的程序无需编译，就能在新版本系统上运行

那Non Fragile ivars是如何实现的呢？最关键的点是，当成员变量布局调整后，怎么能找到变量的新偏移位置呢？

沿着 objc_class的data()->ro->ivars 找下去，struct ivar_list_t 是类所有成员变量的定义列表。

struct ivar_list_t {

     uint32_t entsize;

      uint32_t count;

      ivar_t first;

};

通过first字段，可以取得类里任意一个类成员变量的定义。

struct ivar_t {

     int32_t *offset;

     const char *name;

     const char *type;

//...

};

offset，如果offset直接记录着这个成员变量在对象中的偏移位置，那么，runtime在发现基类大小变化时，通过修改offset值，来更新子类成员变量的偏移值。那Objective-C中获取对象的第N个成员变量偏移位置就需要这样一长串代码：

*((&obj->isa.cls->data()->ro->ivars->first)[N]->offset)

这么多次寻址，看起来很可怕吧。每个成员变量都这样访问的话，性能一定无法接受。看看编译器到底是如何实现的吧，我们祭出LLVM

@interface MyClass : NSError {

@public

      int myInt;

}

@end

@implementation MyClass

@end

int main()

{

     MyClass *obj = [[MyClass alloc] init];

      obj->myInt = 42;

}

obj->myInt = 42;

通过clang，我们看到这句代码被转为：

int32_t g_ivar_MyClass_myInt = 40;  // 全局变量

*(int32_t *)((uint8_t *)obj + g_ivar_MyClass_myInt) = 42;

两条CPU指令搞定，根本不需要一长串的指针调用。LLVM为每个类的每个成员变量都分配了一个全局变量，用于存储该成员变量的偏移值。

这也就是为什么结构体中 ivar_t.offset 用int指针来存储偏移值，而不是直接放一个int的原因。在这个设计中，真正存放偏移值的地址是固定不变的，在编译时就确定了下来。因此才能用区区2条指令搞定动态布局的成员变量。

有了这种灵活而高效的寻址方式，那runtime是在什么时候调整成员变量偏移值的呢？在编译时，LLVM计算出基类NSError对象的大小为40字节，然后记录在MyClass的类定义中。在编译后的可执行程序中，写死了“40”这个魔术数字，记录了在此次编译时MyClass基类的大小。

class_ro_t class_ro_MyClass = {

      .instanceStart = 40, 

      .instanceSize = 48,

//...

}

现在假如苹果发布了OSX 11 SDK，NSError类大小增加到48字节。当我们的程序启动后，runtime加载MyClass类定义的时候，发现基类的真实大小和MyClass的instanceStart不相符，得知基类的大小发生了改变。

于是runtime遍历MyClass的所有成员变量定义，将offset指向的值增加8。具体的实现代码在runtime/objc-runtime-new.mm的moveIvars()函数中。

并且，MyClass类定义的instanceSize也要增加8。这样runtime在创建MyClass对象的时候，能分配出正确大小的内存块

在博客的结尾，又提到了，为什么无法在运行时为类添加成员变量？

上面说过实例变量影响着对象的内存结构体，其实不但影响着当前类的实例内存，还影响着子类实例的内存。为基类动态增加成员变量会导致所有已创建出的子类实例都无法使用。

那为什么runtime允许动态添加方法和属性，而不会引发问题呢？

因为方法和属性并不“属于”类实例，而成员变量“属于”类实例。我们所说的“类实例”概念，指的是一块内存区域，包含了isa指针和所有的成员变量。所以假如允许动态修改类成员变量布局，已经创建出的类实例就不符合类定义了，变成了无效对象。但方法定义是在objc_class中管理的，不管如何增删类方法，都不影响类实例的内存布局，已经创建出的类实例仍然可正常使用。

上面说的类实例就是，我们说的对象在内存中的结构。另外上面提到了 obj->isa.cls->data()->ro 前面说过 ro 存储了当前类在编译期就已经确定的属性、方法以及遵循的协议。在运行期间就不能改变了（只读）

总结

1 在Objective-C，通过 -> 操作符，操作成员变量时，不是C语言指针操作，通过clang 可以发现

2 程序启动后，runtime加载MyClass类定义的时候，比较