iOS開發調試和問題解決策略

iOS開發調試和問題解決策略

常常會聽到有人拋出一些很信息很不全的問題，好比界面顯示不正確、後端網絡請求不通之類的問題，而後開始瞎猜。

我以爲頗有必要分享一下解決問題的範式，由於靠猜的話，十猜九不許。

不要瞎猜，要簡單粗暴地解決問題

「不要瞎猜」是解決問題的首要原則，只有不瞎猜，尋找確切的根據，才能精準和快速地解決問題。

其實解決問題基本上是簡單粗暴的：收集信息，而後根據信息進行調整，而後繼續收集信息...直到問題解決。

收集信息是不可或缺的一個步驟，而它的關鍵問題就是：收集什麼信息纔是有價值的？如何收集這些信息？

根據要解決的問題不一樣，收集的信息類型和方式也會不一樣。

基本和通用的手段：日誌（Log）

日誌基本上是各種問題的最基本和最通用的收集信息方式，放在別的問題領域一樣適用。

記得之前折騰Linux的時候，不去認真檢查日誌，真的是想不到問題是出如今哪裏。

在iOS開發中呢，NSLog應該是人人都在用了。

然而你也會發現，單純的NSLog用多了，也會有些問題，好比老是輸出一大堆無用的信息，除非你在解決完這個問題或解決別的問題時先把無關的NSLog註釋掉。

這種時候，日誌框架就派上用場了，它們能幫你控制日誌的級別、分類和對應的存放位置，有的還提供了工具幫你檢索它。

能夠關注 CocoaLumberjack 和 NSLogger，或者是這個列表：https://github.com/vsouza/awesome-ios#logging

面對崩潰(Crash)

崩潰是很煩人的問題，不少崩潰的實質大致就是「嘗試訪問一個不存在的東西，而後沒有訪問到」。

若是是在調試環境下運行，能夠看調試器(Debbuger)在命令行下輸出的東西，一般它的錯誤信息已經足夠完備。

值得強調的是，一個全局異常斷點是很必要，它讓程序崩潰的時候指向拋出異常的代碼，否則程序一崩潰，xcode就直接跳到main函數去了。

具體方法見文末附錄。

若是是在非調試環境下，就要藉助一些崩潰信息收集的工具了。

蘋果本身有崩潰信息收集的平臺，但我仍是更心怡Twitter的Fabric(之前的Crashlytics)。

調試UI(User Interface)

自XCode6之後，XCode集成了一個簡易的UI調試工具，不過功能上確實不能和第三方的工具相比。

第三方工具推薦兩個，SparkInspector 和 Reveal。

若是想要徹底不改動XCode就啓用第三方工具調試UI，那麼能夠自行經過LLDB動態加載庫，或者在UIApplecationDelegate裏下一個Symbolic斷點，而後自動執行加載第三方庫的命令。

調試網絡請求(Network)

網絡請求是單純的，能夠經過監聽工具查看HTTP/HTTPS請求和響應的全部內容，這樣一來就不再用問你的請求不通是什麼問題了，直接觀察請求和響應吧。

這裏兩個工具是必備的：Charles 和 Postman。

Charles能幫助你在Mac上監聽HTTP/HTTPS請求和響應的詳細內容，而Postman則能夠幫助你輕鬆地生成想要的HTTP/HTTPS請求來測試後端API。

調試技巧(Tips)

開發調試一般都是 Edit->Compile->Run->Edit...這樣一個循環。

其實你也能夠 Edit->Refresh->Edit...

這就須要藉助 Injection for Xcode 這樣一個插件，來進行注入更新，它支持iOS和Mac雙平臺，OC和Swift雙語言。

注入更新能加速程序開發和調試的迭代速度，但彷佛不能和UI調試工具如SparkInspector一塊兒用。

附：添加全局異常斷點，並讓全部工程共享