ARC简介

      什么是ARC，ARC是为了解决什么问题而产生的？

        简述： ARC是 Automatic Reference Counting 的缩写, 我们称之为自动引用计数，是iOS5.0之后推出的内存管理机制。本质上还是引用计数来管理对象，指示我们在编写代码时，不需要向对象发送release或者autorelease方法，也可以调用delloc方法，编译器在合适的时候会自动生成release（autorelease）消息。

ARC不需要我们手动释放内存，系统自动帮我们释放了内存，但是内存管理不当的话仍会存在内存泄露。

       Objective-C 和 Swift 使用 ARC 追踪和管理应用的内存使用. 这一机制使得开发者无需键入 retain 和 release , 这不仅能够降低程序崩溃和内存泄露的风险, 而且可以减少开发者的工作量, 能够大幅度提升程序的 流畅性 和 可预测性 . 但是 ARC 不适用于 Core Foundation 框架中, 仍然需要手动管理内存.

什么是ARC？

ARC是iOS 5推出的新功能，全称叫 ARC(Automatic Reference Counting)。简单地说，就是代码中自动加入了retain/release，原先需要手动添加的用来处理内存管理的引用计数的代码可以自动地由编译器完成了。

该机能在 iOS 5/ Mac OS X 10.7 开始导入，利用 Xcode4.2 可以使用该机能。简单地理解ARC，就是通过指定的语法，让编译器(LLVM 3.0)在编译代码时，自动生成实例的引用计数管理部分代码。有一点，ARC并不是GC，它只是一种代码静态分析（Static Analyzer）工具。

我们之前使用Objective-C中内存管理规则时，往往采用下面的准则

•    生成对象时，使用autorelease
•    对象代入时，先autorelease后再retain
•    对象在函数中返回时，使用return [[object retain] autorelease];

而使用ARC后，我们可以不需要这样做了，甚至连最基础的release都不需要了。

使用ARC的好处

使用ARC以后再写OC的代码变得简单的多了，因为我们不用再担心那令人心烦的内存管理，内存泄露了。

代码量变少了，看上去整洁了很多，节省了我们编程时的劳动量。

 代码高速化，由于使用编译器管理引用计数，减少了低效代码的可能性。

使用ARC的缺点

提供了weak reference（这个很好）却无法提供向后兼容的方案，weak在ios5以前以unsafe unretain的方式存在，这使得要支持ios4的app还是要非常注意清理现场的工作。

当你习惯使用ARC以后，再遇到使用MRC的时候会感觉到不适应，

当内存管理不当的话，同样会存在内存泄露的风险

ARC工作原理

手动内存管理的机理大家应该已经非常清楚了，简单来说，只要遵循以下三点就可以在手动内存管理中避免绝大部分的麻烦：

如果需要持有一个对象，那么对其发送retain 如果之后不再使用该对象，那么需要对其发送release（或者autorealse） 每一次对retain,alloc或者new的调用，需要对应一次release或autorealse调用

初学者可能仅仅只是知道这些规则，但是在实际使用时难免犯错。但是当开发者经常使用手动引用计数 Manual Referecen Counting(MRC)的话，这些规则将逐渐变为本能。你会发现少一个release的代码怎么看怎么别扭，从而减少或者杜绝内存管理的错误。可以说MRC的规则非常简单，但是同时也非常容易出错。往往很小的错误就将引起crash或者OOM之类的严重问题。

在MRC的年代里，为了避免不小心忘写release，Xcode提供了一个很实用的小工具来帮助可能存在的代码问题(Xcode3里默认快捷键Shift+A？不记得了)，可以指出潜在的内存泄露或者过多释放。而ARC在此基础上更进一步：ARC是Objective-C编译器的特性，而不是运行时特性或者垃圾回收机制，ARC所做的只不过是在代码编译时为你自动在合适的位置插入release或autorelease，就如同之前MRC时你所做的那样。因此，至少在效率上ARC机制是不会比MRC弱的，而因为可以在最合适的地方完成引用计数的维护，以及部分优化，使用ARC甚至能比MRC取得更高的运行效率。

ARC机制

学习ARC很简单，在MRC时代你需要自己retain一个想要保持的对象，而现在不需要了。现在唯一要做的是用一个指针指向这个对象，只要指针没有被置空，对象就会一直保持在堆上。当将指针指向新值时，原来的对象会被release一次。这对实例变量，sunthesize的变量或者局部变量都是适用的。比如

1

NSString *firstName = self.textField.text;

firstName现在指向NSString对象，这时这个对象（textField的内容字符串）将被hold住。比如用字符串@“OneV”作为例子，这个时候firstName持有了@”OneV”。

当然，一个对象可以拥有不止一个的持有者（这个类似MRC中的retainCount>1的情况）。在这个例子中显然self.textField.text也是@“OneV”，那么现在有两个指针指向对象@”OneV”(被持有两次，retainCount=2，其实对NSString对象说retainCount是有问题的，不过anyway～就这个意思而已.)。

过了一会儿，也许用户在textField里输入了其他的东西，那么self.textField.text指针显然现在指向了别的字符串，比如@“onevcat”，但是这时候原来的对象已然是存在的，因为还有一个指针firstName持有它。现在指针的指向关系是这样的：

只有当firstName也被设定了新的值，或者是超出了作用范围的空间(比如它是局部变量但是这个方法执行完了或者它是实例变量但是这个实例被销毁了)，那么此时firstName也不再持有@“OneV”，此时不再有指针指向@”OneV”，在ARC下这种状况发生后对象@”OneV”即被销毁，内存释放。

类似于firstName和self.textField.text这样的指针使用关键字”strong”进行标志，它意味着只要该指针指向某个对象，那么这个对象就不会被销毁。反过来说，ARC的一个基本规则即使，只要某个对象被任一strong指针指向，那么它将不会被销毁。如果对象没有被任何strong指针指向，那么就将被销毁。在默认情况下，所有的实例变量和局部变量都是strong类型的。可以说strong类型的指针在行为上和MRC时代retain的property是比较相似的。

既然有”strong”，那肯定有”weak”咯～weak类型的指针也可以指向对象，但是并不会持有该对象。比如：

1

__weakNSString*weakName=self.textField.text

这里声明了一个weak的指针weakName，它并不持有@“onevcat”。如果self.textField.text的内容发生改变的话，根据之前提到的“只要某个对象被任一strong指针指向，那么它将不会被销毁。如果对象没有被任何strong指针指向，那么就将被销毁”原则，此时指向@“onevcat”的指针中没有strong类型的指针，@”onevcat”将被销毁。同时，在ARC机制作用下，所有指向这个对象的weak指针将被置为nil。这个特性相当有用，相信无数的开发者都曾经被指针指向已释放对象所造成的EXC_BAD_ACCESS困扰过，使用ARC以后，不论是strong还是weak类型的指针，都不再会指向一个dealloced的对象，从根源上解决了意外释放导致的crash。

不过在大部分情况下，weak类型的指针可能并不会很常用。比较常见的用法是在两个对象间存在包含关系时：对象1有一个strong指针指向对象2，并持有它，而对象2中只有一个weak指针指回对象1，从而避免了循环持有。一个常见的例子就是oc中常见的delegate设计模式，viewController中有一个strong指针指向它所负责管理的UITableView，而UITableView中的dataSource和delegate指针都是指向viewController的weak指针。可以说，weak指针的行为和MRC时代的assign有一些相似点，但是考虑到weak指针更聪明些（会自动指向nil），因此还是有所不同的。细节的东西我们稍后再说。

注意类似下面的代码似乎是没有什么意义的：

1

2

__weak NSString *str = [[NSString alloc] initWithFormat:…];

NSLog(@"%@",str); //输出是"(null)"

由于str是weak，它不会持有alloc出来的NSString对象，因此这个对象由于没有有效的strong指针指向，所以在生成的同时就被销毁了。如果我们在Xcode中写了上面的代码，我们应该会得到一个警告，因为无论何时这种情况似乎都是不太可能出现的。你可以把weak换成strong来消除警告，或者直接前面什么都不写，因为ARC中默认的指针类型就是strong。

property也可以用strong或weak来标记，简单地把原来写retain和assign的地方替换成strong或者weak就可以了。

1

2

@property(nonatomic,strong)NSString*firstName;

@property(nonatomic,weak)id  delegate;

ARC可以为开发者节省很多代码，使用ARC以后再也不需要关心什么时候retain，什么时候release，但是这并不意味你可以不思考内存管理，你可能需要经常性地问自己这个问题：谁持有这个对象？

比如下面的代码，假设array是一个NSMutableArray并且里面至少有一个对象：

1

2

3

idobj=[arrayobjectAtIndex:0]; 

[arrayremoveObjectAtIndex:0]; 

NSLog(@"%@",obj);

在MRC时代这几行代码应该就挂掉了，因为array中0号对象被remove以后就被立即销毁了，因此obj指向了一个dealloced的对象，因此在NSLog的时候将出现EXC_BAD_ACCESS。而在ARC中由于obj是strong的，因此它持有了array中的首个对象，array不再是该对象的唯一持有者。即使我们从array中将obj移除了，它也依然被别的指针持有，因此不会被销毁。

ARC基本规则

•    retain, release, autorelease, dealloc由编译器自动插入，不能在代码中调用
•     dealloc虽然可以被重载，但是不能调用[super dealloc]

由于ARC并不是GC，并需要一些规则让编译器支持代码插入，所以必须清楚清楚了这些规则后，才能写出健壮的代码。

总结

•     代码中不能使用retain, release, retain, autorelease
•     不重载dealloc（如果是释放对象内存以外的处理，是可以重载该函数的，但是不能调用[super dealloc]）
•     不能使用NSAllocateObject, NSDeallocateObject
•     不能在C结构体中使用对象指针
•     id与void *间的如果cast时需要用特定的方法（__bridge关键字）
•     不能使用NSAutoReleasePool、而需要@autoreleasepool块
•     不能使用“new”开始的属性名称 （如果使用会有下面的编译错误”Property’s synthesized getter follows Cocoa naming convention for returning ‘owned’ objects”）