<meta charset="utf-8">
本文的主要目的是理解类与isa是如何关联的
在介绍正文之前，首先需要理解一个概念：OC对象的本质是什么？
OC对象本质
在探索oc对象本质前，先了解一个编译器：clang
Clang
-
clang是一个由Apple主导编写，基于LLVM的C/C++/OC的编译器 -
主要是用于
底层编译，将一些文件``输出成c++文件，例如main.m输出成main.cpp，其目的是为了更好的观察底层的一些结构及实现的逻辑，方便理解底层原理。
探索对象本质
- 在
main中自定义一个类LGPerson，有一个属性name
@interface LGPerson : NSObject
@property (nonatomic, copy) NSString *name;
@end
@implementation LGPerson
@end
- 通过终端，利用
clang将main.m编译成main.cpp，有以下几种编译命令，这里使用的是第一种
//1、将 main.m 编译成 main.cpp
clang -rewrite-objc main.m -o main.cpp
//2、将 ViewController.m 编译成 ViewController.cpp
clang -rewrite-objc -fobjc-arc -fobjc-runtime=ios-13.0.0 -isysroot / /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.7.sdk ViewController.m
//以下两种方式是通过指定架构模式的命令行，使用xcode工具 xcrun
//3、模拟器文件编译
- xcrun -sdk iphonesimulator clang -arch arm64 -rewrite-objc main.m -o main-arm64.cpp
//4、真机文件编译
- xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc main.m -o main- arm64.cpp
-
打开编译好的main.cpp，找到
LGPerson的定义，发现LGPerson在底层会被编译成struct结构体-
LGPerson_IMPL中的第一个属性 其实就是isa，是继承自NSObject，属于伪继承，伪继承的方式是直接将NSObject结构体定义为LGPerson中的第一个属性，意味着LGPerson拥有NSObject中的所有成员变量。 -
LGPerson中的第一个属性NSObject_IVARS等效于NSObject中的isa
-
//NSObject的定义
@interface NSObject <NSObject> {
Class isa OBJC_ISA_AVAILABILITY;
}
//NSObject 的底层编译
struct NSObject_IMPL {
Class isa;
};
//LGPerson的底层编译
struct LGPerson_IMPL {
struct NSObject_IMPL NSObject_IVARS; // 等效于 Class isa;
NSString *_name;
};
如下图所示
image
通过上述分析，理解了OC对象的本质，但是看到NSObject的定义，会产生一个疑问：为什么isa的类型是Class?
-
在iOS-底层原理 01：alloc & init & new 源码分析文章中，提及过
alloc方法的核心之一的initInstanceIsa方法，通过查看这个方法的源码实现，我们发现，在初始化isa指针时，是通过isa_t类型初始化的， -
而在
NSObject定义中isa的类型是Class，其根本原因是由于isa对外反馈的是类信息，为了让开发人员更加清晰明确，需要在isa返回时做了一个类型强制转换，类似于swift中的as的强转。源码中isa的强转如下图所示
image
总结
所以从上述探索过程中可以得出：
-
OC对象的本质其实就是结构体 -
LGPerson中的isa是继承自NSObject中的isa
objc_setProperty 源码探索
除了LGPersong的底层定义，我们发现还有属性 name 对应的 set 和 get方法，如下图所示，其中set方法的实现依赖于runtime中的objc_setProperty。
image
可以通过以下步骤来一步步解开 objc_setProperty的底层实现
-
在objc4-781中全局搜索
objc_setProperty，找到objc_setProperty的源码实现
image
-
进入
reallySetProperty的源码实现，其方法的原理就是新值retain，旧值release
image
总结
通过对objc_setProperty的底层源码探索，有以下几点说明：
-
objc_setProperty方法的目的适用于关联 上层的set方法 以及底层的set方法，其本质就是一个接口 -
这么设计的
原因是，上层的set方法有很多，如果直接调用底层set方法中，会产生很多的临时变量，当你想查找一个sel时，会非常麻烦 -
基于上述原因，苹果采用了
适配器设计模式（即将底层接口适配为客户端需要的接口），对外提供一个接口，供上层的set方法使用，对内调用底层的set方法，使其相互不受影响，即无论上层怎么变，下层都是不变的，或者下层的变化也无法影响上层，主要是达到上下层接口隔离的目的
下图是上层、隔离层、底层之间的关系
image
cls 与 类 的关联原理
在在iOS-底层原理 01：alloc & init & new 源码分析与iOS-底层原理 04：内存对齐原理中分别分析了alloc中3核心的前两个，今天来探索initInstanceIsa是如何将cls与isa关联的
在此之前，需要先了解什么是联合体，为什么isa的类型isa_t是使用联合体定义
联合体（union）
构造数据类型的方式有以下两种：
-
结构体（struct） -
联合体（union，也称为共用体）
结构体
结构体是指把不同的数据组合成一个整体，其变量是共存的，变量不管是否使用，都会分配内存。
-
缺点：所有属性都分配内存，比较
浪费内存，假设有4个int成员，一共分配了16字节的内存，但是在使用时，你只使用了4字节，剩余的12字节就是属于内存的浪费 -
优点：存储
容量较大，包容性强，且成员之间不会相互影响
联合体
联合体也是由不同的数据类型组成，但其变量是互斥的，所有的成员共占一段内存。而且共用体采用了内存覆盖技术，同一时刻只能保存一个成员的值，如果对新的成员赋值，就会将原来成员的值覆盖掉
-
缺点：，包容性弱
-
优点：所有成员共用一段内存，使内存的使用更为精细灵活，同时也节省了内存空间
两者的区别
-
内存占用情况
- 结构体的
各个成员会占用不同的内存，互相之间没有影响 - 共用体的
所有成员占用同一段内存，修改一个成员会影响其余所有成员
- 结构体的
-
内存分配大小
- 结构体内存
>=所有成员占用的内存总和（成员之间可能会有缝隙） -
共用体占用的内存等于最大的成员占用的内存
- 结构体内存
isa的类型 isa_t
以下是isa指针的类型isa_t的定义，从定义中可以看出是通过联合体（union）定义的。
union isa_t { //联合体
isa_t() { }
isa_t(uintptr_t value) : bits(value) { }
//提供了cls 和 bits ，两者是互斥关系
Class cls;
uintptr_t bits;
#if defined(ISA_BITFIELD)
struct {
ISA_BITFIELD; // defined in isa.h
};
#endif
};
isa_t类型使用联合体的原因也是基于内存优化的考虑，这里的内存优化是指在isa指针中通过char + 位域（即二进制中每一位均可表示不同的信息）的原理实现。通常来说，isa指针占用的内存大小是8字节，即64位，已经足够存储很多的信息了，这样可以极大的节省内存，以提高性能
从isa_t的定义中可以看出：
-
提供了两个成员，
cls和bits，由联合体的定义所知，这两个成员是互斥的，也就意味着，当初始化isa指针时，有两种初始化方式-
通过
cls初始化，bits无默认值 -
通过
bits初始化，cls有默认值
-
-
还提供了一个结构体定义的
位域，用于存储类信息及其他信息，结构体的成员ISA_BITFIELD，这是一个宏定义，有两个版本__arm64__（对应ios 移动端） 和__x86_64__（对应macOS），以下是它们的一些宏定义，如下图所示
image
-
nonpointer有两个值，表示自定义的类等，占1位-
0：纯isa指针 -
1：不只是类对象地址，isa中包含了类信息、对象的引用计数等
-
-
has_assoc表示关联对象标志位，占1位-
0：没有关联对象 -
1：存在关联对象
-
-
has_cxx_dtor表示该对象是否有C++/OC的析构器（类似于dealloc），占1位- 如果
有析构函数，则需要做析构逻辑 - 如果
没有，则可以更快的释放对象
- 如果
-
shiftcls表示存储类的指针的值（类的地址）， 即类信息-
arm64中占33位，开启指针优化的情况下，在arm64架构中有33位用来存储类指针 -
x86_64中占44位
-
-
magic用于调试器判断当前对象是真的对象还是没有初始化的空间，占6位 -
weakly_refrenced是 指对象是否被指向或者曾经指向一个ARC的弱变量- 没有弱引用的对象可以更快释放
-
deallocating标志对象是是否正在释放内存 -
has_sidetable_rc表示 当对象引用计数大于10时，则需要借用该变量存储进位 -
extra_rc（额外的引用计数） --- 导尿管表示该对象的引用计数值，实际上是引用计数值减1- 如果对象的
引用计数为10，那么extra_rc为9
- 如果对象的
-
针对两种不同平台，其isa的存储情况如图所示
image
原理探索
- 通过
alloc --> _objc_rootAlloc --> callAlloc --> _objc_rootAllocWithZone --> _class_createInstanceFromZone方法路径，查找到initInstanceIsa，并进入其原理实现
inline void
objc_object::initInstanceIsa(Class cls, bool hasCxxDtor)
{
ASSERT(!cls->instancesRequireRawIsa());
ASSERT(hasCxxDtor == cls->hasCxxDtor());
//初始化isa
initIsa(cls, true, hasCxxDtor);
}
-
进入
initIsa方法的源码实现，主要是初始化isa指针
image
该方法的逻辑主要分为两部分
- 通过
cls初始化isa - 通过
bits初始化isa
- 通过
验证 isa指针 位域（0-64）
根据前文提及的0-64位域，可以在这里通过initIsa方法中证明有isa指针中有这些位域（目前是处于macOS，所以使用的是x86_64）
-
首先通过main中的
LGPerson断点 -->initInstanceIsa-->initIsa--> 走到else中的isa初始化
image
-
执行lldb命令：
p newisa，得到newisa的详细信息
image
-
继续往下执行，走到
newisa.bits = ISA_MAGIC_VALUE;下一行，表示为isa的bits成员赋值，重新执行lldb命令p newisa，得到的结果如下
image
通过与前一个newsize的信息对比，发现isa指针中有一些变化，如下图所示
image
-
其中
magic是59是由于将isa指针地址转换为二进制，从47（因为前面有4个位域，共占用47位，地址是从0开始）位开始读取6位，再转换为十进制，如下图所示
image
-
isa 与 类 的关联
cls 与 isa 关联原理就是isa指针中的shiftcls位域中存储了类信息，其中initInstanceIsa的过程是将 calloc 指针 和当前的 类cls 关联起来，有以下几种验证方式：
-
【方式一】通过
initIsa方法中的newisa.shiftcls = (uintptr_t)cls >> 3;验证 -
【方式二】通过
isa指针地址与ISA_MSAK的值&来验证 -
【方式三】通过runtime的方法
object_getClass验证 -
【方式四】通过
位运算验证
方式一：通过 initIsa 方法
-
运行至
newisa.shiftcls = (uintptr_t)cls >> 3;前一步，其中shiftcls存储当前类的值信息-
此时查看
cls，是LGPerson类 -
shiftcls赋值的逻辑是将LGPerson进行编码后，右移3位
image
-
-
执行lldb命令
p (uintptr_t)cls，结果为(uintptr_t) $2 = 4294975720,再右移三位，有以下两种方式（任选其一），将得到536871965存储到newisa的shiftcls中-
p (uintptr_t)cls >> 3 -
通过上一步的结果
$2，执行lldb命令p $2 >> 3
image
-
-
继续执行程序到
isa = newisa;部分，此时执行p newisa
image
与
bits赋值结果的对比，bits的位域中有两处变化-
cls由默认值，变成了LGPerson，将isa与cls完美关联 -
shiftcls由0变成了536871965
image
-
所以isa中通过初始化后的成员的值变化过程，如下图所示
image
为什么在shiftcls赋值时需要类型强转？
因为内存的存储不能存储字符串，机器码只能识别 0 、1这两种数字，所以需要将其转换为uintptr_t数据类型，这样shiftcls中存储的类信息才能被机器码理解， 其中uintptr_t是long
为什么需要右移3位？
主要是由于shiftcls处于isa指针地址的中间部分，前面还有3个位域，为了不影响前面的3个位域的数据，需要右移将其抹零。
方式二：通过 isa & ISA_MSAK
-
在方式一后，继续执行，回到
_class_createInstanceFromZone方法，此时cls 与 isa已经关联完成，执行po objc -
执行
x/4gx obj,得到isa指针的地址0x001d8001000020e9 -
将
isa指针地址 &ISA_MASK（处于macOS，使用x86_64中的宏定义），即po 0x001d8001000020e9 & 0x00007ffffffffff8，得出LGPerson-
arm64中，ISA_MASK 宏定义的值为0x0000000ffffffff8ULL -
x86_64中，ISA_MASK 宏定义的值为0x00007ffffffffff8ULL
image
-
方式三：通过 object_getClass
通过查看object_getClass的源码实现，同样可以验证isa与类关联的原理，有以下几步：
-
main中导入#import <objc/runtime.h>
-
通过
runtime的api，即object_getClass函数获取类信息
object_getClass(<#id _Nullable obj#>)
-
查看
object_getClass函数 源码的实现
image
-
点击进入
object_getClass底层实现
image
-
进入
getIsa的源码实现
image
-
点击
ISA()，进入源码，可以看到如果是indexed类型，执行if流程，反之 执行的是else流程
image
- 在
else流程中，拿到isa的bits这个位，再& ISA_MASK，这与方式二中的原理是一致的，获得当前的类信息 - 从这里也可以
得出 cls 与 isa 已经完美关联
- 在
方式四：通过位运算
-
回到
_class_createInstanceFromZone方法。通过x/4gx obj得到obj的存储信息，当前类的信息存储在isa指针中，且isa中的shiftcls此时占44位（因为处于macOS环境）
image
-
想要
读取中间的44位类信息，就需要经过位运算，将右边3位，和左边除去44位以外的部分都抹零，其相对位置是不变的。其位运算过程如图所示，其中shiftcls即为需要读取的类信息
image
-
将
isa地址右移3位：p/x 0x001d8001000020e9 >> 3，得到0x0003b0002000041d -
在将得到的
0x0003b0002000041d``左移20位：p/x 0x0003b0002000041d << 20,得到0x0002000041d00000- 为什么是
左移20位？因为先右移了3位，相当于向右偏移了3位，而左边需要抹零的位数有17位，所以一共需要移动20位
- 为什么是
-
将得到的
0x0002000041d00000再右移17位：p/x 0x0002000041d00000 >> 17得到新的0x00000001000020e8
-
-
获取cls的地址 与 上面的进行验证 ：
p/x cls也得出0x00000001000020e8，所以由此可以证明 cls 与 isa 是关联的
image
网友评论