在我們開發中經常會遇到BAD_ACCESS這樣的錯誤，不用想這就是內存泄漏，即使在現在ARC的大環境下，也會遇到內存過度釋放或是內存泄露的問題;

下面介紹兩種方法來處理BAD_ACCESS：

—————————————————————————————
方案一：

使用Xcode自帶的Instrument,長這個樣子的：

假設現在有一段代碼存在內存泄漏的問題，使用這個工具的步驟如下：

1.設置僵尸對象 （作用是：假設有個對象內存被釋放了，但是你想找到問題所在，這個對象就會讓這個對象的內存不會被釋放，就像活死人一樣，但是切記，解決問題以后，一定要把僵尸對象去掉，不然會遇到很多莫名其妙的Bug）

如圖所示 打開scheme：

• 打開以后界面是這個樣子的，我們使用Instrument 找內存泄漏就需要配合僵尸對象，所以接下來我們需要設置僵尸對象；

2.如圖所示 通過這種方式 打開Instrument

3.打開的界面是這樣的，按照圖中所示進行選擇：

4.進入這樣的界面，按照圖中所示，進行操作：

然后你就會看到這個程序運行起來后的樣子，如圖所示：

點擊你的模擬器 要出問題的地方，把程序搞崩潰，返回到Instrument中，按照下圖進行操作：

點了這個箭頭進去以后，注意到了么？ 有變灰色的行出現了，這就是我們出問題的地方，雙擊這一行進去，就可以定位到我們出問題的地方了：

這里的例子就是因為，二級頁面中沒有移除通知，導致雖然二級頁面pop以后，頁面雖然沒有了，但是這個對象始終沒有釋放掉，仍有一個對象持有他，這就比較尷尬了，就會出現野指針，導致內存問題，不論是ARC還是MRC，都要記住，誰污染誰處理，對象的引用計數為0，才能得到釋放；

—————————————————————————————

方案二：

使用終端命令行加schme的方式進行尋找；

還是使用上面那個例子喲~

1. 編輯scheme，如圖所示：

2.注意到了么？如下圖，你的控制臺多了點東西，兩個箭頭指的東西都是一樣的，我們需要的是前面的那個進程的pid,如1527；

3.運行你的程序，讓它崩潰，在這個例子中，崩潰以后會在控制臺輸出這樣一句話：

message sent to deallocated instance 0x7ff8fdd2f9c0
//0x7ff8fdd2f9c0就是這個對象

4.使用終端，查找問題：

輸入：sudo malloc_history 1527 0x7ff8fdd2f9c0

第一輸入，會讓你輸入這臺電腦的密碼，輸入就是了，沒有關系的；

5.結尾，是不是和上面我們用Instrument找到的同一個地方呢？一般出問題的代碼都在| _objc_rootAlloc | class_createInstance | calloc | malloc_zone_calloc 這些代碼的前面

—————————————————————————————

補充：

1.寫通知 和 NSTimer記住要釋放，Block中解決循環引用。

2.全局斷點：

3.庫文件沖突的時候記住：

要么重新pod 要么刪掉重復的 要么在other link flag刪掉重復的 要么在搜索框搜索重復的 再刪除重復的（比如環信帶音視頻框架和B站框架一起 導入 就會出現這種問題 或者項目已經有MJRefresh 等 再導入環信 也會報重復庫文件沖突）