Android Studio のデバッグ メカニズムとパフォーマンス最適化ツール

Android Studio のデバッグ手順

1. ブレークポイントを設定する

コードの左側にある空白の領域をダブルクリックして、ブレークポイントを設定します

2.デバッグショートカットキーを押してデバッグモードに入り、アプリを起動します

3. ブレークポイントをトリガーする

アプリケーションの開始後、実行がブレークポイントに到達すると、AS は自動的にデバッグ パネルをポップアップ表示し、デバッグ モードを開始します。次に、各ショートカット キーの機能を分析します。

4.機能分析

デバッグボタン

各ショートカット キーの機能を左から右に見てください。

1. Show Execution Point :
このボタンをクリックすると、カーソルが現在のデバッグ位置に配置されます。コードをトレースした後にこの関数を使用すると、デバッグの次のステップにすばやく進むことができます。

2. ステップ オーバー:
ステップ オーバー。このボタンをクリックすると、プログラムが 1 行下に実行されます。現在の行がメソッド呼び出しの場合、この行で呼び出されたメソッドは、メソッドに入らずに次の行に進む前に実行されます。

3. ステップ イン:
ステップ イン、この操作を実行すると、プログラムが 1 行下に実行されます。行にカスタム メソッドがある場合は、実行を継続するためにメソッドに入ります。クラス ライブラリ内のメソッドである場合は、メソッドに入りません。

4. 強制ステップ イン:
強制ステップ インは、関数のステップ インと同様です。主な違いは、現在の行にメソッドがある場合、メソッドが私たちによって定義されているか、クラス ライブラリによって提供されているかに関係なく、そのメソッドにジャンプできることです。メソッドを実行し続ける

5. フレームのドロップ:
実行を中断し、メソッドが呼び出された場所に戻ります. このプロセス中に、コンテキストを変更せずに、メソッドに対応するスタック フレームがスタックから削除されます.

6. Force Run to Cursor:
既存のブレークポイントを無視し、カーソルを対応する位置に配置してから、Force Run to Cursor を実行して、指定された場所まで実行します。

7. 式の評価:
メッセージの長さを知りたい場合、下の図に示すように、プログラムで特定の変数を取得し、実行する操作を入力し、結果を評価して表示できます。 、メッセージ変数を計算し、 messageg .length を入力して結果を取得できます。

ブレークポイントの管理とビューの表示

1. ブレークポイントの表示:
さまざまな現在のビューの数と位置を表示し、各ブレークポイントを管理し、有効化およびその他の属性を設定します

2.ブレークポイントのミュート:
このボタンを使用して、ブレークポイントの状態を切り替えます: 有効または無効. デバッグプロセス中に、すべてのブレークポイントを無効にしたり、一時的に無効にしたりして、アプリケーションを正常に実行できるようにすることができます. この機能は非常に便利です.たとえば、デバッグ プロセス中に、気になるプロセスにブレークポイントが干渉することを急に望まなくなった場合は、ブレークポイントを一時的に無効にすることができます。

3. スレッド ダンプの取得:
スレッドダンプの取得 、このボタンをクリックしてスレッド ダンプ インターフェイスに入ります。システム内の各スレッドのアクティビティ ステータスを確認できます。次の 1 つは、オンライン参照用のスレッドのさまざまなステータス アイコンです。

4. レイアウトの復元:
現在メソッド スタックにプッシュされているメソッドを表示できるため、メソッドが以前に呼び出された位置に戻ることができます。

5. 設定:
ここでの自動変数モードは、この機能がオンになった後、アイデアのデバッガーが特定の変数を自動的に評価することを意味します. ブレークポイントで実行すると、デバッガーは現在の変数の前後の変数の状態を検出します.この機能が有効になる前に、変数領域はすべての変数情報を出力します。

Android Studio のデバッグ プロセスでは、setvalue 関数を使用して変数の値を動的に変更し、デバッグのニーズを満たすことも簡単にできます。

ブレークポイントのタイプ

Android Studio では、ブレークポイントを次の 5 種類に分けています。
- 条件付きブレークポイント
- ロギング ブレークポイント
- 例外ブレークポイント
- メソッド ブレークポイント
- プロパティ ブレークポイント

ここでは、次の例外ブレークポイントとプロパティ ブレークポイントを理解することに焦点を当てます。

例外ブレークポイントはデバッグ プロセス中にあり、例外が発生すると (特定の種類の例外を指定できます)、例外がスローされた場所をすぐに特定します。たとえば、例外のデバッグでは、実行時例外について非常に懸念しており、実行時例外を時間内に見つけたいと考えています。その後、現時点でこのタイプの例外を使用できます。

フィールド ウォッチポイントは本質的に、属性ブレークポイントとも呼ばれる特別な種類のブレークポイントです。フィールド値が変更されると、プログラムは変更時に一時停止します。これは、複数のスレッドをデバッグする場合に特に便利です。

パフォーマンス最適化ツール

Android Studio に付属のメモリ解析ツール Memory は、アプリケーションのメモリを簡単に閲覧し、リアルタイムでメモリ使用量を表示することができます. メモリ リークが発生した場合、主なパフォーマンスはメモリ ジッタであり、使用可能なメモリが徐々に減少していることを確認できます.実際の状況. 分析, メモリ リークや OOM などの問題をさらに分析するために、leakCanary などのツールを使用します。

メモリには、メモリの操作と表示に役立ついくつかの機能ボタンが用意されています。

1. 初期 GC :
このコマンドは、APP にフル GC を実行させます。一般に、Dump Heap の前に 1 回実行されるため、多くの使用オブジェクトが削減されます。

2. Java ヒープのダンプ:
Java ヒープは、すべてのクラス インスタンスおよび配列オブジェクトによって割り当てられる実行時データ領域であり、実行中にすべての Java VM スレッドがヒープ内のデータを共有します。Java ヒープ ダンプは、特定の時点で生成されたスナップショットに相当します。

左上隅に表示するヒープ タイプを選択できます
アプリ ヒープ - 現在のアプリで使用されているヒープ
イメージ ヒープ - ハードディスク上の現在のアプリのメモリ マップ
Zygote ヒープ - ライブラリ、ランタイム クラス、定数データ セットzygote がコピーされると継承されます。zygote スペースはデバイスの起動時に作成され、ここのスペースが割り当てられることはありません。

次の手順は、一般的なワークフローです。

• HPROF ファイル表示ツールでクラス名を選択します。
• クラスのインスタンスを選択します。
• 参照ツリーを表示します。
• 必要に応じて、樹種を参照するエントリを右クリックして、ソース コードまたはサンプルにジャンプできます。

3. 割り当て追跡の開始:
この機能は、特定の間隔で各スレッドおよび各メソッドのメモリ割り当てを記録できます。主に、複雑なシステムでの短期的なメモリ爆発によって引き起こされる頻繁な GC のケースをデバッグするために使用されます。使用方法: 最初に 1 回クリックすると、メモリ レコーダーが回転し始め、APP で対応する操作を開始します。適切なタイミングでもう一度クリックして、記録を終了します。.alloc ファイルを生成できます

alloc データを分析することで、特定のスレッドで呼び出されたすべてのメソッドによって割り当てられたヒープ サイズを知ることができ、これらのデータを通じて、メソッド レベルのヒープ プログラムを最適化できます。

リークカナリア

LeakCanary は、Square によってオープン ソース化された自動メモリ リーク検出アーティファクトであり、Android および Java 用のメモリ リーク検出ライブラリであり、開発中に発生する OOM の問題を大幅に削減できます。
使用方法も非常に簡単で、アプリケーションで初期化してから、メモリ リークを検出する必要がある場所を監視するだけです。

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...
  }
}

LeakCanary 中国語ユーザーマニュアル

アプリケーションにメモリ例外がある場合、問題が発生した場所を特定するのに役立ちます。

トレースビュー

TraceView は各メソッドの実行時間の観点からアプリケーションのパフォーマンスを分析します
.TraceView インターフェイス全体を見てみましょう.インターフェイス全体には上部と下部が含まれます.上記は、プロセス内の各スレッドの実行ステータスです.各スレッドは 1 行を占めます。以下は、各メソッドによって実行される各メトリックの値です。
上の部分は、テスト プロセスで実行されている各スレッドのタイムラインです. 下の図でわかるように、実行されているメイン スレッドは 1 つだけです.

TraceView を使用するには、主に 2 つの方法があります。

最も簡単な方法は、DDMS を直接開き、プロセスを選択してから、上の [メソッド プロファイリングの開始] ボタンを押すことです. 赤い点が黒くなったら、TraceView が動作を開始したことを意味します. その後、リストをスワイプできます (Android システムが Dalvik 仮想マシン内の各 Java メソッドの呼び出しを検出しているため、携帯電話での操作は間違いなく非常に行き詰まるでしょう。これは私の推測です)。小規模なパフォーマンス テストを実施するのが最善であるため、5 秒を超えて操作しないことをお勧めします。次に、先ほど押したボタンをもう一度押すと、しばらくすると上の図が表示され、分析を開始できます。

2 番目の方法は、android.os.Debug.startMethodTracing(); および android.os.Debug.stopMethodTracing(); メソッドを使用することです。このコードを実行すると、/sdcard ディレクトリにトレース ファイルが生成されます。また、startMethodTracing(String traceName) を呼び出してトレース ファイルのファイル名を設定し、最後に adb pull /sdcard/test.trace /tmp コマンドを使用してトレース ファイルをコンピューターにコピーし、DDMS ツールを使用してそれを開くと、上記が表示されます。

各メソッドの前に番号があり、Incl CPU Time に基づくすべてのメソッドのシーケンス番号である可能性があります。メソッドをクリックすると、2 つの部分 (1 つは親、もう 1 つは子) があることがわかります。

• 親は、このメソッドを呼び出すメソッドを示します。これは、親メソッドと呼ぶことができます

• 子は、このメソッドで呼び出される他のメソッドを表し、サブメソッドを呼び出すことができます

上図の横軸は、各メソッドの実行にかかった時間や呼び出し回数などを表しています。 順番に見ていきましょう。

1. Incl Cpu Time: このインジケータは、このメソッドとそのサブメソッドの合計実行時間を示します
2. Excl Cpu Time: メソッド自体がサブメソッドを削除した後、他の操作にかかる時間です。
3. Incl Real Time: このメソッドの実際の実行時間である必要があります.これは、CPU コンテキストの切り替え、ブロック、GC などの理由により、メソッドの実際の実行時間が CPU 時間よりもわずかに長いためである可能性があります. .
4. Excl Real Time: メソッド自体がサブメソッドを削除した後、他の操作にかかった実際の時間。
5. Calls + Recur Calls / Total: Call はこのメソッドが呼び出された回数を示し、Recur Call は再帰呼び出しの回数を示します。
6. CPU 時間 / 呼び出し: 名前が示すように。. . . .
   参考記事：

あなたの知らない Android Studio のデバッグ スキル

転載：https://blog.csdn.net/zoky_ze/article/details/65958628