iOS之武功秘籍①：OC对象原理-上(alloc & init & new)

iOS之武功秘籍 文章汇总

写在前面

春节的夜晚,十分的难以入睡,梦醒时分,翻开秘籍最新objc4-818.2源码,有个小伙在渐渐的发着呆......

1、探索的线索和方向

拿到秘籍的那一刻,脑子就一直在高速的运转着,要怎么才能学好呢?

咱们想着手开始探索"武林绝学"(iOS的底层)，但又不知道从哪里开始，怎么办呢？

那就从main函数入手！

咱们先开启上帝视角！来观察一个粗略的加载流程.进行准备工做：

• 在main函数中直接打断点,而后咱们这时打印一下堆栈信息瞧瞧(bt - lldb 调试指令打印堆栈信息)

嗯哼,咱们都知道main函数是很是之早的,可是结果告诉咱们在main函数以前,系统还作了其余的!!那么在main函数以前还有什么呢?来咱们来瞧瞧

• 添加三个符号断点libSystem_initializer、libdispatch_init、_objc_init

咱们按上图操做依次添加好libSystem_initializer、libdispatch_init、_objc_init符号断点 而后咱们来运行一下程序看看:

此时会来到咱们下的第一个符号断点libSystem_initializer,经过堆栈信息咱们会看到程序会来到很是著名的dyld,通过一系列流程后在来到libSystem_initailizer.这也就从dyld来到了libSystem库.

接下来会来到咱们的第二个符号断点libdispatch_init,也就来到了libdispatch库了 而libdispatch是GCD的源码,咱们后续在研究这个. 过掉这个断点来到咱们下的第三个符号断点_objc_init,也就来到了libobjc的底层,它是整个一个runtime的一些源码.

过完以上三个断点才会来到咱们熟悉的main函数.

过掉main函数的断点就会来到咱们熟悉的了

走完这些流程,可能有些小可爱会问?咦,你这咋有这么详细的堆栈信息呢?

只需关闭 Xcode 左侧 Debug 区域最下面的第一个按钮就行 show only stack frames with debug symbols and between libraries

到此咱们来总结一波. 经过以上的堆栈信息,咱们能够总结一个简单的加载流程:

• dyld启动加载动态库、共享内存、全局C++对象的构造函数的调用、一系列的初始化、dyld注册回调函数
• libsystem 的初始化 libSystem_initializer
• libdispatch_init 队列环境的准备
• 从_os_object_init 过渡到 _objc_init
• 以及_dyld_objc_notify_register 镜像文件的映射
• 类-分类-属性-协议-SEL-方法 的加载
• 展开分析 Runtime 各个部分的原理
• main函数的启动

这里面的分析角度和思惟都是比较有意思的,为了让你们有比较好的体验感.接下来,咱们先从你们都比较熟悉的OC对象开始分析吧.

2、alloc原理初探 一 OC对象的alloc

咱们要研究对象，确定要从建立开始研究的！下面我有一个很是有意思的提问，小伙伴们不妨花个十秒钟思考一下！来代码以下:

%@ 打印对象 %p 打印地址 &p 指针地址

问题:

• 1.这里p1对象是否建立完成
• 2.p一、p二、p3以及p4是否为同一个对象

不知道你脑海中的答案是否和上面的打印一致:

• 从上面能够得出咱们建立了四个临时对象p一、p二、p三、p4
• p一、p二、p3这三个对象的指针是不一样的可是他们所指向的内存是同一片,而p4对象的指针和他所指向的内存地址都和p一、p二、p3不一样(为何呢? - 看完本编你就知道为何了)
  • 遗留问题:
  • ①.p一、p二、p3对象和地址打印都一致， 为什么&p打印不一致?
  • ②.p4的地址为何和p一、p二、p3都不同?
• 从反向能够证实alloc才是建立对象-开辟内存
• init只是一个初始化构造函数.
• new又alloc出了另外一内存空间

嗯哼,alloc出来就已经把对象的内存地址肯定了,那么是怎么肯定的呢?下面开始探索

• 如今咱们跳进这个万恶之源(经过Command+单击->Jump to Defintion的方式进入)
• 发现跳不进去查看实现,怎么办，请来到 objc4官方源码或objc4小编配好可运行的源码,接下来几天都会动不动就进去了！！我但愿每个小伙伴都不要只在这外面蹭一蹭，深层交流才有意义
• 没有注释
• 没有源码实现
• 更加不知道下一步流程

发现进不去了,怎么办？看不到具体的源码实现！ 不少时候咱们常常也会遇到这样的状况，就是想作一些事，就是碰壁，无从下手！你们请注意这里：我要开始装逼咯！

3、alloc底层探索思路(底层探索分析的三种方法)

下面介绍三种方式来查看他的实现.

方法一:符号断点直接定位

添加alloc符号断点(在前面 探索的线索和方向 已经介绍了怎么加符号断点)

• 先将alloc符号断点先置灰(alloc函数在不少地方被调用，在到达咱们目标位置前，先置灰)

• Xcode开启运行,程序到达[TCJPerson alloc]断点后，开启alloc符号断点

• 点击 Xcode日志栏的继续运行按钮

结果以下

• [NSObject alloc] 成功看到所在连接库libobjc.A.dylib
• 其底层调用的就是 _objc_rootAlloc函数

方法二:代码跟踪 - control + step into

• ①关掉以前的相关符号断点,来到研究对象断点处

• ②按住键盘control键+鼠标点击 Xcode日志栏的step into按钮

进去后能够看到objc_alloc

• ③若是你是用真机的请继续第二部的操做,后来到

• ④若是你是用模拟器的话,在第二部后须要添加objc_alloc符号断点后,点击 Xcode日志栏的继续运行按钮

• ⑤无论你是真机仍是模拟器最终都来到了libobjc.A.dylib,进而也看到了底层objc_alloc

• ⑥和方法一不谋而合

方式三：汇编进入分析

• ①关闭其余的符号断点,来到研究对象断点

• ②Xcode 工具栏 选择 Debug --> Debug Workflow --> Always Show Disassembly,这个 选项表示 始终显示反汇编 ，即 经过汇编 跟流程

• ③在汇编显示16行处添加断点到objc_alloc

• ④若是你是用真机操做,按住control键和step into键结果以下: 以后继续按住control键和step into键获得:

• ⑤若是你是用模拟器的话,在第三步添加符号断点后,按住control键和step into键结果如:以后须要添加objc_alloc符号断点后,点击 Xcode日志栏的继续运行按钮

• 嗯哼libobjc.A.dylib - objc_alloc: 也就轻松获得！

此时此刻，还有谁！就这些东西能难倒咱们？不存在的

4、alloc流程分析

①.汇编配合源码跟流程

经过前面 alloc底层探索思路(底层探索分析的三种方法) 的介绍,咱们知道了三种探索底层实现的方法,那咱们来玩一玩. 咱们打开准备好的可编译的objc4源码 咱们刚刚前面查到了alloc流程,咱们在源码里面搜索一下: 在源码里面看到了alloc方法,个人天,好高兴啊,来到这里就有底层的实现.咱们点击_objc_rootAlloc方法来到: 继续点击callAlloc方法来到: 到这的源码可能就会让你头晕目眩，不想看了

原本看源码就枯燥，还有这么多if-else逻辑岔路口，就会有不少人关闭了Xcode.

看啥很差看源码，是嫌本身头发太旺盛吗？

别急，我这里已经帮你掉过头发了（捋过思路了）

那么他到底走的是哪个流程呢?咱们来验证一下

汇编和源码同步辅导来跟流程

• 在咱们的第一份代码里面加入咱们刚刚捋过的三个符号断点_objc_rootAlloc、callAlloc、_objc_rootAllocWithZone.
• 先关闭符号断点,来到咱们的研究对象断点处
• 打开咱们刚刚下的三个符号断点,来到第一个符号断点_objc_rootAlloc:
• 过掉此_objc_rootAlloc断点来到了_objc_rootAllocWithZone断点:

来咱们根据刚刚看的源码来捋个草图: 根据源码咱们知道在callAlloc的时候出现了分叉:objc_msgSend和_objc_rootAllocWithZone,那么他究竟是往那个分叉走的呢?根据刚刚咱们的走的汇编,咱们获得的是走的_objc_rootAllocWithZone. 而咱们跑汇编跟流程的时候,只断了两下即:_objc_rootAlloc直接来到了_objc_rootAllocWithZone.而后callAlloc这个断点变没有断住?为何呢?请看下文

②.编译器优化

咱们先来看下面的例子(使用真机调试,看汇编):

运行程序获得汇编代码:

看到结果有些小伙伴可能会问?为何有w和x呢? 这涉及到寄存器的知识.w表明32位,x表明64位.那为何咱们跑到真机上还有w呢?这考虑到兼容问题,例如咱们存储一个int = 10类型的数据,在32位下就能存储,不须要用64位.

寄存器 - 其寄存器的做用就是进行数据的临时存储

• ARM64拥有31个64位的通用寄存器 x0 到 x30,这些寄存器一般用来存放通常性的数据，称为通用寄存器（有时也有特定用途）
  • 好比x0 ~ x7 用来存储参数,x0主要用来存储参数和接收返回值.
  • 那么w0 到 w28 这些是32位的. 由于64位CPU能够兼容32位.因此能够只使用64位寄存器的低32位.
  • 好比 w0 就是 x0的低32位!
• 一般，CPU会先将内存中的数据存储到通用寄存器中，而后再对通用寄存器中的数据进行运算

咱们刚刚在 int a = 10处打了一个断点,那么哪一个表明他呢,咱们打印一下:

接下来又来到 mov w9, #0x14:

接下来来到add w9, w9, w10即: 10 + 20 放到 w9 里面:

在正常开发过程当中咱们都是Debug模式下,想要提升编译速度，可将Debug环境也选中Fastest，Smallest[-OS]模式:

• target ->BuildSettings: 搜索:optimization

咱们发现Optimization Level中，Release环境下，已自动选择Fastest，Smallest[-OS]

• 接下来咱们将Debug模式下也选中Fastest，Smallest[-OS]模式:

在Fastest，Smallest[-OS]模式下，会发现汇编页面展现的代码已精简不少: 咱们直接读取一下:

那么Fastest，Smallest[-OS]表明什么意思呢?就是按照最快最小的路径来执行.

在下来咱们看源码的过程当中都会看到有不少的过程都会被优化掉 - 这就是编译器的强大. 这也就是咱们在发布版本的时候要调到Release版本(如今苹果在咱们发版的时候会自动帮咱们选择Release环境,早期的时候须要咱们手动设置选择). 由于Release环境下，系统自动选择Fastest，Smallest[-OS]模式，完成编译器优化,节省性能.

③.alloc源码流程

咱们先来看下面的代码

接下来我先给出他们各自调用alloc方法后的堆栈详情图:

看到上面的调用堆栈图,咱们不难发现如下问题:

• 问题一:无论我是NSObject类,仍是自定义的TCJPerson类调用alloc方法为何最开始走的是objc_alloc
• 问题二:NSObject没有走alloc方法
• 问题三:自定义的TCJPerson类为何走了两次callAlloc

③.1 objc_alloc 方法

为何首先会来到objc_alloc?

第一处解释:源码中的Calls [cls alloc]告诉咱们,当咱们调用alloc方法时底层是调用objc_alloc

第二处解释:咱们一块儿来看看汇编代码: 汇编代码也告诉咱们首先调用的是objc_alloc.

第三处解释:须要借助llvm源码来帮助咱们.

• 打开llvm源码文件(用Xcode打开比较慢,可用Visual Studio Code即VSCode打开)，搜索alloc,找到CGObjC.cpp文件
• 能够看到这里有明确标注，[self alloc] -> objc_alloc(self)
• 函数中显示，当接收到alloc名称的selector时，调用EmitObjCAlloc函数.继续全局搜索EmitObjCAlloc:

由此能够得出当咱们调用alloc方法时会调用 objc_alloc，其实这部分是由系统在llvm底层帮咱们转发到objc_alloc的.llvm在咱们编译启动时，就已经处理好了.

咱们来验证一下:

• 首先来到咱们的研究对象断点处:

• 接着在objc4源码中的objc_alloc方法实现处打下断点:

• 结果都来到了objc_alloc方法,接着调用callAlloc方法.

• 那么问题一问题二的答案咱们相信你们都知道了吧.

③.2 callAlloc 方法

①static ALWAYS_INLINE id 中的 ALWAYS_INLINE说明 inline 是一种下降函数调用成本的方法，其本质是在调用声明为 inline 的函数时，会直接把函数的实现替换过去，这样减小了调用函数的成本. 是一种以空间换时间的作法.

#define ALWAYS_INLINE inline __attribute__((always_inline)) ALWAYS_INLINE宏会强制开启inline

②if (slowpath(checkNil && !cls))判断

#define fastpath(x) (__builtin_expect(bool(x), 1)) #define slowpath(x) (__builtin_expect(bool(x), 0))

这两个宏使用__builtin_expect函数

__builtin_expect(EXP, N) __builtin_expect是gcc引入的

• 做用： 容许程序员将最有可能执行的分支告诉编译器.编译器能够对代码进行优化，以减小指令跳转带来的性能降低.即性能优化
• 函数： __builtin_expect(EXP, N) 表示 EXP==N的几率很大

fastpath:定义中__builtin_expect((x),1)表示 x 的值为真的可能性更大；即 执行if 里面语句的机会更大 slowpath:定义中的__builtin_expect((x),0)表示 x 的值为假的可能性更大。即执行 else 里面语句的机会更大

在平常的开发中，也能够经过设置来优化编译器，达到性能优化的目的，设置的路径为：Build Setting --> Optimization Level --> Debug --> 将None 改成 fastest 或者 smallest(前面有介绍)

③if (fastpath(!cls->ISA()->hasCustomAWZ()))判断 跟进hasCustomAWZ()实现可发现: 而FAST_CACHE_HAS_DEFAULT_AWZ的定义为:

判断的主要依据:仍是看缓存中是否有默认的alloc/allocWithZone方法(这个值会存储在metaclass中).

而对于NSObject类而言就有少量不一样了:由于NSObject的初始化，系统在llvm编译时就已经初始化好了.所以缓存中就有alloc/allocWithZone方法了.即hasCustomAWZ()为false那么!cls->ISA()->hasCustomAWZ()就为true:

而咱们自定义的TCJPerson类初次建立是没有默认的alloc/allocWithZone实现的。因此继续向下执行进入到msgSend消息发送流程，调用[NSObject alloc]方法,即就是alloc方法,接着会来到_objc_rootAlloc,后再次来callAlloc,而此次由于调用的是NSObject类的,因此缓存中存在alloc/allocWithZone实现,接着走_objc_rootAllocWithZone方法.

自定义类第一次进入callAlloc走msgSend消息发送流程: 第二次进入callAlloc走_objc_rootAllocWithZone:

到这也就解释了问题三:自定义的TCJPerson类为何走了两次callAlloc.

③.3 alloc 方法

③.4 _objc_rootAlloc 方法

③.5 callAlloc 方法(自定义类二次进入)

调用 NSObject的[NSObject alloc]不会来到③.3-③.4-③.5这个流程,只有自定义的类TCJPerson调用[TCJPerson alloc]才会来到③.3-③.4-③.5这个流程

③.6 _objc_rootAllocWithZone 方法

③.7 _class_createInstanceFromZone 方法 (alloc的核心方法)

①hasCxxCtor()

hasCxxCtor()是判断当前class或者superclass是否有.cxx_construct 构造方法的实现

②hasCxxDtor()

hasCxxDtor()是判断判断当前class或者superclass是否有.cxx_destruct 析构方法的实现

③canAllocNonpointer()

canAllocNonpointer()是具体标记某个类是否支持优化的isa,便是对 isa 的类型的区分，若是一个类和它父类的实例不能使用 isa_t 类型的 isa 的话，返回值为 false.在 Objective-C 2.0 中，大部分类都是支持的.

④size = cls->instanceSize(extraBytes)

instanceSize(extraBytes) 计算须要开辟的内存大小，传入的extraBytes 为 0

跳转至instanceSize的源码实现

经过断点调试，会执行到cache.fastInstanceSize方法

继续跟断点，进入align16源码实现(16字节对齐算法):

既然提到了内存对齐(后面文章会详细讲解),那咱们就来预热一下:

内存字节对齐原则

在解释为何须要16字节对齐以前，首先须要了解内存字节对齐的原则，主要有如下三点:

• 数据成员对齐规则：struct 或者 union 的数据成员，第一个数据成员放在offset为0的地方，之后每一个数据成员存储的起始位置要从该成员大小或者成员的子成员大小（只要该成员有子成员，好比数据、结构体等）的整数倍开始（例如int在32位机中是4字节，则要从4的整数倍地址开始存储）
• 数据成员为结构体：若是一个结构里有某些结构体成员，则结构体成员要从其内部最大元素大小的整数倍地址开始存储（例如：struct a里面存有struct b，b里面有char、int、double等元素，则b应该从8的整数倍开始存储）
• 结构体的总体对齐规则：结构体的总大小，即sizeof的结果，必须是其内部最大成员的整数倍，不足的要补齐.

为何须要16字节对齐

• 提升性能,加快存储速度: 一般内存是由一个个字节组成，cpu在存储数据时，是以固定字节块为单位进行存取的.这是一个以空间换时间的一种优化方式，这样不用考虑字节未对齐的数据，极大节省了计算资源，提高了存取速度。
• 更安全 因为在一个对象中，第一个属性isa占8字节，固然一个对象可能还有其余属性，当无其余属性时，会预留8字节，即16字节对齐.由于苹果公司如今采用的16字节对齐(早期是8字节对齐--objc4-756.2及之前版本),若是不预留，就至关于这个对象的isa和其余对象的isa紧挨着，在CPU存取时它以16字节为单位长度去访问的,这样会访问到相邻对象,容易形成访问混乱,那么16字节对齐后，能够加快CPU读取速度，同时使访问更安全，不会产生访问混乱的状况

下面以align16(size_t 8)->(8 + size_t(15)) & ~size_t(15)为例，图解16字节对齐算法的计算过程，以下所示

• 首先将原始的内存 8 与 size_t(15)相加，获得 8 + 15 = 23其二进制:0000 0000 0001 0111
• 将 size_t(15) 即 15的二进制:0000 0000 0000 1111进行~（取反）操做其取反二进制为:1111 1111 1111 0000，~（取反）的规则是：1变为0，0变为1
• 最后将 23的二进制 与 15的取反结果的二进制 进行 &（与）操做，&（与）的规则是：都是1为1，反之为0，最后的结果为0000 0000 0001 0000即16(十进制)，即内存的大小是以16的倍数增长的.

⑤calloc()

用来动态开辟内存，返回地址指针.没有具体实现代码，接下来的文章会讲到malloc源码

（这里的zone基本是不会走的，苹果废弃了zone开辟空间，而且这里zone的入参传入的也是nil）

根据size = cls->instanceSize(extraBytes)计算的内存大小，向内存中申请大小为size的内存，并赋值给obj.

• 执行前打印obj只有cls类名,执行后打印，已为成功申请内存的首地址了.
• 但并非咱们想象中的格式<TCJPerson: 0x0000000101906140>,这是由于这一步只是单纯的完成内存申请，返回首地址.
• 而类和地址的关联:是在接下来咱们要说的obj->initInstanceIsa(cls, hasCxxDtor)完成

⑥obj->initInstanceIsa(cls, hasCxxDtor) 类与isa关联

已知zone=false，fast=true，则(!zone && fast)=true

内部调用initIsa(cls, true, hasCxxDtor) 初始化isa指针,并将isa指针指向申请的内存地址，在将指针与cls类进行关联(具体的isa结构和绑定关系，后续会做为单独章节进行讲解)

通过initIsa后,打印obj,此时发现地址与类完成绑定:

在_class_createInstanceFromZone中，主要作了3件事，1.计算对象所需的空间大小；2.根据计算大小开辟空间,返回地址指针；3.初始化isa，使其与当前对象关联

到此处一个TCJPerson对象就建立完成了.

5、init源码分析

那么init 作了什么? init什么也不作，就是给开发者使用工厂设计模式提供一个接口

补充： 关于子类中if (self = [super init])为何要这么写——子类先继承父类的属性，再判断是否为空，如若为空不必进行一系列操做了直接返回nil.

就是一个初始化的构造方法！提供构造能力：好比array初始化 字典 还有button 这就是给工厂设计!

6、new源码分析

那么 new 又作了什么？

• 底层就是调用了 alloc 下层的 callAlloc 建立对象
• 而后调用了 init 的初始化方法
• new 方法也就是为了方便直接！

可是通常在开发过程当中不建议使用new，主要是由于有时会重写init方法作一些自定义的操做.

写在后面

最后咱们来一块儿解答前面最开始留下的两个问题:

• ①.p一、p二、p3对象和地址打印都一致， 为什么&p打印不一致?
• ②.p4的地址为何和p一、p二、p3都不同?

解答:

问题1：p一、p二、p3对象和地址打印都一致， 为什么&p打印不一致? 其实说白了alloc就作到了对象指针的肯定，咱们开辟内存真正的家伙就是alloc. 他们的指针都是同一个，可是由于都是不一样对象接受而已，因此执行不一样的地址,即&p打印的是他们自身的地址 问题二:p4的地址为何和p一、p二、p3都不同? 由于p一、p二、p3是同一个alloc开辟出来的，而p4是new出来的，new会单独调用alloc. 因此他们打印确定不同.

总结:

• 对象的开辟内存交由 alloc 方法封装
• init 只是一种工厂设计方案，为了方便子类重写：自定义实现，提供一些初始化就伴随的东西
• new 封装了 alloc 和init
• 这一篇文章里面也涉及了一些探索的思路和方法：
  • 源码跟入
  • 汇编分析
  • 符号断点设置
• 和谐学习,不急不躁.我仍是我,颜色不同的烟火.