我的debug之旅

      

       其实写这篇博客，抒发自己感慨的意味颇多，我一同期的男同事，工作也半年多了，遇到问题从来都是自己打log，解决不了找我。我今天就问他为什么 不debug，他说不会，o(╯□╰)o我就有感慨了。

       当初学习android的时候最先使用的IDE就是eclipse，鉴于自己是地道的门外汉，一开始接触android的时候，最怕的就是出错，每当程序报错的时候，最愁看那。个红红的报错文档了。这种情况一致持续到我工作。

      我的第一次debug 经历

      工作了以后开发工具就从那个eclipse升级成了学习时只听过的那个传说中的android  studio。因为是新手，写代码报错是家常便饭，记得第一次报空指针的时候，我自己钻研了半天也没找到解决方法，后来公司的姐姐就给我debug了一下，立马就找到了我比较字符串用了“null.equals("s)”把可能为空的放到的前面，分分钟找到了问题的所在，当时姐姐和我说，控制针问题是开发过程中最常见的问题之一， 看报错日志，点击空指针的报错位置，会明确的指出那行报错，就可以去分析谁可能为空。这是我第一次见别人算是正式的给我演示debug的使用，当时我就在想，自己一定要学会用debug 解决问题。然后我自己就照着她说的意思自己整出空指针的问题，去简单的debug解决。这时我只是能找到问题的地方，打一个断点而已。

     debug 断点调试

      一次遇到一个带参数跳转界面请求接口，报错的问题，这次我依着之前的方法去分析，就行不通了。一师兄在关键时刻来拯救了我。他找到报错的位置打了第一个断点，然后依次找出界面跳转的位置，参数设置的位置等标记处断点，然后从源头开始一步步向下找去，一个个断点连着走，直到问题的所在。这次是打开了我新世界的大门，找到了debug正确的打开方式。在调试的过程中，还知道了有断点屏蔽这个功能。鉴于自己不怎么聪明，后来又找师兄演示了两遍，就自己去钻研了。

       我的debug研究

       鉴于上述两次经历，我开始遇到问题自己打断点去找问题。就现在而言当一个问题出现时，首先根具日志看一下是什么类型的错误，是空指针、数据下标越界、数字格式问题、类、方法找不到还是其他的问题，我以我解决空指针问题为例：当出现空指针时，找到相应的行数，看是否有什么对象、字符串，一般找都是对象没有初始化或字符串本该用到值的结果字符串为空，这种就可以以对象、字符串为线索去解决问题。总之遇到问题一般就是找到出错的具体行数打第一个断点，之后思考这行是在做什么实现什么功能和什么方法、类、变量之类的相关，去打其他的断点，一层层的找下去，直到找到功能的起始点。进入debug模式，依次走过每一个断点去分析数据，找出问题。

       debug过程中用的小技巧

       1、在androidstudio中debug"app"的时间往往和运行一个应用的时间相近，总觉得太慢了，这时如果你已经运行过要debug的代码，就可以直接让手机进入debug模式，按钮就是（attache debugger to android process）他的图标是手机旁有个绿色的debug虫子图标。

       2、第二个我常用的就是resume program 按钮，应用场景就是假若你有四个一条逻辑上的断点，当运行到第一个断点的时候的你发现这个断点里没有可以继续查看的价值了就可点击下这个按钮，直接进入下个断点了。

        3、stepover 下一步，进入按钮step into按钮，哦是这样用的，如果在某一方法的引用部分打了断点，想看方法内的逻辑，就可点击这个按钮，进入方法，与其相对应的就是step out了回到进入方法的那个断点。

        4、 还有特别重要的就是，在debug模式下，按住alt键，同时鼠标指到相应的位置是可以查看数值的，这个对于分析数据很好用哦！另外debug也是很有爱的，没debug一行以后，这一行相应的数据都会显示在这一行的后面，非常直观。

     

       虽然我做开发的时间不是很长，但我深深的体会到了debug的好处，遇到问题用它来进行调试，可以很快速的找到问题所在，缩短解决问题的时间，提高效率。如果有幸哪位大神看到了这篇博客，就请鞭笞我吧，有好的debug使用方法技巧也可以告诉我哦！