来自于：weixin_39549936
最近遇到很多童鞋，在自己学习开发的时候，顺利的时候还好，一遇到问题就无处下手，今天大智给你分享一下自己的“破案术”，让你解决问题不再迷茫。
这一节主要讲在Unity编辑器中的问题解决方法，发布后的程序（如PC端、WebGL、Andnroid、iOS等）出现异常、崩溃等情况，后面再专门写文章去探讨。

解决问题一般分为几步：
1、观察表现，收集线索，复现问题
2、推测问题所在位置
3、尝试修改并验证
4、验证是否引入了其他问题

1、观察表现，收集线索，复现问题

收集线索是解决问题最重要的一步，有了线索就可以抽丝剥茧，定位问题。
收集线索通常也是最难的一步，原则是：不放过任何信息，将问题复现。
对于英文信息，你要搞明白英文信息的含义。
一般线索从以下几个渠道搜集：

  • 相关提示信息
  • 报错信息
  • 日志信息
  • 运行表现
  • 近期修改的代码

    相关提示信息

    相关提示信息包括各种弹出框、界面上的信息/警告等等。
    很多同学对这些信息视而不见，命名弹出框已经明确告诉你缺少XXX东西了，但是你看都不看就给它关掉了。我太难了。
    比如下图Unity打包Android时的提示：
    image.png
    上面这个提示，只要你把英文看明白，就知道原因是什么，解决办法是什么。

报错信息

很多时候出现问题会有报错或者异常信息，这是非常好的线索。因为报错/异常通常很具体，而且很多可以定位到具体的代码位置。
对于报错信息一定要完整的浏览，不要只看一句报错的概要。
完整的报错信息可能包含：报错的概要信息、详细信息、调用堆栈等等。
有些时候在有异常的时候，异常信息中已经包含了解决异常的办法，一定要仔细去看。

日志信息

日志信息是在运行过程中产生的信息，通常是使用Debug.Log、Debug.Warn、Debug.Error等输出的内容。
日志信息虽然不能直接定位到错误的位置，但是可以看到运行出错之前运行的情况以及对应的代码行。
注意日志信息都是你自己写代码时加的，所以记得在关键位置，或者觉得直觉上容易有BUG的地方保留一些日志。

运行表现

运行表现也就是程序运行中，出现问题时的表现。
运行表现是比较表面的线索，这需要你对代码比较熟悉，才能定位到相关的代码。

近期修改的代码

如果之前运行没有BUG，在修改过某些代码之后出现了错误，就需要着重去排查近期修改的代码中引入的问题。
很多同学说过这样的话：“我什么都没动，昨天还好好的，今天就跑不起来了”。
这话你信么？
我信，不过只有5%的可能是因为运行环境或者服务器出现的问题，95%还是你不经意间改了什么东西导致的。
如果是你不经意间改了什么东西，这个问题还是挺难找的。最好的解药就是版本控制。
一定要做好版本控制，否则你一次不经意间的修改可能会浪费掉一周的时间来DEBUG。

2、推测问题所在的位置

比如有报错/异常信息、日志信息的时候，基本上可以直接定位到有问题的代码行，这样就比较简单。
还有很多时候没办法定位到具体的代码，那该怎么找到出问题的位置呢？
通常有几种方式：

  • 断点调试
  • 加Log
  • 添加/删除代码法
  • Unity 工具窗口

断点调试

断点调试是一个非常常用的工具，适用于大部分可复现的问题。
通过在代码编辑器中打断点，一步一步执行，可以清楚的看到每一步执行后的结果。
断点调试也是一个比较大的话题，后面咱们在开一篇去探索一下。
断点调试不太适用的情况有：循环和多线程。

加Log

不断加Log，直到能定位到出问题的地方。在循环和多线程中出现的问题，加Log这种方法也能有很好的表现。
如果问题是100%复现的，那就比较好办了。肯定能定位到问题所在的位置。如果是偶尔出现的，这种问题最难发现，只能不断加Log，期待它下次出现时能抓到他。

删除/添加代码法（二分法）

在遇到非常复杂的情况时，可以通过定位大概的范围，然后通过二分法删除/添加代码来定位问题。
具体步骤很简单：

  • 先删除一部分代码，看看执行是否如预期。如果还有问题继续删代码。
  • 如果运行代码正常了，可以分批往里面添加代码，直到问题出现。

在删除添加的时候可以使用二分法来提高效率。

Unity 工具窗口

学会合理运用Unity Stats窗口和Profiler window窗口组合调试出需要优化的函数对象（部分卡顿问题）

3、尝试修改并验证

改BUG这个就不用说了，定位到问题，也知道问题所在。
如果还不知道怎么改，这篇文章就帮不了你了，因为问题可能千变万化。
可以根据线索信息去网上搜索或者找人请教。只要不是疑难杂症，网上大部分都能搜到。
修改完后验证是否解决了问题。如果没有解决或者出现了其他问题，请继续解决。

4、验证是否引入了其他问题

最后，也是很多同学容易忽略的一个环节，叫做回归测试。
改完了一个BUG，兴冲冲的提交代码，打包发布，殊不知引入了一个更致命的问题。
在修改完BUG之后，一定要测试，或者给测试同学测试，或者跑自动的测试用例。