目錄
image
前言
Debug斷點跟蹤調試是開發過程中分析代碼、解決BUG的一個重要手段，很多程序員的調試水平往往停留在單步執行階段，因為單步執行往往就可以解決大部分的問題。但是一個優秀的程序員不僅僅要解決問題，還要高效地解決問題，本文將介紹一些非常方便的調試技巧
基本使用
Debug App有兩種途徑：
第一種是直接點擊下圖運行按鈕右側的小蟲狀圖標，運行並調試當前Project
第二種就是調試當前已經處於運行狀態下的App，點擊運行按鈕右側第五個按鈕，彈出Choose Process窗口，選擇對應的進程，點擊OK按鈕即可進入調試模式，此時，我們便可以在需要的地方直接下斷點調試代碼了
接下來就是常見的調試方法了，在Debug窗口頂部工具欄有一排操作按鈕，比如Step Over（單步執行）、Step Into（進入方法）等，如圖所示：
打斷點和取消斷點最直接的方式就是單擊目標代碼行的行號右側空白處，然後在Debug窗口左側有個斷點瀏覽按鈕View Breakpoints，位於停止按鈕下方第一個，可以瀏覽Project中的所有斷點，同時可以添加刪除斷點
條件斷點
有時候，我們的斷點打在了循環體裡面，但是我們只想看某一特定循環次數下的運行情況，難道要不停地跳至下一次斷點直至滿足我們的要求嗎？
條件斷點可以自己輸入條件，比如for循環中輸入i == 5即可讓程序直接運行至第六次循環
日誌斷點
打印日誌也是跟蹤程序分析問題的一個非常有效的手段，但是如果我們的程序已經運行並且處於調試模式，此時如果想打印日誌來分析代碼，難道還要停止調試、添加Log代碼並重新編譯運行嗎？
如果使用日誌斷點，就不用這麼繁瑣了。右鍵點擊斷點，在彈出的窗口中取消勾選Suspeng複選框（即表示程序運行至此斷點時不會停下來供開發者調試），然後勾選Evaluate and log，並輸入打印語句即可。這樣，當Debug模式下的程序執行至此，不會停下來，而是在控制檯中打印對應信息
變量賦值
比如，我們的代碼裡有一個變量，這個變量的值會影響到程序的執行結果。如果我們想觀察這個變量在不同的賦值下程序的執行結果怎麼辦呢？難道要一遍遍的在代碼裡修改變量值，然後重新運行程序嗎？顯然這是非常麻煩的操作。如果利用Debug模式下的變量賦值（Set Value），只需要運行一次，就能達到我們的觀察效果。在使用該變量的代碼處打個斷點，然後在Variables窗口找到對應的變量，修改變量值並執行即可
如這裡我們可以把b的值改為false，那麼Toast輸出的值就是Hi
變量觀察
在Variables變量區和Watches觀察區可以查看Debug模式下，程序執行到斷點處的變量值或者對象的各屬性值，如果程序比較複雜變量很多看起來就有點不方便。那麼就可以通過彈出窗口的形式查看屬性值，只要將光標定位至斷點代碼行所用到的變量，IDE會自動彈出一個小窗口，如下圖所示，此時，使用對應的快捷鍵或者點擊這個小窗口裡的變量即可彈出變量屬性值窗口，Mac下的快捷鍵位command + F1，如圖所示：
我們也可以使用New watch，方便我們更快定位到需要觀察的變量
對象求值
在斷點處，如果有變量對象，系統提供了表達式求值功能，針對Variables視圖中的變量對象，我們可以輸入任何計算語句，實時查看錶達式計算結果。具體操作為，右鍵Variables視圖中的變量對象，選擇Evaluate Expression，彈出表達式窗口，輸入任何你想要的計算語句，點擊Evaluate計算按鈕，即可顯示計算結果
方法斷點
當我們想要觀察某個方法的調用時機，可以使用方法斷點
這裡有一個小建議，我們可以在寫一個方法的時候，在方法註釋中列出方法入參，這樣一方面是可以給入參增加一些註釋，同時在打斷點的時候，也能非常直觀的看到方法入參的值
變量斷點
有時候，我們想知道自定義的變量的何時何地發生了改變，就可以使用變量斷點。在變量定義行打斷點，開啟Debug模式，在程序執行的過程中，如果該變量的值發生改變，程序會自動停下來，並定位在改變變量值的地方。這裡要注意的是，對於引用數據類型，通過set方法改變內部的值並不會觸發變量斷點，只有引用的地址發生改變才會觸發
異常斷點
程序在執行的過程中可能會出現各種各樣的未知性異常，如果能在發生異常的時候第一時間讓程序停下來，並定位到異常出現的地方，而不是讓應用直接崩潰，那樣有時候能幫助我們更方便定位問題
打開斷點管理器，點擊工具欄菜單Run，選擇View Breakpoints；在Debug窗口直接點擊View Breakpoints圖標。點擊左上角加號按鈕，可以添加各種斷點，包括前文提到的Method Breakpoints和Field Watchpoints斷點，這裡我們選擇Exception Breakpoints異常斷點，在彈出的Enter Exception Class窗口中輸入需要監控的異常類別即可
這樣當我們運行下面的代碼，IDE會自動幫我們定位到問題發生的位置
image
總結
debug是非常非常基礎的技術，所謂磨刀不誤砍柴工，掌握一些小技巧，往往能幫我們更高效的解決一些問題。本文拋磚引玉，希望大家在開發過程中多留心一些很基礎的技術，有時候瞭解一些你認為很不起眼的知識點，能夠幫助你解決一些很棘手的問題
但是，在多線程環境下，光靠 debug 是不行的。有時 debug 本身會帶來一些問題混淆了現場，比如因為 debug 時的卡頓造成環境不一致等等，這時應該學會使用打日誌的形式幫忙調試，平時打日誌的時候也應該多注意一些規範，這樣能更方便排查問題
Android 發展至今，競爭日趨激烈，衝擊更高的職位，才有更高的收入！而我們Android程序員，要學的東西有很多，要想不被環境淘汰就只有不斷提升自己，從來都是我們去適應環境，而不是環境來適應我們！
附上我的Android核心技術學習大綱，獲取相關內容關注我，私信我【安卓】獲取Android學習pdf總結
閱讀更多 Android01 的文章
