一、內(nèi)存管理（MRC）
(一) 管理對象
管理對象：OC對象
原因：
? ? ? ? 1、OC對象存放于堆里面
? ? ? ? 2、非OC對象(int、char、float、double、struct、enum)一般放在棧里面(棧內(nèi)存會被系統(tǒng)自動回收)
(二) 基本原理
1、每個OC對象內(nèi)部都有4個字節(jié)的存儲空間來存放引用計數(shù)器
2、誰創(chuàng)建誰release :如果你通過alloc、new或[mutable]copy來創(chuàng)建一個對象(引用計數(shù)+1)，那么你必須調(diào)用release或autorelease(引用計數(shù)-1)
3、誰retain誰release:只要你調(diào)用了retain(引用計數(shù)+1)，就必須調(diào)用一次release(引用計數(shù)-1)
4、release并不代表銷毀\回收對象,僅僅是計數(shù)器-1；引用計數(shù)為0時，對象被銷毀，系統(tǒng)會自動給對象發(fā)送一條dealloc消息。
5、一般來說，除了alloc、new或copy之外的方法創(chuàng)建的對象都被申明了autorelease。
(三) Set方法
- (void) setName:(NSString *)name
{
? ? ? ? if(_name!= name){
? ? ? ? ? ? ? ? [_namerelease];
? ? ? ? ? ? ? ? _name= [name retail];
? ? ? ? }
}
(四) ?一些術(shù)語
1、僵尸對象
已經(jīng)被銷毀的對象(不能再使用的對象)
2、野指針
指向僵尸對象(不可用內(nèi)存)的指針
給野指針發(fā)消息會報EXC_BAD_ACCESS錯誤
3、空指針
沒有指向存儲空間的指針(里面存的是nil,也就是0)
給空指針發(fā)消息是沒有任何反應(yīng)的
objc_msgSend會通過判斷self來決定是否發(fā)送消息，如果self為nil，那么selector也會為空，直接返回，所以不會出現(xiàn)問題。視方法返回值，向nil發(fā)消息可能會返回nil(返回值為對象)、0（返回值為一些基礎(chǔ)數(shù)據(jù)類型）或0X0（返回值為id）等。但是對[NSNull null]對象發(fā)送消息時，是會crash的，因為這個NSNull類只有一個null方法
為了避免野指針錯誤的常見辦法
在對象被銷毀之后,將指向?qū)ο蟮闹羔樧優(yōu)榭罩羔?/p>
(五) 一些設(shè)置
1、關(guān)閉ARC功能
Building->AutoMatic Reference Counting->NO
2、開啟僵尸對象監(jiān)控
Edit Scheme->Diagnostics->Enable Zombie Object
(六) NSString創(chuàng)建類的幾種方式
NSString類型的字符串有三種方法:
方法1.直接賦值:?? ??NSString?*str1=?@"my string";
方法2.類函數(shù)初始化生成: ? ??NSString?*str2= [NSString stringWithString:@"my string"];
方法3.實例方法初始化生成: NSString?*str3= [[NSString alloc] initWithString:@"my string"];
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?NSString?*str4?=[[NSString?alloc]initWithFormat:@"my string"];
區(qū)別1:方法一生成字符串時,不會初始化內(nèi)存空間,所以使用結(jié)束后不用釋放內(nèi)存;
? ? ? ? ? 而其他三個都會初始化內(nèi)存空間,使用結(jié)束后要釋放內(nèi)存;
? ? ? ? ? 在釋放內(nèi)存時方法2和3也不同,方法2是autorelease類型,內(nèi)存由系統(tǒng)釋放;方法3則必須手動釋放
區(qū)別2:用Format初始化的字符串，需要初始化一段動態(tài)內(nèi)存空間，如：0x6a42a40;
? ? ? ? ? 而用String聲明的字符串，初始化的是常量內(nèi)存區(qū)，如：0x46a8，常量內(nèi)存區(qū)的地址，只要值相同，占用的 ?地址空間是一致的。
所以str3和str1的地址一致，但是str4和str1的地址不一致。
二、內(nèi)存警告
(一)?app收到Memory Warning后會調(diào)用：
UIApplication::didReceiveMemoryWarning->
UIApplicationDelegate::applicationDidReceiveMemoryWarning,
然后調(diào)用當(dāng)前所有的viewController進行處理。
因此處理的主要工作是在viewController。
(二) 當(dāng)我們的程序在第一次收到內(nèi)存不足警告時，應(yīng)該釋放一些不用的資源，以節(jié)省部分內(nèi)存。否則，當(dāng)內(nèi)存不足情形依然存在，iOS再次向我們程序發(fā)出內(nèi)存不足的警告時，我們的程序?qū)籭OS kill掉。
1、iOS3-iOS5.0以前版本收到內(nèi)存警告：
調(diào)用didReceiveMemoryWarning內(nèi)調(diào)用super的didReceiveMemoryWarning會將controller的view進行釋放。所以我們不能將controller的view再次釋放。
處理方法：
-(void)didReceiveMemoryWarning{
? ? ? ? [super?didReceiveMemoryWarning];//如沒有顯示在window上，會自動將self.view釋放。
? ? ? ? //?ios6.0以前，不用在此做處理，self.view釋放之后，會調(diào)用下面的viewDidUnload函數(shù)，在viewDidUnload函數(shù)中做處理就可以了。
}
-(void)viewDidUnload{
? ? ? ? //?Release?any?retained?subviews?of?the?main?view.不包含self.view
? ? ? ? //處理一些內(nèi)存和資源問題。?
? ? ? ? [super?viewDidUnload];
}
2、iOS6.0及以上版本的內(nèi)存警告：
調(diào)用didReceiveMemoryWarning內(nèi)調(diào)用super的didReceiveMemoryWarning
只是釋放controller的resouse，不會釋放view
處理方法：
-(void)didReceiveMemoryWarning{
? ? ? ? [super didReceiveMemoryWarning];//即使沒有顯示在window上，也不會自動的將self.view釋放。
? ? ? ? // Add code to clean up any of yourown resources that are no longer necessary.
? ? ? ? //此處做兼容處理需要加上ios6.0的宏開關(guān)，保證是在6.0下使用的,6.0以前屏蔽以下代碼，否則會在下面使用self.view時自動加載viewDidUnLoad
? ? ? ?if ([[UIDevicecurrentDevice].systemVersion floatValue] >= 6.0) {
? ? ? ? //需要注意的是self.isViewLoaded是必不可少的，其他方式訪問視圖會導(dǎo)致它加載，在WWDC視頻也忽視這一點。
? ? ? ? ? ? ? if (self.isViewLoaded &&!self.view.window)//是否是正在使用的視圖{
? ? ? ? ? ? ? ? ? ? ? // Add code to preserve data storedin the views that might be
? ? ? ? ? ? ? ? ? ? ? // needed later.
? ? ? ? ? ? ? ? ? ? ? // Add code to clean up other strongreferences to the view in
? ? ? ? ? ? ? ? ? ? ? // the view hierarchy.
? ? ? ? ? ? ? ? ? ? ? self.view = nil;//目的是再次進入時能夠重新加載調(diào)用viewDidLoad函數(shù)。
? ? ? ? ? ? ? ?}
? ? ? ? }
}
但是似乎這么寫相對于以前并不省事。最終我們找到一篇文章，文章中說其實并不值得回收這部分的內(nèi)存，原因如下：
1. UIView是UIResponder的子類，而UIResponder有一個CALayer的成員變量，CALayer是具體用于將自己畫到屏幕上的。
2. CALayer是一個bitmap圖象的包裝類，當(dāng)UIView調(diào)用自身的drawRect時，CALayer才會創(chuàng)建這個bitmap圖象類。
3.具體占內(nèi)存的其實是一個bitmap圖象類，CALayer只占48bytes, UIView只占96bytes。而一個iPad的全屏UIView的bitmap類會占到12M的大?。?/p>
4.在iOS6時，當(dāng)系統(tǒng)發(fā)出MemoryWarning時，系統(tǒng)會自動回收bitmap類。但是不回收UIView和CALayer類。這樣即回收了大部分內(nèi)存，又能在需要bitmap類時，根據(jù)CALayer類重建。
所以，iOS6這么做的意思是：我們根本沒有必要為了幾十byte而費力回收內(nèi)存。
生命周期圖
三、內(nèi)存泄漏分析解決方法
(一) 靜態(tài)分析
通過靜態(tài)分析我們可以最初步的了解到代碼的一些不規(guī)范的地方或者是存在的內(nèi)存泄漏，這是我們第一步對內(nèi)存泄漏的檢測。當(dāng)然有一些警告并不是我們關(guān)心的可以略過。
(二) 通過instruments來檢查內(nèi)存泄漏
這個方法能粗略的定位我們在哪里發(fā)生了內(nèi)存泄漏。方法是完成一個循環(huán)操作，如果內(nèi)存增長為0就證明我們程序在該次循環(huán)操作中不存在內(nèi)存泄漏，如果內(nèi)存增長不為0那證明有可能存在內(nèi)存泄漏，當(dāng)然具體問題需要具體分析。
(三) 代碼測試內(nèi)存泄漏
在做這項工作之前我們要注意一下，在dealloc的方法中我們是否已經(jīng)釋放了該對象所擁有的所有對象。觀察對象的生成和銷毀是否配對。準(zhǔn)確的說就是init（創(chuàng)建對象的方法）和dealloc是否會被成對觸發(fā)（簡單說來就是走一次創(chuàng)建對象就有走一次dealloc該對象）。
四、內(nèi)存檢查工具
編譯和分析工具Analyze
內(nèi)存泄漏檢測工具—Leak
內(nèi)存猛增檢測工具—Allocations
