主要 NSObjec 中的 alloc 和自定义类的 alloc的源码流程区别,以及为什么NSObject 的 alloc 不走源码工程
在上一篇文章中分析了 alloc 源码,这篇文章是对上一篇的补充,去探索为什么 NSObject 的 alloc 不走源码工程
NSObject的 alloc 无法进入源码的问题
-
首先在源码工程的 main 中添加一个 NSObject 和 SATest,同时加上断点
-
在 alloc 源码实现中同时加上一个断点,同时需要暂时关闭断点
-
运行 target,断点断在 NSObject 部分,同时打开 alloc 源码部分断点,然后继续执行,会出现以下情况
探索原因
第一步:探索 NSObject 的 alloc 到底走哪一步源码
- 打开汇编模式调试 Debug -> Debug workflow -> Always Show Disassembly
-
关闭源码中所有的断点,只留 main 中的断点,重新运行程序,通过汇编可以发现NSObject并没有走 alloc 源码,而是走的objc_alloc
-
然后关闭汇编调试,在全局搜索objc_alloc,在objc_alloc处下断点,先暂时关闭
-
重新运行调试,断住,然后重新打开 objc_alloc 的断点,发现会进入 objc_alloc的源码实现,此时查看 cls 是 NSObject
第二步:探索 NSObject 为什么会走objc_alloc
首先我们先看看 NSObject 和 SATest 的区别
- NSObject 是ios 中的基类,所有自定义的类都需要集成自 NSObject
- SATest 是继承自 NSObject 的,重写了NSObject 中的 alloc 方法
根据汇编中的显示,可以看出,NSObject 和 SATest 都调用了objc_alloc,所以就产生了两个疑问, - 为什么 NSObject 调用 alloc 方法,会走到 objc_alloc方法源码?
- 为什么 SATest中的 alloc 会走两次?既调用了 alloc,进入源码,还要走到 objc_alloc?
SATest中的 alloc为什么会走两次
-
首先,需要在源码中调试,在 main 中的 SATest 处加断点,断在 SATest,再在 alloc,objc_alloc,callAlloc 处加上断点,运行 demo 会断在 objc_alloc源码中(重新运行前,需要关闭所有断点)
-
继续运行,发现第一次会走 objc_alloc -> callAlloc 中最下面的消息发送方法
-
继续执行,发现会走alloc -> callAlloc -> _objc_rootAllocWithZone也就是第二篇中 alloc 流程
以下是第二次走到 callAlloc 方法中的调用堆栈情况
由上面描述可以得出,SATest 走两次的原因是首先去查找 sel,以及对应的 IMP 的关系,当前需要查找的是 alloc 方法编号,但是为什么会找到 objc_alloc,请往下看
NSObject 中的 alloc 为什么会走到 objc_alloc
需要通过 llvm源码来分析源码地址 -
在 llvm 源码中搜索objc_alloc
-
搜索shouldUseRuntimeFunctionForCombinedAllocInit,表示版本控制
-
搜索tryEmitSpecializedAllocInit,著名的特殊消息发送,也没找到 objc_alloc
继续尝试,开启上帝视角,搜索 alloc 字符串,如果还是找不到,可以通过omf_alloc
找到tryGenerateSpecializedMessageSend-
然后在这个 case 里面就可以找到调用 alloc,转而调用 objc_alloc的逻辑,其中关键代码是EmitObjCAlloc
-
跳转到EmitObjCAlloc方法,可以看到alloc 的处理是调用了 objc_alloc
由此可以得出NSObject 中的 alloc会走到 objc_alloc,其实这部分是由系统级别的消息发送处理,所以 NSObject的初始化是由系统完成的,因此不会走源码工程
NSObjet 中源码的调用流程
自定义类的源码调用流程
