バックエンド

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

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

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

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

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

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

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

それでも、アプリの実行時の動作に関して重要で正確で適切にフォーマットされたデータを抽出する必要がある場合に信頼するイントロスペクションツールである、王冠のひし形はまだ古き良き時代です Dalvikデバッグモニターサーバー（DDMS） Eclipse Androidプラグインの時代から、Android Studioで使用されています（非常に多くのチームで十分に活用されていません）。

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

Android DDMSカバーイラスト：DDMSを使用した開発者のデバッグ。

そして、DDMSはマスターするのがとても簡単です！

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

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

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

AndroidStudioのDDMSのクイックガイド

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

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

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

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

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

スクリーンショット：Androidデバイスモニターを介したDDMSへのアクセス

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

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

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

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

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

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

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

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

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

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

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

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

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

DDMSのオブジェクト割り当てトラッカー、ユーザーインターフェイス

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

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

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

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

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

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

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のネットワーク統計コンソール

ヒント： 画像をそのままメモリにロードしないでください。これは、発生するのを待っているメモリ不足のクラッシュです。代わりに、縮小された読み込み、またはさらに良いことに、サードパーティライブラリスケーリングを管理します。

この情報を使用することはめったにありませんが、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メモリでは不十分な場合、たとえばメディアを多用するアプリの場合のように、_を上げると、ほとんどのデバイスで15〜20％の追加メモリを獲得できることに注意してください。 largeHeap マニフェストフラグ：https：//developer.android.com/guide/topics/manifest/application-element.html_

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

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

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

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

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

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

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

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

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

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

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

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

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

DDMSでのなりすましに使用される手動の位置制御

Windows7はどの言語で書かれていますか

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

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

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

ここで、エミュレーターにモックルートを設定する段階を見ていきましょう。

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

Googleマップを使用したDDMSでの位置スプーフィング

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

DDMSロケーションスプーフィング：GPSWisualizerのセットアップ

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

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

DDMSロケーションコントロールでのGPXのインポート

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

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

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

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

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

0 2017-02-02T08:01:41Z

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

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

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

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

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