iOS開發之Crash分析，以及收集

一  先談談iOS的Crash收集方式：

1. APP 發生crash，使用者手機手機上肯定會有crash紀錄，當然刪除了該app，或是刪了再裝 crash紀錄還是沒了。

2. 如果使用者設定-隱私  同意的話，你的crash日誌會傳送到App store，你可以去賬號上去檢視crash日誌 。（PS：但是，這個要使用者自己同意，大部分人選的是不同意，我也選的不同意。可能你的賬號上根本沒有任何crash紀錄，這不代表你的app 沒有crash過。）

3.第三方日誌統計平臺，國外的比如Crashlytics，Hockeyapp，國內的也有 友盟，Bugly 等等。

4.當然也可以自己收集，開源專案很多，如 KSCrash，plcrashreporter，CrashKit 等。（PS：小公司的話，用用第三方的省心點。但是對安全性高的，並且有人力有時間情況下，還是自己實現收集吧，阿里 京東 這些公司肯定不會用 3.xxx  ，都是有自己的收集服務。騰訊肯定用自家的Bugly ）

現在聊聊選用方式：

1.大公司的話，老老實實 自己 實現收集。

2.中小公司的話如果是金融類或是涉及個人資料比較多的，並且使用者量特別巨大的，建議 也是老老實實自己收集。

3.如果你說我是金融類的，目前／以後 使用者不一定多，自己也沒時間 人力搞，那你就用國外的第三方。（PS：個人見解是，你的那點資料對於國外的平臺，人家不是很care，相對安全點。但是，用國內的第三方的話，不是說國內做的不好，而是更容易暴露 你的app 什麼什麼問題。）

4.中小公司涉及使用者安全不是很多的app，以及遊戲，可以考慮使用第三方 ，  友盟 或是 Bugly 。

二  選擇友盟好還是Bugly好？

1.友盟很早就出了，資料統計，推送，crash統計，分享，IM 等 服務很多，也很全。小公司也用的多。（我之前有2個專案都用了友盟 ）

2.Bugly ，看著騷氣的名字還以為是國外的第三方，其實是大企鵝出的，我記得剛出來時間不是很長，但是 騰訊出品，必屬精品 ！騰訊產品，值得信耐！ 打2句騷氣的廣告，因為最近要去騰訊面試，先奶一口。（ps：有一個專案用了Bugly！騰訊的信鴿推送我感覺比  極光 這些好多了。當年有對幾個平臺測試分析，遺憾的是 沒有紀錄下來！）

我個人推薦使用Bugly，騰訊自己的產品也都在用，Bugly定期也有分享文章，都是乾貨，大家可以去搜搜。

三  談談我之前處理一個crash 的經驗，僅做參考

去年某天，人事跟我講他在 app store 下載的 我們自己的app crash了。我當時就想，老子寫的app 竟然會crash？竟然會crash？

1. 我然後問了，哪個介面什麼操作導致的？可以復現嗎？ 得到的結果是，在就診人列表，然後在點選 新增 就診人按鈕的時候 GG的。另外，不是必現的。

2. 我首先跑去 appstore 看下日誌統計，對 一個 紀錄都沒。（這就是要自己實現或是藉助第三方的原因。）

3. 讓測試 用不同機型 跟測。（測試復現率，然而n輪沒有再次crash，為什麼讓測試繼續測，主要是統計下復現率，另外測試的時候多點選下其他介面，有可能是其他頁面有記憶體洩漏，剛好在這個介面時候出了問題，估測下受潛在影響的使用者）

4. 我拿了那crash 的機子 ，匯出了crash日誌到 xcode ，點開日誌 並沒有直觀的顯示哪個地方crash。

5. 我看了下版本，crash 的 是  上個 小版本，目前線上的 這一塊 都有 重寫過，（git還原到上個版本）檢測下程式碼也沒啥問題。

然後只能通過crash和 .app 分析：

1. 建議 桌面 建 個資料夾  appxx  ，然後 將那個閃退 對應的 包  xxx.app 放入  appxx資料夾

2. 開啟終端cd命令，進入該資料夾

3.在命令列輸入“dwarfdump --uuid XXX.app/XXX”

4.在終端中輸入以下命令“atos -o XXX.app/XXX -arch arm64 0x00000001006544f8 ”

“0x00000001006544f8” 這個地址是

檢視日誌搜尋“Triggered by Thread”：得到“Triggered by Thread:  0”，我們知道是0號執行緒閃退，找到0號執行緒得到如下：

Thread 0 Crashed:

0  libsystem_kernel.dylib        0x00000001833114bc mach_msg_trap + 8

1  libsystem_kernel.dylib        0x0000000183311338 mach_msg + 72

2  CoreFoundation                0x0000000183740ac0 __CFRunLoopServiceMachPort + 196

3  CoreFoundation                0x000000018373e7c4 __CFRunLoopRun + 1032

4  CoreFoundation                0x000000018366d680 CFRunLoopRunSpecific + 384

5  GraphicsServices              0x0000000184b7c088 GSEventRunModal + 180

6  UIKit                          0x00000001884e4d90 UIApplicationMain + 204

7  XXX                      0x00000001006544f8 0x10009c000 + 5997816

8  libdyld.dylib                  0x000000018320e8b8 start + 4

XXX：就是你的XXX.app的名稱，找到他的第一個地址，這個地址就是要輸入的地址，如果存在多個地址，那麼直接在後面追加。

最後顯示，是因為友盟統計  的時候 報了錯，第一時間跟友盟技術客服溝通，然後他們有記錄下，承諾下個版本改進。然後我有查詢了一下，使用友盟確實有極小極小的奔潰率，我們app也不是第一個。當然在可接受範圍內。以上的crash分析 只是當時那個階段的解決方式，當然也有更合適的定位方案。

最後結論： 第三方也不要用太多，能自己實現的還是自己實現。