前言

为什麽要把 debug 拿出来说呢？
我发现其实 debug 的流程比较少人讨论，
一般我们会看到的讨论文章也只有 error log，
跟系列文章一样，这边也是教大家一些 debug 的技巧。

加速

很多人在 debug 的时候还是会选择按 ，
但这其实是重新编译并从 app 一开启就进入 debug 模式，
可以在 app 开启的状态下按 ，
就会直接进入 debug 模式，不管有没有进 debug 模式，也都可以动态加上中断点。

有条件的中断

有时候中断点是下在回圈里面，
这样即使一直按 F9 跳到下一次中断也还是要花很多时间，
我们可以在中断点上按右键，输入停下来的条件。

evaluate（单步停下来後，按 ⌥+F8）

我们经常遇到以下情境：

• 遇到 bug 回报说一个情境遇到问题
• 视觉设计说要看列表 item 数量 0、多个
• 测试工程师说想知道空值或边际值的情况

我们可以直接在 evaluate 里面写 code，像是：
修改变数

呼叫函式

修改 list

这样做的优点是，我们就不需要 hard code（写死）然後重新编译，
节省时间也避免 hard code 没有改回来的悲剧。

需要特别注意的是：

• 本来该走却没走的流程（当然也可以手动执行）。
• 被改完的变数会不会造成後续问题（比如数据搜集、打 api 後状态变更）。

log 搜集

有时候用户形容的情境我们无法理解，
我们也该建立一套记录 log 的机制，
在合法的情况下（请与法务讨论），
请用户操作，回传 log，
以便判断流程以及遇到的问题。

结语

导致 app 出问题的可能性真的很多，
有的时候甚至跟自己服务都无关，像是用户有开挡广告的 app 导致 api 失效，
建议列出可以调查的方向，
像是内外网 api、旧版更新、装置版本、短网址、协定等等，
至於在开发阶段，我们尽量做到多测不同装置、写测试、考量不同情境，
祝各位永不遇到 timing issue、crash 都有 error log。