iOS各类调试技巧

抽刀断Bug

断点，我要说的断点是BreakPoint！基本上不是残废的IDE都具备断点调试功能吧！尤为是XCode，咱们家的IDE断点调试功能但是强中又是强中手！在这以前你们能够先了解一下哈子是断点？它怎么实现的？工做原理怎么样的？

普通操做

点击那个黑列列就建立了一个断点，再次点击就临时取消这个断点(可是不删除)，长按那个断点拖出去就删除了(mac os的系统工程师就是稀饭拖动的快感)，固然也能够右键那个建立的断点，会弹出相应地菜单。
固然也还能够监视某个变量！

在对象视图中，右键某个对象，点击“Watch ‘XXX’”就完成XXX对象的监视了。

这里我监视了lab这个UILabel的变量，每当这个变量进行更新它的信息就会被打印到控制台。
好吧！咱们最基本的建立断点的工做已经学会了，Xcode舒服在什么地方呢？就是不分Debug模式和Run模式的，能够说是无缝切换的，你只要没有建立断点，那么就是Run的正常模式，若是建立了断点而且运行到断点处，就自动进入Debug模式咯，不像某EC开头的IDE，控制面板就像开飞机的同样，几万个按钮觉得很强大，其实只用了Run和Stop，还有什么Debug模式，App模式……，果真Xcode的优越感在对比中更增强烈了，舒服到极点呀，就像夏天的海风拂过菊花，嗯是的 就是那种感受！
咱们建立好了断点，运行到断点就自动停下来了，像这样：

这些Debug的最基本操做技能是每个入门的IOS开发者都要掌握的

全局断点（Global BreakPoint）

有时候在程序出错的时候不能能准肯定位到奔溃的那一行代码,而是直接跑到main循环或者Appdelegate里面， 或者会给你这样的提示：

在Debug导航面板进行上图的操做，你就创建了全局断点，这样只要遇到错误，debug程序就会自动定位到栈底的信息，也就是你最早出错的代码的那一行，这样你就能够快乐的debug拉~~

条件断点(Condational Breakpoints)

咱们来看一段代码

咱们若是在一个循环里面使用了断点，若是这个循环执行了100万次，那你的断点要执行那么屡次，你不以为蛋蛋都凉了的忧伤么？因此咱们这么作：

这样只有遍历到c==“H”的时候 断点才会被触发。

是否是很棒呢！
有些童鞋的钛合金狗眼已经看到了编辑断点那里有一个Action的东西，那是什么呢？
这个是很是强大的，能够在你断点的位置，执行各类操做，好比执行脚本命令，控制台命令(能够制定调试信息自定义保存)、打印信息等，
博主最喜欢的就是这个Log message啦，简单粗暴！根本就不须要print啊NSLog嘛，直接在断点的Action打印就行了（其实这个是Xcode和调试器结合的高能产物，下面再介绍）。具体能够这样：

固然还有更增强大的条件断点就是这货啦

添加以后在 Symbol 一栏输入 viewDidLoad。
这样一来，在程序中全部的 viewDidLoad 方法被调用时都会触发断点。

固然，咱们也能够仅仅为特定的某个类的方法添加断点。在 Symbol 一栏输入 [ClassName viewDidLoad] (Objective-C) 或 ClassName.viewDidLoad (Swift) 便可。
好比：unrecognized selector sent to instance 0xaxxxx 这种错误，这个instance能够这样快速定位

打印的艺术

尽管ARC已经让内存管理变得简单、省时和高效，可是在object的life-cycles中跟踪一些重要事件依然十分重要。毕竟ARC并无彻底排除内存泄露的可能性，或者试图访问一个被release的对象。为了这个目的，咱们能够很艺术地偷窥对象正在作些什么，想一想就好有快感。

NSLog

小伙伴们第一节课学习ViewController的生命周期的时候，老师确定很猥琐的教了你们，在viewController的每一个生命周期的方法中使用了NSLog来偷窥！没错，这样其实就是最简单爆炸的跟踪生命周期的方法了，不过系统本身的NSLog真心有点羸弱，输出的信息太少，根本就不能知足咱们的欲望，这里我教你们强化你的Log！！
能够用下面的这段宏

开启僵尸对象(Enable NSZombie Objects)

Xcode能够把那些已经release掉得对象，变成“僵尸”，当咱们访问一个Zombie对象时，Xcode能够告诉咱们正在访问的对象是一个不该该存在的对象了。由于Xcode知道这个对象是什么，因此可让咱们知道这个对象在哪里，以及这是何时发生的。
因此Zombies是你的好基友！他可让你输出的信息更具体！！
具体这样作：

本身再试试输出Object的信息咯，是否是很棒呢？
僵尸只能用在模拟器和OC语言哦~

进击的码农

Console(lldb 命令)

咱们的目标是要武装到鼻毛！console窗口你们知道就是哪一个黑乎乎好多字会滚出来，尤为是被逼优鸡干到的时候，那么同窗们有没有遇到这种console呢

咱们家的编译器历史 敬请乱入 《IOS中的预编译指令的初步探究》 ，没错咱们如今正在使用着世界上最好的c、c++、oc、swift的编译器——LLVM,lldb就是这个世界上最好的LLVM的调试器！不要害羞，由于咱们是最优秀的！因此确定要用最好的！千万别客气哟，随便用，就像本身家同样啊，啊 哈哈 吃吃吃 别只顾着吃饭，多夹菜……哎~博主好客的职业病又犯了~，什么？你不知道在哪里用lldb？
首先！你得先crash或者把程序断下来！直到你看到图16的(lldb)字样出现，你就能够敲命令了~~
每次你想查看变量，常量，你要从新写NSLog去打印，而后从新编译，去执行，重头开始？太累了，有了lldb你只要这样

是否是方便到爆炸？
当你有一个switch语句，你为了测试每个case，你都要制造假条件去测试；有一个if…else…语句，你为了测试不一样的状况，你要硬编码写了不一样的状况，编译好几回为了测试每种状况……，我想你应该知道为何本身的头发那么稀疏了。
以上的这些状况，只需一次编译，使用lldb的thread命令，伪造返回值，欺骗寄存器，就能够为所欲为的作完全部测试了。
是否是牛逼到爆炸？
lldb真的很强大，博主没有骗你，这篇博文到此的全部调试技巧lldb均可以实现，各类断点，各类打印，调用python插件，运行中断，操做硬件底层，控制程序运行线程……lldb均可以作到！仿佛lldb就是另外一个强大的世界！！！
是否是强大到爆炸？
其实若是你不想贪多嚼不烂的话，你只要精通这个调试工具，基本前面的调试技能你能够不用学了，在这里博主也是不才，lldb的强大不是博主随便说几句就能够表达的出来的， 
更多地须要你们事必躬亲，才能真正体会到那种美好，那种畅快无比的调试体验！
这里博主无私地掏出任意门，这里有很好的文章！可让你好好的回味，呵呵

Profile(instruments)

这个东西怎么翻译呢？咱们就叫检查器吧！！也许已经学习了IOS开发大半年的你，历来都没注意到或者使用这个工具，可是博主很负责任的告诉你如今市面上任何一款出色的APP都会使用instruments来让代码更加健壮！

instrument里面包含了不少工具，内存溢出分析，性能分析，各类分析…… 若是细说的话，这个真的能够为每一个工具开一篇博客，可是博主是一个懂得授人以鱼不如授人以渔的道理的老司机！因此博主固然不会所有说一遍！咱们就来领着你们看看专用debug的内存溢出分析工具的使用吧！

在使用leaks以前你们能够试试这个“Analyze”

analyze能够快速的发现你的代码中release的问题，以及继承过程当中的父类方法缺失等等问题！通常一个优秀的IOS开发工程师No Warning、Pass Analyze是最基本的操守！我知道你已经对于你本身的项目的上百个warning已经麻木了，但博主我负责人地告诉你，这样很差！

咱们继续回来使用leaks！若是analyze都经过了，那么就可使用leaks工具，发现千年老妖级别的侧漏了！

若是提示某一个对象有侧漏的风险，你还能够这样弹出侧边的拓展细节

直接点击方法就能够直接进入代码部分了！！
是否是很简单粗暴呢！固然还不少其余工具，不过叫作篇幅的东西老是限制人，诶 真蛋疼~真的还想多说点的 
想要更多了解instrument 你们能够看看这篇文章！

Xcode视图调试

最终锁定是可爱又可恨的xib和storyboard出了问题！！某个constraint或者view的嵌套逻辑又或者团队协做Git冲突等等问题，致使io -v什么的错误，这种状况去检查视图文件，可能xcode崩溃打不开那个xib或者storyboard，你直接使用文本工具打开这个xml类型的标记文件，你差点吐血，几万行的记录狗眼都看瞎了……。

可是这个历史要被终结！！由于咱们强大的xcode的视图调试功能！！

如下内容，彻底copy，若有不适，坚持看完！请叫我快乐的搬运工！
抄袭自《View Debugging in Xcode 6》
苹果在Xcode 6中作了很多明显的改善和优化，视图调试就是其中之一。一般，App用户界面的行为不会符合开发者指望的那样，好比或者不展现视图，或者没有正确地展现。本文讲解如何使用Xcode的新的视图调试功能来简化开发者对问题界面的确认和修复。

1.Demo 工程

开始之初先从github（https://github.com/tutsplus/ViewDebugging）上下载示例工程并打开ViewDebugging.xcodeproj。该工程包含一个简单的包含少数视图控制器的可点击的应用程序、应用程序委托以及一个storyboard。该app是为iPhone而设计，但受益于iOS 8的自适应布局,因此界面展现在任何设备上都没有问题。

您刚刚下载的应用程序示例工程是一个简单的to-do list应用程序，包含可查看其余信息的简单屏幕，好比该示例工程中的项目数，用户头像以及@***的推特操做。点击Xcode左上角的运行按钮将展现在iOS模拟器中运行的应用程序。

很快会注意到用户界面中存在问题-表视图中没有展现任何数据。在工程导航面板中打开FirstViewController.swift并找到如下代码：

能够看到mockNotesDataSource变量是表视图的数据源。使用Swift的属性观察者功能，在数据源发生改变时，表视图会自动从新加载。经过查看以上代码片断，你会发现应该应用中应该有4个项目须要展现，但如今不展现数据就说明某些地方出现了差错。

启用视图调试

问题彷佛与用户界面有关。运行app过程当中，按下底部的Debug View Hierarchy 按钮，或者从菜单中选择Debug > View Debugging > Capture View Hierarchy 来启动视图调试。

启动视图调试后，Xcode会对应用程序的视图层次拍一个快照并展现三维原型视图来探究用户界面的层级。该三维视图除了展现app的视图层次外，还展现每一个视图的位置、顺序和视图尺寸，以及视图间的交互方式。

示例工程在Xcode中的三维视图展现正常，但表视图单元格彷佛有点太宽了。

暂停应用程序调试并在左侧选中Main.Storyboard来修复问题。点击表视图并选中Editor > Resolve Auto Layout Issues > Reset to Suggested Constraints.

编译并再次运行应用程序以肯定用户界面展现正常。点击Debug View Hierarchy按钮更进一步了解视图调试的功能。

视图调试功能

点击并拖拽三维渲染图的任意一边，可旋转或者倾斜用户界面，向左或者向右倾斜可选中某个表视图。

选中后，Xcode会高亮该视图，并在会在右边展现Object 和Size检查器。查看在跳转栏顶部并确认UITableView是右边最后一个项目。

Object 和 Size检查器包括大量有用的信息。过去开发者须要依赖日志语句或者断点来检查视图的配置。

打开右边的Size inspector（规格检查器），下方是Auto Layout，能够看到视图上已经应用了正确的约束。在Object inspector中，咱们能够检查所选视图的属性。

从左到右控件排序：

调整视图间距：调整不一样视图间的间距。

展现被剪切的内容：当前展现视图中被剪切的部分。

展现约束：展现选中视图的约束。

重置查看区域：将3D渲染透视图恢复至默认状态。

调整查看模式：选择性地展现3D渲染透视图，好比仅展现内容，仅展现框架以及同时展现内容和框架。

缩小：缩小3D渲染透视图

恢复：将3D渲染透视图恢复至默认尺寸。

放大：放大3D渲染透视图

调整可视视图范围：隐藏视图或展现视图，一步步解析3D渲染视图，向左或者向右滑动滑块儿有相反的效果。

建议花一点时间上手操做下这些空间，并理解各自的用处。

视图层排序

再次编译和运行应用程序，并点击用户界面底部的"More"标签。第一眼看去界面看起来还OK，可是它没有按照开发者的定义准确执行，图片上的模糊效果没有展现出来。咱们能够经过调试视图层次来更好地肯定问题所在。

向左或者向右拖拽视图来查看具体状况，接着将view spacing slider向右拖动。

这样一来，不一样视图间的间距变大了，层次也更加清晰，咱们看到在图片"下方"还隐藏着另外一个视图，选中隐藏的视图，它就是"丢失"的视觉效果视图。

打开Main.storyboard 并选中Second View Controller Scene。在左侧的文档概览面板中，展开Second View Controller的视图对象以查看子视图的排序。

Xcode在文档概览中按照递升顺序堆叠视图，换句话说，列表顶层的视图是视图层次的基础。

修复问题很简单。运行时，Blur Effect View隐藏在Sky Image之下，由于它是视图层次的第一个视图。在文档概览中点击并拖拽 Blur Effect View，结果会以下图展现同样：

再次运行应用程序就能看到模糊效果了。应用程序的用户界面看起来符合设计的初衷。咱们还能够查看iOS模拟器的其余调试功能，看看还完善了其余什么地方或功能。

5.iOS模拟器调试功能

编译并运行应用程序，选中模拟器，从 Debug菜单中选择Color Blended Layers选项。

而后会看到app的用户界面被红色和绿色覆盖，显示了哪些图层能够被叠加覆盖，以及哪些图层是透明的。混合层属于计算密集型视图，因此推荐尽量地使用不透明的图层。

苹果在其文档（iOS Simulator User Guide）中对此进行了注明，并在表视图处理上使用了不透明图层。滚动视图时会有些表现不大好的地方，一个重要的缘由就是使用了混合图层，而若是内容背景是不透明层，那么页面滚动效果就会很是流畅和平稳。

对于这款应用程序来讲，假使用户有数百个项目要展现，可能会出现滚动性能不一致的状况。表视图单元格当前使用的是混合层。因为视图控制器的视图背景是白色，因此无论表视图单元格使用的是混合层或者不透明层，终端用户不会觉察到有什么不同。

打开Main.storyboard并选中To Do list Scene中的表视图单元格属性。在属性检查器（Attributes Inspector）中，向下滚动Drawing分区并勾选Opaque。

在启用Color Blended Layers的状态下编译并运行应用程序。因为表视图单元格如今使用了不透明层，因此会用绿色覆盖，以指示它们是不透明的。

除了标记图层外，还有其余一些有用的功能可帮开发者在iOS模拟器中调试应用。如下是其中一些比较有用的：

Toggle Slow Animations in Frontmost App: 选中模拟器，打开Debug菜单选中Toggle Slow Animations in Frontmost App，该功能能够下降app中动画的运行速度，适合调试包含复杂动画的应用程序。也但是使用快捷键Command-T来操做。
Color Copied Images:该选项能够给绘制时被Core Animation复制的图片添加蓝绿色叠加层。
Color Misaligned Images:若是图片边界没有与目标像素完美对齐，该功能可为图片叠加上一层品红色。若是图片使用肯定的比例大小绘制，那么该功能会为图片添加一层黄色叠加。
Color Off Screen Rendered:.该选项为离屏渲染内容添加一个黄色的叠加层。
不少开发者会忽略接入电话时应用状态栏的设计问题，你能够经过触发通话中状态栏来简单测试。在iOS模拟器中，从Hardware菜单中选中Toggle In-Call Status Bar。

想查看app如何响应事件，可按下Command-T来启用slow animations，并按下Command-Y来展现电话接入时的状态栏。假若你的应用程序使用了导航栏，那么操做系统会为你兼顾到这一起。

除了给视图着色外，还要记住iOS模拟器也能够调试Core Location问题。你能够在特定经纬度模拟设备，

若是你的应用程序使用iCloud来管理数据，你也能够手动触发同步事件。

本文中使用的demo app很是简单，使用文中提到的技术能够帮你在将来节省很多时间。视图调试能够帮你修正不少用户界面中出现的问题。

除了Xcode和InterfaceBuilder以外，使用iOS模拟器的调试功能能够提高应用性能和识别开发过程当中的瓶颈。苹果的人机交互指南（中文版 英文版）强调了积极响应对app的重要性，能让用户以为应用易于使用和操做。苹果对InterfaceBuilder的提高让视图调试变得史无前例的简单。