iOS 底层拾遗：autorelease 优化

波儿菜

发布于 2019-12-23 19:04:39

1.3K0

发布于 2019-12-23 19:04:39

文章被收录于专栏：iOS技术

由于 ARC 下 retain/release/autorelease 的调用都是编译器代劳，所以需要使用编译后的代码进行分析，通常笔者选择 Xcode 自带的工具，它有一个优势是自动将一些符号地址改为符号名，并且可以选择 Running 或 Archiving 下的汇编代码，后者生成的代码往往是前者的优化版本。

本文基于 Runtime 750，arm64，Archiving 汇编代码。

先前置声明一个后文会用到的类：

@interface TestObject : NSObject <NSCopying>
@end
@implementation TestObject
+ (id)foo {
    return [NSObject new];
}
- (id)copyWithZone:(NSZone *)zone {
    return [NSObject new];
}
@end

一、alloc / new / copy / mutableCopy 方法

编写这样一段代码：

[[NSObject new] copy];

汇编代码为：

...
    adrp    x8, l_OBJC_CLASSLIST_REFERENCES_$_@PAGE
    ldr x0, [x8, l_OBJC_CLASSLIST_REFERENCES_$_@PAGEOFF]
    adrp    x8, l_OBJC_SELECTOR_REFERENCES_@PAGE
    ldr x1, [x8, l_OBJC_SELECTOR_REFERENCES_@PAGEOFF]
    bl  _objc_msgSend
    mov x19, x0
    adrp    x8, l_OBJC_SELECTOR_REFERENCES_.6@PAGE
    ldr x1, [x8, l_OBJC_SELECTOR_REFERENCES_.6@PAGEOFF]
    bl  _objc_msgSend
    bl  _objc_release
    mov x0, x19
    bl  _objc_release
...

...@PAGE / ...@PAGEOFF两句一起出现表示通过页基址+符号在页中偏移来计算地址。首先把NSObject类地址和new方法地址找到分别放入x0和x1，然后调用_objc_msgSend，调用完成后x0里面放的就是[NSObject new]得到的对象地址，所以后面直接找到copy方法调用。这一段基本分析后文不会再详细描述了。

由于new和copy将引用计数+2，其后调用了两次_objc_release，这很符合直觉，看起来编译器并未做什么优化。

尝试使用alloc和mutableCopy，得到几乎一致的结果，似乎就能得到只要是生成本类实例的方法都不会做优化的结论？ 并不能。

将上面的代码换成：

[[TestObject new] copy];

发现编译后的汇编代码仍然和上面的差不多，而此时TestObject的copy返回了另外类的实例，退一步讲，前面的NSObject的copy方法也并未实现，所以可以猜测：

编译器不是通过返回类型来判断的，而是通过简单的符号匹配，发现alloc/new/copy/mutableCopy符号就不做优化。

二、自定义带返回值的方法

写这样一句代码：

[TestObject foo];

汇编代码为：

...
    bl  _objc_msgSend
Ltmp9:
    mov x29, x29    ; marker for objc_retainAutoreleaseReturnValue
    bl  _objc_unsafeClaimAutoreleasedReturnValue
...

调用方的逻辑

调用_objc_msgSend前x0 -> TestObject, x1 -> foo，这里出现了一个不符合直觉的 C 函数_objc_unsafeClaimAutoreleasedReturnValue，光看名字猜不到具体是干嘛的，所以去掉 C 语言符号修饰_，直接查看源码：

id objc_unsafeClaimAutoreleasedReturnValue(id obj) {
    if (acceptOptimizedReturn() == ReturnAtPlus0) return obj;
    return objc_releaseAndReturn(obj);
}

objc_releaseAndReturn函数不展开，只需知道是真正的release操作。那么大家就奇怪了，理论上foo方法会把返回值先加入自动释放池，这里根本就不需要release，常理来说只有当这个acceptOptimizedReturn() == ReturnAtPlus0为 YES 不做release操作才与大家的意识契合。那么看一下这个关键方法：

enum ReturnDisposition : bool {
    ReturnAtPlus0 = false, ReturnAtPlus1 = true
};
static ALWAYS_INLINE ReturnDisposition acceptOptimizedReturn() {
    ReturnDisposition disposition = getReturnDisposition();
    setReturnDisposition(ReturnAtPlus0);  // reset to the unoptimized state
    return disposition;
}
static ALWAYS_INLINE ReturnDisposition getReturnDisposition() {
    return (ReturnDisposition)(uintptr_t)tls_get_direct(RETURN_DISPOSITION_KEY);
}
static ALWAYS_INLINE void setReturnDisposition(ReturnDisposition disposition) {
    tls_set_direct(RETURN_DISPOSITION_KEY, (void*)(uintptr_t)disposition);
}

看到最终是使用tls_get_direct(RETURN_DISPOSITION_KEY)取的 TLS（Thread Local Storage）里的值，取了后还把这个值变为false。看起来这里的代码非常简单，我们只需要关心是 何时把 TLS 对应的值变成true的。

被调用方的逻辑

由于刚才分析了，foo函数会将生成的对象放入自动释放池，这里理论上不需要release，直接分析汇编代码看是否有什么奇怪操作：

...
    bl  _objc_msgSend
    ldp x29, x30, [sp], #16
    b   _objc_autoreleaseReturnValue
...

发现调用了_objc_autoreleaseReturnValue函数，切到源码：

id objc_autoreleaseReturnValue(id obj) {
    if (prepareOptimizedReturn(ReturnAtPlus1)) return obj;
    return objc_autorelease(obj);
}
static ALWAYS_INLINE bool prepareOptimizedReturn(ReturnDisposition disposition) {
    assert(getReturnDisposition() == ReturnAtPlus0);
    if (callerAcceptsOptimizedReturn(__builtin_return_address(0))) {
        if (disposition) setReturnDisposition(disposition);
        return true;
    }
    return false;
}

objc_autorelease就是真正的autorelease操作，会将对象加入自动释放池。若if判断成功会调用了一个前面分析过的方法setReturnDisposition(...)将 TLS 对应 Key 的值设置为true，如果设置成功后将放弃autorelease操作。

核心逻辑分析

这里先考虑做了优化的情况。

重点分析： 若这里不进行autorelease，调用foo后生成的对象将不会被自动释放池管理，这个对象的引用计数为 1。那之前的objc_unsafeClaimAutoreleasedReturnValue(...)函数就需要进行release操作，[TestObject foo]生成对象的引用计数才能减为 0。对比前面分析完全符合，至此，形成了逻辑通路。

优化点： 这个场景少了一步autorelease，多了一步release，也就是省去了加入自动释放池的时间消耗、避免对象对自动释放池的内存占用。

另外一个场景，代码如下：

id obj = [TestObject foo];

汇编代码有些变化：

...
    bl  _objc_msgSend
    mov x29, x29    ; marker for objc_retainAutoreleaseReturnValue
    bl  _objc_retainAutoreleasedReturnValue
    bl  _objc_release
...

笔者只是加了一个临时变量持有这个返回值，直觉上会调用_objc_retain然后调用_objc_release，但先调用的是_objc_retainAutoreleasedReturnValue：

id objc_retainAutoreleasedReturnValue(id obj) {
    if (acceptOptimizedReturn() == ReturnAtPlus1) return obj;
    return objc_retain(obj);
}

foo方法若不会将创建的对象进行autorelease，那么这里也就不需要进行retain了，很好理解。

优化点： 这个场景少了一步autorelease，少了一步retain，优化效果就变得明显了。

如何判断 autorelease 是否需要优化？

看关键的一个判断：

if (callerAcceptsOptimizedReturn(__builtin_return_address(0))) ...

__builtin_return_address(n)拿到的是前第 n + 1 函数栈的lr (Link Register) ，那么这里就是拿到上一个栈的lr（函数在调用其它函数时会将下一句指令地址写入lr便于恢复执行），也就是前面的这句汇编代码（别疑惑函数栈这么深怎么会拿到第一个函数的lr，因为这些函数都是内联的）：

mov x29, x29    ; marker for objc_retainAutoreleaseReturnValue

看起来这句代码什么也没做，先看一下这个判断函数：

static ALWAYS_INLINE bool callerAcceptsOptimizedReturn(const void *ra) {
    // fd 03 1d aa    mov fp, fp
    // arm64 instructions are well-aligned
    if (*(uint32_t *)ra == 0xaa1d03fd) {
        return true;
    }
    return false;
}

这个函数就是将ra指向的值和0xaa1d03fd对比，若相等就执行优化。注释已经比较明白了，这个值就是mov fp, fp的十六进制表示（注意 iOS 是小端）。

那么只要被调用方拿到调用方的lr判断就行了，所以是否进行这个优化的决定权在调用方手中。

MRC 模式下是否开启了优化

将代码设置为-fno-objc-arc，随便写些代码查看汇编，发现编译器并不会将开发者显式写的objc_autorelease/objc_retain/objc_release函数强制改为objc_autoreleaseReturnValue等方法，且 MRC 下编译的代码在调用方法时不会加入mov fp fp企图优化（推理也可知，因为retain/release操作是不能优化的）。

objc_retain/objc_release就是直接进行引用计数加减，而objc_autorelease在OBJC2上的定义却有所变化：

__attribute__((aligned(16))) id objc_autorelease(id obj) {
    if (!obj) return obj;
    if (obj->isTaggedPointer()) return obj;
    return obj->autorelease();
}
inline id objc_object::autorelease() {
    if (isTaggedPointer()) return (id)this;
    if (fastpath(!ISA()->hasCustomRR())) return rootAutorelease();
    return ((id(*)(objc_object *, SEL))objc_msgSend)(this, SEL_autorelease);
}
objc_object::rootAutorelease() {
    if (isTaggedPointer()) return (id)this;
    if (prepareOptimizedReturn(ReturnAtPlus1)) return (id)this;
    return rootAutorelease2();
}

若当前类没有自定义的retain/release方法实现时，最终仍然会调用prepareOptimizedReturn(ReturnAtPlus1)进行优化，所以当调用方是 ARC，被调用方是 MRC 时这个优化仍然有效。