alloc 底层原理探究

要想探索objc的底层原理，首先得初始化对象

YDLog(@"alloc 探索");
    
YDPerson *p1 = [YDPerson alloc];
YDPerson *p2 = [p1 init];
YDPerson *p3 = [p1 init];
YDPerson *p4 = [YDPerson alloc];
    
NSLog(@"%@-%p-%p",p1,p1,&p1);
NSLog(@"%@-%p-%p",p2,p2,&p2);
NSLog(@"%@-%p-%p",p3,p3,&p3);
NSLog(@"%@-%p-%p",p4,p4,&p4);

alloc 探索
2021-06-21 10:34:51.956810+0800 001-alloc&init探索[2083:53572] <YDPerson: 0x600003c40350>-0x600003c40350-0x7ffeedff4078
2021-06-21 10:34:51.956985+0800 001-alloc&init探索[2083:53572] <YDPerson: 0x600003c40350>-0x600003c40350-0x7ffeedff4070
2021-06-21 10:34:51.957089+0800 001-alloc&init探索[2083:53572] <YDPerson: 0x600003c40350>-0x600003c40350-0x7ffeedff4068
2021-06-21 10:34:51.957222+0800 001-alloc&init探索[2083:53572] <YDPerson: 0x600003c40360>-0x600003c40360-0x7ffeedff4060

总结

• alloc开辟了内存空间
• init没有对指针进行操作（指针p1、p2、p3指向了同一片内存区域）
• 栈区的内存地址由高到低连续分配（p1、p2、p3每个相差8字节在栈里是连续的）
• 堆区的内存地址由低到高分配

问题

• alloc开辟了内存空间，他是怎么做到的呢？
• class和objc是怎样进行关联的呢？
• init又有什么用呢？

点击跳转查看alloc的实现，发现alloc是NSObject.h文件的一个函数声明且没实现
首先要探索alloc，在alloc处打下一个断点并运行

• xode断点调试工具+符号断点
  在需要调式的位置打上断点，然后运行工程，此刻在断点处按住control健，同时点击Xcode日志调试工具的step into，接着会来到汇编里，然后查找这个方法添加符号断点，流程图如下：

通过step into跟流程会来到objc_alloc，对objc_alloc下符号断点，确定objc_alloc属于libobjc.A.dylib库

• 汇编+符号断点
  当断点断住的时候选择Debug下的Debug Workflow接着选择 Always Show Disassembly

通过汇编代码查看alloc在底层调用了objc_alloc，然后对objc_alloc下符号断点，发现objc_alloc属于libobjc.A.dylib库

• 通过已知符号alloc下断点

• 通过对已知符号alloc断点发现alloc归属于libobjc.A.dylib库

通过以上三种下断点的方式发现，alloc的调用都会来到同一个库libobjc.A.dylib，即objc的底层源码，"很不幸"在苹果开源网站opensource中找到了libobjc的底层源码。那么就开启objc底层原理的探索吧！

通过对 objc源码全局搜索找到了alloc的实现，但是断点alloc时先调用了objc_alloc然后调用了callAlloc但没有走_objc_rootAllocWithZone，而是直接走的objc_msgSend发送了一个alloc的消息，然后来到了alloc的实现，接着执行_objc_rootAlloc然后又来到了callAlloc，接着执行了_objc_rootAllocWithZone，最后返回

问题

• callAlloc为什么会执行两次？后面章节来补充
• 在调试时发现下了三个符号断点_objc_rootAlloc、callAlloc、 _objc_rootAllocWithZone但执行_objc_rootAlloc后直接调用了_objc_rootAllocWithZone其中的callAlloc直接被跳过了 why?

编译器优化

首先通过一个案例来测试，打开汇编模式

通过汇编代码发现变量a和b的值10和20通过寄存器进行了存储用并调用了ydSum函数，（真机测试）为什么是w而不是x呢，arm64不应该是x吗？因为x代表64位，如果用一个64位的寄存器存储一个int值是非常浪费的，这是编译器低位兼容的优化

重新运行两次代码发现代码少了很多并且在最后一次发现ydSum没有了，编译器直接将结果算好了存储在w8里面了，这就是编译器的优化，同时验证了为什么callAlloc为什么被跳过的原因。

编译器的优化设置如下

alloc源码流程图

那alloc又做了什么呢？

打开objc底层源码文件，并在main.m主函数中创建YDPerson对象,YDPerson继承于NSObject，且不添加任何属性或成员变量，因为上面通过下符号断点推断出了callAlloc函数内的执行流程，在YDPerson初始化时打下断点，因为有了源码更方便调试，直接在callAlloc下断点并运行，最终会进入一个非常重要的函数_class_createInstanceFromZone

通过函数名也可发现这是创建一个实例对象的函数，那创建对象需要开辟多大的内存空间呢？我们一直说obj是关于某一个类的对象，那么创建出来的对象和类是怎么进行关联？进入函数_class_createInstanceFromZone

在函数内首先看到了第一个函数instanceSize，获取实例变量大小

函数会先判断是否有快速缓存实例变量大小，如果有则直接返回缓存中的实例变量的大小并且返回前做16字节对齐，如果没有则会进入到alignedInstancesize中，会执行下面的流程`alignedInstanceSize

word_align会将未经过对齐的实例变量大小即编译好的干净内存的实例变量的大小进行字节对齐，进入word_align，发现里面是一个算法 (x + WORD_MASK) & ~WORD_MASK，这是什么玩意？

案例中YDPerson是继承于NSObject，NSObject有一个Class 类型的成员变量isa，Class又是struct objc_class *类型，因为结构体指针为8字节，所以YDPerson的实例变量大小为8，那么为什么要(x + WORD_MASK) & ~WORD_MASK这样来一下呢？

由于__LP64__ 的WORD_MASK等于7，(x + WORD_MASK) & ~WORD_MASK就等同于 （8+7）& ～7即 15 & ～7换算成二进制0000 1111 & ～0000 0111等价于 0000 1111 & 1111 1000 等于 0000 1000 就等于8 ，也就是说成员变量之间的排序以8字节对齐，那么为什么要以8字节对齐而不是16、32呢？

假设对象内有三个成员变量8字节的name，4字节的age，1字节的sex，那么cpu在读取name时需要先以8字节的大小才能读取到name，读取age时又得改变成4字节，读取sex时又得改变成1字节，在读取时频繁的更改读取的字节数是非常消耗性能的，而在对象的成员变量中没有超过8字节的变量，那么通过8字节的对齐使得访问name是8字节，age也是8字节，sex也是8字节，这样读取时间就大大的缩短了，即通过时间换取空间，那age和sex都占8字节那不是很浪费内存吗？其实苹果在底层还做了内存的优化，通过下面的案例测试

可以发现sex和age共用了一个8字节，说明系统的确对内存进行了优化，那为什么从快速缓存获取实例变量的大小又需要16字节对齐呢？请看后面的篇章结构体的内存对齐

alloc扩展