iOS 内存管理

软件运行时会分配和使用设备的内存资源，因此，在软件开发的过程中，需要进行内存管理，以保证高效、快速的分配内存，并且在适当的时候释放和回收内存资源。
一、Objective-C内存管理的对象
IOS开发中，内存中的对象主要有两类，一类是值类型，比如int、float、struct等基本数据类型，另一类是引用类型，也就是继承自NSObject类的所有的OC对象。前一种值类型不需要我们管理，后一种引用类型是需要我们管理内存的，一旦管理不好，就会产生非常糟糕的后果。
为什么值类型不需要管理，而引用类型需要管理呢？那是因为他们分配内存方式不一样。
值类型会被放入栈中，他们依次紧密排列，在内存中占有一块连续的内存空间，遵循先进后出的原则。引用类型会被放到堆中，当给对象分配内存空间时，会随机的从内存当中开辟空间，对象与对象之间可能会留有不确定大小的空白空间，因此会产生很多内存碎片，需要我们管理。
栈内存与堆内存从性能上比较，栈内存要优于堆内存，这是因为栈遵循先进后出的原则，因此当数据量过大时，存入栈会明显的降低性能。因此，我们会把大量的数据存入堆中，然后栈中存放堆的地址，当需要调用数据时，就可以快速的通过栈内的地址找到堆中的数据。
值类型和引用类型之间是可以相互转化的，把值类型转化为引用类型的过程叫做装箱，比如把int包装为NSNumber，这个过程会增加程序的运行时间，降低性能。而把引用类型转为值类型的过程叫做拆箱，比如把NSNumer转为float，在拆箱的过程中，我们一定要注意数据原有的类型，如果类型错误，可能导致拆箱失败，因此会存在安全性的问题。手动的拆箱和装箱，都会增加程序的运行时间，降低代码可读性，影响性能。
在IOS开发过程中，栈内存中的值类型系统会自动管理，堆内存中的引用类型是需要我们管理的。每个OC对象内部都专门有四个字节来存储引用计数器，它是一个整数，表示对象被引用的次数，通过它可以判断对象是否被回收，如果引用计数为0，对象回收，不为0不回收。当对象执行alloc、new或者retain时，引用计数加1，release时，引用计数减1。
二、Objective-C管理内存的方式

Objective-c中提供了两种内存管理机制MRC（Mannul Reference Counting）和ARC(Automatic Reference Counting)，分别提供对内存的手动和自动管理，来满足不同的需求。

1.MRC（人工引用计数），手动管理内存。
MRC模式下，所有的对象都需要手动的添加retain、release代码来管理内存。使用MRC，需要遵守谁创建，谁回收的原则。也就是谁alloc，谁release；谁retain，谁release。
当引用计数为0的时候，必须回收，引用计数不为0，不能回收，如果引用计数为0，但是没有回收，会造成内存泄露。如果引用计数为0，继续释放，会造成野指针。为了避免出现野指针，我们在释放的时候，会先让指针=nil。

2.ARC(自动引用计数)，自动管理内存。
ARC是IOS5推出的新功能，通过ARC，可以自动的管理内存。在ARC模式下，只要没有强指针（强引用）指向对象，对象就会被释放。在ARC模式下，不允许使用retain、release、retainCount等方法。并且，如果使用dealloc方法时，不允许调用[super dealloc]方法。
ARC模式下的property变量修饰词为strong、weak，相当于MRC模式下的retain、assign。strong :代替retain，缺省关键词，代表强引用。weak：代替assign，声明了一个可以自动设置nil的弱引用，但是比assign多一个功能，指针指向的地址被释放之后，指针本身也会自动被释放。
三、与内存有关的修饰符
strong ：强引用，ARC中使用，与MRC中retain类似，使用之后，计数器+1。
weak ：弱引用 ，ARC中使用，如果只想的对象被释放了，其指向nil，可以有效的避免野指针，其引用计数为1。
readwrite : 可读可写特性，需要生成getter方法和setter方法时使用。
readonly : 只读特性，只会生成getter方法 不会生成setter方法，不希望属性在类外改变。
assign ：赋值特性，不涉及引用计数，弱引用，setter方法将传入参数赋值给实例变量，仅设置变量时使用。
retain ：表示持有特性，setter方法将传入参数先保留，再赋值，传入参数的retaincount会+1。
copy ：表示拷贝特性，setter方法将传入对象复制一份，需要完全一份新的变量时。
nonatomic ：非原子操作，不加同步，多线程访问可提高性能，但是线程不安全的。决定编译器生成的setter getter是否是原子操作。
atomic ：原子操作，同步的，表示多线程安全，与nonatomic相反。

四、MRC与ARC混编
MRC与ARC理论上是不能兼容的，也就是你如果创建的项目是ARC模式的，在你的代码中是不能使用release，否则会出现内存问题。现在大部分程序都会选择ARC的方式，但是很多第三方的框架是MRC模式，如果想把这些第三方的文件加到自己项目中，需要进行标识，否则编译的时候会出现错误。
在ARC的项目中，对MRC的文件可以添加编译选项-fno-objc-arc的标识；在MRC的项目中，对ARC的文件可以添加编译选项 -fobjc-arc的标识。

五、ARC与Block

---

在MRC时代，Block会隐式地对进入其作用域内的对象（或者说被Block捕获的指针指向的对象）加retain，来确保Block使用到该对象时，能够正确的访问。

这件事情在下面代码展示的情况中要更加额外小心。

MyViewController *myController = [[MyViewController alloc] init…];

// 隐式地调用[myController retain];造成循环引用
myController.completionHandler =  ^(NSInteger result) {
   [myController dismissViewControllerAnimated:YES completion:nil];
};

[self presentViewController:myController animated:YES completion:^{
   [myController release]; // 注意，这里调用[myController release];是在MRC中的一个常规写法，并不能解决上面循环引用的问题
}];

在这段代码中，myController的completionHandler调用了myController的方法[dismissViewController...]，这时completionHandler会对myController做retain操作。而我们知道，myController对completionHandler也至少有一个retain（一般准确讲是copy），这时就出现了在内存管理中最糟糕的情况：循环引用！简单点说就是：myController retain了completionHandler，而completionHandler也retain了myController。循环引用导致了myController和completionHandler最终都不能被释放。我们在delegate关系中，对delegate指针用weak就是为了避免这种问题。

不过好在，编译器会及时地给我们一个警告，提醒我们可能会发生这类型的问题：

对这种情况，我们一般用如下方法解决：给要进入Block的指针加一个__block修饰符。

这个__block在MRC时代有两个作用：

• 说明变量可改
• 说明指针指向的对象不做这个隐式的retain操作

一个变量如果不加__block，是不能在Block里面修改的，不过这里有一个例外：static的变量和全局变量不需要加__block就可以在Block中修改。

使用这种方法，我们对代码做出修改，解决了循环引用的问题：

MyViewController * __block myController = [[MyViewController alloc] init…];
// ...
myController.completionHandler =  ^(NSInteger result) {
    [myController dismissViewControllerAnimated:YES completion:nil];
};
//之后正常的release或者retain

在ARC引入后，没有了retain和release等操作，情况也发生了改变：在任何情况下，__block修饰符的作用只有上面的第一条：说明变量可改。即使加上了__block修饰符，一个被block捕获的强引用也依然是一个强引用。这样在ARC下，如果我们还按照MRC下的写法，completionHandler对myController有一个强引用，而myController对completionHandler有一个强引用，这依然是循环引用，没有解决问题：

于是我们还需要对原代码做修改。简单的情况我们可以这样写：

__block MyViewController * myController = [[MyViewController alloc] init…];
// ...
myController.completionHandler =  ^(NSInteger result) {
    [myController dismissViewControllerAnimated:YES completion:nil];
    myController = nil;  // 注意这里，保证了block结束myController强引用的解除
};

在completionHandler之后将myController指针置nil，保证了completionHandler对myController强引用的解除，不过也同时解除了myController对myController对象的强引用。这种方法过于简单粗暴了，在大多数情况下，我们有更好的方法。

这个更好的方法就是使用weak。（或者为了考虑iOS4的兼容性用unsafe_unretained，具体用法和weak相同，考虑到现在iOS4设备可能已经绝迹了，这里就不讲这个方法了）（关于这个方法的本质我们后面会谈到）

为了保证completionHandler这个Block对myController没有强引用，我们可以定义一个临时的弱引用weakMyViewController来指向原myController的对象，并把这个弱引用传入到Block内，这样就保证了Block对myController持有的是一个弱引用，而不是一个强引用。如此，我们继续修改代码：

MyViewController *myController = [[MyViewController alloc] init…];
// ...
MyViewController * __weak weakMyViewController = myController;
myController.completionHandler =  ^(NSInteger result) {
    [weakMyViewController dismissViewControllerAnimated:YES completion:nil];
};

这样循环引用的问题就解决了，但是却不幸地引入了一个新的问题：由于传入completionHandler的是一个弱引用，那么当myController指向的对象在completionHandler被调用前释放，那么completionHandler就不能正常的运作了。在一般的单线程环境中，这种问题出现的可能性不大，但是到了多线程环境，就很不好说了，所以我们需要继续完善这个方法。

为了保证在Block内能够访问到正确的myController，我们在block内新定义一个强引用strongMyController来指向weakMyController指向的对象，这样多了一个强引用，就能保证这个myController对象不会在completionHandler被调用前释放掉了。于是，我们对代码再次做出修改：

MyViewController *myController = [[MyViewController alloc] init…];
// ...
MyViewController * __weak weakMyController = myController;
myController.completionHandler =  ^(NSInteger result) {
    MyViewController *strongMyController = weakMyController;

　　if (strongMyController) {
        // ...
        [strongMyController dismissViewControllerAnimated:YES completion:nil];
        // ...
    }
    else {
        // Probably nothing...
    }
};

到此，一个完善的解决方案就完成了。