在alloc & init & new文章中,alloc
有3个核心操作,其中一个就是obj->initInstanceIsa:类与isa关联
,这就是今天需要探索的内容。
本文的主要目的是理解类与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;
};
复制代码
- clang编译结果,如下图所示:
通过上述分析,理解了OC对象的本质,但是看到NSObject
的定义,会产生一个疑问:为什么isa
的类型是Class
?
-
在alloc & init & new文章中,提及过
alloc
方法的核心之一的initInstanceIsa
方法,通过查看这个方法的源码实现,我们发现,在初始化isa
指针时,是通过isa_t
类型初始化的, -
而在
NSObject
定义中isa的类型是Class
,其根本原因是由于isa
对外反馈的是类信息
,为了让开发人员更加清晰明确
,需要在isa
返回时做了一个类型强制转换
,类似于swift
中的as
的强转。源码中isa
的强转
如下图所示
总结
所以从上述探索过程中可以得出:
OC对象的本质
其实就是结构体
LGPerson
中的isa
是继承自NSObject
中的isa
objc_setProperty 源码探索
除了LGPersong
的底层定义,我们发现还有属性 name
对应的 set
和 get
方法,如下图所示,其中set
方法的实现依赖于runtime中的objc_setProperty
。
-
可以通过以下步骤来一步步解开
objc_setProperty
的底层实现 -
全局搜索
objc_setProperty
,找到objc_setProperty
的源码实现
进入reallySetProperty
的源码实现,其方法的原理就是新值retain,旧值release
总结
通过对objc_setProperty
的底层源码探索,有以下几点说明:
objc_setProperty
方法的目的适用于关联 上层
的set
方法 以及底层
的set
方法,其本质就是一个接口
- 这么设计的
原因
是,上层
的set
方法有很多,如果直接调用底层set
方法中,会产生很多的临时变量
,当你想查找
一个sel时,会非常麻烦
- 基于上述原因,苹果采用了
适配器设计模式(即将底层接口适配为客户端需要的接口)
,对外
提供一个接口
,供上层的set方法使用,对内
调用底层的set方法
,使其相互不受影响,即无论上层怎么变,下层都是不变的
,或者下层的变化也无法影响上层
,主要是达到上下层接口隔离的目的
下图是上层、隔离层、底层之间的关系
cls 与 类 的关联原理
在在alloc & init & new与内存对齐原理中分别分析了alloc中3核心的前两个,今天来探索initInstanceIsa
是如何将cls
与isa
关联的
在此之前,需要先了解什么是联合体
,为什么isa
的类型isa_t
是使用联合体定义
联合体(union)
构造数据类型的方式有以下两种:
结构体
(struct
)联合体
(union
,也称为共用体
)
结构体
结构体
是指把不同的数据组合成一个整体
,其变量
是共存
的,变量不管是否使用,都会分配内存。
- 缺点:所有属性都分配内存,比较
浪费内存
,假设有4个int成员,一共分配了16
字节的内存,但是在使用时,你只使用了4
字节,剩余的12
字节就是属于内存的浪费 - 优点:存储
容量较大
,包容性强
,且成员之间不会相互影响
联合体
联合体也是由不同的数据类型组成
,但其变量是互斥
的,所有的成员共占一段内存
。而且共用体
采用了内存覆盖技术
,同一时刻只能保存一个成员的值
,如果对新的成员赋值
,就会将原来成员的值覆盖掉
- 缺点:包容性弱
- 优点:所有成员共用一段内存,使内存的使用更为精细灵活,同时也节省了内存空间
两者的区别
-
内存占用情况
- 结构体的
各个成员会占用不同的内存
,互相之间没有影响
- 共用体的
所有成员占用同一段内存
,修改一个成员会影响
其余所有成员
- 结构体的
-
内存分配大小
- 结构体内存
>=
所有成员占用的内存总和
(成员之间可能会有缝隙) 共用体
占用的内存
等于最大的成员
占用的内存
- 结构体内存
isa的类型 isa_t
以下是isa指针的类型isa_t
的定义,从定义中可以看出是通过联合体(union)
定义的。
isa_t
类型使用联合体
的原因也是基于内存优化
的考虑,这里的内存优化是指在isa指针中通过char + 位域
(即二进制中每一位均可表示不同的信息)的原理实现。通常来说,isa指针
占用的内存大小是8
字节,即64
位,已经足够存储很多的信息了,这样可以极大的节省内存,以提高性能
从isa_t
的定义中可以看出:
-
提供了两个成员,
cls
和bits
,由联合体的定义所知,这两个成员是互斥
的,也就意味着,当初始化isa指针时,有两种初始化方式- 通过
cls
初始化,bits无默认值
- 通过
bits
初始化,cls有默认值
- 通过
-
还提供了一个结构体定义的
位域
,用于存储类信息及其他信息,结构体的成员ISA_BITFIELD
,这是一个宏
定义,有两个版本__arm64__
(对应ios 移动端) 和__x86_64__
(对应macOS),以下是它们的一些宏定义,如下图所示
-
-
nonpointer
是否对isa指针开启指针优化,有两个值,表示自定义的类等,占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(这个仅为举例说明),实际上iPhone 真机上的extra_rc
是使用 19位来存储引用计数的
- 如果对象的
-
针对两种不同平台,其isa
的存储情况如图所示
原理探索
- 通过
alloc --> _objc_rootAlloc --> callAlloc --> _objc_rootAllocWithZone --> _class_createInstanceFromZone
方法路径,查找到initInstanceIsa
,并进入其原理实现
进入initIsa
方法的源码实现,主要是初始化isa指针
该方法的逻辑主要分为两部分
- 通过
cls
初始化isa
- 通过
bits
初始化isa
验证 isa指针 位域(0-64)
根据前文提及的0-64
位域,可以在这里通过initIsa
方法中证明有isa指针中有这些位域(目前是处于macOS
,所以使用的是x86_64
)
首先通过main中的LGPerson
断点 –> initInstanceIsa
–> initIsa
–> 走到else
中的 isa
初始化
继续往下执行,走到newisa.bits = ISA_MAGIC_VALUE;
下一行,表示为isa
的bits
成员赋值,重新执行lldb命令p newisa
,得到的结果如下
其中magic
是59
是由于将isa
指针地址转换为二进制
,从47
(因为前面有4个位域,共占用47位,地址是从0开始)位开始读取6
位,再转换为十进制
,如下图所示
isa 与 类 的关联
cls
与 isa
关联原理
就是isa
指针中的shiftcls
位域中存储了类信息
,其中initInstanceIsa
的过程是将 calloc
指针 和当前的 类cls
关联起来,有以下几种验证方式:
- 【方式一】通过
initIsa
方法中的newisa.shiftcls = (uintptr_t)cls >> 3;
验证 - 【方式二】通过
isa指针地址
与ISA_MSAK
的值&
来验证 - 【方式三】通过runtime的方法
object_getClass
验证 - 【方式四】通过
位运算
验证
方式一:通过 initIsa 方法
运行至shiftcls = (uintptr_t)newCls >> 3
前一步,其中 shiftcls
存储当前类的值信息
- 此时查看
cls
,是LGPerson
类 shiftcls
赋值的逻辑是将LGPerson
进行编码后,右移3
位
执行lldb命令p (uintptr_t)cls
,结果为(uintptr_t) $8 = 4295000992
,再右移三位,有以下两种方式(任选其一),将得到536875124
存储到newisa
的shiftcls
中
p (uintptr_t)newCls >> 3
- 通过上一步的结果
$8
,执行lldb命令p $8 >> 3
- 继续执行程序到
isa = newisa;
部分,此时执行p newisa
与bits赋值
结果的对比
,bits的位域
中有两处变化
cls
由默认值
,变成了LGPerson
,将isa与cls完美关联
shiftcls
由0
变成了536875124
所以isa
中通过初始化
后的成员
的值变化过程
,如下图所示
为什么在shiftcls赋值时需要类型强转?
因为内存
的存储不能存储字符串
,机器码
只能识别 0 、1
这两种数字,所以需要将其转换为uintptr_t
数据类型,这样shiftcls
中存储的类信息
才能被机器码理解
, 其中uintptr_t
是long
主要是由于shiftcls
处于isa
指针地址的中间
部分,前面还有3
个位域,为了不影响前面的3个位域
的数据,需要右移
将其抹零
。
方式二:通过 isa & ISA_MSAK
- 在方式一后,继续执行,回到
_class_createInstanceFromZone
方法,此时cls 与 isa已经关联完成
,执行po objc
- 执行
x/4gx obj
,得到isa
指针的地址0x011d8001000083a1
将isa
指针地址 & ISA_MASK
(处于macOS
,使用x86_64
中的宏
定义),即 po 0x011d8001000083a1 & 0x00007ffffffffff8
,得出LGPerson
arm64
中,ISA_MASK 宏定义的值为0x0000000ffffffff8ULL
x86_64
中,ISA_MASK 宏定义的值为0x00007ffffffffff8ULL
方式三:通过 object_getClass
通过查看object_getClass
的源码实现,同样可以验证isa与类关联的原理,有以下几步:
- main中导入#import <objc/runtime.h>
- 通过
runtime
的api,即object_getClass
函数获取类信息
object_getClass(<#id _Nullable obj#>)
复制代码
- 查看
object_getClass
函数 源码的实现
- 进入
getIsa
的源码实现
- 点击
ISA()
,进入源码
- 点击
getDecodedClass
,进入源码
- 点击
getClass
,进入源码
- 在
else
流程中,拿到isa
的bits
这个位,再& ISA_MASK
,这与方式二中的原理是一致的,获得当前的类信息
- 从这里也可以
得出 cls 与 isa 已经完美关联
方式四:通过位运算
- 回到
_class_createInstanceFromZone
方法。通过x/4gx obj
得到obj
的存储信息,当前类的信息存储在isa
指针中,且isa中的shiftcls
此时占44
位(因为处于macOS
环境)
想要读取
中间的44
位 类信息
,就需要经过位运算
,将右边3
位,和左边除去44
位以外的部分都抹零
,其相对位置是不变
的。其位运算过程如图所示,其中shiftcls
即为需要读取
的类信息
-
将
isa
地址右移3
位:p/x 0x011d8001000083a1 >> 3
,得到0x0023b00020001074
-
在将得到的
0x0023b00020001074
,左移20位:p/x 0x0045138768236660 << 20
,得到0x0002000107400000
-
为什么是
左移20
位?因为先右
移了3
位,相当于向右偏移了3位
,而左边
需要抹零
的位数有17
位,所以一共需要移动20
位 -
将得到的
0x0002000107400000
再右移17
位:p/x 0x0002000107400000 >> 17
得到新的0x00000001000083a0
-
获取cls的地址 与 上面的进行验证 :
p/x cls
也得出0x00000001000083a0
,所以由此可以证明 cls 与 isa 是关联的