Android DDMS：究極のAndroidコンソールのガイド

公開: 2022-03-11

開発はトリッキーなビジネスです。ターゲットは動き続け、新しいテクノロジーとドメインが定期的に実現し、新しいツールがときどき出現し、言語は大混乱で管理されているように見えます。

それでも、これらすべての変更があっても、基本的なルールは同じままです。これらの基本的なルールの中で最も重要なものの1つは、本当に素晴らしいソフトウェアを作成するには、実行中のシステムを深く、継続的に、詳細に内省する必要があると述べています。診断、デバッグ、およびプロファイリングは、このコンテキストで使用されることがある用語ですが、ルールはさらに深くなります。一流の開発者は、文字通り自分のシステムを「感じ」ます。彼は、より多くのメモリが解放されるのをチャンク待機すること、スレッドをCPUの枯渇に追い込むこと、そのアクションによって大量のI / Oまたはネットワークアクセスが発生するため、操作全体が遅くなることを知っています。

それを回避する方法は本当にありません。あなたは素晴らしいコードを書く非常に賢い開発者かもしれませんが、上記のスキル、つまりシステムの実行時の動作の詳細を監視および調査できるようになるまでは、本当に一流のサービスを提供することに関しては失敗します。アプリケーション。

実際、ある程度の経験を積んだ後、内省のルールを無視したことに起因する「コード疾患」のカテゴリ全体を検出します。簡単に言えば、実際のプラットフォームへの影響を継続的に監視せずにコード（場合によってはスマートコード）を記述します。。

AndroidのDDMS：内省のための私の選択の武器

私たちにとって幸いなことに、Androidコミュニティは、非常に多くの一流のイントロスペクションツールを提供することができました。 FacebookのStethoは最高の製品のひとつであり、AT＆TのARO（「アプリケーションリソースオプティマイザー」）はやや古いですが、それでも一流であり、おそらく最高のネットワーク監視コンソールを備えています。 it）ランタイムメモリリーク検出ライブラリ。簡単に言えば、Androidデバッグツールに不足はありません。

それでも、アプリの実行時の動作に関して重要で正確で適切にフォーマットされたデータを抽出する必要がある場合に信頼するイントロスペクションツールである王冠のダイヤモンドは、AndroidStudioの古き良きDalvikDebug Monitor Server（DDMS）です。 Eclipse Androidプラグインの時代から、私たちと一緒にいます（多くのチームで十分に活用されていません）。

Android開発においてDDMSはどのくらい重要ですか？さて、DDMSとモバイルアプリの監視について私が今知っていることを一般的に知っていると、5〜6年前は、経験の浅いAndroid開発者として、多くの頭痛とデバッグの夜を節約できたでしょう。

そして重要なのは、DDMSをマスターするのはとても簡単だということです！

もちろん、他のソフトウェアツールと同様に、正しく使用することの大部分には経験が伴います。実行時のパフォーマンス監視が本当に上手になるまで、しばらくの間、専門的なスキルを磨く必要があります。しかし、ほんの数時間でさえ、この記事を読んだ後、私の提案に従い、次のアプリに適用すると、素晴らしい結果が得られます！複雑なシステムでもプロファイリングとチューニングはそれほど難しくありません。それも楽しいことができます！

初心者とマスターレベルのモバイル開発者の違いについてよく質問されます。 AndroidでDDMSを習得すること、または一般的に言えば、アプリケーションのプロファイリングとイントロスペクション機能は、そのような大きな違いの1つです。

注：一流の開発者になるための大部分は、ドメインで利用可能な最高のライブラリを使用することです。 以前のToptalの記事で、Androidで利用できる最高の開発者ライブラリをいくつか挙げました。 ある意味で、この記事は「ライブラリ」記事の続編であり、多くのAndroidツールの1つをカバーしています。 言うまでもなく、Android開発者のスキルを向上させることを目的としている場合は、今すぐお読みください。

AndroidStudioでのDDMSのクイックガイド

それでは、これ以上面倒なことはせずに、究極のAndroid開発者ツールの1つであるDDMSの説明を詳しく見ていきましょう。

努力と利益を比較検討する場合、アプリの品質を向上させ、アプリに含まれている可能性のある非常に厄介でとらえどころのないバグを見つけるのに役立つツールはおそらく他にありません。しかし、それでも、何らかの理由（怠惰、誰か？）のために、非常に多くのチームがDDMSを使用できません。

DDMSのクラッシュコースから始めましょう。

DDMSには、 [スタジオ]>[ツール]>[Android]> [Androidデバイスモニター]からアクセスし、メニューの[DDMS]ボタンをクリックします。上部パネルにショートカットアイコンとして配置することもできます（私はそうします）。

開くと、次のように表示されます。

左側のパネルではデバイス/アプリを選択でき、右側のコンソールでは複数のビューが表示され、それぞれが独自のタブにあり、それぞれがアプリの特定のビューを表示します。

Dalvik DebugMonitorServerが提供する主なサービスは次のとおりです。

アプリのメモリ使用量の統計（ヒープとオブジェクトの割り当ての合計統計）
アプリスレッドの統計
デバイスのスクリーンキャプチャ
デバイスファイルエクスプローラー
着信とSMSのなりすまし
位置データのなりすまし
Logcat

アプリで使用されている現在のヒープメモリ値を取得するには、次のようにします。

アプリが実行されているデバイスを接続します
[ヒープの更新]ボタンをクリックして、ヒープ統計の収集を有効にします
[ヒープ]タブを開きます
「GCの原因」をクリックして、GCを強制的に実行します。そのような実行の後でのみ、ヒープデータ収集が開始されます
タブを開いたまま、アプリでの作業を続行し、定期的に[Cause GC]を再度クリックして、ヒープ統計データを更新します

この最後の行には、おそらく追加の説明が必要です。メモリ使用量は、そのダイナミクスが初期値よりもはるかに重要である分析値の1つです。ほとんどのアプリでは、初期ヒープ使用量の値についてはあまり気にしません。この値の進捗状況については、モバイル開発者が待ち望んでいる真の悪夢の1つであるAndroidメモリリークを明確に示すことができるため、非常に注意を払っています。

スクリーンショット：ヒープデータを使用して、DDMSでAndroidのメモリリークを特定します

ヒープ統計モジュールの使用法は簡単です。アプリ開発のライフサイクルの一環として、ヒープの使用に影響を与える変更を導入した後、モジュール「Cause GC」をアクティブにして統計収集を開始し、アプリのヒープを多用する位置をアクティブにします（通常は複数回）。定期的に「GCを引き起こして」更新します。ヒープの使用量が増え続ける場合は、手にメモリリークがあり、それを解決する必要があります（方法の詳細-以下を参照）。そうでない場合は、実際のヒープサイズに関係なく、問題ありません。

メモリリークが検出された場合、次に使用するツールはオブジェクト割り当てトラッカーです。 Androidのメモリ管理で何ができるか見てみましょう。

オブジェクト割り当てトラッカー

割り当てトラッカーは、簡単に言えば、現在のヒープサイズの「責任」を誰が負っているのかを把握するために必要な情報を提供します。このモジュールでは、割り当てコマンドがどのスレッドとメソッドから取得されたかをリアルタイムで通知するため、Androidでのメモリ分析に非常に役立ちます。

追跡を開始するには、次のようにします。

以前と同様に、関連するデバイス/プロセスを選択します
[割り当てトラッカー]タブに切り替え、[追跡の開始]をクリックして開始します。
ここから、すべての新しい割り当てが追跡されます
[割り当ての取得]をクリックして、すべての最新の割り当てのリストビューを表示します（最後の「開始」から最新）
割り当て権限が誰であるかを確認するには、リスト内の特定の行をクリックします

さて、私自身の経験から、アプリで割り当てを多用するアクションを実行した後、[割り当ての取得]をクリックして割り当てカウンターを表示すると、通常、簡単な方法でリークに誘導されます。場合によっては、リークが非線形である場合（つまり、時々発生する場合）、またはアプリに機能しない可能性のある複数のリークが含まれている場合があります。このような場合、これらの多くに遭遇したことはありませんが、ダンプHPROFファイルを手動で作成して分析する必要があります。この記事では、メモリ分析とAndroidメモリ管理について詳しく説明しません。いくつかのリードについては、ここを参照してください。

スレッド情報コンソール：AndroidのCPU使用率が簡単になりました

開発者にはよく知られているように、実行ロジックの同期パスはスレッドにグループ化され、それぞれがアプリ内で1つのシリアル実行フローを構成します。文字通り、すべてのアプリは複数の実行スレッドを使用します。それらのいくつかは数十を使用します。

スレッドを使用する際の潜在的な問題の全体的な調査は、この記事の範囲外です。次に、スレッド情報コンソールにアクセスする主な問題であるスレッドの枯渇という1つの問題に集中しましょう。

すべてのモバイルアプリケーションで、異なるスレッドがCPU時間を競います。周りを回るのに十分なものはありません。何らかの理由で、これらのスレッドが必要な実行時間を取得できない場合、1つ以上のスレッドはどうなりますか？通常は悪いことです。システムは、計画どおりに動作しません。これは常に悪い考えです。この問題の考えられる理由は、優先度を低く設定すること、他のスレッドが優先度を高くして設定を同時に実行すること、同期モニターに長い時間を費やすことなどです。コードレビューだけでは検出が難しいことで有名です。

Android DDMSスレッドコンソールが救いの手を差し伸べます！

スレッドビューに入ると、スレッドレコードで構成されたリストが表示されます。各レコードには、スレッドの名前とID、およびutimeとstimeと呼ばれる2つの追加のカウンターが含まれています。 Utimeは、スレッドがユーザーコード（関数やサードパーティライブラリを考えてください）を実行するのに費やした合計時間を測定し、stimeは、システムコード（スリープ、同期、システムコールなど）に費やした合計時間を測定します。最初の問題であるutimeは、通常、私たちにとってより興味深いものになりますが、ほとんどの場合、stimeカウンターによって現れる問題について考えることができます。

OK、いくつかのスレッドを含むコードを実行しています。すべてのスレッドがCPU時間の一部を確実に取得できるようにします。このために、最初にシステムをしばらく実行させてから、スレッドタブを開いて、「固有の」utime値の検索を開始します。ゼロは確かに問題を表す可能性があります。スレッドは文字通りCPU時間もCPU使用率もありません。ただし、値が高すぎると、同じ問題の別の側面を表す可能性があります。つまり、優先度が非常に高く、他の人を飢えさせるスレッドです。

あるタイプのスレッドでは、ゼロまたはゼロに近いutime値は実際の問題を示していないことに注意してください。これらはI/Oバウンドスレッドであり、主にネットワークまたはディスク（またはデータベース）アクセスを行うスレッドです。これらのスレッドは、データが到着するのを待つか、保留中のシステムコールをブロックするかのいずれかにほとんどの時間を費やす必要があります。これらのアクションは、どちらもutimeカウンターを増加させません。あなたのスレッドを知ってください！

ヒント：スレッドのデフォルト名は絶対に使用しないでください。 これは何の意味もなく、通常、DDMSビューでの検出に失敗します。 代わりに、スレッドを作成したり、スレッドプールからスレッドをフェッチしたりするときはいつでも、わかりやすい名前を付けて対話を開始してください。 これにより、システムのデバッグ/プロファイリングよりもはるかに簡単になります。 私は通常、Androidで生成されたスレッドと、自分のコードによって生成されたスレッドを区別するために、アプリの名前を付加します。例：MyApp-server-connector、MyApp-db-interactorなど。

ヒント：スレッドの優先度は、（大まかに言えば）スケジューラーによって付与されるCPU時間を示します。 ワーカースレッドに割り当てられた優先度は、アプリの全体的なパフォーマンスと「スムーズさ」にとって非常に重要であり、多くの場合、滑らかな高速動作とでこぼこした低速動作の違いになります。ここでのルールは単純です。Androidによって割り当てられたデフォルトの優先度であるNORMAL=5は、ほとんどの場合、使用したい優先度ではありません。 代わりに、ほとんどのワーカースレッドでは、全体的なCPU使用率への影響をはるかに小さくする必要があります。 これを行うには、スレッドの起動時に、その優先度をより低い値に設定します。通常、priority=3を使用します。

ネットワーク統計コンソール

ネットワーク統計とは、アプリへの着信通信チャネルと発信通信チャネルの両方を、人間が読める形式で監視できるようにすることです。

ネットワークチャートのy軸は、KB /秒で測定された送信の転送速度を表し、x軸は秒で測定された経過時間を表します。したがって、トランスミッションのサイズをすばやく見積もるには、関連するスパイクの面積を見積もってください。しばらくすると、これはかなり簡単になります。

このコンソールに入った後、ネットワーク測定値が表示されるようにするには、上部の「有効化」ボタンをクリックする必要があることに注意してください。

ネットワークコンソールが現在のレベルに成熟する前は、開発者は通常、同様の情報を取得するためにスニファーアプリを使用する必要がありました（一部はまだ使用しています）。

このコンソールの優れている点は、バッテリーの消耗に関する主要な動作の1つである、進行中の小型パケットサイズの通信を視覚化する方法です。多くの人が知っているように、アプリをバッテリーの消耗させるのは、5分間の集中的なネットワークではなく、キープアライブ、診断、ステータスの更新などのための短時間の繰り返しネットワークです。

このようなパターンが検出され、ネットワークコンソールの視覚的なパケット表示によってこれまでになく簡単になったら、すぐにバッチ処理を検討してください。複数の小さなトランスミッションを1つの大きなトランスミッションにまとめることはできますか？この変更によるバッテリーへの影響は、アプリをバッテリーの消耗から正常なカテゴリに移行することになります。

ヒント：画像をそのままメモリにロードしないでください。 これは、発生するのを待っているメモリ不足のクラッシュです。 代わりに、スケールダウンされたロードを実行するか、サードパーティのライブラリを使用してスケーリングを管理します。

この情報を使用することはめったにありませんが、DDMSはAndroid Debug Bridge（ADB）スタックに依存してデバイスとの間でデータをやり取りすることに注意してください。 DDMSがアプリの表示に失敗した場合、またはDDMSセッションの途中でフリーズした場合は、コンソールを開いて次のように入力することをお勧めします。

 adb devices

デバイスがADBでアクセス可能であり、承認されていることを確認します。そうでない場合、多くの場合、ローカルADBサーバーを再起動すると問題が解決するはずです。

 adb kill-server adb devices # restarts the adb server and displays all detected devices

それでも問題が解決せず、アプリが物理デバイスにインストールされている場合は、すべてのエミュレーターインスタンスを切断してみてください。なんで？ DDMSはそれ自体を物理デバイスデバイスとエミュレータインスタンスの両方に接続するため、デフォルトは後者です。

実際のDDMSの使用例：アプリが停止します（クラッシュではなく、停止するだけです）。 ユーザーはすぐに近くのワークステーションに移動し、USBに接続し、スレッドビューでDDMSを開いて、スレッドスタック»失敗したスレッド»スタックトレースを見つけます。私の場合、同期デッドロックが原因で、検出されると、切り替えによって簡単に解決されました。

ヒント： Androidによってアプリに割り当てられた標準のRAMメモリでは不十分な場合、たとえばメディアを多用するアプリで発生する可能性がある場合は、_ largeHeapマニフェストフラグを上げることで、ほとんどのデバイスで15〜20％の追加メモリを取得できることに注意してください：https：//developer.android.com/guide/topics/manifest/application-element.html_

AndroidDDMSでのデバイス状態エミュレーション

原則として、モバイルアプリは線形構造ではありません。代わりに、デバイスの状態の変化を監視して対応できるようにする認識戦略を展開します。アプリは、たとえば、着信やテキストメッセージを聞いたり、ネットワークの状態に応じて状態を再調整したり、デバイスの場所の変化を追跡して対応したりできます。

後者の簡単な例はGPSアプリです。私たちのほとんどはそのようなアプリを開発していませんが（ああ、市場は十分に大きくありません...）、それでも多くの場合、ユーザーの現在の位置の単純なマップビュー、ルートトラッキングであるかどうかにかかわらず、場所に依存するロジックをデプロイします、または場所に応じたデータ表示。

このような状態に敏感な条件のテストは、実際のコードを書くよりも複雑なことで有名です。 SIMを備えた物理デバイスをお持ちの場合は、もちろん、通話やSMSを送受信できます。デバイスのテレフォニーステータスを変更するのは非常に困難ですが、それでも実行できます。ノートパソコンを持って街を散歩することもできますが、場所の変更をテストするのは難しいかもしれません…

しかし、それでも、エミュレータインスタンスをどのように処理するのでしょうか。これらの変更についてどのようにテストできますか？

DDMSが再び救助に。 DDMSの強力でありながら見過ごされがちな機能の1つは、実行中のエミュレーターインスタンスにモックイベントを発行（「なりすまし」）する機能です。 DDMSは、特定の番号からエミュレーターに電話をかけたり、SMSを送信したり、テレフォニーステータスデータを変更したりすることができます。

エミュレータに到達すると、これらのなりすましイベントはすべて、「実際の」イベントと区別できなくなります。つまり、基盤となるハードウェアセンサーによって受信されたかのようになります。具体的には、関連するすべてのアプリの受信者は、実際の通話/SMSメッセージを受信したときと同じ方法でアクティブ化されます。

テレフォニーステータスとアクションのアクティブ化はかなり簡単です。

ネットワーク接続が低い場合（ネットワーク中心のアプリで行う必要があります）についてアプリをテストするには、[テレフォニーステータス]セクションに移動し、速度と遅延の値を目的の値に設定します。私は通常、低い接続性をエミュレートするための効果的な方法として両方のGPRS値を使用しますが、独自の値を自由に設定してください。

電話またはSMSをシミュレートするには、[テレフォニーアクション]セクションに移動し、発信元の電話番号を設定し、必要に応じてテキストメッセージを追加して、発砲します。このツールは、海外からの通話専用のコードルートを設定し、予算内でテストしたい場合に特に効果的です。

新しい場所をあざけることになると、物事はより面白くなります。

エミュレータインスタンスの新しい場所を設定するだけの場合は、[手動]を選択し、目的の緯度/経度の値を設定して、[送信]をクリックします。

しかし、1つの固定位置を設定する代わりに、アプリに事前設定されたルートを通過させたい場合はどうでしょうか。たとえば、ユーザーがある都市から別の都市に移動するときの動作を調べます。このようなテストは、マップに裏打ちされたアプリだけでなく、ユーザーの場所ごとにデータウィンドウを設定する他の場所に依存するアプリにも大きな価値があります。ここでは、異なる速度で位置をシフトすると、表示されているデータウィンドウが最新の状態に保たれることを確認する必要があります。

このために、Google Earthで使用するために特別に開発された、KMLと呼ばれる特別な形式を使用します。これは、GPS対応デバイスで使用できる、空間内の接続ポイントのセットとしてルートまたはパスを表します。

GPXは、DDMSでサポートされている代替パス形式です。すべての実用的な目的で、モバイルロケーションスプーフィングに使用する場合、これら2つは互換性があると見なす必要があります。

ここで、エミュレータへの模擬ルートを設定する段階を見ていきましょう。

ルートを作成します。最も簡単な方法は、適切な出発地と目的地を設定するGoogleマップの方向オプションを使用することです。

ルートが地図上に表示されたら、アドレス行に移動してURLをコピーします
クリップボードのURLを使用して、GPSビジュアライザーに移動し、[URLの提供]テキストボックスに貼り付けて、[変換]ボタンをクリックします。

クリックして、結果のGPXファイルをダウンロードします（例：20170520030103-22192-data.gpx）

DDMS Location Controlに戻り、[GPX]タブを開き、[Load GPX]をクリックして、新しくダウンロードしたファイルを選択します。

終わったね！これで、戻るボタンと進むボタンをクリックするか、再生ボタンをクリックして設定された速度でルートを自動的に通過することにより、異なるルートの場所間を移動できます。

独自のルートを作成する必要はありません。 OpenStreetMapなどのサイトからダウンロードするための多数のルート（「GPSトレース」セクションを参照）。

最後に、ルートファイルのロードが簡単だった古いバージョンのDDMSとは異なり、新しいバージョンでは、特定のルートをロードするときに試行錯誤が必要になる場合があることに注意してください。

たとえば、DDMSではGPX1.1のみがサポートされているようです。新しいGPXバージョンでは、手動で調整する必要がある場合があります。

さらに、GPXウェイポイント形式はサポートされなくなりました。代わりに、GPXトラック形式を使用してください。

 <trk> <name /> <cmt /> <trkseg> <trkpt lat="27.0512" lon="-80.4324"> <ele>0</ele> <time>2017-02-02T08:01:41Z</time> </trkpt> </trkseg> </trk>

Androidのデバッグ：1週間に1時間で違いが生まれます！

十分な理論！練習の時間です。あなたがAndroid開発者であると仮定すると、次のプロジェクトから、DDMSを介してアプリのパフォーマンスを内省するために週に1時間だけ専念することをお勧めします。

質の高い情報（つまり、アプリの状態をすぐに改善するために使用される可能性のある情報）の量に驚かれることでしょう。これにより、情報が提供されます。

Android DDMSは、初心者の開発者と何度も目撃してきましたが、習得して適切に使用すれば、開発者の能力を大幅に向上させることができるツールです。一流のシステムを提供するAndroid開発者の能力は、Android開発におけるDDMSの可能性を最大限に活用すると、文字通り1〜2段階向上します。したがって、DDMSを有効に活用するために数時間を確保することは、Androidのパフォーマンスと効率を大幅に向上させることができるため、賢い投資のように思えます。

賢い人の一人になりましょう。これを使って。