alloc探究

作者: 镜像 | 来源:发表于2021-06-13 21:33 被阅读0次

关于alloc后指针内存

首先，我们先创建3个不同指针，并且打印他们的内存地址

SJPerson *p1 = [SJPerson alloc];
SJPerson *p2 = [p1 init];
SJPerson *p3 = [p1 init];

NSLog(@"%@  -  %p  -  %p", p1, p1, &p1);
NSLog(@"%@  -  %p  -  %p", p2, p2, &p2);
NSLog(@"%@  -  %p  -  %p", p3, p3, &p3);

打印结果如下：

alloc探究[7204:137646] <SJPerson: 0x6000017d8420>  -  0x6000017d8420  -  0x7ffee8df9088
alloc探究[7204:137646] <SJPerson: 0x6000017d8420>  -  0x6000017d8420  -  0x7ffee8df9080
alloc探究[7204:137646] <SJPerson: 0x6000017d8420>  -  0x6000017d8420  -  0x7ffee8df9078

我们发现，三个指针前两个打印内容一样，最后一个不一样。
第一个执行description方法打印指针指向内存地址，第二个直接打印指针指向内存地址，第三个打印指针的内存地址。也就是说，上述代码创建了3个指针，这三个指针指向同一内存区域。

苹果源码

alloc底层如何执行

如果想查看alloc底层执行哪些方法，有三种方法可以查看

添加符号断点

image

再运行，如下图

image

这时候会发现代码执行到libobjc.A.dylib这个库里面的_objc_rootAlloc方法，我们可以去找苹果开源对应库的代码查看即可

按住ctrl+step into
打断点运行程序，执行到断点位置时，按住ctrl点击如图位置

image

会跳转到汇编代码

image

这时添加符号断点

image

根据汇编查看流程
走到断点位置时，显示汇编，勾选always show disassembly

image

根据汇编添加符号断点

image

这三种方法都可以根据汇编查看alloc底层执行哪些方法，但是通过汇编查看非常难懂，所以还是通过源码查看比较好理解。

根据源码查看alloc底层实现

打开源码，找到alloc方法

执行_objc_rootAlloc()方法

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

诶？我们好像找到了alloc执行的方法？非常开心，但是大坑随之而来，如果我们打个断点并且进入汇编代码，就会发现汇编显示的和我们预想的不太一样。

image

如果看源码，我们得到alloc的流程应该是alloc -> _objc_rootAlloc -> callAlloc -> _objc_rootAllocWithZone.......
根据汇编内容我们发现alloc执行的是objc_alloc，并不是源码里面的_objc_rootAlloc(self)。是不是哪有问题？
第一，我们从源码找一些端倪。
程序运行都会走_read_images方法加载镜像文件。

image
这里面有个方法

image

/***********************************************************************
* fixupMessageRef
* Repairs an old vtable dispatch call site. 
* vtable dispatch itself is not supported.
**********************************************************************/
static void 
fixupMessageRef(message_ref_t *msg)
{    
    msg->sel = sel_registerName((const char *)msg->sel);

    if (msg->imp == &objc_msgSend_fixup) { 
        if (msg->sel == @selector(alloc)) {
            msg->imp = (IMP)&objc_alloc;
        } else if (msg->sel == @selector(allocWithZone:)) {
            msg->imp = (IMP)&objc_allocWithZone;
        } else if (msg->sel == @selector(retain)) {
            msg->imp = (IMP)&objc_retain;
        } else if (msg->sel == @selector(release)) {
            msg->imp = (IMP)&objc_release;
        } else if (msg->sel == @selector(autorelease)) {
            msg->imp = (IMP)&objc_autorelease;
        } else {
            msg->imp = &objc_msgSend_fixedup;
        }
    } 
    else if (msg->imp == &objc_msgSendSuper2_fixup) { 
        msg->imp = &objc_msgSendSuper2_fixedup;
    } 
    else if (msg->imp == &objc_msgSend_stret_fixup) { 
        msg->imp = &objc_msgSend_stret_fixedup;
    } 
    else if (msg->imp == &objc_msgSendSuper2_stret_fixup) { 
        msg->imp = &objc_msgSendSuper2_stret_fixedup;
    } 
#if defined(__i386__)  ||  defined(__x86_64__)
    else if (msg->imp == &objc_msgSend_fpret_fixup) { 
        msg->imp = &objc_msgSend_fpret_fixedup;
    } 
#endif
#if defined(__x86_64__)
    else if (msg->imp == &objc_msgSend_fp2ret_fixup) { 
        msg->imp = &objc_msgSend_fp2ret_fixedup;
    } 
#endif
}

这里进行imp的重新赋值，发现如果selector是alloc，imp直接绑定到objc_alloc，这里虽然是修复，但是如果一开始方法绑定没有问题，不走这个修复逻辑，应该也会走objc_alloc。这就说明了为什么一开始会走objc_alloc方法而不是runtime里面的_objc_rootAlloc。
第二，上面只是说明有问题走修复时会走到objc_alloc，那么不走修复时一定会执行objc_alloc吗，我们现在就进行验证。
在_read_images之前，会执行dyld，我们从github上下载llvm源码进行查看。
在llvm源码中，我们可以看到我们OC消息机制都会走下面这个方法

image

CodeGen::RValue CGObjCRuntime::GeneratePossiblySpecializedMessageSend(
    CodeGenFunction &CGF, ReturnValueSlot Return, QualType ResultType,
    Selector Sel, llvm::Value *Receiver, const CallArgList &Args,
    const ObjCInterfaceDecl *OID, const ObjCMethodDecl *Method,
    bool isClassMessage) {
/// 先有个判断，第一次会走到if里面，第二次再进来`SpecializedResult`是NO就会走到下面走正常的消息流程
  if (Optional<llvm::Value *> SpecializedResult =
          tryGenerateSpecializedMessageSend(CGF, ResultType, Receiver, Args,
                                            Sel, Method, isClassMessage)) {
    return RValue::get(SpecializedResult.getValue());
  }
/// 正常的消息机制
  return GenerateMessageSend(CGF, Return, ResultType, Sel, Receiver, Args, OID,
                             Method);
}

image

tryGenerateSpecializedMessageSend方法有个非常重要的case就是OMF_alloc，也就是说，当这个方法是alloc时，会有特殊处理。

llvm::Value *CodeGenFunction::EmitObjCAlloc(llvm::Value *value,
                                            llvm::Type *resultType) {
  return emitObjCValueOperation(*this, value, resultType,
                                CGM.getObjCEntrypoints().objc_alloc,
                                "objc_alloc");
}

再下一步方法会走到objc_alloc方法，完美证明。
总结一下，就是苹果觉得alloc方法非常重要，所有对象要使用都要创建，所以在这个非常重要的方法执行的时候插了个桩，做了一些特殊处理，这些特殊处理，处理完后又发了objc_msgSend(receiver, @selector(alloc))，这时候已经做过标记的receiver会直接走alloc流程，这也是callalloc为什么会走两次的原因。

执行callAlloc()方法

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

核心代码

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())) {    /// 第一次if里面不会执行，会直接走最后的msgSend
        return _objc_rootAllocWithZone(cls, nil);   // 申请内存空间
    }
#endif

    // No shortcuts available.
    if (allocWithZone) {
        return ((id(*)(id, SEL, struct _NSZone *))objc_msgSend)(cls, @selector(allocWithZone:), nil);
    }
    return ((id(*)(id, SEL))objc_msgSend)(cls, @selector(alloc));
}

申请内存空间

id
_objc_rootAllocWithZone(Class cls, malloc_zone_t *zone __unused)
{
    // allocWithZone under __OBJC2__ ignores the zone parameter
    return _class_createInstanceFromZone(cls, 0, nil,
                                         OBJECT_CONSTRUCT_CALL_BADALLOC);
}

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());

    // Read class's info bits all at once for performance
    bool hasCxxCtor = cxxConstruct && cls->hasCxxCtor();
    bool hasCxxDtor = cls->hasCxxDtor();
    bool fast = cls->canAllocNonpointer();
    size_t size;

// 1. 开辟内存大小
    size = cls->instanceSize(extraBytes);
    if (outAllocatedSize) *outAllocatedSize = size;

    id obj;
    // 现在苹果已经废弃zone，所以zone的流程不用关心，早期是通过zone的内存申请出来的
    if (zone) {
        obj = (id)malloc_zone_calloc((malloc_zone_t *)zone, 1, size);
    } else {
// 2. 申请内存
        obj = (id)calloc(1, size);
    }
    if (slowpath(!obj)) {
        if (construct_flags & OBJECT_CONSTRUCT_CALL_BADALLOC) {
            return _objc_callBadAllocHandler(cls);
        }
        return nil;
    }

    if (!zone && fast) {
// 3. 将当前的类和指针地址进行绑定
        obj->initInstanceIsa(cls, hasCxxDtor);
    } else {
        // Use raw pointer isa on the assumption that they might be
        // doing something weird with the zone or RR.
        obj->initIsa(cls);
    }

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

    construct_flags |= OBJECT_CONSTRUCT_FREE_ONFAILURE;
    return object_cxxConstructFromClass(obj, cls, construct_flags);
}

这里分三步：

cls->instanceSize(extraBytes) 计算申请空间的大小
obj = (id)calloc(1, size); 开辟内存空间
obj->initInstanceIsa(cls, hasCxxDtor); 绑定到相应的类

至此，alloc执行完毕，里面具体细节同学可以进去自己看一下，总结下alloc流程图如下：

alloc.jpg

init 与 new

从上面分析我们知道，alloc就已经开辟内存创建对象了，为什么还需要initn呢。从源码中看init到底执行了什么：

+ (id)init {
    return (id)self;
}

- (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;
}

类方法和实例方法init最后都是返回self，那这不是多此一举吗。
这就是构造方法，工厂设计，说白了这个方法其实是给用户提供入口的。

再看下new的底层实现：

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

这里面执行了callAlloc，callAlloc就是alloc的流程，也就是说new等价于[[X alloc] init]。
使用new可以快速创建一个对象，但是不推荐使用，因为我们可能会重写init方法，这时再使用new可能得不到我们想要的结果了。

LLDB 调试命令含义

lldb

alloc探究

关于alloc后指针内存

苹果源码

alloc底层如何执行

根据源码查看alloc底层实现

init 与 new

LLDB 调试命令含义

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读