iOS 底层探索 - alloc & init
2020/1/4 14:13:24
本文主要是介绍iOS 底层探索 - alloc & init,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
alloc & init 探索
作为 iOS
开发者,我们每天打交道最多的应该就是对象了,从面向对象设计的角度来说,对象的创建以及初始化是最基础的内容。那么,今天我们就一起来探索一下 iOS
中最常用的 alloc
和 init
的底层是怎么实现的吧。
一、 如何进行底层探索
对于第三方开源框架来说,我们去剖析内部原理和细节是有一定的方法和套路可以掌握的。而对于 iOS
底层,特别是 OC
底层,我们可能就需要用到一些开发中不是很常用的方法。
我们这个系列主要的目的是为了进行底层探索,那么我们作为 iOS
开发者,需要关注应该就是从应用启动到应用被 kill
掉这一整个生命周期的内容。我们不妨从我们最熟悉的 main
函数开始,一般来说,我们在 main.m
文件中打一个断点,左侧的调用堆栈视图应该如下图所示:
要得到这样的调用堆栈有两个注意点:
- 需要关闭
Xcode
左侧Debug
区域最下面的show only stack frames with debug symbols and between libraries
- 需要增加一个
_objc_init
的符号端点
我们通过上面的调用堆栈信息不难得出一个简单粗略的加载流程结构
我们现在心中建立这么一个简单的流程结构,在后期分析底层的时候我们会回过头来梳理整个启动的流程。
接下来,让我们开始实际的探索过程。
我们直接打开 Xcode
新建一个 Single View App
工程,然后我们在 ViewController.m
文件中调用 alloc
方法。
NSObject *p = [NSObject alloc];
我们按照常规探索源码的方式,直接按住 Command
+ Control
来进入到 alloc
内部实现,但结果并非如我们所愿,我们来到的是一个头文件,只有 alloc
方法的声明,并没有对应的实现。这个时候,我们会陷入深深的怀疑中,其实这个时候我们只要记住下面三种常用探索方式就能迎刃而解:
1.1 直接下代码断点
具体操作方式为 Control
+ in
这里的 in
指的是左侧图片中红色部分的按钮,其实这里的操作叫做 Step into instruction
。我们可以来到下图这里
我们观察不难得出我们想要找的就是 libobjc.A.dylib
这个动态链接库了。
1.2 打开反汇编显示
具体操作方式为打开 Debug
菜单下的 Debug Workflow
下的 Always Show Disassembly
接着我们还是下代码断点,然后一步一步调试也会来到下图这里:
1.3 下符号断点
我们先选择 Symbolic Breakpoint
,然后输入 objc_alloc
,如下图所示:
至此,我们得到了 alloc
实现位于 libObjc
这个动态库,而刚好苹果已经开源了这部分的代码,所以我们可以在 苹果开源官网 最新版本 10.14.5 上下载即可。最新的 libObc
为 756。
二、 探索 libObjc
源码
我们下载了 libObjc
的源码到我们的电脑上后是不能直接运行的,我们需要进行一定的配置才能实现源码追踪流程。这一块内容不在本文范围内,读者可参考 iOS_objc4-756.2 最新源码编译调试。
配置好 libObjc
之后,我们新建一个命令行的项目,然后运行如下代码:
NSObject *myObj = [NSObject alloc];
2.1 objc_alloc
然后我们直接下符号断点 objc_alloc
,然后一步步调试,先来到的是 objc_alloc
// Calls [cls alloc]. id objc_alloc(Class cls) { return callAlloc(cls, true/*checkNil*/, false/*allocWithZone*/); }
2.2 第一次 callAlloc
然后会来到 callAlloc
方法,注意这里第三个参数传的是 false
static ALWAYS_INLINE id callAlloc(Class cls, bool checkNil, bool allocWithZone=false) { // 判断传入的 checkNil 是否进行判空操作 if (slowpath(checkNil && !cls)) return nil; // 如果当前编译环境为 OC 2.0 #if __OBJC2__ // 当前类没有自定义的 allocWithZone if (fastpath(!cls->ISA()->hasCustomAWZ())) { // No alloc/allocWithZone implementation. Go straight to the allocator. // 既没有实现 alloc,也没有实现 allocWithZone 就会来到这里,下面直接进行内存开辟操作。 // fixme store hasCustomAWZ in the non-meta class and // add it to canAllocFast's summary // 修复没有元类的类,用人话说就是没有继承于 NSObject // 判断当前类是否可以快速开辟内存,注意,这里永远不会被调用,因为 canAllocFast 内部 // 返回的是false if (fastpath(cls->canAllocFast())) { // No ctors, raw isa, etc. Go straight to the metal. bool dtor = cls->hasCxxDtor(); id obj = (id)calloc(1, cls->bits.fastInstanceSize()); if (slowpath(!obj)) return callBadAllocHandler(cls); obj->initInstanceIsa(cls, dtor); return obj; } else { // Has ctor or raw isa or something. Use the slower path. id obj = class_createInstance(cls, 0); if (slowpath(!obj)) return callBadAllocHandler(cls); return obj; } } #endif // No shortcuts available. if (allocWithZone) return [cls allocWithZone:nil]; return [cls alloc]; }
2.3 _objc_rootAlloc
因为我们在 objc_init
中传入的第三个参数 allocWithZone
是 true
,并且我们的 cls
为 NSObject
,那么也就是说会这里直接来到 return [cls alloc]
。我们接着往下走会来到 alloc
方法:
+ (id)alloc { return _objc_rootAlloc(self); }
然后我们接着进入 _objc_rootAlloc
方法内部:
// Base class implementation of +alloc. cls is not nil. // Calls [cls allocWithZone:nil]. id _objc_rootAlloc(Class cls) { return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/); }
2.4 第二次 callAlloc
是不是有点似曾相似,没错,我们第一步进入的 objc_init
也是调用的 callAlloc
方法,但是这里有两个参数是不一样的,第二个参数 checkNil
是否需要判空直接传的是 false
,站在系统角度,前面已经在第一次调用 callAlloc
的时候进行了判空了,所以这里没必要再次进行判空的了。第三个参数 allocWithZone
传的是 true
,关于这个方法,我查阅了苹果开发者文档,文档解释如下:
Do not overrideallocWithZone:
to include any initialization code. Instead, class-specific versions ofinit...
methods.
This method exists for historical reasons; memory zones are no longer used by Objective-C.
译:不要去重载allocWithZone
并在其内部填充任何初始化代码,相反的,应该在init...
里面进行类的初始化操作。
这个方法的存在是有历史原因的,内存zone
已经不再被Objective-C
所使用的。
按照苹果开发者文档的说法,其实 allocWithZone
本质上和 alloc
是没有区别的,只是在 Objective-C
远古时代,程序员需要使用诸如 allocWithZone
来优化对象的内存结构,而在当下,其实你写 alloc
和 allocWithZone
在底层是一模模一样样的。
好的,话题扯远了,我们接着再次进入到 callAlloc
方法内部,第二次来到 callAlloc
的话,在 !cls->ISA()->hasCustomAWZ()
这里判断 cls
没有自定义的 allocWithZone
实现,这里的判断实质上是对 cls
也就是 object_class
这一结构体内部的 class_rw_t
的 flags
与上一个宏 RW_HAS_DEFAULT_AWZ
。经过笔者测试,在第一次进入 callAlloc
方法内部的时候, flags
值为 1 ,然后 flags
与上 1<<16
结果就是 0 ,返回过去也就是 false
,然后在 hasCustomAWZ
这里取反之后,返回的就是 true
,然后再一取反,自然就会跳过 if
里面的逻辑;而第二次进入 callAlloc
方法内部的时候, flags
值是一个很大的整数,与上 1<<16
后结果并不为0 ,所以 hasDefaultAWZ
会返回 true
,那么 hasCustomAWZ
这里就会返回 false
,那么返回到 callAlloc
的时候自然就会进入 if
里面的逻辑了。
这里插一句,在我们 OC 的类的结构中,有一个结构叫class_rw_t
,有一个结构叫class_ro_t
。其中class_rw_t
是可以在运行时去拓展类的,包括属性,方法、协议等等,而class_ro_t
则存储了成员变量,属性和方法等,不过这些是在编译时就确定了的,不能在运行时去修改。
bool hasCustomAWZ() { return ! bits.hasDefaultAWZ(); } bool hasDefaultAWZ() { return data()->flags & RW_HAS_DEFAULT_AWZ; }
然后我们会来到 canAllocFast
的判断,我们继续进入该方法内部
if (fastpath(cls->canAllocFast()))
bool canAllocFast() { assert(!isFuture()); return bits.canAllocFast(); } bool canAllocFast() { return false; }
结果很显然,这里 canAllocFast
是一直返回 false
的,也就是说会直接来到下面的逻辑
id obj = class_createInstance(cls, 0); if (slowpath(!obj)) return callBadAllocHandler(cls); return obj;
我们再次进入 class_createInstance
方法内部
id class_createInstance(Class cls, size_t extraBytes) { return _class_createInstanceFromZone(cls, extraBytes, nil); } static __attribute__((always_inline)) id _class_createInstanceFromZone(Class cls, size_t extraBytes, void *zone, bool cxxConstruct = true, size_t *outAllocatedSize = nil) { // 对 cls 进行判空操作 if (!cls) return nil; // 断言 cls 是否实现了 assert(cls->isRealized()); // Read class's info bits all at once for performance // cls 是否有 C++ 的初始化构造器 bool hasCxxCtor = cls->hasCxxCtor(); // cls 是否有 C++ 的析构器 bool hasCxxDtor = cls->hasCxxDtor(); // cls 是否可以分配 Nonpointer,如果是,即代表开启了内存优化 bool fast = cls->canAllocNonpointer(); // 这里传入的 extraBytes 为0,然后获取 cls 的实例内存大小 size_t size = cls->instanceSize(extraBytes); // 这里 outAllocatedSize 是默认值 nil,跳过 if (outAllocatedSize) *outAllocatedSize = size; id obj; // 这里 zone 传入的也是nil,而 fast 拿到的是 true,所以会进入这里的逻辑 if (!zone && fast) { // 根据 size 开辟内存 obj = (id)calloc(1, size); // 如果开辟失败,返回 nil if (!obj) return nil; // 将 cls 和是否有 C++ 析构器传入给 initInstanceIsa,实例化 isa obj->initInstanceIsa(cls, hasCxxDtor); } else { // 如果 zone 不为空,经过笔者测试,一般来说调用 alloc 不会来到这里,只有 allocWithZone // 或 copyWithZone 会来到下面的逻辑 if (zone) { // 根据给定的 zone 和 size 开辟内存 obj = (id)malloc_zone_calloc ((malloc_zone_t *)zone, 1, size); } else { // 根据 size 开辟内存 obj = (id)calloc(1, size); } // 如果开辟失败,返回 nil if (!obj) return nil; // Use raw pointer isa on the assumption that they might be // doing something weird with the zone or RR. // 初始化 isa obj->initIsa(cls); } // 如果有 C++ 初始化构造器和析构器,进行优化加速整个流程 if (cxxConstruct && hasCxxCtor) { obj = _objc_constructOrFree(obj, cls); } // 返回最终的结果 return obj; }
至此,我们的 alloc
流程就探索完毕,但在这其中我们还是有一些疑问点,比如,对象的内存大小时怎么确定出来的, isa
是怎么初始化出来的呢,没关系,我们下一篇接着探索。这里,先给出笔者自己画的一个 alloc
流程图,限于笔者水平有限,有错误之处望读者指出:
2.5 init 简略分析
分析完了 alloc
的流程,我们接着分析 init
的流程。相比于 alloc
来说, init
内部实现十分简单,先来到的是 _objc_rootInit
,然后就直接返回 obj
了。其实这里是一种抽象工厂设计模式的体现,对于 NSObject
自带的 init
方法来说,其实啥也没干,但是如果你继承于 NSObject
的话,然后就可以去重写 initWithXXX
之类的初始化方法来做一些初始化操作。
- (id)init { return _objc_rootInit(self); } id _objc_rootInit(id obj) { // In practice, it will be hard to rely on this function. // Many classes do not properly chain -init calls. return obj; }
三、总结
先秦荀子的劝学中有言:
不积跬步,无以至千里;不积小流,无以成江海。
我们在探索 iOS
底层原理的时候,应该也是抱着这样的学习态度,注意点滴的积累,从小做起,积少成多。下一篇笔者将对本文留下的两个疑问进行解答:
- 对象初始化内存是如何分配的?
- isa 是如何初始化的?
这篇关于iOS 底层探索 - alloc & init的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2022-10-05Swift语法学习--基于协议进行网络请求
- 2022-08-17Apple开发_Swift语言地标注释
- 2022-07-24Swift 初见
- 2022-05-22SwiftUI App 支持多语种 All In One
- 2022-05-10SwiftUI 组件参数简写 All In One
- 2022-04-14SwiftUI 学习笔记
- 2022-02-23Swift 文件夹和文件操作
- 2022-02-17Swift中使用KVO
- 2022-02-08Swift 汇编 String array
- 2022-01-30SwiftUI3.0页面反向传值