Crashlytics 崩潰日誌記錄工具

crashlytic 成立於2023年，是專門為移動應用開者發提供的儲存和分析應用崩潰資訊的工具。crashlytics的使用者包括：支付工具paypal, 點評應用yelp, **分享應用path, **應用groupon等移動應用。

2023年1月，crashlytics被twitter收購，成為又乙個成功的創業產品。被收購之後，由於沒有了創業公司的不穩定因素，我們更有理由使用它來分析應用崩潰資訊。

使用crashlytics的好處有：

2、crashlytics可以象bug管理工具那樣，管理這些崩潰日誌。例如：crashlytics會根據每種型別的crash的出現頻率以及影響的使用者量來自動設定優先順序。對於每種型別的crash，crashlytics除了會像一般的工具提供call stack外，還會顯示更多相關的有助於診斷的資訊，例如：裝置是否越獄，當時的記憶體量，當時的ios版本等。對於修復掉的crash日誌，可以在crashlytics的後台將其關掉。下圖所示的是乙個我的早期應用的崩潰記錄，在我修復後，我將其更新為已修復狀態。

3、crashlytics可以每天和每週將崩潰資訊彙總發到你的郵箱，所有資訊一目了然。

下面我就給大家介紹如何使用crashlytics。

crashlytics的服務是免費提供的，但是並不能直接註冊使用，需要先申請，開啟crashlytic的官網 ，輸入自己的郵箱申請使用。如下圖所示：

提交完郵箱之後，你的申請會放在crashlytics的申請佇列中，網頁跳轉到如下介面。在這個介面的右側，你可以提供更多有效資訊來讓crashlytics優先處理你的申請，建議大家都填上更多自己的資訊。

如果順利，通常1-2天左右，你就會收到crashlytics發來的申請通過郵件，如下圖所示，通過郵件鏈結跳轉到註冊介面，填寫密碼即可完成註冊。

didfinishlaunchingwithoptions:(nsdictionary *)launchoptions

之後，執行一下程式，crashlytics就會檢測到你設定成功。如果你感興趣，可以自己手工觸發乙個崩潰記錄，看crashlytics能否幫你收集到。使用如下**即可

[[crashlytics sharedinstance] crash];

如果你想測試乙個exception導致的崩潰，可以使用如下**：

[nsobject doesnotrecognizeselector];

[arraywithonlytwoelements objectatindex:3];

在原理上，crashlytics的通過以下2步完成崩潰日誌的上傳和分析：

提**用sdk，你需要在應用啟動時呼叫其sdk來設定你的應用。sdk會整合到你的應用中，完成crash資訊的收集和上傳。

修改工程的編譯配置，加入一段**，在你每次工程編譯完成後，上傳該工程對應的dsym檔案。研究過手工分析crash日誌的同學應該知道，只有通過該檔案，才能將crash日誌還原成可讀的call stack資訊。

為了更加方便開發者設定相應的工程，crashlytics提供了mac端的應用程式，幫助你檢測相關工程是否正確設定並且提供相應的幫助資訊。後來我還發現，該程式還會自動幫你公升級crashlytics的sdk檔案。雖然這一點很體貼，但是我個人覺得還是不太友好。因為畢竟修改sdk會影響應用編譯後的內部邏輯，在沒有任何通知的情況下公升級，我都無法確定crashlytics有沒有幹壞事。不過國外的服務，特別是象twitter這種相對較大知名度公司提供的服務要有節操得多，所以在這一點上我還是比較放心的。

使用crashlytics可以讓你擺脫管理應用崩潰記錄的煩惱。並且幫助你找出應用的一些重大隱藏性bug。例如我之前寫的乙個應用就過乙個快取過期的問題，只有當快取過期時才會觸發這個bug，這樣的問題在測試人員那邊很難觸發，因為他們不可能了解你的應用內部實現細節。通過crashlytics，使我清楚了解到應用crash的數量和位置，結合自己的開發經驗，就很容易找到問題所在了。

值得一提的是，crashlytics本身的官方文件也非常健全，如果你在使用中遇到任何問題，也可以上去檢視詳細的文件。

願crashlytics能讓大家的應用都更加健壯～

使用Crashlytics收集iOS崩潰報告

雖然說itunes connect上有crash report功能，但好像我還從來都沒在上面收集到過。然後自己動手寫crash report collection功能的成本又太高。所以我將目光投向了第三方整合解決方案。因為ts3的使用者群主要在國外，客戶也在國外，所以國內的 友盟 一開始就被排除了。...

IOS崩潰日誌

1.普通崩潰日誌 參考 1 程序資訊 incident identifier 30e46451 53fd 4965 896a 457fc11ad05f 崩潰報告的唯一識別符號 是與裝置標識相對應的唯一鍵值。雖然它不是真正的裝置識別符號，但也是乙個非常有用的情報 如果你看到100個崩潰日誌的crash...

iOS應用崩潰（三） 崩潰日誌

當我們在模擬器上除錯時，可能經常遇到下面的記憶體訪問錯誤 該錯誤是對乙個已經釋放的物件進行操作，定位如下 2 終端輸入 info malloc history 命令，即可得到堆疊資訊，從而分析具體問題所在 gdb info malloc history 0x12e4b0 3 也可輸入如下資訊 gdb...