前段時間做了一個APP，在測試的時候遇到了很奇怪的閃退情況。

這個APP是有關聲音處理的：裝置一邊錄音，一邊對聲音進行處理。所以需要2個執行緒，一個執行緒將錄音儲存下來，另一個處理儲存下來的聲音。測試的時候，會在1~10min之內，不定時、無預兆的出現閃退的情況，報的錯也各不一樣，有的是

1)”NSGenericException ‘Collection was mutated while being enumerated”

或者：

2)”pointer being freed was not allocated”

還有的閃退資訊提示記憶體用的太多：

3)”crash due to memory pressure”

更有的打出了天書：

4)”First throw call stack:

(0x30170ecb 0x3a907ce7 0x301709b9 0x4a177 0x40a97 0x30b5bab5 0x3013bf0f 0x3013bb2b 0x30139eb3 0x300a4729 0x300a450b 0x350036d3 0x32a05871 0x4f4b9 0x3ae05ab7)”

而時間要求又比較急，真是有點焦頭爛額。經過1天多的研究，這些問題被一一搞定。

首先，第3條，明顯是生成了記憶體而沒有釋放。咦，Objective-C不是有ARC嗎，自動處理記憶體啊，好長時間都沒有因為記憶體煩惱了。但是聲音的處理都是比較底層的，用的都是C語言，對這部分的記憶體，ARC就愛莫能助了。處理起來也不麻煩了，先用Instruments定位一下，哪邊洩漏的記憶體，然後對所有malloc出來的記憶體塊，用完了都free掉。再試一下，記憶體的增加果然慢下來了。

第1條，”Collection was mutated while being enumerated”，意思是，一個物件(一般是NSArray什麼的)在被訪問的時候，這個物件發生了變化，導致程式掛掉了。在我的程式裡，這個物件就是儲存聲音資料的東西，暫且叫它data。第1個執行緒會源源不斷的向data裡寫入新資料，並將舊資料刪掉。而第2個執行緒，則會定時讀取data的內容並做處理。因為這兩個執行緒每次操作data的時間都比較短，所以它們同時操作的情況不是很常見，所以一般程式也能堅持個幾分鐘。然而它們一旦同時對data進行操作/訪問，程式就掛了。

解決方法也很簡單，Objective-C裡有一個語法，專門處理這樣的事：@synchronized(引數){程式碼塊}

當兩個@synchronized程式碼塊的引數相同的時候，這兩個程式碼塊是不能同時操作的。對於引數，我們經常使用self來做引數。例如：

執行緒1：

@synchronized(self){

//寫data

}

執行緒2：

@synchronized(self){

//讀data

}

當執行緒1在寫data時，執行緒2只能等著。這樣就避免了同時多執行緒同時讀/寫global資料塊會出現的閃退問題。

第2條，”pointer being freed was not allocated”，也是因為多執行緒同時寫data的問題，但有一些特殊。data裡只包含了最近一段時間的聲音資料，當data儲存的太多了，就會先將舊資料刪了，再將新資料存起來。問題是執行緒1的呼叫次數非常快，達到1秒鐘50次。有時候上一次呼叫a還沒結束，下一次呼叫b又過來了，這時候就可能會出問題：a檢測到data裡的資料太多了，就將最舊的資料刪了。然而沒等a真正將資料刪除，b又來了，它也要將最舊的資料刪了，這樣同一個資料就要被free兩次，編譯器就要叫：尼碼這個指標裡已經空了，你還要老子再free它，老子不幹了！

解決方法同上，也加一個@synchronized，將這段資料塊包起來，告訴編譯器：為了保證服務質量，每次只向一個執行緒提供服務，等上一位大爺舒坦了，再讓下一個進來。

最後，有時候編譯器還會抽風，只告訴你，”我要掛了！”(EXC_BAD_ACCESS)，然後嘔吐出一大堆排洩物：

“First throw call stack:

(0x30170ecb 0x3a907ce7 0x301709b9 0x4a177 0x40a97 0x30b5bab5 0x3013bf0f 0x3013bb2b 0x30139eb3 0x300a4729 0x300a450b 0x350036d3 0x32a05871 0x4f4b9 0x3ae05ab7)”

作為程式設計師，我們要從這堆排洩物中找到編譯器的病因，看看它到底吃了啥：

在AppDelegate.m里加入這個函式：

void uncaughtExceptionHandler(NSException *exception) {

NSLog(@”CRASH: %@”, exception);

NSLog(@”Stack Trace: %@”, [exception callStackSymbols]);

//Internal error reporting

}

然後：

– (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);

}

這樣，當編譯器掛了的時候，就會打印出這樣的東西：

0   CoreFoundation                      0x30c16f9b <redacted> + 154,
1   libobjc.A.dylib                     0x3b491ccf objc_exception_throw + 38,
2   CoreFoundation                      0x30b4da39 <redacted> + 176,
3   TEST                    0x001ce2c9 -[TestBaseViewController viewDidLoad] + 848,

我們就能看到，問題出在[TestBaseViewController viewDidLoad]函式裡(請忽略後面的+848，我不知道是什麼意思，貌似也沒人知道)。雖然無法定位到具體哪一行，但至少是大大縮小的範圍。

另外，還有一個關於崩潰定位的小技巧：在所有你懷疑會出現閃退的地方附近，瘋狂的NSLog，這樣，當閃退的時候，很快就能定位到在哪個位置閃退了。

對於程式設計師來說，定位到問題意味著問題解決了90%。