二 OC底层原理 探究 OC 对象创建过程

前言

在 iOS 的开发中使用的 Objective C 语言，它是一种面向对象的语言，但是对象是怎么产生吗，怎么被创建的呢？ 下面我们就来看看

对象的创建

在 OC 中，我们创建对象 一般有两种方法

  • [[class alloc] ] init]
  • [class new]

先看个案例

我们先定一个 Object 的类

@interface TObject : NSObject

@end

@implementation TObject

@end

案例

    TObject *ob = [TObject alloc];
    TObject * oba = [TObject alloc];
    TObject * ob1 = [ob init];
    TObject * ob2 = [ob1 init];
    
    NSLog(@"%p -- %p",ob,&ob);
    NSLog(@"%p -- %p",ob1,&ob1);
    NSLog(@"%p -- %p",ob2,&ob2);
    NSLog(@"%p -- %p",oba,&oba);
======= 输出结果如下======
2020-12-05 23:04:23.493569+0800 OC[2258:77272] 0x600003c80290 -- 0x7ffee9ee01a8
2020-12-05 23:04:23.493781+0800 OC[2258:77272] 0x600003c80290 -- 0x7ffee9ee01a0
2020-12-05 23:04:23.493918+0800 OC[2258:77272] 0x600003c80290 -- 0x7ffee9ee0198
2020-12-05 23:04:23.494045+0800 OC[2258:77272] 0x600003c8c8e0 -- 0x7ffee9ee0190

从案例可以看出，三者对象地址相同，说明是同一个对象，但是对象指针地址又不一样，为什么会这样呢？alloc 和 init 到底做了什么呢？

带着疑问 我们接下来探究

我们先看看 alloc init 是如何创建的

1. alloc 源码探索

通过断点 汇编调试， callq汇编指令 也就是调用函数的意思

  1. 可以看见第一步调用了 objc_alloc 函数

    image.png

  2. 接着调用了 alloc

    image.png

  3. 调用 objc_rootAlloc

image.png
  1. 调用了 _objc_rootAllocWithZone

相关源码展示

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


static ALWAYS_INLINE id
callAlloc(Class cls, bool checkNil, bool allocWithZone=false)
{
#if __OBJC2__
    if (slowpath(checkNil && !cls)) return nil;
    // 当类指针存在并实现了 allocWithZone 就不会走这里的代码
    if (fastpath(!cls->ISA()->hasCustomAWZ())) {
        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)alloc {
    return _objc_rootAlloc(self);
}

_objc_rootAlloc(Class cls)
{
    return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/);
}
// Replaced by ObjectAlloc
+ (id)allocWithZone:(struct _NSZone *)zone {
    return _objc_rootAllocWithZone(self, (malloc_zone_t *)zone);
}
_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);
}



 // 这个方法表示 当类或者父类有自定义的 alloc/allocWithZone 方法时 返回 false 否则 返回 true
bool hasCustomAWZ() const {
// FAST_CACHE_HAS_DEFAULT_AWZ:
//class or superclass has default alloc/allocWithZone: implementation
        return !cache.getBit(FAST_CACHE_HAS_DEFAULT_AWZ);
   }

#define fastpath(x) (__builtin_expect(bool(x), 1))
#define slowpath(x) (__builtin_expect(bool(x), 0))
两者都是指令优化编译器编译时的代码布局
fastpath 很有可能为 true，slowpath表示很有可能为 false

顺序分为两种情况

当该类第一次被使用的时候
objc_alloc -> callAlloc(cls,true,false)
在 callAlloc 方法中 由于cls 还没有 指针 isa，当然也就没有所谓的 allocWithZone 方法了
所以调用了objc_msgSend(cls, @selector(alloc));
alloc -> callAlloc(cls, false, true) 

objc_alloc-> callAlloc(cls,true,false) 

未实现allocWithZone 方法时,就会运行 fastpath(!cls->ISA()->hasCustomAWZ()) 中的代码
这是的顺序就是
objc_alloc->callAlloc(cls,true,false)->_objc_rootAllocWithZone

实现的话
objc_alloc->callAlloc(cls,true,false)->allocWithZone -> _objc_rootAllocWithZone(self, (malloc_zone_t *)zone);

解析一下 _class_createInstanceFromZone

到底做了什么




/***********************************************************************
* class_createInstance
* fixme
* Locking: none
*
* Note: this function has been carefully written so that the fastpath
* takes no branch.
**********************************************************************/
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
    // 判断当前 Class 或者 superClass 是否有 cxxConstruct 构造方法的实现
    bool hasCxxCtor = cxxConstruct && cls->hasCxxCtor();
    // 判断当前 Class 或者 superClass 是否有 destruct 构造方法的实现
    bool hasCxxDtor = cls->hasCxxDtor();
    bool fast = cls->canAllocNonpointer();
    size_t size;
    // 计算对象内存大小
    size = cls->instanceSize(extraBytes);
    // 额外的空间
    if (outAllocatedSize) *outAllocatedSize = size;
    // 开辟内存空间
    id obj;
    //  zone 永远都是 false
    if (zone) {
        obj = (id)malloc_zone_calloc((malloc_zone_t *)zone, 1, size);
    } else {
        obj = (id)calloc(1, size);
    }
    // false
    if (slowpath(!obj)) {
        if (construct_flags & OBJECT_CONSTRUCT_CALL_BADALLOC) {
            return _objc_callBadAllocHandler(cls);
        }
        return nil;
    }

    if (!zone && fast) {
        // 到这里     初始化 isa, 关联 cls
        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)是进行内存对齐得到的实例大小

    size_t instanceSize(size_t extraBytes) const {
        if (fastpath(cache.hasFastInstanceSize(extraBytes))) {
            return cache.fastInstanceSize(extraBytes);
        }

        size_t size = alignedInstanceSize() + extraBytes;
        // CF requires all objects be at least 16 bytes.
        if (size < 16) size = 16;
        return size;
    }
   // May be unaligned depending on class's ivars.
    uint32_t unalignedInstanceSize() const {
        ASSERT(isRealized());
        return data()->ro()->instanceSize;
    }

    // Class's ivar size rounded up to a pointer-size boundary.
    uint32_t alignedInstanceSize() const {
        return word_align(unalignedInstanceSize());
    }

static inline uint32_t word_align(uint32_t x) {
    return (x + WORD_MASK) & ~WORD_MASK;
}
#ifdef __LP64__
#   define WORD_SHIFT 3UL
#   define WORD_MASK 7UL
#   define WORD_BITS 64
#else
#   define WORD_SHIFT 2UL
#   define WORD_MASK 3UL
#   define WORD_BITS 32
#endif

由于 TObject 对象中没有任何属性,所以 extraBytes 是为0的,但是内存空间并不是0，因为 TObject 还有一个 isa 指针

@interface NSObject <NSObject> {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wobjc-interface-ivars"
    Class isa  OBJC_ISA_AVAILABILITY;
#pragma clang diagnostic pop
}

通过计算可以得知，有一个对象指针，这个大小是8字节，所以到word_align 方法中 x 就是8，其中WORD_MASK在64位系统下是7，否则是3，因此，word_align()方法在64位系统下进行计算是8字节对齐按照里面的算法就是相当于8的倍数。返回到instanceSize()方法中的size就是对象需要的空间大小为8，因为里面有小于16的返回16。

所以 按照现在的算法 经过instanceSize 计算，内存最小是16，内存是8的倍数
-- 具体的下一篇详细探索

init 解析

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

没有任何操作 就是返回它本身的
可能是设计原则的关系，这样设计 方便开发者更好的自定义吧，可以在其中初始化一些设置

new 解析

可见 new 就是 callAlloc 和 init 方法的结合

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

问题

  • 通过源码定义 jumpDefinition 时，alloc 应该是直接调用类方法 alloc 函数的，为什么会调用 objc_alloc 呢?

可能:

static void 
fixupMessageRef(message_ref_t *msg)
{    
   msg->sel = sel_registerName((const char *)msg->sel);

   if (msg->imp == &objc_msgSend_fixup) { 
// 当改方法的方法编号时 alloc 时，将方法函数实现 指向了 objc_alloc
       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;
   }

最后 附上一张初始化流程图

image.png
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 214,588评论 6赞 496
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 91,456评论 3赞 389
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 160,146评论 0赞 350
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 57,387评论 1赞 288
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 66,481评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 50,510评论 1赞 293
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,522评论 3赞 414
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,296评论 0赞 270
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,745评论 1赞 307
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,039评论 2赞 330
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,202评论 1赞 343
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,901评论 5赞 338
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,538评论 3赞 322
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,165评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,415评论 1赞 268
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,081评论 2赞 365
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,085评论 2赞 352

推荐阅读更多精彩内容