介紹frames、threads、evaluate的使用，斷點的一些屬性以及條件斷點、日志斷點、異常斷點等使用場景，幫助提高debug效率
跳過單步調(diào)試的stepOver stepInto等基礎(chǔ)調(diào)試，從上一幅圖開始。
frames查看幀調(diào)用關(guān)系
圖中右邊箭頭指著的圖標(biāo)用來控制是否顯示frames。
左邊的箭頭指著的是調(diào)用關(guān)系，從Debug的frames也可以看到：onClick是在performClick中調(diào)用的，同時可以看到前面是由ActivityThread調(diào)用。
即使沒有導(dǎo)入frameWork的源碼,從這里點進(jìn)去，也是可以看到ActivityThread（frameWork層）的源碼的！??！（just a joke，只能看看，不能調(diào)試frameWork）
通過這種方式也可以看到activityThread，可以看到app的入口main函數(shù)，就和java的public static void main一樣！
順便看看驗證下ui線程的Looper也是要prepare loop的，只是activityThread在main函數(shù)里面提前做了罷了。
Thread查看線程信息
這里開了2個線程來執(zhí)行doSomeTask函數(shù)，然后在deSomeTask那里斷點，從debug的Threads可以看到除了Thread-154，另外還有個Thread-155也是被斷到了的，把斷點放開后會接著由155線程執(zhí)行doSomeTask。而且從這里我們也可以意識到這是多線程訪問，bug可能來源于線程同步未做好。
evaluate計算運行到斷點時的相關(guān)狀態(tài)
evaluate就是左邊箭頭指著的像計算器的那個小圖標(biāo)。
當(dāng)運行到斷點的時候，點擊evaluate,彈出左邊的彈框，輸入要計算的表達(dá)式，如當(dāng)前的線程信息或者其他你想知道的東西。如圖可以看到當(dāng)前線程id是155，所以不是ui線程（threadId = 1），如果在這個函數(shù)執(zhí)行ui操作會拋出異常（非ui線程更新ui）。
這個操作簡直666啊，如果以前按單步調(diào)試想看某一項信息就比如threadId，必須要寫一行代碼，重新編譯運行
long threadId = Thread.currentThread().getId();
然后斷點到這里看threadId變量的值是多少，而且調(diào)試完了之后還需要把這行代碼刪除掉，用evaluate簡直太方便。
幾種特殊斷點
點擊紅色箭頭或者右鍵黑色箭頭指向的斷點都可以彈出右邊的彈框：設(shè)置斷點的各種屬性。
粉紅色的Suspend指是否掛起，如果勾選了（默認(rèn)suspend），執(zhí)行到斷點處會停下。
藍(lán)色的Condition指掛起的條件，勾選后，符合所寫表達(dá)式的條件才會停下。
黃色的Evaluate and log指會將evaluate的值打印到console上。
紅色的filters指Class的過濾，比如只看某個類的斷點或者不看某個類的斷點。
不同的斷點方式由不同的斷點條件組合而成。
- 條件斷點
勾選Condition，然后寫上需要的條件，比如圖中我覺得Bug很可能出現(xiàn)在isRequestWeb = false的情況，我就把condition寫上去，執(zhí)行時忽略掉為true的情況，專心查看為flase的情況。
又比如循環(huán)遍歷的時候，不想一直手動跳到下一個斷點查看每一個循環(huán)體，就可以寫一個自己想要的條件斷下來。 -
日志斷點
有的時候改bug，不確定問題在哪兒，不能瞎J8到處斷點，一步一步的調(diào)試，這樣太低效了。這時就需要打日志出來看。
但是log的代碼寫上bug改完后，還要把這些log刪除掉，比較麻煩。更麻煩的是加寫一句log，又要重新編譯一次。這時就需要使用日志斷點。
打上斷點，把Suspend打鉤取消掉，這樣程序不會被斷點斷下來。然后evaluate and log寫上需要打印的日志即可。
image.png
如圖無需加代碼，無需重新編譯。直接再觸發(fā)一次斷點，在debug的Console那里就可以看到運行的日志（之前演示多線程的例子，這里就是典型的線程同步的問題，導(dǎo)致請求了2次網(wǎng)絡(luò)）
-
異常斷點
看斷點方式那幅圖綠色的箭頭指向的+，顯示出另外幾種斷點
image.png
其中第一個是方法斷點：也就是斷點打在方法上，斷點的樣子會像左邊的圖標(biāo)那樣（和在方法體里的第一行代碼打斷點差不多）。
第二種是field斷點：用來查看字段的訪問（和在getter setter斷點相似）
image.png
第三種java異常斷點好像有點雞肋的，程序異常的時候，可以通過異常斷點查看是哪個地方出問題了。但是崩潰的時候，也可以通過AS的崩潰日志鎖定出問題的地方。
選中第三個java exception 斷點，在里面輸入格式轉(zhuǎn)化出錯的異常
image.png
OK后斷點里面就有這個format異常的斷點了。
image.png
圖中可以看到，上面還可以選擇Any Exception，即只要是exception都會斷到。
強(qiáng)行寫一個NumberFormat異常，然后重新運行，進(jìn)入debug模式，觸發(fā)異常：
String a = "12a";
try {
int b = Integer.parseInt(a);
} catch (NumberFormatException e) {
e.printStackTrace();
}
可以看到是MainActiviy的237行出現(xiàn)了NumberFormatException,點擊進(jìn)入到對應(yīng)行，果然是那里的問題。
這里為了方便查看就把frames的調(diào)用關(guān)系隱藏掉了，點擊之前frames說的那個圖標(biāo)即可。
異常斷點可以結(jié)合各種filter使用，比如結(jié)合class Filter只查看MainActiviy里面的異常，或者不查看BinaryThree里面的異常，崩潰日志就做不到這一點。
后面的三種暫時也沒用到過，就跳過了。
- 其他
調(diào)試的花樣還有，比如在變量表里面setValue改變變量值、添加到watcher觀察等操作。
總之一切為了提高效率！人生苦短~~
