前言
最近，因為調(diào)試的問題浪費了不少時間，之前不打印崩潰日志的問題，近日又遇到崩潰信息無法定位到具體代碼，只是簡單的報錯信息：
類似這樣的：
-[NSNull length]: unrecognized selector sent to instance 0x1b74e0878
表面看是因為 調(diào)用 length 崩了，全局搜了 length 打斷點也無濟于事，實在頭大，找了各種方法：
方法一：
第一步：需要保存打包的dSYMs文件(查找的時候一定要找到對應(yīng)的dSYMs文件，不然找不到對應(yīng)的代碼)
找到最終需要的符號表文件：
第二步：打開終端，
dwarfdump --arch=arm64 --lookup 0x1b6e54878
（報錯的內(nèi)存地址）/Users/username/Library/Developer/Xcode/Archives/2018-11-11/GantangBus\ 2018-11-11\ 下午8.08.xcarchive/dSYMs/GantangBus.app.dSYM
后邊為項目符號表的目錄，一定是到 app.dSYM 結(jié)束，回車：
恭喜你中獎了，然并卵，這種方式實用于 release 版本的，本地打包的 release 版本也不行，因為 debug 版本 打包后壓根沒有 符號表文件，并且是上線以后用報錯的地址，在上線的這個符號表中才能知道的，適用于上線后的調(diào)試，我猜測是這樣，蘋果有一個隨機地址分配。
像集成騰訊 的 Bugly 上線后上傳符號表文件，隨后就看到找到相應(yīng)報錯的代碼在第幾行了，其他的一個原理。
方法一 kill;
方法二：
其實就是 Xcode 的全局?jǐn)帱c，突然給忘了，忽略了，一時沒想起來，網(wǎng)上查閱時才想起來，以前有的時候可能會不好使，有的好使，其實很簡單 ，如下：
- 在 XCode 界面中按cmd + 相應(yīng)的序號，快捷鍵，或者直接點擊選項卡，跳到Breakpoint的tab 下
- 然后點擊左下角的+號，增加一個Exception的斷點，如下圖所示。
- 點擊接下來會出現(xiàn)一個“All Exception”的調(diào)試選項：
其實已經(jīng) OK 了，一個全局?jǐn)帱c已經(jīng)添加了，將鼠標(biāo)放到上面，右擊選擇“Edit Breakpoint”，可以查看選項的具體內(nèi)容如下：（不用做任何修改，也可以設(shè)置相應(yīng)的條件，編輯斷點）
OK，大功告成，當(dāng)異常出現(xiàn)時，會自動停在異常處，而不會拋出到UIApplicationMain。就可以定位到具體拋出異常的代碼了，完美的解決了我的問題，以前沒發(fā)現(xiàn)這么好使，就沒怎么用了，可能沒注意到吧！
直接定位到我的代碼行數(shù)，原來是因為后臺的數(shù)據(jù)有一條為 null 的情況，沒有做處理造成的。
attributionName = "<null>"
還有數(shù)組越界的情況，很常見了，定位很準(zhǔn)確?。。≠澮粋€，重新啟用
