Android Studio除錯步驟

1.設定斷點

雙擊程式碼左側的空白區域，即可設定斷點

2.按下debug快捷鍵進入debug模式啟動app

3.觸發斷點

應用啟動後，執行到斷點時，AS會自動彈出debug面板，開始debug模式。接下來分析下各個快捷鍵的作用。

4.功能分析

除錯按鍵

從左到右來看下各個快捷鍵的功能：

1. Show Execution Point ：
點選該按鈕時, 游標將定位到當前正在除錯的位置。在我們進行追蹤程式碼後使用這個功能能夠很快繼續下一步除錯。

2. Step Over ：
單步跳過，點選該按鈕將導致程式向下執行一行。如果當前行是一個方法呼叫，此行呼叫的方法被執行完畢後再到下一行，而不會進入方法內部。

3. Step Into ：
單步跳入，執行該操作將導致程式向下執行一行。如果該行有自定義的方法，則進入該方法內部繼續執行，如果是類庫中的方法，則不會進入方法內部。

4. Force Step Into :
強制單步跳入，和step into功能類似，主要區別在於：如果當前行有任何方法，則不管該方法是我們自行定義還是類庫提供的，都能跳入到方法內部繼續執行

5. Drop Frame:
中斷執行,並返回到方法被呼叫的地方,在這個過程中該方法對應的棧幀會從棧中移除,且不會改變上下文。

6. Force Run to Cursor：
忽略已經存在的斷點，將游標定位到相應的位置,然後執行Force Run to Cursor即可執行到指定的地方。

7.Evaluate expression :
能夠獲取到程式中的某個變數，然後輸入需要執行的操作，進行evaluate後能夠顯示出結果，如下圖中，想知道message的長度時，可以對message變數進行計算，輸入messag.length即可獲取result。

斷點管理與檢視顯示

1. View Breakpoints ：
顯示當前的各類檢視的數量及位置，能對每一個斷點進行管理，設定enable等屬性

2.Mute Breakpoints ：
使用該按鈕來切換斷點的狀態:啟動或者禁用.在除錯過程中,你可以禁用暫時禁用所有的斷點,已實現應用正常的執行.該功能非常有用,比如當你在除錯過程中,突然不想讓斷點干擾你所關心的流程時,可以臨時禁用斷點.

3.Get thread dump ：
獲取執行緒Dump,點選該按鈕將進入執行緒Dump介面，可以看到系統各個執行緒的活動狀態，下面一張是網上參考的Thread的各種狀態圖示。

4. Restore Layout：
可以檢視到當前壓入方法棧中的方法，幫助我們返回到之前呼叫該方法的位置。

5. Settings :
這裡的 Auto-Variables Mode是指 開啟這個功能後,idea的Debugger會自動評估某些變數當你執行在某個斷點時,Debugger會檢測當前除錯點之前或者之後的變數的狀態,然後在變數區選擇性輸出，未開啟該功能之前,變數區輸出所有的變數資訊:

在Android Studio 除錯過程中，我們也可以很方便的使用setvalue功能去動態改變某一個變數的值，達到滿足除錯需求的效果。

斷點的型別

在Android Studio中 ，斷點分為以下五種型別。
- 條件斷點
- 日誌斷點
- 異常斷點
- 方法斷點
- 屬性斷點

這裡著重瞭解以下 異常斷點和屬性斷點

異常斷點就是在除錯過程中，一旦發生異常（可以指定某類異常），則會立刻定位到異常丟擲的地方。比如在除錯異常中，我們非常關注執行時異常，希望在產生任何執行異常時及時定位，那麼此時就可以利用該型別異常

Filed WatchPoint是本質上是一種特殊的斷點，也稱為屬性斷點：當我們某個欄位值被修改的時候，程式暫停在修改處。通常在除錯多執行緒時尤為可用。

效能優化工具

Android Studio 自帶的記憶體分析工具Memory，可以很方便的檢視應用記憶體情況，實時地顯示出記憶體佔用情況，記憶體洩漏發生時的主要表現為記憶體抖動，可用記憶體慢慢變少，我們可以根據實際情況分析，從而使用leakCanary等工具進一步去分析記憶體洩漏和OOM等問題。

在Memory提供幾個功能按鈕幫助我們對記憶體進行操作和檢視。

1. Initial GC:
這個命令會讓APP執行一次Full GC。一般是在Dump Heap之前執行一次，這樣會減少很多 用的物件。

2. Dump Java Heap ：
Java Heap 是所有類例項和陣列物件分配的一個執行時資料區，其間所有Java VM執行緒在執行期間共享Heap 中的資料。那麼一個Java heap dump相當於在一個特殊的時間點上生成的一個快照。

我們可以在左上角選擇檢視的heap型別
App heap - 當前app使用的堆
Image heap - 當前app在硬碟上的記憶體對映
Zygote heap - zygote 複製時繼承來的庫、執行時類和常量的資料集。zygote空間裝置啟動時建立，從不分配這裡的空間。

以下步驟是典型工作流程：

• 在HPROF檔案檢視工具中選擇一個類名；
• 選擇該類的一個例項；
• 檢視引用樹；
• 當需要的時候可以右鍵引用樹種的條目跳轉到原始碼或者例項。

3. Start Allocation Tracking ：
這個功能可以記錄一段區間內各個執行緒各個方法的記憶體分配情況，主要用於除錯在複雜系統裡面短時間記憶體暴增造成GC頻繁的Case。使用方法：先點選一次，然後會看到Memory Recorder開始轉動，然後自己開始在APP上面做相應的操作。在合適的時間再點一次，結束記錄。即可生成一個.alloc檔案

通過分析alloc資料，我們可以知道某一個thread裡面的所有的呼叫過的方法所分配的堆大小，通過這些資料可以讓我們針對方法級別堆程式進行優化。

LeakCanary

LeakCanary是Square開源的一個記憶體洩露自動探測神器，它是一個Android和Java的記憶體洩露檢測庫，可以大幅度減少了開發中遇到的OOM問題。
使用方法也很簡單，只需在Application中進行初始化，然後在需要檢測記憶體洩漏的地方進行watch即可

dependencies {
   debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
   releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
   testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
 }

public class ExampleApplication extends Application {

  @Override public void onCreate() {
    super.onCreate();
    if (LeakCanary.isInAnalyzerProcess(this)) {
      // This process is dedicated to LeakCanary for heap analysis.
      // You should not init your app in this process.
      return;
    }
    LeakCanary.install(this);
    // Normal app init code...
  }
}

如果應用中出現記憶體異常的時候，能夠幫助我們定位到哪個地方出現問題：

TraceView

TraceView是從每個方法執行的時間的角度來分析應用的效能，
現來看一下整個TraceView介面的圖，整個介面包括上下兩部分，上面是你測試的程序中每個執行緒的執行情況，每個執行緒佔一行；下面是每個方法執行的各個指標的值。
上面一部分是你測試程序的中每個執行緒執行的時間線，下圖中可以可以看到，主要只有一個main執行緒在執行。

使用TraceView主要有兩種方式：

最簡單的方式就是直接開啟DDMS，選擇一個程序，然後按上面的“Start Method Profiling”按鈕，等紅色小點變成黑色以後就表示TraceView已經開始工作了。然後我就可以滑動一下列表（現在手機上的操作肯定會很卡，因為Android系統在檢測Dalvik虛擬機器中每個Java方法的呼叫，這是我猜測的）。操作最好不要超過5s，因為最好是進行小範圍的效能測試。然後再按一下剛才按的按鈕，等一會就會出現上面這幅圖，然後就可以開始分析了。

第2種方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法，當運行了這段程式碼的時候，就會有一個trace檔案在/sdcard目錄中生成，也可以呼叫startMethodTracing(String traceName) 設定trace檔案的檔名，最後你可以使用adb pull /sdcard/test.trace /tmp 命令將trace檔案複製到你的電腦中，然後用DDMS工具開啟就會出現上面圖了。

每個方法前面都有一個數字，可能是全部方法按照Incl CPU Time 時間的排序序號，點一個方法後可以看到有兩部分，一個是Parents，另一個是Children。

• Parent表示呼叫這個方法的方法，可以叫做父方法

• Children表示這個方法中呼叫的其他方法，可以叫做子方法

上圖中橫軸表示各個方法執行佔用的各種時間，呼叫次數等，我們依次來看下

1. Incl Cpu Time：這個指標表示 這個方法以及這個方法的子方法一共執行的時間
2. Excl Cpu Time ：就是方法本身除去子方法後，其他操作所佔用的時間。
3. Incl Real Time ： 應該是這個方法的實際執行時間，可能是因為CPU的上下文切換、阻塞、GC等原因方法的實際執行時間要比Cpu Time 要稍微長一點。.
4. Excl Real Time ： 方法本身除去子方法後，其他操作所佔用的實際時間。
5. Calls + Recur Calls / Total： 一個Call表示這個方法呼叫的次數，Recur Call表示遞迴呼叫次數
6. Cpu Time / Call ： 如名字可知。。。。。
   參考文章：