主要 NSObjec 中的 alloc 和自定义类的 alloc的源码流程区别,以及为什么NSObject 的 alloc 不走源码工程
在上一篇文章中分析了 alloc 源码,这篇文章是对上一篇的补充,去探索为什么 NSObject 的 alloc 不走源码工程

NSObject的 alloc 无法进入源码的问题

探索原因

打开汇编模式调试 Debug -> Debug workflow -> Always Show Disassembly
关闭源码中所有的断点,只留 main 中的断点,重新运行程序,通过汇编可以发现NSObject并没有走 alloc 源码,而是走的objc_alloc

image.png
然后关闭汇编调试,在全局搜索objc_alloc,在objc_alloc处下断点,先暂时关闭

image.png
重新运行调试,断住,然后重新打开 objc_alloc 的断点,发现会进入 objc_alloc的源码实现,此时查看 cls 是 NSObject

image.png

首先我们先看看 NSObject 和 SATest 的区别

NSObject 是ios 中的基类,所有自定义的类都需要集成自 NSObject
SATest 是继承自 NSObject 的,重写了NSObject 中的 alloc 方法
根据汇编中的显示,可以看出,NSObject 和 SATest 都调用了objc_alloc,所以就产生了两个疑问,
为什么 NSObject 调用 alloc 方法,会走到 objc_alloc方法源码?
为什么 SATest中的 alloc 会走两次?既调用了 alloc,进入源码,还要走到 objc_alloc?

首先,需要在源码中调试,在 main 中的 SATest 处加断点,断在 SATest,再在 alloc,objc_alloc,callAlloc 处加上断点,运行 demo 会断在 objc_alloc源码中(重新运行前,需要关闭所有断点)

image.png
继续运行,发现第一次会走 objc_alloc -> callAlloc 中最下面的消息发送方法

image.png
继续执行,发现会走alloc -> callAlloc -> _objc_rootAllocWithZone也就是第二篇中 alloc 流程
以下是第二次走到 callAlloc 方法中的调用堆栈情况

image.png

由上面描述可以得出,SATest 走两次的原因是首先去查找 sel,以及对应的 IMP 的关系,当前需要查找的是 alloc 方法编号,但是为什么会找到 objc_alloc,请往下看
NSObject 中的 alloc 为什么会走到 objc_alloc
需要通过 llvm源码来分析源码地址
在 llvm 源码中搜索objc_alloc

image.png
搜索shouldUseRuntimeFunctionForCombinedAllocInit,表示版本控制

image.png
搜索tryEmitSpecializedAllocInit,著名的特殊消息发送,也没找到 objc_alloc

image.png
继续尝试,开启上帝视角,搜索 alloc 字符串,如果还是找不到,可以通过omf_alloc
找到tryGenerateSpecializedMessageSend
然后在这个 case 里面就可以找到调用 alloc,转而调用 objc_alloc的逻辑,其中关键代码是EmitObjCAlloc

image.png
跳转到EmitObjCAlloc方法,可以看到alloc 的处理是调用了 objc_alloc

image.png

由此可以得出NSObject 中的 alloc会走到 objc_alloc,其实这部分是由系统级别的消息发送处理,所以 NSObject的初始化是由系统完成的,因此不会走源码工程

NSObjet 中源码的调用流程

未命名文件.png

自定义类的源码调用流程

未命名文件-2.png