NSObject的alloc 源码分析

iOS 底层原理 文章汇总

在上一篇文章中分析了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中的基类，所有自定义的类都需要继承自NSObject
• LGPerson 是继承自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

自定义类