本文的主要目的是理解类与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;
};
如下图所示
通过上述分析,理解了OC对象的本质,但是看到NSObject
的定义,会产生一个疑问:为什么isa
的类型是Class
?
- 在iOS-底层原理 02: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
的底层实现
-
在objc4-781中全局搜索
objc_setProperty
,找到objc_setProperty
的源码实现
-
进入
reallySetProperty
的源码实现,其方法的原理就是新值retain,旧值release
总结
通过对objc_setProperty
的底层源码探索,有以下几点说明:
objc_setProperty
方法的目的适用于关联 上层
的set
方法 以及底层
的set
方法,其本质就是一个接口
这么设计的
原因
是,上层
的set
方法有很多,如果直接调用底层set
方法中,会产生很多的临时变量
,当你想查找
一个sel时,会非常麻烦
基于上述原因,苹果采用了
适配器设计模式(即将底层接口适配为客户端需要的接口)
,对外
提供一个接口
,供上层的set方法使用,对内
调用底层的set方法
,使其相互不受影响,即无论上层怎么变,下层都是不变的
,或者下层的变化也无法影响上层
,主要是达到上下层接口隔离的目的
下图是上层、隔离层、底层之间的关系
cls 与 类 的关联原理
在在iOS-底层原理 02:alloc & init & new 源码分析与iOS-底层原理 05:内存对齐原理中分别分析了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),以下是它们的一些宏定义,如下图所示
-
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(这个仅为举例说明),实际上iPhone 真机上的extra_rc
是使用 19位来存储引用计数的
- 如果对象的
-
针对两种不同平台,其isa
的存储情况如图所示
原理探索
- 通过
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指针
该方法的逻辑主要分为两部分- 通过
cls
初始化isa
- 通过
bits
初始化isa
- 通过
验证 isa指针 位域(0-64)
根据前文提及的0-64
位域,可以在这里通过initIsa
方法中证明有isa指针中有这些位域(目前是处于macOS
,所以使用的是x86_64
)
-
首先通过main中的
LGPerson
断点 -->initInstanceIsa
-->initIsa
--> 走到else
中的isa
初始化
-
执行lldb命令:
p newisa
,得到newisa
的详细信息
-
继续往下执行,走到
newisa.bits = ISA_MAGIC_VALUE;
下一行,表示为isa
的bits
成员赋值,重新执行lldb命令p newisa
,得到的结果如下
通过与前一个newsize的信息对比,发现isa指针中有一些变化,如下图所示
- 其中
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 方法
-
运行至
newisa.shiftcls = (uintptr_t)cls >> 3;
前一步,其中shiftcls
存储当前类的值信息
此时查看
cls
,是LGPerson
类-
shiftcls
赋值的逻辑是将LGPerson
进行编码后,右移3
位
-
执行lldb命令
p (uintptr_t)cls
,结果为(uintptr_t) $2 = 4294975720
,再右移三位,有以下两种方式(任选其一),将得到536871965
存储到newisa
的shiftcls
中p (uintptr_t)cls >> 3
-
通过上一步的结果
$2
,执行lldb命令p $2 >> 3
-
继续执行程序到
isa = newisa;
部分,此时执行p newisa
与bits赋值
结果的对比
,bits的位域
中有两处变化-
cls
由默认值
,变成了LGPerson
,将isa与cls完美关联
-
shiftcls
由0
变成了536871965
-
所以isa
中通过初始化
后的成员
的值变化过程
,如下图所示
为什么在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
方式三:通过 object_getClass
通过查看object_getClass
的源码实现,同样可以验证isa与类关联的原理,有以下几步:
main中导入#import <objc/runtime.h>
通过
runtime
的api,即object_getClass
函数获取类信息
object_getClass(<#id _Nullable obj#>)
-
查看
object_getClass
函数 源码的实现
-
点击进入
object_getClass
底层实现
-
进入
getIsa
的源码实现
-
点击
ISA()
,进入源码,可以看到如果是indexed
类型,执行if
流程,反之 执行的是else
流程
- 在
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 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 是关联的