iOS底层原理--001：alloc & init

内存地址 & 指针地址

搭建allocDemo项目

打印对象的内存地址和指针地址

- (void)viewDidLoad {
   [super viewDidLoad];

   LGPerson *p1 = [LGPerson alloc];
   LGPerson *p2 = [p1 init];
   LGPerson *p3 = [p1 init];
   
   NSLog(@"对象：%@，内存：%p，指针：%p",p1,p1,&p1);
   NSLog(@"对象：%@，内存：%p，指针：%p",p2,p2,&p2);
   NSLog(@"对象：%@，内存：%p，指针：%p",p3,p3,&p3);
}

输出结果：

对象：<LGPerson: 0x282a28700>，内存：0x282a28700，指针：0x16b375b38
对象：<LGPerson: 0x282a28700>，内存：0x282a28700，指针：0x16b375b30
对象：<LGPerson: 0x282a28700>，内存：0x282a28700，指针：0x16b375b28

上述案例中，三个对象的内存地址相同，但指针地址不同

在alloc方法中，为对象在堆区开辟内存空间，并返回指针地址。而init方法中，并没有对内存做任何处理，所以三个对象的内存地址相同

但它们的指针地址不同，因为指针地址在栈区，以连续的内存地址存储，相隔8字节，并指向相同的堆空间

底层探索的三种方法

日常开发中，我们只能找到alloc的方法定义，却找不到它的方法实现

+ (instancetype)alloc OBJC_SWIFT_UNAVAILABLE("use object initializers instead");

所以想了解底层原理，必须从源码中进行探索

底层探索的三种方法：

  • 使用Control + Step into单步调试
  • 查看汇编代码
  • 对已知方法设置符号断点

【方式一】

使用Control + Step into单步调试

底层调用的objc_alloc函数

选择Symbolic Breakpoint...，设置符号断点

对objc_alloc设置符号断点

点击Continue继续执行

进入objc_alloc函数

  • 来自于libobjc.A.dylib动态库，想了解它的底层原理，必须探索objc源码

【方式二】

查看汇编代码

在菜单中，选择Debug→Debug Workflow→Always Show Disassembly

来到汇编代码，当bl指令一旦执行，就会进入objc_alloc函数

使用Control + Step into单步调试，执行两步，进入objc_alloc函数

对objc_alloc设置符号断点，即可跟踪到方法来源

【方式三】

对已知方法设置符号断点

对象初始化依赖于alloc方法，对已知的alloc方法设置符号断点

一旦设置成功，整个项目中，针对alloc方法设置的断点非常多

所以，先对[LGPerson alloc]设置断点，暂时禁用alloc断点

项目运行后，先进入[LGPerson alloc]断点，然后启用alloc断点，点击Continue继续执行

+[NSObject alloc]方法，同样来自libobjc.A.dylib。所以我们想更深入的了解底层，对于objc源码的探索是必不可少的

下载objc源码

【方式一】

打开 Apple Open Source

选择系统版本，例如：11.3

在列表中，搜索objc

【方式二】

打开 Source Browser

在列表中，搜索objc

选择objc的源码版本

汇编结合源码探索

下载objc4-818.2源码，打开项目

搜索alloc {关键字，打开NSObject.mm文件，找到alloc方法实现

alloc方法的执行流程：alloc→_objc_rootAlloc→callAlloc

在callAlloc方法中，出现了复杂的代码逻辑

使用汇编结合源码，定位条件分支的触发

延用allocDemo项目

将alloc流程中找到的几个的函数，全部设置符号断点

运行项目，查看汇编代码，进入alloc方法

进入_objc_rootAlloc函数，由于编译器优化，不会执行callAlloc函数，直接跳转_objc_rootAllocWithZone函数

进入_objc_rootAllocWithZone函数

编译器优化

Code Generation Options

在Build Setting中的设置：

设置Optimization Level，编译器的优化程度

  • None [-O0]：不优化
  • Fast [-O1]：大函数所需的编译时间和内存消耗都会稍微增加
  • Faster [-O2]：编译器执行所有不涉及时间空间交换的所有的支持的优化选项
  • Fastest [-O3]：在开启Fast [-O1]项支持的所有优化项的同时，开启函数内联和寄存器重命名选项
  • Fastest, Smallest [-Os]：在不显着增加代码大小的情况下尽量提供高性能
  • Fastest, Aggressive Optimizations [-Ofast]：与Fastest, Smallest [-Os]相比该级别还执行其他更激进的优化
  • Smallest, Aggressive Size Optimizations [-Oz]：不使用LTO的情况下减小代码大小
alloc源码解析

打开objc源码

进入alloc方法

+ (id)alloc {
   return _objc_rootAlloc(self);
}

进入_objc_rootAlloc函数

id
_objc_rootAlloc(Class cls)
{
   return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/);
}

进入callAlloc函数

static ALWAYS_INLINE id
callAlloc(Class cls, bool checkNil, bool allocWithZone=false)
{
#if __OBJC2__
   if (slowpath(checkNil && !cls)) return nil;
   if (fastpath(!cls->ISA()->hasCustomAWZ())) {
       return _objc_rootAllocWithZone(cls, nil);
   }
#endif

   if (allocWithZone) {
       return ((id(*)(id, SEL, struct _NSZone *))objc_msgSend)(cls, @selector(allocWithZone:), nil);
   }
   return ((id(*)(id, SEL))objc_msgSend)(cls, @selector(alloc));
}
  • #if __OBJC2__：编译器优化。如果给定条件为真，则编译下面代码
  • slowpath：假值判断。入参较大可能为false
  • fastpath：真值判断。入参较大可能为true
  • hasCustomAWZ：类或父类具有默认的alloc/allocWithZone:实现

fastpath和slowpath的定义

#define fastpath(x) (__builtin_expect(bool(x), 1))
#define slowpath(x) (__builtin_expect(bool(x), 0))
  • __builtin_expect，由GCC引入。向编译器提供分支预测信息，从而帮助编译器进行代码优化
  • __builtin_expect(EXP, N)，表示EXP等于N的概率较大

进入_objc_rootAllocWithZone函数

NEVER_INLINE
id
_objc_rootAllocWithZone(Class cls, malloc_zone_t *zone __unused)
{
   return _class_createInstanceFromZone(cls, 0, nil,
                                        OBJECT_CONSTRUCT_CALL_BADALLOC);
}

进入_class_createInstanceFromZone函数

static ALWAYS_INLINE id
_class_createInstanceFromZone(Class cls, size_t extraBytes, void *zone,
                             int construct_flags = OBJECT_CONSTRUCT_NONE,
                             bool cxxConstruct = true,
                             size_t *outAllocatedSize = nil)
{
   ASSERT(cls->isRealized());

   bool hasCxxCtor = cxxConstruct && cls->hasCxxCtor();
   bool hasCxxDtor = cls->hasCxxDtor();
   bool fast = cls->canAllocNonpointer();
   size_t size;

   size = cls->instanceSize(extraBytes);
   if (outAllocatedSize) *outAllocatedSize = size;

   id obj;
   if (zone) {
       obj = (id)malloc_zone_calloc((malloc_zone_t *)zone, 1, size);
   } else {
       obj = (id)calloc(1, size);
   }
   if (slowpath(!obj)) {
       if (construct_flags & OBJECT_CONSTRUCT_CALL_BADALLOC) {
           return _objc_callBadAllocHandler(cls);
       }
       return nil;
   }

   if (!zone && fast) {
       obj->initInstanceIsa(cls, hasCxxDtor);
   } else {
       obj->initIsa(cls);
   }

   if (fastpath(!hasCxxCtor)) {
       return obj;
   }

   construct_flags |= OBJECT_CONSTRUCT_FREE_ONFAILURE;
   return object_cxxConstructFromClass(obj, cls, construct_flags);
}
  • instanceSize：计算内存大小
  • calloc：开辟内存空间
  • initInstanceIsa：将class与isa进行关联

alloc流程图

llvm优化alloc

调用alloc方法，入口函数却是objc_alloc，这是为什么呢？

在objc源码中，_read_images函数在dyld之后被调用

在_read_images函数中，调用fixupMessageRef函数

进入fixupMessageRef函数

  • 关键代码：如果方法编号为alloc，修改为objc_alloc的函数地址

fixupMessageRef函数的作用，修复旧版本的方法调度表。难道在新版本中，alloc方法理应关联objc_alloc的函数地址吗？

fixupMessageRef函数被_read_images调用，而_read_images在objc源码中的执行时机，已经非常优先了

所以，只剩下两个时机可以关联alloc和objc_alloc：

  • 在dyld中进行关联
  • 在编译时期已经关联

查看MachO文件，在符号表中搜索alloc

  • 在编译时期，MachO中已经生成_objc_alloc符号

可以确定alloc和objc_alloc的关联，是在编译时期由llvm完成

打开llvm源码，搜索objc_alloc关键字

  • 在注释中找到线索，alloc关联objc_alloc，allocWithZone:nil关联objc_allocWithZone
  • 代码进行了版本控制，哪些系统和版本有此关联

进入GeneratePossiblySpecializedMessageSend函数

  • 判断如果为特殊消息，调用tryGenerateSpecializedMessageSend函数，否则调用GenerateMessageSend函数
  • 特殊消息，例如：alloc方法

进入tryGenerateSpecializedMessageSend函数

  • 在OMF_alloc条件中，如果方法编号为alloc，调用EmitObjCAlloc函数并返回

进入EmitObjCAlloc函数

  • 将alloc方法编号，修改为objc_alloc的函数地址

苹果对特殊方法，自身会进行HOOK。例如alloc方法，优先进入objc_alloc流程，执行完毕后，对当前对象发送alloc消息，然后进入alloc流程

打开objc源码

在对象的alloc方法上设置断点

首先进入objc_alloc函数

id
objc_alloc(Class cls)
{
   return callAlloc(cls, true/*checkNil*/, false/*allocWithZone*/);
}

来到callAlloc函数，发送alloc消息

进入alloc流程：alloc→_objc_rootAlloc→callAlloc

再次进入callAlloc函数，调用_objc_rootAllocWithZone函数，继续alloc流程

[LGPerson alloc]流程图

init源码解析

在对象的alloc + init方法上设置断点

调用alloc + init方法，入口函数为objc_alloc_init

打开objc源码

进入objc_alloc_init函数

id
objc_alloc_init(Class cls) {
   return [callAlloc(cls, true/*checkNil*/, false/*allocWithZone*/) init];
}
  • 在callAlloc函数执行完毕后，调用对象的init方法

进入init方法

- (id)init {
   return _objc_rootInit(self);
}

进入_objc_rootInit函数

id
_objc_rootInit(id obj) {
   return obj;
}

至此，init流程结束，方法只做了一件事，将传入的self对象返回。init本质是构造方法，通过工厂设计模式，给用户提供入口以便重写和定制

new源码解析

对象初始化的另一种方式，new方法

调用new方法，入口函数为objc_opt_new

打开objc源码

进入objc_opt_new函数

id
objc_opt_new(Class cls)
{
#if __OBJC2__
   if (fastpath(cls && !cls->ISA()->hasCustomCore())) {
       return [callAlloc(cls, false/*checkNil*/) init];
   }
#endif
   return ((id(*)(id, SEL))objc_msgSend)(cls, @selector(new));
}
  • hasCustomCore：类或父类具有默认的new/self/class/respondsToSelector/isKindOfClass
  • 符合条件，直接调用alloc + init方法。否则进行消息发送

触发消息发送流程，调用new方法，最终调用的还是alloc + init方法

+ (id)new {
   return [callAlloc(self, false/*checkNil*/) init];
}

结论：new方法等价于alloc + init方法。但我更推荐alloc + init方式，因为在开发中，我们会定义initWithXXX等方法，new方法将初始化固定为init，所以alloc + init相比new方法而言扩展性更好，使用更灵活。并且在原则上，显示调用比隐式调用更清晰

NSObject初始化流程

NSObject与自定义类的初始化流程有一些区别

alloc流程

当NSObject调用alloc方法，首先进入objc_alloc流程

进入callAlloc函数，不触发objc_msgSend，直接调用_objc_rootAllocWithZone函数

new流程

NSObject调用new方法，进入objc_opt_new流程，不触发objc_msgSend，直接调用alloc + init方法

总结

内存地址 & 指针地址

  • 不同指针地址指向相同堆空间
  • alloc方法，为对象开辟内存空间，并返回指针地址
  • init方法，并没有对内存做任何处理

底层探索的三种方法

  • 使用Control + Step into单步调试
  • 查看汇编代码
  • 对已知方法设置符号断点

下载objc源码

汇编结合源码探索

  • alloc方法的执行流程：alloc→_objc_rootAlloc→callAlloc
  • 由于编译器优化，没有触发callAlloc方法的断点

编译器优化

  • 在Build Setting中，设置Optimization Level，编译器的优化程度
  • 七个不同程度的优化等级供开发者选择，Debug模式默认为None [-O0]不优化

alloc源码解析

  • alloc→_objc_rootAlloc→callAlloc→_objc_rootAllocWithZone→_class_createInstanceFromZone
  • alloc核心方法
    ◦ instanceSize：计算内存大小
    ◦ calloc：开辟内存空间
    ◦ initInstanceIsa：将class与isa进行关联

llvm优化alloc

  • alloc方法，优先进入objc_alloc流程，执行完毕后，对当前对象发送alloc消息，然后进入alloc流程
  • 自定义对象，callAlloc函数会执行两遍
    ◦ 对当前对象发送alloc消息
    ◦ 调用_objc_rootAllocWithZone函数
  • 通过源码分析和MachO中的_objc_alloc符号，可以确定alloc和objc_alloc的关联，是在编译时期由llvm完成
  • llvm源码中，如果是特殊消息，例如：alloc方法，调用tryGenerateSpecializedMessageSend函数，否则调用GenerateMessageSend函数
  • 在OMF_alloc条件中，如果方法编号为alloc，修改为objc_alloc的函数地址

init源码解析

  • init方法本质是构造方法
  • 用于将传入的self对象返回
  • 通过工厂设计模式，给用户提供入口以便重写和定制

new源码解析

  • new方法等价于alloc + init方法
  • 更推荐alloc + init方式，扩展性更好，使用更灵活，显示调用比隐式调用更清晰

NSObject初始化流程

  • NSObject与自定义类的初始化流程有一些区别
  • NSObject调用alloc和new方法，都不触发objc_msgSend，直接进入各自初始化流程
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容