這邊文章不是講Instruments 的，另外兩種檢測(cè)內(nèi)存泄漏的方法
內(nèi)存泄漏矮冬。其實(shí)有兩種泄漏。
第一個(gè)是真正的內(nèi)存泄漏次哈，一個(gè)對(duì)象尚未被釋放胎署，但是不再被引用的了。因此窑滞，存儲(chǔ)器不能被重新使用琼牧。
第二類泄漏是比較麻煩一些径筏。這就是所謂的“無界內(nèi)存增長(zhǎng)”。這發(fā)生在內(nèi)存繼續(xù)分配障陶，并永遠(yuǎn)不會(huì)有機(jī)會(huì)被釋放滋恬。
如果永遠(yuǎn)這樣下去你的程序占用的內(nèi)存會(huì)無限大,當(dāng)超過一定內(nèi)存的話 會(huì)被系統(tǒng)的看門狗給kill掉.
另外兩種檢測(cè)內(nèi)存泄漏的方法
第一種
NSZombieEnabled設(shè)置的使用 （z?mbi 僵尸 ）
雖然iOS 5.0版本之后加入了ARC機(jī)制，由于相互引用關(guān)系比較復(fù)雜時(shí)抱究，內(nèi)存泄露還是可能存在恢氯。所以了解原理很重要。如果知道crash的地方了鼓寺，但是不知道具體crash的原因應(yīng)該怎么辦勋拟？
又或者當(dāng)遇到EXC_BAD_ACCESS錯(cuò)誤的時(shí)候，該怎么處理妈候？
（設(shè)置 Enable Zombie Objects參數(shù)敢靡，在可執(zhí)行選項(xiàng)，這有時(shí)候有助于縮小問題原因苦银。
具體設(shè)置方法是：點(diǎn)擊Product--> Scheme -->Edit Scheme 在Run選項(xiàng)的Diagnositics中設(shè)置Enable Zombie Objects啸胧。然后Close。再次運(yùn)行幔虏，可能會(huì)出現(xiàn)一些問題提示纺念。）
1、運(yùn)行Demo想括。
打開運(yùn)行陷谱，崩潰截圖：如圖五
先實(shí)現(xiàn)準(zhǔn)備好的內(nèi)存泄露的Demo：leak app
2.解決方案: 設(shè)置NSZombieEnabled圖五.png
這是一個(gè) “EXC_BAD_ACCESS”錯(cuò)誤。我們打開XCode的選項(xiàng)：“NSZombieEnabled” 瑟蜈。在crash時(shí)可能會(huì)給你更多的一些提示信息烟逊。如圖四 選擇Edit Scheme 會(huì)出現(xiàn)一個(gè)彈窗如圖六操作 勾選 Zomble Objects
3.再次運(yùn)行，再次crash铺根，這次在output窗口會(huì)看到多了一項(xiàng)錯(cuò)誤信息： 2016-11-05 16:51:27.916 XXX [27377:981617] *** -[People setStr:]: message sent to deallocated instance 0x60800000c380
大概意思是：向已釋放的內(nèi)存發(fā)送消息宪躯。也就是說使用了已釋放的內(nèi)存，在C語言相當(dāng)于使用了“野指針”
第二種
靜態(tài)內(nèi)存分析--> Analyze
分析到哪里有內(nèi)存泄露 ( an(?)l??z 愛ne來z 對(duì)...分析）
1.不運(yùn)行程序夷都， app沒有了Crash,直接對(duì)代碼進(jìn)行內(nèi)存分析眷唉，查看一下代碼是否有內(nèi)存泄露
優(yōu)點(diǎn)：分析速度快，并且可以對(duì)所有的代碼進(jìn)行內(nèi)存分析
缺點(diǎn)：分析結(jié)果不一定準(zhǔn)確（沒有運(yùn)行程序囤官，根據(jù)代碼的上下文語法結(jié)構(gòu)）
2.注意：如果有提示有內(nèi)存泄露，一定結(jié)合代碼查看代碼是否有問題
操作步驟:
1蛤虐、Analyze是靜態(tài)分析工具 可以通過菜單 Product→Analyze啟動(dòng)
或者
2党饮、(shift+command+b) 圖八效果如：圖七圖八.png點(diǎn)擊 圖九 里的藍(lán)色按鈕圖七.png顯示如圖十 所示圖九.png圖十.png
Analyze-xcode編輯和解析工具
iOS的分析工具可以發(fā)現(xiàn)編譯中的warning，內(nèi)存泄漏隱患驳庭，甚至還可以檢查出logic上的問題刑顺；所以在自測(cè)階段一定要解決Analyze發(fā)現(xiàn)的問題氯窍，可以避免出現(xiàn)嚴(yán)重的bug；
內(nèi)存泄漏隱患提示：Potential Leak of an object allocated on line ……
數(shù)據(jù)賦值隱患提示：The left operand of …… is a garbage value;
對(duì)象引用隱患提示：Reference-Counted object is used after it is released;
動(dòng)態(tài)內(nèi)存分析(Profile == Instruments )
真正運(yùn)行程序蹲堂，對(duì)程序進(jìn)行內(nèi)存分析（查看內(nèi)存分配情況狼讨、內(nèi)存泄露）
優(yōu)點(diǎn)：分析非常準(zhǔn)確，如果發(fā)現(xiàn)有提示內(nèi)存泄露柒竞，基本可以斷定代碼問題
缺點(diǎn)：分析效率低（真正運(yùn)行了一段代碼政供，才能對(duì)該代碼進(jìn)行內(nèi)存分析）
注意點(diǎn)：如果發(fā)現(xiàn)有內(nèi)存泄露，基本需要修改代碼（基本有內(nèi)泄露）
操作步驟: Product -->Profile-->Allocations
二.內(nèi)存使用注意
1.加載小圖片\使用頻率比較高的圖片
1> 利用imageNamed:方法加載過的圖片, 永遠(yuǎn)有緩存, 這個(gè)緩存是由系統(tǒng)管理的, 無法通過代碼銷毀緩存
2.加載大圖片\使用頻率比較低的圖片(一次性的圖片, 比如版本新特性的圖片)
1> 利用
initWithContentsOfFile:\imageWithContentsOfFile:\imageWithData:等方法加載過的圖片, 沒有緩存, 只要用完了, 就會(huì)自動(dòng)銷毀
2> 基本上, 除imageNamed:方法以外, 其他加載圖片的方式, 都沒有緩存
三.2個(gè)專業(yè)術(shù)語
1.內(nèi)存泄漏
1> 該釋放的對(duì)象, 沒有被釋放(已經(jīng)不再使用的對(duì)象, 沒有被釋放)
2.內(nèi)存溢出(Out Of Memory)
1> 內(nèi)存不夠用了
2> 數(shù)據(jù)長(zhǎng)度比較小的數(shù)據(jù)類型 存儲(chǔ)了 數(shù)據(jù)長(zhǎng)度比較大的數(shù)據(jù)
四.圖片在沙盒中的存在形式(d??pl??m(?)nt,部署)
1.如果項(xiàng)目的Deployment Target <= 6.x (不支持圖片壓縮)
1> 所有圖片直接暴露在沙盒的資源包(main Bundle), 不會(huì)壓縮到Assets.car文件
2.如果項(xiàng)目的Deployment Target >= 7.x (支持圖片壓縮)
1> 放在Images.xcassets里面的所有圖片會(huì)壓縮到Assets.car文件, 不會(huì)直接暴露在沙盒的資源包(main Bundle)
2> 沒有放在Images.xcassets里面的所有圖片會(huì)直接暴露在沙盒的資源包(main Bundle), 不會(huì)壓縮到Assets.car文件
3.總結(jié)
1> 會(huì)壓縮到Assets.car文件, 沒有直接暴露在沙盒的資源包(main Bundle)
- 條件 : "Deployment Target >= 7.x" 并且是 "放在Images.xcassets里面的所有圖片"
- 影響 : 無法得到圖片的全路徑, 只能通過圖片名(imageNamed:方法)來加載圖片, 永遠(yuǎn)會(huì)有緩存
2> 不會(huì)壓縮到Assets.car文件, 直接暴露在沙盒的資源包(main Bundle)
- 條件 : 除1> 以外的所有情況
- 影響 : 可以得到圖片的全路徑, 可以通過全路徑(imageWithContentsOfFile:方法)來加載圖片, 不會(huì)有緩存
4.結(jié)論
1> 小圖片\使用頻率比較高的圖片
* 放在Images.xcassets里面
2> 大圖片\使用頻率比較低的圖片(一次性的圖片, 比如版本新特性的圖片)
* 不要放在Images.xcassets里面
五.設(shè)備信息相關(guān)的開發(fā)(非私有API, 底層API)
1.設(shè)備的型號(hào)
2.設(shè)備的CPU型號(hào)\使用情況
3.設(shè)備的內(nèi)存容量\使用情況
4.設(shè)備的硬盤容量\使用情況
5.......
6.推薦的第三方庫
uidevice-extension
* 地址 : https://github.com/erica/uidevice-extension
* 實(shí)現(xiàn)思路 : 利用分類給UIDevice進(jìn)行了擴(kuò)展
* 使用難易度 : 非常簡(jiǎn)單
六.如何讓程序盡量減少內(nèi)存泄漏
1.非ARC
* Foundation對(duì)象(OC對(duì)象) : 只要方法中包含了alloc\new\copy\mutableCopy\retain等關(guān)鍵字, 那么這些方法產(chǎn)生的對(duì)象, 就必須在不再使用的時(shí)候調(diào)用1次release或者1次autorelease
* CoreFoundation對(duì)象(C對(duì)象) : 只要函數(shù)中包含了create\new\copy\retain等關(guān)鍵字, 那么這些方法產(chǎn)生的對(duì)象, 就必須在不再使用的時(shí)候調(diào)用1次CFRelease或者其他release函數(shù)
2.ARC(只自動(dòng)管理OC對(duì)象, 不會(huì)自動(dòng)管理C語言對(duì)象)
* CoreFoundation對(duì)象(C對(duì)象) : 只要函數(shù)中包含了create\new\copy\retain等關(guān)鍵字, 那么這些方法產(chǎn)生的對(duì)象, 就必須在不再使用的時(shí)候調(diào)用1次CFRelease或者其他release函數(shù)
3.block的注意
// block的內(nèi)存默認(rèn)在棧里面(系統(tǒng)自動(dòng)管理)
void (^test)() = ^{
};
// 如果對(duì)block進(jìn)行了Copy操作, block的內(nèi)存會(huì)遷移到堆里面(需要通過代碼管理內(nèi)存)
Block_copy(test);
// 在不需要使用block的時(shí)候, 應(yīng)該做1次release操作
Block_release(test);
[test release];
