http://www.cocoachina.com/applenews/devnews/2014/0721/9199.html
前言
我們知道，iOS bug定位是極看重crash log的，目前網上提供了不少crash log收集與管理服務，較有名的有Crashlytics, Flurry, 友盟，可能大部分人也就是使用這個。我這裏要說的QuincyKit + KSCrash是一對開源組合，可能沒有前者各種高大上的功能，基本功能還是有的，但更偏重於以下使用場合：
1）訪問外網不太方便，或者大部分情況下在內網測試
2）對出現的crash問題要求快速響應，快速定位
3）需要自己掌控Crash Report，而不是交給別人
顯而易見，第1條就足以把Crashlytics, Flurry, 友盟諸如此類的排除在外了；
關於第2條，我所知道的Flurry顯示crash report延遲比較大，至少爲6小時，Crashlytics稍微好一些，但是它們的服務器在國外，網頁打開也比較慢。這裏要額外說的是比較討厭Crashlytics在程序每次編譯時都會上傳app binary與dSYM文件，在網絡情況較差或app比較大的情況下相當費時。 還有我經歷的另一種情況，就是開發與測試人員相隔比較遠，比如開發的在5樓，測試的在1樓，在最原始的階段測試人員發現了崩潰問題，會將測試設備送到5樓讓開發人員用Mac解析，想想這效率，不言自明瞭吧。
第3點其實比較勉強，crash log又沒多少機密可言。
QuincyKit
相信還是有一些人瞭解QuincyKit的，不過我看到相關的文章比較少。我之前主要參考的是Nico的《QuincyKit的crashReport框架》和《炒冷飯，再提一次QuincyKit》。
QuincyKit，簡而言之，是一個爲iOS和Mac OS X提供的程序崩潰報告管理解決方案。關於QuincyKit的介紹大家看Nico的文章就瞭解得差不多了，它對測試期的應用來說確實是很方便的，不需要提前註冊APP Key，不管你有多少個應用，App中集成了QuincyKit的Client端後，只管向Server端發送crash log就行，Server端會自動根據App ID來分類管理。
QuincyKit分Server端和Client端。它的Server端是用php編寫的，用一個支持PHP5.2以上，還有Mysql、Apache的服務器就可以搭建起一個完整的環境，Mac/Linux/Windows系統上應該都可以完成。看似簡單，實際上對從沒搭建過服務器環境的初學者可能有點麻煩，不用擔心，還有XAMPP這個神器來解決大部分麻煩。當初我圖簡單省事，就是用XAMPP來搭建基本環境的，不過相關的筆記找不到了，這裏就沒辦法貼上了。
另外要說明一下，QuincyKit Server端的Web管理界面比較簡陋，比如連按時間排序的功能都沒有，不過既然是開源的，就不能要求太高，會PHP的完全可以嘗試爲自己訂製更高級的功能。
KSCrash
這裏要說的是我只使用了QuincyKit的Server端，Client端我選擇了KSCrash，可能有很多人對KSCrash對比較陌生，這也不奇怪，在國內就沒見到有人介紹KSCrash。爲什麼是KSCrash呢，箇中原因，且聽我慢慢道來：
1）如果我沒記錯的話，QuincyKit client端生成的crash報告與原生crash報告相比總是缺少最關鍵的那一行，而KSCrash客戶端生成的crash報告會把這關鍵的一行放在最後一行，並提供一些額外的信息，非常有利於問題定位。大部分情況下，我只看這最後一行就能定位到問題所在。
2）QuincyKit在2013年初基本就停止更新了，而KSCrash目前仍舊是持續更新的，對於我們來說最重要是Client端的更新，比如考慮未來支持Swift的可能性。而Server端主要是用來管理crash log，免費開源的QuincyKit足夠對付使用。
3）KSCrash客戶端生成的crash報告在大部分情況下都不需要dSym符號文件你就可以看到函數名，問題比較明顯的話很快就能得到定位。但是默認顯示的行號還是不對的，如果需要具體行號，還得利用dSym符號文件解析crash報告才行。（這點似乎QuincyKit客戶端也支持的）
最關鍵是第1點，我想會不會有人因爲這放棄使用了QuincyKit。
需要注意的是，KSCrash只是一個Client端，本身是沒有Server端的。但這也是它的靈活之處，因爲它能對接免費的QuincyKit，收費的Hockey、Victory等Server端，也能將生成的crash log通過Email的方式發送。這只是KSCrash的特性之一，更多KSCrash的關鍵特性你可以看下面列舉出來的，相信你能看到驚喜：
* 支持設備上解析與離線重新解析
* 生成的報告格式完全兼容iOS原生crash報告格式
* 支持32位和64位模式（實驗性質）
* 能處理mach level下的錯誤，例如堆棧溢出
* 偵測未能捕捉的C++異常的真實原因
* 偵測訪問殭屍(zombie or deallocated)對象的行爲
* 恢復殭屍對象或內存覆蓋情況下NSException的異常信息
* 提取對象異常調用的有效信息（比如發生unrecognized selector sent to instance 0xa26d9a0異常的情況）
* 支持多種Server端，提供方便的API接口
* 顯示堆棧內容
* 診斷崩潰原因
* 記錄比Apple原生crash報告更多的信息，使用JSON格式儲存
* 支持顯示用戶自定義的額外數據
KSCrash能處理的crash分以下幾種：
* Mach kernel 異常
* Fatal signals
* C++ 異常
* Objective-C異常
* 主線程死鎖 (實驗性質)
* 自定義崩潰（腳本語言）
經過我的測試，使用KSCrash目前主要有以下兩個問題：
1) 在部分情況下會造成死鎖（deadlock）crash，這通常是應用在做比較耗時的操作時出現的，如果發生這樣的問題，你應該儘量優化你的APP，避免耗時操作（可能是我打開了死鎖檢測的功能，目前這個功能是Unstable Features）
2) 如果發生crash後重啓應用時收集crash報告的服務器不可達，則之前的crash報告就會被廢棄，即使重新恢復網絡，仍然不會重新發送。
如果有人介意這些問題，可以嘗試自行修改KSCrash的開源代碼達到自己的目的。
需要說明的是，App發佈時，還是建議大家使用Flurry、Crashlytics或者友盟，畢竟你面對的可能是數以萬計甚至更多的用戶。你可以在你的應用中增加一個開關，測試期打開開關使用KSCrash上報crash log，發佈前關閉開關，使用Crashlytics或其它在線crash report工具。萬萬要記得在自己的checklist里加上一條開關狀態覈對，以免忘記。
Crash Log自動解析
關於QuincyKit還有一個解析端，或者說是Mac端，因爲crash log的解析是必須在Mac上進行的。要解析QuincyKit Server端收集到的crash log，就必須在解析端的Mac電腦上執行一個symbolicate.php腳本。它做的事情實際上就是將QuincyKit上未解析過的crash log下載到本地，批量進行解析，然後再批量上傳回去。你可以啓動一個定時任務定時去執行這個腳本，就不用每次都手動執行了。
但是有一個問題，如果你想每次都能解析成功，你的Mac上需要提前擁有與crash log對應的.app文件、.app.dSYM文件的索引。這個索引可以通過mdimport命令來實現（mdimport的介紹可參考這裏）。不過肯定還是有人覺得手動執行mdimport命令進行索引挺麻煩的，最好的辦法還是用腳本將各個流程串通起來自動化實現。
我能想到的一個自動化流程是：
(1) 自動構建版本，生成ipa文件和dSYM.zip文件
(2) 解析端通過腳本拿到ipa文件和dSYM.zip文件，然後copy到指定文件夾，解壓，執行mdimport
(3) 在解析端的Mac電腦上開啓一個定時任務，定時執行symbolicate.php
經歷這3步，就可以保證你在QuincyKit web網頁上永遠看到的是解析後的crash log。
做到了這一切，如果你經歷過手動執行symbolicatecrash命令來解析crash log的階段，就知道一個是天上，一個是地下了。
後記
原諒我沒有貼圖，因爲我都是在公司裏搭的系統，家裏沒有。在網上就找到一張QuincyKit的web管理界面，供參考
搜索資料時還有意外發現，《Doutzen: Local symbolication for QuincyKit》一文的作者做了一個Mac應用來完成解析端的工作，將配置簡單化，並實現了定時自動解析。不過根據評論，應該是不兼容Lion系統，估計更不會兼容最新的10.9/10.10了，好在代碼是開源的，會Mac開發的稍作修改就可以拿來爲己所用了。
還有人用Rails寫了一個類QuincyKit的Server端，提供在線服務網站holdbug.com，但是代碼好像不開源，網站也打不開了，估計是停止支持了，鏈接見這裏。
參考：
The battle of the iOS crash reporters
Doutzen: Local symbolication for QuincyKit
