1)了解OC运行底层入口
通常是直接进入main函数,通过插入断点,在工作台运行bt命令,可以得知线程调用状态,如下:

为了进一步了解,在进入main之前所做的事情,插入符号断点,可以看到start时,调用到了libdyld.dylib,如下:

同理,可以查看到在dylb_start之前还有libSystem.B.dylib(libSystem_initializer,连接系统函数库),libdispatch.dylib(libdispatch_init,对应系统GCD),libobjc.A.dylib(_objc_init,对应底层runtime),如下:

进入main函数之后,通过命令查看全貌,如下:

由此引出底层探索的范围,除了dylib启动自动加载动态库,可能还涉及到libsystem、类(分类/方法/协议/属性/对象)、runtime、runloop、kvc、kvo等。
2)了解对象alloc与init
对象通过alloc申请内存之后,打印出对象、对象指针、以及所对应的指针地址,可以看到三个对象p1、p2、p3,对象与指针内容所对应的地址是完全相同的,因为他们都指向同一块内存区域;但是,三个对象打印出的指针,所在地址是不同的,因为存储指针占用的空间由系统内存统一分配,此处要区分出与指针指向内容是不同的。

简单示意如下:

通过观察进一步发现,p1、p2、p3内存相差8,这就涉及到内存分配栈空间连续,以及16字节对齐问题(以往是8字节对齐,目前都是16字节)。
3)定位alloc源码库
苹果开源源码地址:https://opensource.apple.com/,其中objc更新地址为:https://opensource.apple.com/source/objc4/。

截止目前,mac os 10.15.5对objc有更新版本对应如下,但是还不稳定,所以本文采用的objc-781版本:

有三种方式查找对应alloc源码库,依次如下:
[1]利用苹果开源源码,插入符号断点进行分析

[2]插入符号断点obj_alloc,编译器提示

[3]运行导对象断点处,按住ctrl,step in,点击Debug菜单,Debug workflow-always show disassembly,打开调用汇编(FIXME:后面如果是通过调试源码验证,此处务必取消勾选,否则无法进入到objc源码中,本人因为这个问题耗费了两天时间,才找到原因,直接跟汇编的大神可忽略!),如下:

4)alloc源码分析
打开官方下载到的objc源码,直接搜索 『alloc {』,即可定位到,如下:

可以看到alloc调用的正是_objc_rootAlloc,这与dylib库查看到的一致。通过跳转可以总结出调用链,如下:

由此可知,真正分配内存的关键函数是_class_createInstanceFromZone,这个函数包含如下几个关键步骤:

备注:zone是老系统的分配方式,目前已经基本舍弃!
下面需要调试以验证执行流程,在此之前配置源码,参考https://juejin.im/post/6844904082226806792,具体步骤分析:
[1] 内存分配 instanceSize

通过运行实例发现,extraBytes=0,并且进入fastpath分支(x大概率不为0,标识编译器优化,对应的还有slowpath,大概率为0,简单标识优化处理),即fastInstanceSize调用,接下来了解这个调用具体逻辑:

其中,_flags表示当前类标识(类似nonpointerisa),与x64的内存优化有关,另外还有两个用于字节对齐的mask,FAST_CACHE_ALLOC_MASK = 0x1ff8,FAST_CACHE_ALLOC_DELTA16 = 0x0008(新版本才有对应介绍),通过计算size=40,然后返回调用align16进行对齐(入参:40 + 0 - 8 = 32),具体如下:

通过以上计算,得到了分配内存的实际size = 32。至于内存对齐,主要是为了系统访问对象(至少isa会占用8字节)提供便利,类似固定的『滑动窗口』。
在控制台执行内存查看命令『x』,正是32字节分配,内容地址如下:

执行『x/4g』以每8字节格式化展示,由于ios在内存分配上采用的小端对齐,所以从上到下打印,第一个地址0x001d80010000226d表示isa,直接打印是无效的,需要结合mask,第2~4各个属性打印如下:

[2] calloc开辟内存
通过调用obj = (id)calloc(1, size)开辟内存,拿到对应的指针地址,具体定义如下:

[3]initIsa内存与isa绑定

[4]object_cxxConstructFromClass执行对象构造,发送msg消息,至此alloc流程全部走完。

5)alloc调用流程图

6)init和new作用与区别
init作用:从定义可以看出,其是为用户提供构造方法,进行重写初始化,属于工厂设计模式。

new作用:从定义可以看出,原理等同于alloc init,但是new不会调用到用户重写的init方法,而是直接调用系统的,所以用户自定义的初始化操作就被漏掉了,因此不建议直接new。

7)NSObect调用alloc不会进入实际内存分配
通过执行NSObject*objc = [NSObject alloc];,发现没有进入alloc?
定义:NSObject只是『充当对象』,并非类似于LGPerson的对象。

通过调试程序,发现NSObject并未先调用alloc,而是直接调用objc_alloc,走完msg_send流程;然而,NSObject在进入alloc之前,第一个系统执行的cls=NSAarray,此时由于msg_send时,查找不到alloc方法,所以会通知子类进行查找;NSArray的父类是NSObject,由此可知main函数中,NSObject在执行alloc之前,NSObject初始化已经由系统执行完成了。


当LGPerson第一次alloc进入时,对应的cls是LGPerson,系统通过LLVM消息转发(如上图所示),任何调用alloc方法的类,先转去try调用obj_alloc,之后又回到了子类的alloc,如图『LGPerson alloc完整调用链』红色部分所示,这也就解释了为何LGPerson会调用两次alloc的原因。
网友评论