開篇
好久沒更新簡書，今天總結一下項目開發中對于已發布項目的bug監控，與發現crash后代碼的調試，本文主要介紹Bugly與zombies。
Bugly
關于Bugly的接入直接可以從文檔上查到詳細的教程，Bugly iOS SDK 使用指南。這里我們主要說一下接入以后的使用方式。
如下圖
在集成了Bugly以后出現crash會在Bugly的后臺體現出來。
在問題詳情處我們可以看到具體的崩潰信息。
符號表
雖然看到了崩潰信息，但是是已經轉化為相關內存地址的信息我們無法看到具體是哪一行代碼出現了問題，于是要進行符號表的配置，符號表配置SDK
-
符號表配置的注意事項
image.png
我們需要上傳的dSYM文件的uuid要與bug提示對應的uuid一致，這樣才能解析出對應的crash信息。
首先要去拿到dSYM文件
顯示包內容之后在dSYMs文件夾內我們可能看到一個或者多個dSYM文件如下圖所示，每次編程打包會生成一個dSYM文件。那么我們怎么知道在這么多文件中那個才是我們需要的呢？
我們可以通過文件名來知道每個dSYMs對應的uuid是多少，也可以通過命令行來查看
xcrun dwarfdump --uuid <dSYM文件>
壓縮對應的dSYM文件，然后上傳至Bugly后臺我們就能看到對應的crash信息。
我們可以看到具體的文件和方法造成了項目的crash，甚至可以精確到對應的行數。那么問題來了？配置了符號表我們就能清楚的看到所有的崩潰信息了嘛，看下圖
驚不驚喜，意不意外，雖然通過Bugly我們看到了crash次數和crash信息，但是我們仍然不清楚是哪里導致的crash，真機調試的時候也確實發現了crash，但是是崩在主線程里。真正的痛苦不是crash，而是我不知道哪里導致了crash。
zombies
面對主線程的crash一般的應對模式是，打開僵尸斷點，然后進行調試，一頓操作之后我們看到了控制臺的打印信息
-[CFString release]: message sent to deallocated instance 0xxxxxxx內存地址xxxxxxx
告訴我這個我也很絕望，我只是想知道崩潰的是哪一行，我又不是計算機要個錘子的內存地址，一頓操作猛如虎，一看戰績??????。。。只能乖乖打開我們的終極神器 zombies
選擇zombies
之后運行項目在crash地點我們可以看到一個紅色的小箭頭，激動人心的時刻終于來了，
就是他，點擊他你將看到真相
點擊之后出現的部分里，對應的高亮部分就是對應的bug信息，這里我們已經可以明確的可以看到類名和方法等，雙擊高亮部分，我們甚至可以看到對應的項目中某一行，沒錯就是這些導致的crash，下面著手改掉他就好了。
后記
通過Bugly與zombies我們可以調試項目中出現的很大一部分問題，終于可以愉快的敲代碼了。
最近半年真的是一言難盡，終于穩定了下來希望以后能多多積累，努力學習，upup。
