iOS-底层原理 04：NSObject的alloc 源码分析

主要NSObject中的alloc是与自定义类的alloc的源码流程的区别，以及为什么NSObject中的alloc不走源码工程。

在上一篇文章中分析了alloc的源码，这篇文章是作为对上一篇文章的补充，去探索为什么NSObject的alloc方法不走源码工程。

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

接下来，我们就来探索为什么NSObject的alloc会出现这种情况，首先，

打开Debug --> Debug Workflow --> 勾选 Always Show Disassemly，开启汇编调试
关闭源码的断点，只留main中的断点，重新运行程序，然后通过下图的汇编可以发现NSObject并没有走 alloc源码，而是走的objc_alloc
然后关闭汇编调试，在全局搜索 objc_alloc，在objc_alloc中加一个断点，先暂时关闭，
重新运行进行调试，断住，然后打开objc_alloc的断点，发现会进入objc_alloc的源码实现，此时查看 cls 是 NSObject

首先，我们来看看 NSObject 与 LGPerson的区别

然后根据第一步中汇编的显示，可以看出，NSObject 和 LGPerson 都调用了objc_alloc，所以这里就有两个疑问：

首先，需要在源码中调试，在main中LGPerson加断点，断在LGPerson，再在alloc 、 objc_alloc 和 calloc 源码加断点,运行demo，会断在objc_alloc源码中（重新运行前需要暂时关闭源码中的所有断点）
继续运行，发现LGPerson 第一次的alloc会走到 objc_alloc --> callAlloc方法中最下方的objc_msgSend，表示向系统发送消息
继续执行代码，发现会走到 alloc --> callAlloc --> _objc_rootAllocWithZOne，也就是iOS-底层原理 02：alloc & init & new 源码分析源码分析中的alloc流程.

以下是第二次走到calloc方法中的调用堆栈情况

所以由上述调试过程可以得出，LGPerson走两次的原因是首先需要去查找sel，以及对应的imp的关系，当前需要查找的是 alloc 的方法编号，但是为什么会找到objc_alloc？这个就需要问系统了，肯定是系统在底层做了一些操作。请接着往下看

这部分需要通过 LLVM源码（即llvm-project）来分析

准备工作：首先需要一份llvm源码

在llvm源码中搜索objc_alloc
搜索shouldUseRuntimeFunctionForCombinedAllocInit，表示版本控制
搜索tryEmitSpecializedAllocInit，非常著名的特殊消息发送，在这里也没有找到 objc_alloc
继续尝试，开启上帝视角，通过alloc字符串搜索，如果还找不到，还可以通过omf_alloc:找到tryGenerateSpecializedMessageSend，表示尝试生成特殊消息发送

然后在这个case中可以找到调用alloc，转而调用了objc_objc的逻辑，其中的关键代码是EmitObjCAlloc
跳转至EmitObjCAlloc的定义可以看到alloc 的处理是调用了 objc_alloc