关于 strong、weak、unsafe_unretained 性能测试

最近在看某些博客和文章的时候,有谈到对于这几个修饰符选择的话题,突然想对这几个修饰符做一下性能测试,关于这几个修饰符的用法我列了一张表简单介绍一下,本次我们关注的重点是性能对比

修饰符 使用场景 备注
__weak 避免循环引用 不对对象进行retain,变量销毁时指针变nil,比如block、代理等地方使用
__strong 防止变量被释放 实际上进行retain操作,retainCount + 1,OC默认方式
__unsafe_unretained 避免循环引用 不对对象进行retain,变量销毁时指针仍然指向原来的空间,危险性较高,通常情况下不建议使用

1、先来看一组测试

- (void)viewDidLoad {
    [super viewDidLoad];

    NSObject *obj = [NSObject new];
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    [self test1:obj];
}
- (void)test1:(NSObject *)obj {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    [self test2:obj];
}
- (void)test2:(NSObject *)obj {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test1(obj);
}
void test1(NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test2(obj);
}
void test2(NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test3(obj);
}
void test3(NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test4(obj);
}
void test4(NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
}

打印结果

1
2
3
4
5
6
7

可以看出,在oc中,默认情况下,NSObject *obj实际上等效于__strong NSObject *obj,每个指针会对接收的变量进行一次ratain操作,正如我上边的测试用例,会发现只要将obj传入方法,方法就会默认对传入的参数进行一次retain导致objretainCount一直在向上叠加,当然这个测试存在一个方法栈叠加的过程,如果调用过程中方法结束,会自动对内部变量(被retain过的)进行一次release,而且我们发现无论是OC方法还是C方法,在ARC环境下表现一致

这样做的目的是为了在当前方法栈内,形参obj被保持生命,通常情况下oc的方法基本都是这种实现方式,不过当我在研究一些第三方框架的时候发现了__unsafe_unretained,我们知道__unsafe_unretained功能上基本等效于__weak,但是某些框架为什么要用以及我们在开发中怎么选中呢?

为了回到这个问题,我们先经过一段漫长的测试:oops

如果在上述方法中将形参加上__weak或者__unsafe_unretained后,什么表现呢

- (void)viewDidLoad {
    [super viewDidLoad];

    NSObject *obj = [NSObject new];
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    [self test1:obj];
}
- (void)test1:(__weak NSObject *)obj {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    [self test2:obj];
}
- (void)test2:(__weak NSObject *)obj {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test1(obj);
}
void test1(__weak NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test2(obj);
}
void test2(__weak NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test3(obj);
}
void test3(__weak NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test4(obj);
}
void test4(__weak NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
}

打印

1
2
3
4
5
6
7

发现__weak的ratainCount表现和上边一致,不过__weak表面上增加了引用计数,实质上这些从__weak而来的计数是虚的,不会对对象的生命周期产生任何印象,可以理解为 虚指针弱指针

我们再试试__unsafe_unretained

- (void)viewDidLoad {
    [super viewDidLoad];

    NSObject *obj = [NSObject new];
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    [self test1:obj];
}
- (void)test1:(__unsafe_unretained NSObject *)obj {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    [self test2:obj];
}
- (void)test2:(__unsafe_unretained NSObject *)obj {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test1(obj);
}
void test1(__unsafe_unretained NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test2(obj);
}
void test2(__unsafe_unretained NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test3(obj);
}
void test3(__unsafe_unretained NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
    test4(obj);
}
void test4(__unsafe_unretained NSObject *obj) {
    NSLog(@"%ld", (long)CFGetRetainCount((__bridge CFTypeRef)(obj)));
}
1
1
1
1
1
1
1

发现__unsafe_unretained修饰的变量,不会导致其引用计数发生变化。由此我们知道__weak肯定是比__unsafe_unretained多做了一些事,具体多做了什么,我们稍后讨论

2、再看一组测试

我们定义两个方法,第一个用__weak,第二个用__unsafe_unretained,我们在这两个方法中均延迟1s再去访问obj变量

- (void)viewDidLoad {
    [super viewDidLoad];

    NSObject *obj = [NSObject new];
    [self test1:obj];
    [self test2:obj];
}

- (void)test1:(__weak NSObject *)obj {
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        // 这里打印出obj:null
        NSLog(@"obj:%@", obj);
    });
}

- (void)test2:(__unsafe_unretained NSObject *)obj {
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        // 这里打跑出异常:Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
        NSLog(@"obj:%@", obj);
    });
}

以上测试中,由于viewDidLoad方法执行完毕后,函数栈销毁,obj释放,由于test1:中是弱指针,对变量生命周期无影响,变量销毁__weak指针会自动置为nil,所以1s之后去访问到的值自然是null

test2:方法中,没有引用计数的变化,对obj的生命周期也没有影响,obj也会释放,但是__unsafe_unretained指向的对象销毁后,该指针不会清空,仍然指向已经被释放的空间,所以当我们1s之后去访问时,发现访问到的是已经被释放的空间,系统跑出异常EXC_BAD_INSTRUCTION

综上可以粗略的得出一个结论,就是通常开发中我们应该使用__weak而不是__unsafe_unretained,相对来说,__weak比较安全,不会因为对象释放给我们带来野指针隐患,但这并不是说__unsafe_unretained就没有用武之地,我们继续往下看

3、对比性能

我这里使用分别使用三种修饰符修饰指针变量,run下面案例,由于是空方法,为了表现出差异,我将循环次数加到10000000次

- (void)viewDidLoad {
    [super viewDidLoad];

    NSObject *obj = [NSObject new];
    CFTimeInterval time = CFAbsoluteTimeGetCurrent();
    for (int i = 0; i < 10000000; i++) {
        [self test1:obj];
    }
    NSLog(@"%f", CFAbsoluteTimeGetCurrent() - time); 
}
- (void)test1:(NSObject *)obj { } // 0.580411
- (void)test1:(__weak NSObject *)obj { } // 0.826589
- (void)test1:(__unsafe_unretained NSObject *)obj { } // 0.051507

可以看出,__unsafe_unretained虽然不安全,但其性能比__strong__weak高了一个数量级,这就是为什么有些框架仍然使用它的原因

为什么__weak性能损耗是三个中最大的一个,这里主要是__weak有一个操作weak表的过程,其中包括objc_loadWeak()、objc_storeWeak()等操作,因此性能损耗较大

其次性能__strong也有较大的开销,主要是对变量的retainrelease等操作

__unsafe_unretained除了赋值操作外,基本没有别的副作用,因此会带来较高性能

综上,我们可以得出以下几点结论结论

  • 性能上:__unsafe_unretained > __strong > __weak

  • 通常情况下我们不需要考虑__strong,它是默认的方式,除非我们有主动保留变量生命周期的打算,比如block内部使用__strong变量等

  • 普通开发中,一般使用__weak即可,但若有对性能比较敏感的地方,可以考虑使用__unsafe_unretained,比如我们存在瞬间大量的函数调用又或者是大量隐含多余的retain、release操作的地方

  • __unsafe_unretained需要时刻注意所修饰变量的生命周期,一般在我们能保证某个变量在其被使用期间不会被释放的时候,可以考虑使用以换取性能的提升

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,362评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,330评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,247评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,560评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,580评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,569评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,929评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,587评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,840评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,596评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,678评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,366评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,945评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,929评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,165评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,271评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,403评论 2 342