1. 用ARC管理內存

ARC(Automatic ReferenceCounting, 自動引用計數)和iOS5一起發(fā)布，它避免了最常見的也就是經常是由于我們忘記釋放內存所造成的內存泄露。它自動為你管理retain和release的過程，所以你就不必去手動干預了.除了幫你避免內存泄露，ARC還可以幫你提高性能，它能保證釋放掉不再需要的對象的內存。

2.避免過于龐大的XIB

iOS5中加入的Storyboards(分鏡)正在快速取代XIB。然而XIB在一些場景中仍然很有用。比如你的app需要適應iOS5之前的設備，或者你有一個自定義的可重用的view,你就不可避免地要用到他們。

如果你不得不XIB的話，使他們盡量簡單。嘗試為每個Controller配置一個單獨的XIB，盡可能把一個View Controller的view層次結構分散到單獨的XIB中去。

注意:當你加載一個XIB的時候所有內容都被放在了內存里，包括任何圖片。如果有一個不會即刻用到的view，你這就是在浪費寶貴的內存資源了。Storyboards就是另一碼事兒了，storyboard僅在需要時實例化一個view controller.

3.常見的加載圖片的方式有兩種，一個是用`imageNamed`，二是用`imageWithContentsOfFile`，第一種比較常見一點。

差別:`imageNamed`的優(yōu)點是當加載時會緩存圖片。`imageNamed`的文檔中這么說:這個方法用一個指定的名字在系統(tǒng)緩存中查找并返回一個圖片對象如果它存在的話。如果緩存中沒有找到相應的圖片，這個方法從指定的文檔中加載然后緩存并返回這個對象。

相反的，`imageWithContentsOfFile`僅加載圖片。

下面的代碼說明了這兩種方法的用法:

UIImage *img = [UIImage imageNamed:@"myImage"];// caching

// or

UIImage *img = [UIImage imageWithContentsOfFile:@"myImage"];// no caching

如果你要加載一個大圖片而且是一次性使用，那么就沒必要緩存這個圖片，用`imageWithContentsOfFile`足矣，這樣不會浪費內存來緩存它。

然而，在圖片反復重用的情況下`imageNamed`是一個好得多的選擇。

4.選擇正確的數據存儲選項

當存儲大塊數據時"

· 使用`NSUerDefaults`:雖然它很nice也很便捷，但是它只適用于小數據，比如一些簡單的布爾型的設置選項，再大點你就要考慮其它方式了

· 使用XML, JSON, 或者 plist :你需要讀取整個文件到內存里去解析，這樣是很不經濟的。使用SAX又是一個很麻煩的事情。

· 使用NSCoding存檔 :不幸的是，它也需要讀寫文件，所以也有以上問題。

在這種應用場景下，使用SQLite 或者 Core Data比較好。使用這些技術你用特定的查詢語句就能只加載你需要的對象。

· 使用類似SQLite的本地SQL數據庫?

· 使用 Core Data

在性能層面來講，SQLite和Core Data是很相似的。他們的不同在于具體使用方法。Core Data代表一個對象的graph model，但SQLite就是一個DBMS。Apple在一般情況下建議使用Core Data，但是如果你有理由不使用它，那么就去使用更加底層的SQLite吧。

如果你使用SQLite，你可以用FMDB(https://GitHub.com/ccgus/fmdb)這個庫來簡化SQLite的操作，這樣你就不用花很多經歷了解SQLite的 API了。

5. 減少使用Web特性

UIWebView很有用，用它來展示網頁內容或者創(chuàng)建UIKit很難做到的動畫效果是很簡單的一件事。

但是你可能有注意到UIWebView并不像驅動Safari的那么快。這是由于以JIT compilation為特色的Webkit的Nitro Engine的限制。

盡可能移除不必要的javascript，避免使用過大的框架。能只用原生js就更好了。

另外，盡可能異步加載例如用戶行為統(tǒng)計script這種不影響頁面表達的javascript。

javascript:通過JS，把一個頁面全我們想要的意思進行渲染，執(zhí)行相應的功能，生成相應的效果，比如，顯示當前系統(tǒng)時間，比如，顯示實時信息的更新.最后，永遠要注意你使用的圖片，保證圖片的符合你使用的大小。使用Sprite sheet提高加載速度和節(jié)約內存。

6.避免反復處理數據

許多應用需要從服務器加載功能所需的常為JSON或者XML格式的數據。在服務器端和客戶端使用相同的數據結構很重要。在內存中操作數據使它們滿足你的數據結構是開銷很大的。

比如你需要數據來展示一個table view,最好直接從服務器取array結構的數據以避免額外的中間數據結構改變。

類似的，如果需要從特定key中取數據，那么就使用鍵值對的dictionary。

7.IBOutlet 對象需要release

8.特別是UIScrollView上add相同SubView。一定要記得清除之前的SubView，并且在dealloc函數中執(zhí)行該方法

for (UIView* sbViewin scrvBg.subviews)

{

[sbView removeFromSuperview];

}

這里還有個獲得subView的小技巧：

[subView setTag:300];

subView = [self.viewviewWithTag:300]

9.dealloc不一定會被調用，所以可以自己手寫一個myRelease方法，當退出該界面的時候手動調用release需要釋放的對象，并且將其置為nil。

10.記住:如果你不太明白UIView的drawRect的調用時機，千萬不要輕易往drawRect里寫代碼，特別是沒有立即release的對象。很容易在這里因為多次調用了drawRect而沒有release該對象導致內存溢出。

iOS的繪圖操作是在UIView類的drawRect方法中完成的

iOS平臺的內存管理采用引用計數的機制；

當創(chuàng)建一個對象時使用alloc或者allWithZone方法時，引用計數就會+1；當釋放對象使用release方法時，引用計數就是-1； 這就意味著每一個對象都會跟蹤有多少其他對象引用它，一旦引用計數為0，該對象的內存就會被釋放掉；另外，iOS也提供了一種延時釋放的機制 AutoRelease，以這種方式申請的內存，開發(fā)者無需手動釋放，系統(tǒng)會在某一時機釋放該內存； 開發(fā)者在內存使用上很容易出現內存泄漏或者程序莫名崩潰的情況

2 iOS平臺內存使用原則

如果是以alloc，new或者copy，mutableCopy創(chuàng)建的對象，則必須調用release或者autorelease方法釋放內存；如果沒有釋放，則導致內存泄漏！

2.1.2 誰retain，誰釋放；

如果對一個對象發(fā)送 retain消息，其引用計數會+1，則使用完必須發(fā)送release或者autorelease方法釋放內存或恢復引用計數；如果沒有釋放，則導致內存泄漏！

2.1.3 沒創(chuàng)建且沒retain，別釋放；

不要釋放那些不是自己alloc或者retain的對象，否則程序會crash；

不要釋放autorelease的對象，否則程序會crash；

2.2 對象的深拷貝與淺拷貝

一般來說，復制一個對象包括創(chuàng)建一個新的實例，并以原始對象中的值初始化這個新的實例。 復制非指針型實例變量的值很簡單，比如布爾，整數和浮點數。復制指 針型實例變量有兩種方法。一種方法稱為淺拷貝，即將原始對象的指針值復制到副本中。因此，原始對象和副本共享引用數據。另一種方法稱為深拷貝，即復制指針 所引用的數據，并將其賦給副本的實例變量。

2.2.1 深拷貝

深拷貝的流程是 先創(chuàng)建一個新的對象且引用計數為1，并用舊對象的值初始化這個新對象；

ClassA* objA = [[ClassA alloc] init];

ClassA* objB = [objA copy];

objB是一個新對象，引用計數為1，且objB的數據等同objA的數據；

注意： objB需要釋放，否則會引起內存泄漏！

2.2.2 淺拷貝

淺拷貝的流程是，無需引入新的對象，把原有對象的引用計數+1即可

ClassA* objA = [[ClassA alloc] init];

ClassA* objB = [objA retain];

注意： objB需要釋放，恢復objA的引用計數，否則會引起內存泄漏！

2.3對象的存取方法2.3.1 屬性聲明和實現

變量聲明的常用屬性類型包括readonly，assign，retain和copy；且系統(tǒng)會自動為聲明了屬性的變量生成set和get函數；

readonly屬性： 只能讀，不能寫；

assign屬性： 是默認屬性，直接賦值，沒有任何保留與釋放問題；

retain屬性： 會增加原有對象的引用計數并且在賦值前會釋放原有對象，然后在進行賦值；

copy屬性： 會復制原有對象，并在賦值前釋放原有對象，然后在進行賦值；

2.3.2 使用屬性聲明可能帶來的隱患

當一個非指針變量使用retain（或者copy）這個屬性時，盡量不要顯性的release這個變量；直接給這個變量置空即可；否則容易產生過度釋放，導致程序crash； 例如：

ClassA類的strName是NSString* 類型的變量且聲明的屬性為retain；

ClassA.strName = nil; /* 釋放原有對象且對此對象賦值為空 */

[ClassA.strName release]; /* strName內存可能已經被釋放過了，將導致程序crash */

Assign這個屬性一般是非指針變量（布爾類型，整形等）時用這個類型；屬于直接賦值型，不需要考慮內存的保留與釋放；

如果一個指針類型的變量使用assign類型的屬性，有可能引用已經釋放的變量；導致程序crash； 例如：

ClassB* obj =[[[ClassB alloc] init] autorelease];

ClassA.strName = obj; /* strName 指向obj的內存地址*/

后續(xù)在使用ClassA.strName的時候， 因為obj是autorelease的，可能obj的內存已經被回收；導致引用無效內存，程序crash；

3iOS平臺AutoRelease機制

3.1 自動釋放池的常見問題

大家在開發(fā)iOS程序的時候，是否遇到過在列表滑動的情況內存莫名的增長，頻繁訪問圖片的時候內存莫名的增長，頻繁的打開和關閉數據庫的時候內存莫名的增長…… 這些都是拜iOS的autorelease機制所賜；具體分析如下：

1: 滑動列表的時候，內存出現莫名的增長，原因可能有如下可能：

1：沒有使用UITableView的reuse機制； 導致每顯示一個cell都用autorelease的方式重新alloc一次； 導致cell的內存不斷的增加；

2：每個cell會顯示一個單獨的UIView， 在UIView發(fā)生內存泄漏，導致cell的內存不斷增長；

2: 頻繁訪問圖片的時候，內存莫名的增長；

頻繁的訪問網絡圖片，導致iOS內部API，會不斷的分配autorelease方式的buffer來處理圖片的解碼與顯示； 利用圖片cache可以緩解一下此問題；

3: 頻繁打開和關閉SQLite，導致內存不斷的增長；

在進行SQLite頻繁打開和關閉操作，而且讀寫的數據buffer較大，那么 SQLite在每次打開與關閉的時候，都會利用autorelease的方式分配51K的內存； 如果訪問次數很多，內存馬上就會頂到幾十兆，甚至上百兆！ 所以針對頻繁的讀寫數據庫且數據buffer較大的情況， 可以設置SQLite的長連接方式；避免頻繁的打開和關閉數據庫；

3.2 自動釋放池的概念

NSAutoreleasePool內部包含一個數組（NSMutableArray），用來保存聲名為autorelease的所有對象。如果一個對象聲明為autorelease，系統(tǒng)所做的工作就是把這個對象加入到這個數組中去。

ClassA *obj1 = [[[ClassA alloc] init] autorelease]; //retain count = 1，把此對象加入autorelease pool中

NSAutoreleasePool自身在銷毀的時候，會遍歷一遍這個數 組，release數組中的每個成員。如果此時數組中成員的retain count為1，那么release之后，retain count為0，對象正式被銷毀。如果此時數組中成員的retain count大于1，那么release之后，retain count大于0，此對象依然沒有被銷毀，內存泄露。

3.3 自動釋放池的作用域與嵌套

AutoreleasePool是可以嵌套使用的！

池是被嵌套的，嵌套的結果是個棧，同一線程只有當前棧頂pool實例是可用的：

當短生命周期內，比如一個循環(huán)中，會產生大量的臨時內存，可以創(chuàng)建一個臨時的autorelease pool，這樣可以達到快速回收內存的目的；

3.4 自動施放池的手動創(chuàng)建與自動創(chuàng)建

3.4.1 需要手動創(chuàng)建自動釋放池

●如果你正在編寫一個不是基于Application Kit的程序，比如命令行工具，則沒有對自動釋放池的內置支持；你必須自己創(chuàng)建它們。

●如果你生成了一個從屬線程，則一旦該線程開始執(zhí)行，你必須立即創(chuàng)建你自己的自動釋放池；否則，你將會泄漏對象。

●如果你編寫了一個循環(huán)，其中創(chuàng)建了許多臨時對象，你可以在循環(huán)內部創(chuàng)建一個自動釋放池，以便在下次迭代之前銷毀這些對象。這可以幫助減少應用程序的最大內存占用量。

3.4.2 系統(tǒng)自動創(chuàng)建自動釋放池

Application Kit會在一個事件周期（或事件循環(huán)迭代）的開端—比如鼠標按下事件—自動創(chuàng)建一個自動釋放池，并且在事件周期的結尾釋放它.

4 iOS平臺內存使用陷阱

4.1 重復釋放

在前文已經提到，不要釋放不是自己創(chuàng)建的對象；

釋放自己的autorelease對象，app會crash；

釋放系統(tǒng)的autorelease對象，app會crash；

4.2 循環(huán)引用

循環(huán)引用，容易產生野引用，內存無法回收，最終導致內存泄漏！可以通過弱引用的方式來打破循環(huán)引用鏈；所謂的弱引用就是不需要retain，直接賦值的方式，這樣的話，可以避免循環(huán)引用的問題，但是需要注意的是，避免重復釋放的問題；

5 iOS平臺內存報警機制

由于iOS平臺的內存管理機制，不支持虛擬內存，所以在內存不足的情況，不會去Ram上 創(chuàng)建虛擬內存；所以一旦出現內存不足的情況，iOS平臺會通知所有已經運行的app，不論是前臺app還是后臺掛起的app，都會收到 memory warning的notice；一旦app收到memory warning的notice，就應該回收占用內存較大的變量；

5內存報警處理流程

1： app收到系統(tǒng)發(fā)過來的memory warning的notice；

2： app釋放占用較大的內存；

3： 系統(tǒng)回收此app所創(chuàng)建的autorelease的對象；

4： app返回到已經打開的頁面時，系統(tǒng)重新調用viewdidload方法，view重新加載頁面數據；重新顯示；

5.2 內存報警測試方法

做iOS開發(fā)在模擬器上可以通過 Hardware -> Simulate Memory Warning 模擬內存警告

開發(fā)者可以在模擬器上來模擬手機上的低內存報警情況，可以避免由于低內存報警引出的app的莫名crash問題；

6 iOS平臺內存檢查工具

6.1 編譯和分析工具Analyze

iOS的分析工具可以發(fā)現編譯中的warning，內存泄漏隱患，甚至還可以檢查出logic上的問題；所以在自測階段一定要解決Analyze發(fā)現的問題，可以避免出現嚴重的bug；

內存泄漏隱患提示：

Potential Leak of an object allocated on line ……

數據賦值隱患提示：

The left operand of …… is a garbage value;

對象引用隱患提示：

Reference-Counted object is used after it is released;

以上提示均比較嚴重，可能會引起嚴重問題，需要開發(fā)者密切關注！

6.2 內存檢測工具

內存泄漏檢測工具—Leak

Leak工具可以很容易的統(tǒng)計所有內存泄漏的點，而且還可以顯示在那個文件，哪行代碼有 內存泄漏，這樣定位問題比較容易，也比較方面；但是Leak在統(tǒng)計內存泄漏的時候會把autorelease方式的內存也統(tǒng)計進來； 所以我們在查找內存泄漏情況的時候，可以autorelease的情況忽略掉；

Leak工具：通過Leak工具可以很快發(fā)現代碼中的內存泄漏，通過工具也可以很快找到發(fā)生內存泄漏的代碼段：

6.2內存猛增檢測工具—Allocations

Allocations工具可以很容易的列出所有分配內存的點，這樣我們可以按照分配內存大小來進行排序， 這樣可以很容易的發(fā)現哪些點分配的內存最多，而且是持續(xù)分配，這樣我們來針對性的分析這些持續(xù)分配較大內存的地方；