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能帮助你在Mac上监听HTTP/HTTPS请求和响应的详细内容，而Postman则可以帮助你轻松地生成想要的HTTP/HTTPS请求来测试后端API。
调试技巧(Tips)
开发调试通常都是 Edit->Compile->Run->Edit...这样一个循环。
其实你也可以 Edit->Refresh->Edit...
这就需要借助 Injection for Xcode 这样一个插件，来进行注入更新，它支持iOS和Mac双平台，OC和Swift双语言。
注入更新能加速程序开发和调试的迭代速度，但似乎不能和UI调试工具如SparkInspector一起用。
附：添加全局异常断点，并让所有工程共享
来源：oschina
链接：https://my.oschina.net/u/1256177/blog/540492