bugly-crash監控能讓我們及時的掌控應用的crash，並快速修復。這種情況就在於我們把應用發布出去了，但是使用者那邊有著各種各樣我們想象不到的系統崩潰，我們無法通過簡單的控制台捕獲錯誤資訊和崩潰的堆疊內容，那麼我們可以利用bugly這樣乙個平台，實時查獲我們的crash資訊。
3、開啟sdk的資料夾，可以看到有libc++ 和libstdc++兩個版本，具體使用哪個我們要根據我們的專案來定
4、開啟如下位置，可以看到我們使用的是libc++
5、將sdk資料夾下對應的framework拉入到我們的專案中
6、在專案中引入如下依賴庫（libc++和libz 在要注意區分是不是arm64，會要求contain bitcode）
8、然後我們在專案中簡單寫乙個陣列越界的bug，測試一下，當然測試的時候，要注意debug完程式，要先斷掉run，然後再單獨在應用程式中跑一次
9、然後就可以在**去檢視crash的資訊
利用「崩潰軌跡」分析崩潰
原文出自 聽雲技術部落格 崩潰，嚴重傷害使用者的情感，嚴重損害使用者體驗，罪惡行徑簡直令人髮指，特請xx獅 xx猿火速緝拿案犯歸案，刻不容緩，欽此。上圖所示，已經定位到某原始檔的某行，再加上崩潰message，崩潰的原因就顯而易見了。但有些崩潰的原因就不是那麼顯而易見了，往往需要尋找更多蛛絲馬跡來定...
利用「崩潰軌跡」分析崩潰
更多技術乾貨請戳 聽雲部落格 崩潰，嚴重傷害使用者的情感，嚴重損害使用者體驗，罪惡行徑簡直令人髮指，特請xx獅 xx猿火速緝拿案犯歸案，刻不容緩，欽此。上圖所示，已經定位到某原始檔的某行，再加上崩潰message，崩潰的原因就顯而易見了。但有些崩潰的原因就不是那麼顯而易見了，往往需要尋找更多蛛絲馬跡...
iOS應用崩潰（三） 崩潰日誌
當我們在模擬器上除錯時，可能經常遇到下面的記憶體訪問錯誤 該錯誤是對乙個已經釋放的物件進行操作，定位如下 2 終端輸入 info malloc history 命令，即可得到堆疊資訊，從而分析具體問題所在 gdb info malloc history 0x12e4b0 3 也可輸入如下資訊 gdb...