在上一篇文章中分析了alloc的源码,这篇文章是作为对上一篇文章的补充,去探索为什么NSObject的alloc方法不走源码工程。
主要NSObject中的alloc
是与自定义类的alloc
的源码流程
的区别,以及为什么NSObject中的alloc不走源码工程。
NSObject的alloc无法进入源码的问题
首先在可编译源码中的main函数中增加一个NSObject定义的对象,NSObject 和 LGPerson同时加上断点.
运行target,断点断在NSObject
部分,打开alloc
源码的断点,然后继续执行,会发现没有走断点,而LGPerson却走断点。
探索Why
【第一步】探索[NSObject alloc]
走的是哪步源码
接下来,我们就来探索为什么NSObject的alloc会出现这种情况,首先,
- 打开
Debug --> Debug Workflow --> 勾选 Always Show Disassemly
,开启汇编调试
关闭源码的断点,只留main中的断点,重新运行程序,然后通过下图的汇编可以发现NSObject
并没有走 alloc
源码,而是走的objc_alloc
然后关闭汇编调试,在全局搜索 objc_alloc
,在objc_alloc中加一个断点。
【第二步】探索 NSObject 为什么走 objc_alloc?
首先,我们来看看 NSObject 与 LGPerson的区别
NSObject
是iOS中的基类
,所有自定义的类都需要继承自NSObjectLGPerson
是继承
自NSObject
类的,重写
了NSObject
中的alloc
方法
然后根据第一步中汇编的显示,可以看出,NSObject
和 LGPerson
都调用了objc_alloc
,所以这里就有两个疑问
:
- 为什么
NSObject
调用alloc
方法 会走到objc_alloc
源码? - 为什么
LGPerson
中的alloc
会走两次
?即调用了alloc
,进入源码,然后还要走到 objc_alloc
?
LGPerson中alloc 走两次 的 Why?
- 首先,需要在源码中调试,在
main
中LGPerson
加断点,断在LGPerson,再在alloc
、objc_alloc
和calloc
源码加断点,运行中会断在objc_alloc
源码中。
继续运行,发现LGPerson
第一次的alloc
会走到 objc_alloc --> callAlloc
方法中最下方的objc_msgSend
,表示向系统发送消息
继续执行代码,发现会走到 alloc --> callAlloc --> _objc_rootAllocWithZOne
,也就是alloc & init & new 源码分析的alloc流程。
以下是第二次走到calloc方法中的调用堆栈情况
所以由上述调试过程可以得出,LGPerson
走两次
的原因是首先需要去查找sel
,以及对应的imp
的关系,当前需要查找的是 alloc
方法,但是为什么会找到objc_alloc?这个就需要问系统了,肯定是系统在底层做了一些操作。
NSObject中alloc 走到 objc_alloc 的 why?
这部分需要通过 LLVM
源码(即llvm-project
) 来分析
准备工作:首先需要一份llvm源码
通过omf_alloc:
找到tryGenerateSpecializedMessageSend
,表示尝试生成特殊消息发送
然后在这个case中可以找到调用alloc,转而调用了objc_objc的逻辑,其中的关键代码是EmitObjCAlloc
跳转至EmitObjCAlloc
的定义可以看到alloc
的处理是调用了 objc_alloc
由此可以得出 NSObject
中的alloc
会走到 objc_alloc
,其实这部分是由系统级别的消息处理逻辑,所以NSObject的初始化是由系统完成
的,因此也不会走到alloc的源码工程中。
总结
总结下NSObject中alloc 和自定义类中alloc的调用流程
NSObject
自定义类