常見崩潰
1、多線程同步問題造成的Crash
對于數(shù)據(jù)源的訪問一定要注意多線程同時訪問的情況，要做好對它的保護。這里可以使用GCD的串行隊列來同步線程操作。
2、Observer的移除
注冊observer很簡單，但是移除的時候很容易出問題了。要么是忘記移除observer了，要么是移除的時機不對。如果某個被觀察對象已經(jīng)被釋放了，observer還在，那結(jié)果只能是crash了，所以切記至少在dealloc里面移除一下observer。
3、NSMutableArray, NSMutableDictionary成員的判空保護
在addObject或insertObject到NSMutableArray或者NSMutableDictionary時最好加一下判空保護，尤其網(wǎng)絡相關的邏輯，如果網(wǎng)絡返回為空(jason解析出來為空)，而直接add到NSMutableArray里面或者insert到NSMutableDictionary, 那么就會Crash。
關于dSYM文件
dSYM文件：Xcode編譯項目后，會得到一個同名的dSYM文件，dSYM是保存16進制函數(shù)地址映射信息的中轉(zhuǎn)文件，調(diào)試的symbols都會包含在這個文件中，并且每次編譯項目的時候都會生成新的dSYM文件，位于/sers/<用戶名>/Library/Developer/Xcode/Archives目錄下，對于每一個發(fā)布版本都很有必要保存對應的 Archives文件。
當軟件release模式打包或上線后，不會像在Xcde中那樣直觀的看到用崩潰的錯誤，這個時候就需要分析crash report文件，iOS設備中會有日志文件保存每個應用出錯的函數(shù)內(nèi)存地址，通過Xcode的Organizer可以將設備中的Devicelog導出成crash文件，這個時候就可以通過出錯的函數(shù)地址去查詢dSYM文件中程序?qū)暮瘮?shù)名和文件名。大前提是需要有軟件版本對應的dSYM文件，這也是為什么很有必要保存每個發(fā)布版本的Archives文件了。
每一個xx. app和xx.app. dsym文件都有對應的UUD，crash文件也有自己的UUD，只要這三個文件的UUD一致，就可以通過他們解析出正確的錯誤函數(shù)信息了。
- 查看××app文件的UUD，terminal中輸入命令dwarfdump-- uuid xx. app/×x(x代表你的項目名）
- 查看 xx. app.dsYM文件的UUD，在 termina中輸入命令：dwarfdump- uuid xx. app.dSYM
- crash文件內(nèi)第一行Incident Identifier就是該crash文件的UUD
dSYM分析工具：可以分析友盟崩潰日志。
