iOS底层-OC对象原理（上）

☆MOON

已于 2022-05-15 01:29:59 修改

阅读量301

点赞数 1

分类专栏：移动互联网-iOS笔记移动互联网-iOS底层原理文章标签： ios objective-c xcode

于 2021-09-28 00:14:00 首次发布

本文链接：https://blog.csdn.net/MOON_YZM/article/details/120520270

版权

移动互联网-iOS笔记同时被 2 个专栏收录

35 篇文章 1 订阅

订阅专栏

移动互联网-iOS底层原理

17 篇文章 0 订阅

订阅专栏

背景

iOS开发，我们每天都在 `alloc`对象，但是我们`jump to Definition`到NSObject底层能看到的仅有个未实现的`alloc`方法，而我们对`alloc`底层的逻辑却一无所知。
`alloc`底层有什么、
`alloc`做了什么、
`init`做了什么、
`alloc`、`init`和`new`到底有什么关系和区别呢？

掘金地址同步：掘金-OC对象原理（上）

实例

简单的代码和打印(分别输出对象的内容，对象的地址，以及对象指针的地址)示例：

ZMPerson *p1 = [ZMPerson alloc];
ZMPerson *p2 = [p1 init];
ZMPerson *p3 = [p1 init];

ZMPerson *newP = [ZMPerson alloc];

NSLog(@"%@ - %p - %p",p1,p1,&p1);
NSLog(@"%@ - %p - %p",p2,p2,&p2);
NSLog(@"%@ - %p - %p",p3,p3,&p3);
NSLog(@"%@ - %p - %p",newP,newP,&newP);

<ZMPerson: 0x6000030f40e0> - 0x6000030f40e0 - 0x7ffeed054068
<ZMPerson: 0x6000030f40e0> - 0x6000030f40e0 - 0x7ffeed054060
<ZMPerson: 0x6000030f40e0> - 0x6000030f40e0 - 0x7ffeed054058
<ZMPerson: 0x6000030f40f0> - 0x6000030f40f0 - 0x7ffeed054050

从打印结果我们可以看到：

p1、p2、p3的对象地址是一模一样，但指针地址不一样并且是从高位到低位连续的间隔8字节。
newP和p1、p2、p3的对象地址，指针的地址是不一样的。

为什么呢：

alloc具备在堆中开辟内存的功能
init不具备在堆中开辟内存的功能，但可以在栈中生成指向堆内存的指针地址
栈区开辟的内存是高地址 到 低地址，堆区则是低地址 到 高地址

如图：

alloc探索

准备工作

下载objc4-818.2(版本号根据自己macOS版本变化)
编译源码

alloc流程图

四种探索方式

1. 断点模式 & `control`+`step into`

需要调试的alloc位置打上断点，编译走到断点的时候control+step into进入下一步的汇编里面，如图：

然后找到方法objc_alloc，并给这个方法添符号断点。如图：

然后继续编译，进到libobjc.A.dylib`objc_alloc,在这里我们看到objc_alloc里面有_objc_rootAllocWithZone和objc_msgSend

2. 汇编(比较给手的方法，👏)

同样，在需要调试的alloc位置打上断点，然后Xcode->Debug->Debug Workflow -> Always Show Disassembly勾选Always Show Disassembly

然后找到方法objc_alloc直接添加符号断点调试，或者断住要跳转的地方，control+step into一步一步一直走

3. 符号断点，断位置

直接给要调试的方法添加符号断点，比如下图给我们探索的alloc添加符号断点，不过有个注意点，这个符号断点需要在断住的方法之后添加并激活，因为alloc项目运行中可能很多地方调用，那数据量，你说你不想知道结果，但那是考验机器性能和你识别度的。如图：

然后找到我们需要的alloc：

4. 编译源码LLDB调试

objc_alloc是属于libobjc库的方法，在alloc探索的准备模块里，我们准备好了objc源码，然后源码编译成工程run起来，这种就比较beautiful的方法
根据编译源码工程，我们点击进入alloc，更直观一目了然的看到alloc的执行过程，流程图如下：

进入`alloc`:

然后到`_objc_rootAlloc`:

然后到`callAlloc`:

重磅提示这里是核心方法
slowpath(x):x很可能为假，为真的概率很小
fastpath(x):x很可能为真
其实将fastpath和slowpath去掉完全不影响任何功能,写上是告诉编译器对代码进行优化

然后断点到`_objc_rootAllocWithZone`:

问题来了（这两个问题将在下面的 alloc init & new去解答）：

问题1，我们通过上面汇编发现是进到objc_alloc,为什么通过源码LLDB却走了_objc_rootAlloc？
问题2，我们打印alloc时在走到_objc_rootAlloc时，线程里面有了objc_alloc->callAlloc，然后走到NSObject的alloc -> _objc_rootAlloc -> callAlloc-> _objc_rootAllocWithZone及之后的流程,为什么？

然后断点进入核心方法`_class_createInstanceFromZone`:

cls->instanceSize计算需要开辟的内存大小
(id)calloc(1, size)向内存申请开辟空间,并返回地址指针
obj->initInstanceIsa初始化的isa指针和cls关联

核心方法-`instanceSize`

进入cache.fastInstanceSize

断点进入align16

16字节对齐算法公式：（x + 15）& ～15

比如我们以align(9)为例：

总结：align16 算法实际上就是取16的整数倍。对于变量x来说是向上取整，比如30，向上取整为32（16<30 但是 16*2>30），算法的角度有人认为是向下取整：(x + 15)是16的几倍，超过的部分抹去。例如 (20 + 15) = 35 = 16 * 2 + 3，结果是32。这种算法和 >> 4 << 4 是一样的，得出的结果就是16的倍数，不足16的全部抹去。

为什么对象需要16字节对齐

cpu的性能和读取速度 cpu 读取数据是一个用空间换取时间的做法，以固定字节块来读取的，如果频繁的读取字节未对齐的数据，降低了cpu的性能和读取速度。
更安全 由于在一个对象中isa指针是占8个字节，如果不进行节对齐，对象之间就会紧挨着，容易造成访问混乱。16字节对齐，会预留部分空间，访问更安全

核心方法-calloc

开辟内存，返回地址指针
由 instanceSize 方法计算出需要的内存大小，然后向内存申请 size 大小的内存，返回给objc，因此objc是指向内存地址的指针

执行calloc后打印的是一个16进制的指针地址，说明已经开辟了内存

核心方法-initInstanceIsa

方法内部isa结构后续探索待补充

执行完initInstanceIsa后

图示打印结果说明：指针已经与类进行了关联

init探索

断点进入_objc_rootInit

可以看到init返回的是对象本身,可以提供给开发者更多的自由去自定义重写init ，通过id实现强转，返回我们需要的类型

new探索

new的流程走了callAlloc的方法流程，然后走了init方法，所以 new看做是alloc + init

alloc init & new

Calls [[cls alloc] init]

object_alloc问题及解答：

如果直接LLDB源码调试NSObject*obj = [[NSObject alloc] init];能走进底层alloc么？为什么？
如图：

经过源码一步一步探索我们发现并不能走到底层alloc代码但走了obj_alloc，但为什么呢？设置符号断点继续跟源码：

通过跟源码，我们发现子类进入这里经过了俩次，从alloc中进入，又进了object_alloc进行发送系统消息，然后又出来重新进入alloc方法，而NSObject却不是，他没有经过给系统发送消息的一步，直接开辟内存，所以我们可以猜测，它是在系统编译之后就已经执行了，跟程序员无关，那么问题又来了，为什么子类却要经过俩次呢？
解答：通过_read_images找到fixupMessageRef函数:

答案就出来了，在read_images做了一次fixup的修复，😂
然后我们通过LLVM源码：搜索objc_alloc

通过对LLVM探索：

alloc在系统被系统拦截 -> objc_alloc -> 标记receiver 判断进不去这个时候objc_alloc-> objc_msgSend -> 然后重新走alloc方法这个时候receiver已经有了标记最后就正常走alloc流程（alloc-> _objc_rootAlloc -> …）
如图：