iOS底层原理:OC对象底层探索之开辟内存

164 阅读13分钟

1.webp

在上篇文章iOS底层原理(二):OC对象底层探索之alloc初探 中,我们体验了 objc 底层源码的调试流程,也介绍了一部分 [JQPerson alloc] 在底层的工作流程,最终在**callAlloc中走到了_objc_rootAllocWithZone方法。那么今天我们就来继续探索_objc_rootAllocWithZone**方法之后的流程吧!

继续alloc底层探索

首先,我们先把上文中介绍的**[JQPerson alloc]**的流程图拿出来

2.webp

看到这幅图,就找到了组织,找到了方向,45°仰望天空!!!好,我们接着往下看。

_class_createInstanceFromZone 创建实例对象

老规矩,还是打开我之前编译好的 objc4-818.2 项目,断点来到 main.m 的**16行[JQPerson alloc]**。

3.webp

接着点进**alloc的源码中,前面的方法我们就省略了(上篇文章已经探索过),直接来到_objc_rootAllocWithZone** 这个方法中

4.webp

可以看到**_objc_rootAllocWithZone方法中返回了_class_createInstanceFromZone这个方法的调用,毫不犹豫,直接来到_class_createInstanceFromZone**方法

5.webp

哎~,这才是我们想要看到的东西嘛!一直返回方法调用,啥时候才是底嘛! 废话不多说,直接断点一步步走,发现** _class_createInstanceFromZone** 中走了三个核心的方法: size = cls->instanceSize(extraBytes); obj = (id)calloc(1, size); obj->initInstanceIsa(cls, hasCxxDtor); 最终走到 return obj;

6.webp

7.webp

8.webp

9.webp

instanceSize 计算实例对象所需要的内存大小

好,接着我们断点来到 **instanceSize**方法看一下

10.webp

11.webp

上面看图就明白了,那我们继续下一步,断点进入**cache.fastInstanceSize**

12.webp

断点进入**align16**

13.webp

我们看到这里只有**(x + size_t(15)) & ~size_t(15)这一句代码,那么这句代码是什么意思呢? 这其实是二进制位运算的一个对齐算法,(x + size_t(15)) & ~size_t(15)在这里代表的是对齐16和16的整数倍数。为什么这么说呢?下面我们看个例子就明白了

14.webp

由此我们可以得出结论:

  • align16就是取16的整数倍,不足的全部抹掉。这个算法和 >> 4 << 4 是一样的,得出的结果就是16的倍数。那么我们断点中传的值x = 8,所以,(8 + 15)& ~15 = 16
  • OC对象与对象之间的内存是以16字节对齐的。

此时,问题多的小明就要问了,为什么要以16字节对齐呢? 回答:

  • cpu 读取内存数据是以固定字节块来读取的,如果字节不对齐,那么对于**1、2、4、8**不同字节的数据,就会增加 cpu 的读取次数,从而降低了 cpu 的性能和读取速度。所以这是一个用空间换取时间的做法,主要还是对性能的提升。
  • 在一个对象中,我们什么也不做,isa 指针就占了**8个字节,那么也就是说我们给对象随便添加个属性,就超过了8字节。如果以8字节对齐,对象之间紧挨着的几率就会大大增加,容易造成访问混乱(也就是野指针访问)。如果是32字节对齐,又比较浪费内存空间,因为比如9个字节的对象,32字节对齐,就浪费了23字节。所以,16**字节对齐,既预留了部分空间,访问更安全,又不会浪费很多内存空间。

好,到此,我们就知道了**instanceSize**这一步,就是计算并返回了该对象所需的内存大小。

接着,我们就来拓展一个知识点:内存对齐

内存对齐

没有代码玩个🔨!!!老规矩,还是先上代码:

15.webp

打印结果:

16.webp

我们先了解一下**sizeof、class_getInstanceSize、malloc_size**什么意思: sizeof :获取对象类型的内存大小 class_getInstanceSize :获取对象实际的内存大小 malloc_size :获取系统分配给该对象的内存大小

我们可以看出:

  1. p1pNew对象的 sizeof都是 8,这个不难理解,sizeof 获取的是对象类型的内存大小,而类在底层的本质是结构体,对象的本质是结构体指针,占8个字节;

17.webp

18.webp

  1. 那么为什么**class_getInstanceSize获取的内存是24,malloc_size**获取的是32呢?

接下来,我们就一一揭开它的面纱。首先,我们先了解以下内存的原则:

1、数据成员对⻬规则:结构(struct)(或联合(union))的数据成员,第一个数据成员放在offset为0的地方,以后每个数据成员存储的起始位置要从该成员大小或者成员的子成员大小(只要该成员有子成员,比如说是数组,结构体等)的整数倍开始(比如int为4字节,则要从4的整数倍地址开始存储。 min(当前开始的位置mn) m=9 n=4 9 10 11 12 2、结构体作为成员:如果一个结构里有某些结构体成员,则结构体成员要从其内部最大元素大小的整数倍地址开始存储。(struct a里存有struct b,b里有char,int ,double等元素,那b应该从8的整数倍开始存储。) 3、收尾工作:结构体的总大小,也就是sizeof的结果,必须是其内部最大成员的整数倍,不足的要补⻬。

只有原理,没有例子,是没有说服力的。既然OC的类在底层的本质是结构体,我们就先拿结构体来举例。上代码:

19.webp

在这里,我们发现 JQStruct1JQStruct2 内部的成员变量是一样的,只是位置不一样,但是内存大小却不一样,JQStruct3JQStruct1的区别就是JQStruct3中嵌套了一个JQStruct1,内存相差却很大。why? 这就是结构体内存对齐。

下面我根据内存对齐原则对**JQStruct1JQStruct2JQStruct3**进行简单的计算和分析: JQStruct1 1. 变量a: 占8个字节,offset从0开始,即 [0 ~ 7] 存放a; 2. 变量b: 占4个字节,接着offset在8号位置,8是4的倍数,所以offset从8开始, 即 [8 ~ 11] 存放b; 3. 变量c: 占2个字节,接着offset来到12号位置,12是2的倍数,所以offset从12开始,即[12 ~ 13] 存放c; 4. 变量d: 占1个字节,接着offset来到14号位置,14是1的倍数,所以offset从14开始,,即 [14] 存放d。 JQStruct2 1. 变量a: 占8个字节,offset从0开始,即 [0 ~ 7] 存放a; 2. 变量d: 占1个字节,接着offset在8号位置,8是1的倍数,所以offset从8开始, 即 [8] 存放d; 3. 变量b: 占4个字节,接着offset来到9号位置,9不是4的倍数,所以offset往后继续移动,直到12号位置,才是4的倍数,即[12 ~ 15] 存放b; 4. 变量c: 占2个字节,接着offset来到16号位置,16是2的倍数,所以offset从16开始,,即 [16 17] 存放c。 JQStruct3 1. 变量a: 占8个字节,offset从0开始,即 [0 ~ 7] 存放a; 2. 变量b: 占4个字节,接着offset在8号位置,8是4的倍数,所以offset从8开始, 即 [8 ~ 11] 存放b; 3. 变量c: 占2个字节,接着offset来到12号位置,12是2的倍数,所以offset从12开始,即[12 ~ 13] 存放c; 4. 变量d: 占1个字节,接着offset来到14号位置,14是1的倍数,所以offset从14开始,,即 [14] 存放d。 5. 变量jqStr: 占16个字节(**`JQStruct1`**就是占16个字节),接着offset来到15号位置,15不是8(**`JQStruct1`**中最大的变量是a占个 8 字节)的倍数,所以offset往后继续移动,来到16号位置,16是8的整数倍,即 [16 ~ 31] 存放jqStr。

计算结果显示**JQStruct1JQStruct2JQStruct3的实际的内存大小分别是15字节、18字节和32字节。但是我们打印出来的内存大小分别为16字节、24字节和32字节。这是因为:根据内存对齐原则中的第3条(结构体的总大小,也就是sizeof的结果,必须是其内部最大成员的整数倍,不足的要补⻬。),JQStruct1中最大的变量是a占个 8 字节。所以JQStruct1的实际内存大小必须是8的整数倍,15不是8的整数倍,向上取整,不足的自动补齐,结果为16字节。JQStruct2中最大的变量是a也占个 8 字节,同理,18也不是8的整数倍,向上取整,不足的自动补齐,结果为24字节。JQStruct3**中则可以理解为非结构的成员计算内存大小后(对齐),再加上成员结构体的内存大小,也就是16+16=32字节。当然也可以把成员结构体中的成员拿出来一一计算。

由此我们也可以得出结论:

  • **结构体**是以其最大成员的字节数对齐的。
内存优化

看完了结构体的内存对齐,我们再来看一下OC对象的内存对齐又是怎样的呢?

20.webp

21.webp

**JQPerson中自定义的变量和JQStruct2的成员的类型和顺序是一模模一样样的,他们打印出来的内存大小都是24字节,也是一模模一样样的,乍一看,没毛病呀。大哥,你忘记了对象本身自带了一个变量isa指针吗?它也占了8个字节呢。所以这样一看,JQPerson**中自定义的变量只占了16个字节,这就很奇怪了啊,变量的类型和顺序都是一样的啊。这到底是为啥呢?这就是接下来我们要说的内存优化。 来,我们具体看看是它是怎么优化的,上代码:

22.webp

通过**lldb**断点打印可以看出 :

  1. **isa**的值通过读取 0x0000000109dc6658 (8字节)这个内存的数据;
  2. **a**的值通过读取 0x4067200000000000 (8字节)这个内存的数据;
  3. **b**的值通过读取 0x00000012 (4字节)这个内存的数据,
  4. **c**的值通过读取 0x0002 (2字节)这个内存的数据,
  5. **d**的值通过读取 0x0063 (2字节)(内存对齐,高位补0,所以这里看着就是俩字节了)这个内存的数据,

我们发现 int b,short c,char d,共用了一个8字节内存空间,系统进行了内存优化,将对象的属性或者变量存储顺序进行了重排,达到内存占用最小。

上面这个例子理解起来可能还不够透彻,下面我们在**JQPerson**中在增加一些属性,打印一下内存数据,一看就明白了。

23.webp

24.webp

25.webp

26.webp

看图👆,没有文字了!!!

由此我们可以得出结论:

  • OC对象与对象之间是以16字节对齐的。
  • 对象内部的成员变量之间是以8字节对齐的(OC最大数据类型是8字节,而每个对象都自带了一个8字节的**isa**)。
calloc 开辟内存

上面我们讲到了**instanceSize方法计算对象所需的内存大小,并且拓展了内存对齐内存优化。接着,我们就来看一下calloc是怎么去开辟内存的。 好,我们断点快速来到_class_createInstanceFromZone**方法中

27.webp

这里可以看出,此时的**obj还没有进行赋值,就已经有地址了,说明系统给obj**分配了一块内存地址(脏地址)。

28.webp

接着走断点,看到:执行**calloc**后打印的是一个16进制的指针地址,说明已经开辟了内存,但是和平常见到的地址指针(下图👇)不一样。

29.webp

也就是说,**calloc**只是开辟了内存;但是这块内存空间并没有和相应的类进行关联。

我们一步一步来看,先点击**calloc,进去看看calloc**都做了什么?

30.webp

31.webp

发现这里进不去了,**calloc**没有提供方法实现,好想进去啊,怎么办?

拿出我们上篇文章讲的三种底层调试方法,符号断点跟一下流程

32.webp

看到这里**calloc方法在libsystem_malloc.dylib中,这是个系统库啊。毫不犹豫,直接去 Open Source 下载libsystem_malloc.dylib的源码啊。(ps:其实上面已经指出了calloc的位置,macOS 11.3/usr/include/malloc**,天哪,这明显是个系统库啊)

好,接下里,我们拿**malloc的源码编译调试,看看calloc**的做了啥。上代码

33.webp

  • 进入 calloc

34.webp

  • 进入 _malloc_zone_calloc

35.webp

  • 进入 zone->calloc,发现点不进去,怎么办呢?首先想到的是汇编跟一下流程。但是注意,**C语言指针->指向的就是函数的首地址,我们直接打印一下zone->calloc**看看

36.webp

  • 看到下一个跳转是**default_zone_calloc**,全局搜索 default_zone_calloc

37.webp 卧槽,又来一个**zone->calloc**

  • 断点来到这里,继续打印一下**zone->calloc**看看

38.webp

  • 看到下一个跳转是**nano_calloc**,全局搜索 nano_calloc

39.webp

  • 断点发现会执行到**_nano_malloc_check_clear,进入_nano_malloc_check_clear**看一下

40.webp

  • 继续进入**segregated_size_to_fit**看看

41.webp

这里发现只有201、202这两句核心代码:

k = (size + NANO_REGIME_QUANTA_SIZE - 1) >> SHIFT_NANO_QUANTUM; // round up and shift for number of quanta
	
slot_bytes = k << SHIFT_NANO_QUANTUM;	

这两句啥意思呢?我们看到 >> 和 **<<这两个符号,这很熟悉了啊,这不就是右移和左移嘛! 我们分别点击宏NANO_REGIME_QUANTA_SIZESHIFT_NANO_QUANTUM**进去看一下都代表什么

42.webp

知道了宏的定义,我们就还原一下上面201、202那两句代码:

k = (size + (1 << 4) - 1) >> 4; 
slot_bytes = k << 4;	

这就很清晰了,前面内存对齐时我们讲过, >> 4 再 << 4 得出的结果就是16的整数倍,(size + (1 << 4) - 1) = size + 15。意思就是先给**size**升到16(二进制10000)以上,不足的位全抹0。这就是16进制对齐的算法!

我们拿上面传的40计算一下:

43.webp OK,到此,我们**calloc**的底层就结束了。

下面继续完善一下**alloc**的流程图:

44.webp

总结

  • 结构体是以其最大成员的字节数对齐的。
  • 对象内部的成员变量之间是以8字节对齐的。
  • OC对象与对象之间是以16字节对齐的。
  • instanceSize 是计算实例对象所需要的内存大小
  • calloc 是系统为对象开辟内存