Inside ARC — to see the code inserted by the compiler
前言
这是我在我们技术团队所做的一次分享，稍作改动放到博客上来。
我们技术团队会不定期（一般一个月1~2次）做技术分享，对我们团队有兴趣的能够私信我。
下面是正文。
这里的主题是“Inside ARC”，顾名思义。主要是探讨ARC在我们看不见的地方为我们做了什么事情。以及怎么做的。出发点是对底层实现的兴趣，不了解这些也最好还是碍写好代码。了解一点应该故意。
下面一些内容參考自Apple的官方文档《Transitioning to ARC Release Notes》或维基百科。兴许不再一一说明。
首先要明白的是ARC并非GC。仅仅是把之前由程序猿手工管理内存（如retain/release）的事情交给编译器来处理，即编译器为程序猿在合适的时机插入一些内存管理代码。
比較例外的是weak特性，除了编译器外，还须要runtime的支持。这直接体如今OS X 10.7和iOS 5之后，才支持完整的ARC特性，包含弱引用的支持（为什么弱引用须要runtime支持？）。
利用Xcode提供的汇编功能（Product - Perform Action - Assemble “filename”）。我们能够初步了解（或猜測）编译器为我们加入的代码。
只是我们看到的是AT&T汇编代码。一片的数据在寄存器之间流动，不是非常利于分析。
所以我们能够“在一个ARC项目中针对部分文件不採取ARC编译”，比方针对“ARCObject.m”採用ARC方式编译，而针对“nonARCObject.m”不採取ARC方式编译。用来作比較。
栈上的变量默认初始化为nil
在ARC的编译条件下。strong、weak和autoreleasing三种栈上的变量会被默认初始化为nil。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvamFzb25ibG9n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">（图-2）
如上两张代码片段，图-1的nonARCObject是不採用ARC编译的。图-2的ARCObject则採用ARC进行编译。于是图-2的obj会被初始化为nil，图-1的则不会。
我们能够简单地用if-else语句再加上一些日志输出来推断是否真的初始化为nil，也能够通过汇编后的代码来观察，以便于由浅入深地探讨兴许内容。
图-4是相应于图-1的汇编代码片段，从25行的“-[ARCObject testFunc]”能够看出；而图-5则相应图-2的汇编代码片段。
两者显著的区别在于图-4的L50-L51相应于“ARCObject.m:15:0”。这里的一行汇编代码“movl $0, -16(%ebp)”目測做的是初始化obj为nil的工作。应该是将马上数0放到基址指针偏移-16的地方去。
我们能够再添加一个变量来验证下：
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvamFzb25ibG9n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">（图-6）
此时的汇编代码关键片段例如以下：
由此能够验证编译器为我们插入了初始化为nil的代码。
保证变量的释放，不会有内存泄露
ARC的一个主要作用就是会帮我们合理释放内存。避免内存泄露。
为了看下编译器是怎么做的，我们在既有代码上添加内存的分配：
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvamFzb25ibG9n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">（图-9）
在非ARC的情况下。图-8的代码片段为obj分配了内存但没有释放，存在内存泄露。
在图-9中。尽管代码一模一样，但在ARC模式下，编译器会为我们释放obj对象。
图-10和图-11都有两次objc_msgSend的出现，相应于内存的分配和初始化：
NSObject *obj = objc_msgSend(NSObject, @selector(alloc));
objc_msgSend(obj, @selector(init));
不同的是相应于源码的L16，即表示作用域结束的花括号，图-10是简单的return出去，而图-11多做了一次objc_storeStrong。
參考Clang的ARC文档。objc_storeStrong的代码例如以下：
idobjc_storeStrong(id*object,id
value) {
value=
[value retain];
id
oldValue=*object;
*object=
value;
[oldValue release];
return
value;
}
即在retain新值的同一时候释放旧值。
从图-11能够猜測出。在出作用域时，应该是运行了“objc_storeStrong(obj, nil)”。
我们能够对代码稍作改动进一步验证：
相应的汇编片段例如以下：
图-13中的关键变化有：
相应于图-12中的L17，这里的赋值语句包括了一次objc_retain，这是因为默觉得__strong类型。强引用产生的全部权须要对引用计数+1。
相应于图-12中的L19，因为此时显式指定了__unsafe_unretained类型，不具有全部权，所以仅仅是简单的指针赋值；
相应于图-12中的L20，此时出作用域，调用了两次objc_storeStrong进行释放。
所以，对象分配、赋值产生的引用计数变化，以及出作用域时对象的释放。都得到了验证。
命名风格决定的对象全部权
在我们还没全然迁移到ARC的时候。我们拟定的编码规范中提到了——这时候我去翻阅了下发现居然没有！尽管我印象中非常深刻地有这么一条。可能是在群里有说
在非ARC的时候我们约定，以alloc/new等词开头的方法应该返回对象的全部权，即无需增加自己主动释放池。
在ARC的时候。编译器就是这么做的。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvamFzb25ibG9n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">（图-14）
在非ARC的情况下，这两个函数的汇编代码是一样的。但在ARC的情况下则不然：
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvamFzb25ibG9n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">（图-15）
如图-15，“testObj”方法在为obj分配内存并初始化后，调用了一次objc_retain对引用计数+1，在出作用域时调用objc_storeStrong释放了一次。最后调用objc_autoreleaseReturnValue将对象增加自己主动释放池。所以对于返回出去的testObj。外部默认是没有全部权的。
而对于图-16。即“newTestObj”方法，最后并没有调用objc_autoreleaseReturnValue，由于编译器依据方法名前缀“new”推断出此时返回的对象，外部应该拥有全部权。
那么。是否返回对象全部权有什么差别呢？
如图-17。分别调用“testObj”和“newTestObj”。相应的汇编片段例如以下：
对于图-17中的L15，编译器添加了objc_retainAutoreleasedReturnValue，然后马上调用objc_release进行释放。
而对于图-17中的L17。编译器直接调用objc_release进行释放。
这能够依据方法名来进行决策。
自己主动释放池
上面讨论了__strong（默认）和__unsafe_unretained，接着先讨论__autoreleasing。再讨论__weak。
能够看出，对于__autoreleasing变量，编译器会自己主动调用objc_autorelease，将对象加入到最内层的自己主动释放池中。
而假设加入了@autorelease_pool代码块，编译器还会添加一对调用。各自是objc_autoreleasePoolPush和objc_autoreleasePoolPop，前者创建一个新的自己主动释放池作为当前自己主动释放池。而后者将之前注冊的对象一一释放。并将上一层自己主动释放池设为当前释放池。
弱引用
因为ARC并非GC，所以没办法检測出循环引用并消除，所以提供了__weak弱引用机制来解决问题。
__weak通经常使用于两个互相引用的对象的当中一方，比方delegate。
另外。使用__weak訪问对象时会将对象增加到自己主动释放池中，避免由于没有强引用被马上释放，导致兴许代码逻辑出错。
这里出现了objc_initWeak和objc_destroyWeak两个调用，代码实现分别例如以下：
idobjc_initWeak(id*object,id
value) {
*object=nil;
return
objc_storeWeak(object, value);
}
voidobjc_destroyWeak(id*object)
{
objc_storeWeak(object,nil);
}
objc_storeWeak的函数原型为“id objc_storeWeak(id *object, id value);”，它的作用是：
当value为nil时，或者object指向的对象開始析构时。object会被置为nil。而且从weak table中移除。
当value不为nil时，object会被注冊到weak table中。
这里能够插一下上次我和子通讨论的break retain-cycle的问题，跟__weak、retain-cycle和dealloc都有关。
析构
以图-21中的L16为例。考虑到可能有多个__weak指针指向obj对象，在obj对象析构时须要将这些__weak指针所有置为nil。那么weak table将维护着以obj对象地址为key的表项，该项的值应该是一个数组，维护着多个指向obj对象的__weak指针。
当obj对象被销毁时。以obj对象地址为key去weak table寻找相应的表项进行操作并移除。
之前和慕华讨论过在ARC模式下，不须要在dealloc中释放成员变量。当时有个点是runtime在何时为我们释放成员变量，依据Clang的文档（ARC下的dealloc）能够得知成员变量的销毁是在dealloc之后。
当然，这并不意味着不须要写“dealloc”方法。
假设我们在dealloc方法中设置断点进行调试，那么我们会发现有个方法名叫“.cxx_destruct”，这里有篇文章对其进行探究。
參考Apple的开源文件，当一个对象的引用计数变为0时。会调用dealloc。接着是_objc_rootDealloc
- object_dispose - objc_destructInstance - objc_clear_deallocating，在最后一个调用中清理weak table。
关于block
我之前有分享过一个主题叫《iOS中block实现的探究》，当中谈到依据内存位置区分，block能够分为三种，各自是_NSConcreteGlobalStack、_NSConcreteStackBlock和_NSConcreteMallocBlock，相应着全局、栈和堆三种不同的内存位置。
在非ARC的情况下，我们在传递block对象时须要使用Block_copy进行拷贝，而不能仅仅是使用strong属性做强引用。由于当栈展开后，指向的block对象就不在了，我们须要提前将其复制到堆上。
而在ARC下，编译器自己主动为我们做了处理：
能够看到在进行赋值时，因为默认是__strong类型，所以编译器调用了objc_retainBlock。
这种方法的作用是。假设block对象在栈上则将其复制到堆上。假设block对象已经在堆上。则做retain操作。
考虑到如今默认是__strong类型的变量赋值，所以block中假设引用外部变量都是强引用，可是否须要所有採用弱引用呢？这里能够供參考。
最新文章
- PHP7中php.ini、php-fpm和www.conf的配置
- 基于MVC4+EasyUI的Web开发框架经验总结（8）--实现Office文档的预览
- 年前辞职-WCF入门学习（5）
- Spring中的工厂模式和单例模式
- 自动登录 登陆成功那个alert遮盖一直存在bug
- Python类,域,方法,对象,继承
- 安卓中bundle的使用
- 在一个工程管理多个应用－b
- 同一台Windows机器中启动多个Memcached服务
- ORACLE_DBA管理脚本
- CentOS 启动提示unexpected inconsistency;RUN fsck MANUALLY
- web项目的集成测试:模拟点击
- 【转】高性能服务器架构(High-Performance Server Architecture)
- 深度残差网(deep residual networks)的训练过程
- firstChild,lastChild,nextSibling,previousSibling & 兼容性写法
- CSS预处理器——Sass、LESS和Stylus实践【未删减版】
- call和apply；this；闭包
- 如何在Ubuntu上开启SSH服务
- dedecms 在模版页面获取当前栏目id
- 2D空间中求线段与圆的交点