从MRC过渡到ARC

在苹果的软件生态系统里面，作为一枚程序员，犹如一条穿梭在激流里的鱼，必须要接受这激流所赋予的各种考验。从使用iOS5一路走来的童鞋们，想必一定会记得有一个绕不过的考验：从MRC过渡到ARC。

虽然在这个过渡的过程里，绝大多数问题是由苹果自己解决的，但在实际的开发过程中，总有那么几个时刻会让你不得不重提旧事，下面就简要说说我对iOS内存管理演进的理解。

事实上，移动设备的内存比较有限，每一个APP所能占用的内存是有限制的。在app运行的过程中，会分配和使用当前设备的内存资源，那么一切有关内存管理的概念也就源于此处。

那么实际的开发过程中，我们对内存管理的操作依据就明朗了，目的自然就是尽可能高效，快速的分配内存，并在适当的时机释放和回收内存资源，以此来高效使用设备资源，优化用户体验。

Objective-C内存管理的对象主要有两类：一类是值类型(例如:int,float,struct等基本数据类型)，另一种是引用类型，就是继承自nsobject类的所有OC对象。

值类型的内存不需要开发者管理，由系统解决。引用类型是需要我们手动进行管理的。为何会有如此区分？ 主要是因为他们的内存分配方式不一样：

在创建值类型之后，他们会被系统存放在栈中，依次紧密排列，在内存中会占有一块连续的内存空间，遵循先进后出原则。

当给对象分配内存空间时，系统会以堆的方式随机从内存当中开辟空间，而且对象与对象之间还可能留有不确定大小的空白空间，因此会产生内存碎片，这也是为什么引用类型的内存需要我们管理的原因。

举个例子:

- (void)memorymanagement_test {

inta1 =8;//栈

inta2 =18;//栈

Egg* e1 = [[Eggalloc]init];

}

这段代码在内存中的表现方式如下图：

可以看出，栈里存放的是非对象的基本数据类型，堆里存放的是oc对象。

这段代码执行之后，栈中的a1，a2，*e1指针会由系统编译器自动回收，堆中的oc对象不会被回收。

这里需要注意的是栈和堆的概念，如果按分配方式说：

堆是动态分配和回收内存的，没有静态分配的堆；

栈有两种分配方式：静态分配和动态分配。静态分配是系统编译器完成的，比如局部变量的分配；

动态分配是有alloc函数进行分配的，但是这里栈的动态分配和堆不同，它的动态分配也是由系统编译器进行释放，不需要开发者手动管理。

每一个oc对象内部都有一个引用计数器用以记录该对象被引用的次数，当引用计数为0，对象回收，不为0，不回收。当该对象执行alloc，new，或者retain时，引用计数+1，release时，引用计数-1。

目前，oc提供MRC和ARC两种内存管理机制来进行内存管理。

MRC顾名思义，需要程序员手动操作引用计数来管理内存，该模式下，所有对象都需要手动添加retain/release代码来进行管理，需要遵守谁创建谁回收的原则，简单说就是谁alloc谁release，谁retain谁release。

ARC是iOS5推出的功能，通过它可实现自动管理内存，该模式下只要没有强引用指向对象，对象就会被释放。不需要程序员手动添加retain，release之类的代码，如果需要使用dealloc方法，不允许调用[super dealloc]。

需要注意的是ARC模式下，property变量修饰词为strong，weak，相当于MRC模式下的retain，assign。strong代替retain，代表强引用。weak代替assign声明一个可以自动设置nil的弱引用，但它比assign多一个功能，指针指向的地址被释放后，指针本身也会被释放。

现在大部分程序都选择ARC模式开发，但笔者曾经有很长一段时间维护着公司基于MRC的某大型app项目，由于历史遗留问题，这当中遇到过各种关于内存管理优化的奇葩问题，好在都能够通过MRC的规则和苹果提供的文档得以解决。该项目现在已由MRC过渡到ARC，这个过程当中也积累里很多关于内存管理方面的优化经验。MRC与ARC理论上是不兼容的，但是如果有需求比如在MRC项目中引入ARC模式的第三方框架，这时候就需要添加一些编译选项来进行标识。对MRC的文件可以添加-fno-objc-arc的标识，在MRC的项目中使用ARC文件可以添加-fobjc-arc的标识。

具体添加方式如图：

其实关于内存管理是个比较大的话题，道道远不止这些，笔者个人感觉主要还是在开发中遇到相关问题去思考解决，体会才会更多也更深刻。希望上面的内容对你有所帮助。