ARC & MRC，这不是技术路线问题。

源地址：http://www.cocoachina.com/bbs/read.php?tid=181864&keyword=ARC

写这个帖子是因为好多人（有经验的，没经验的）对于ARC 很陌生，所以不敢用。更有一些人道听途说了ARC的只言片语就开始下结论ARC是否适合自己。我相信要成为一名优秀的程序员，实事求是肯定是必须具备的素质。所以需要先彻底了解ARC，而且在一个项目中应用才能下决定。

另外一个目的则是给新人看，我希望减少被误导的新人数目，一个也好。

那么，什么是 ARC。对于有C++背景的人来说，ARC的本质从某种角度上来说类似
C++ 的智能指针，区别就是ARC更智能简单，而且会加速程序，而不是像智能指针那样会一定程度上减慢程序运行。对于纯ObjC背景的人来说，ARC相当于编译器自动帮你填写了
retain, release。但是，远远不是这么简单。

首先ARC不会真的填写retain/release，retain/release
是 ObjC的消息，ARC会直接调用runtime的C函数，这会快很多。另外对于MRC中恶心的
return [[[XXX alloc] init] autorelease] ，ARC不但可以简化其写法，还可以让它更快，原因就在于它可以消除不必要的“入池”操作，详见，objc_retainAutoreleasedReturnValue.

基于上面两点，ARC会让所有涉及到内存的操作变快。

ARC虽然会让单位内存操作变快，甚至会智能的取消某些retain/release
pair，但是毕竟ARC不是人脑，如果一个人完全清晰的掌握某个对象的生命周期，那么他完全可以只retain一次，然后在最后不需要的时候release掉，所以MRC可以在这种情况下比ARC快。至于具体应用到项目中的数据，可以参考 http://www.learn-cocos2d.com/2013/12/performance-comparison-cocos2diphone-v2-v3-sparrow-arc-mrc/ 。其中有快有慢。

MRC的代价。代码有好多代价，最简单直白的代价是编写时的代价，然后更重大的代价则是维护的代价。

编写的代价：

每个人的脑力都是有限的，而在编程的时候往往需要全心专注，这说明编程本身就耗费了100%的脑力。基于这个出发点，那么如果一个人在每写100行代码里面10行都是内存维护相关的代码时，他分配给其他的东西（程序结构，API设计，业务逻辑）肯定会减少，除非他愿意花更多的时间来写这个东西（加班）。注意，内存维护的10行代码并非简单地事情，要把他们搞正确，一个合格的MRC程序员肯定会前后审阅自己的代码好几遍。

维护的代价：

代码的本质是动态的，它会随着时间不停的改变自己，所以代码不但需要运行时健壮，同时还需要重构健壮，即你能安全的重构一段代码，而不是重构之后错误百出。这个举个常见例子：

在MRC下，有一个函数，在运行中间会 return 掉，那么所有合格的MRC程序员必然会记得在return之前把 alloc 的对象逐个 release 掉，咱不讨论在MRC下如果多几个中途return会让代码多么难写（这是编写代价），假设写好了，程序OK，没bug。然后某天重构了，把
return 提前了，然后由于位置提前，需要release的对象变成了另外一些，这会造成相当多的重构bug。另外一个例子，假设这个MRC程序员采用了极端的 retain/release 优化，那么在重构时必然要全面审视新的代码下面原来的优化是否安全，代价很高。那如果这些代码要交给别人重构呢？

维护代价的另一面是阅读时的代价。代码的价值是给人（别人或者自己）读，一行代码敲下去，可能要被读10遍，20遍。设想一下阅读到处穿插 retain/ release 的代码 vs 阅读清晰的业务逻辑的代码的容易程度对比。

ARC 是不是给“怕自己管理不好内存的人”用的？

有一句话是这么说的，把事情做复杂很容易，把事情做简单很难。ARC就是这样一种简单的技术。它让你在明确并且遵守其所有规则的时候减少犯错的可能性（在MRC下，即使你明确所有规则，犯错的可能性仍然很大）。一个管理不好内存的人，无论用什么技术都会出问题，在ARC下面，他肯定会陷入无穷无尽的循环引用之中，甚至还会碰到
zombie 的问题。

ARC 是不是不适合新人？

很多人会有这样的担心，即如果新人直接学习ARC，完全不知道retain
relase会不会出问题。其实不会，ARC的出现本身就是要取代MRC。只要你遵守ARC的规范，明确表达了是strong
还是 weak 的意愿，函数符合ARC的命名规范，你的程序就会良好运行，同时还有更好的可读性，可维护性，何乐而不为？为什么非要纠结MRC呢？茴字有四样写法，真要去知道吗？所以新人完全用ARC写出更好的，更容易维护的程序。

ARC 与
MRC 不是技术路线的问题，而是骑马与开车的问题。车子能到的地方，骑马基本也能到，但是速度不是一回事。量变产生质变，最后可能是项目成败的区别。

////////////////////////////////////////////////////////

什么时候用 MRC 是合理的。

JSONKit 为了达到极限的速度（比Apple自带的快一倍），他极限优化了retain，release，所以他只能MRC。而且他采用MRC的代价也很小，因为JSON格式不会天天变，而且用户只需要调用它的API，很少有必要去阅读实现。这么多特殊情况组合在一起，MRC更适合JSONKit。

然而如果真的到了这个地步，必须要极快的JSON解析速度，那么可以直接考虑 C++ 的 rapidjson，它支持 Insitu parsing，速度大概是JSONKit的5倍左右。