React Native DevToolsを使用したコンポーネントレンダリングの検査
React Native 0.83から、Vegaアプリのデバッグとプロファイリングに推奨されるツールはReact Native DevToolsになりました。React Native DevToolsはMetroに組み込まれており、次の機能を提供します。
- 階層、プロパティ、スタイルを調査するコンポーネントインスペクター。
- JavaScriptログを表示するコンソール。
- コンポーネントの再レンダリングとその原因を分析する組み込みプロファイラー。
- より詳細な分析を提供する [Network]、[Performance]、[Memory] の各タブ。
前提条件
- React Native 0.83以降。React Native DevToolsはそれ以前のバージョンでは使用できません。アプリでRN 0.72を使用している場合は、代わりにChrome DevToolsを使用してください。
- 2つのターミナルウィンドウ。1つはポートフォワーディングとアプリの起動のコマンドに使用し、もう1つはMetroバンドラーに使用します。
- デバッグモードでビルドされたVegaアプリ。
React Native DevToolsのセットアップ
手順1: ポートフォワーディングを設定する
1つ目のターミナルで、次のコマンドを実行します。
vega device start-port-forwarding --port 8081 --forward false
複数のデバイスが接続されている場合は、デバイスのシリアル番号を指定します。
vega device start-port-forwarding --port 8081 --forward false -d <<デバイスのシリアル番号>>
Vega仮想デバイスでのテストには、<<デバイスのシリアル番号>>にVirtualDeviceを指定します。
このコマンドを実行すると、プロンプトに戻ることなく実行状態が続きます。これは、転送セッションがアクティブであることを示しています。このターミナルは開いたままにしておきます。
手順2: Metroを起動する
2つ目のターミナルで、プロジェクトディレクトリに移動してMetroバンドラーを起動します。
npm start
Metroサーバーに次のように表示されるまで待ちます。
INFO Dev server ready.
INFO Key commands available:
r - reload app(s)
d - open Dev Menu
j - open DevTools
手順3: デバッグアプリを起動する
Metroが起動したら、1つ目のターミナルに戻り、デバッグバージョンのアプリを起動します。
vega run-app <<デバッグVPKGのパス>> <<対話型コンポーネントのID>>
たとえば、Fire TV Stickでは次のように指定します。
vega run-app build/armv7-debug/keplersample_armv7.vpkg com.amazon.keplersampleapp.main
アプリがMetroに接続すると、Metroターミナルに「BUNDLE index.js」と表示されます。これにより、デバイスがバンドラーと通信していることを確認できます。
Metroに「BUNDLE index.js」と表示されない場合は、ポートフォワーディングが有効になっていることと、アプリよりも先にMetroが起動していることを確認してください。
手順4: React Native DevToolsを開く
Metroターミナルで、jを押してReact Native DevToolsを開きます。ブラウザウィンドウが開き、React Native DevToolsインターフェイスが表示されます。
![React DevToolsの [Components] パネルのスクリーンショット。](https://m.media-amazon.com/images/G/01/mobile-apps/dex/vega/react-devtools/RNDevTools_UI._TTH_.jpg)
タイトルバーにはアプリ名とデバイス情報が表示されます(たとえば、「com.amazon.keplersampleapp (Unknown Device) - React Native DevTools」のようになります)。
React Native DevToolsが開かない場合は、Metroターミナルでrを押して、アプリを再読み込みしてからやり直してください。
アプリの検査とデバッグ
React Native DevToolsには、 [Welcome]、[Console]、[Sources]、[Network]、[Performance]、[Memory]、[Components]、[Profiler] の各タブがあります。このページでは、[Components]、[Profiler]、[Network]、[Performance]、[Memory] の各タブについて説明します。
[Components]
コンポーネントの階層、プロパティ、スタイルを調査するには、[Components] タブを使用します。ツリービューにReactコンポーネントツリーの構造全体が表示されます。これには、RootComponentから、下位にある個々のText要素やView要素までが含まれます。
![React DevToolsの [Components] パネルのスクリーンショット。](https://m.media-amazon.com/images/G/01/mobile-apps/dex/vega/react-devtools/RN_components._TTH_.jpg)
[Profiler]
[Profiler] タブでは、アプリを操作しながらコミットサイクルを記録して、レンダリングパフォーマンスを測定できます。
![プロファイリングが進行中の [Profiler] タブのスクリーンショット。記録を停止するには記録ボタンを押すように指示するメッセージが表示されています。](https://m.media-amazon.com/images/G/01/mobile-apps/dex/vega/react-devtools/RN_profiler_UI._TTH_.jpg)
手順1: プロファイリングを開始する
[Profiler] タブを選択し、ツールバーの記録ボタン(青色の丸)をクリックします。レンダリングデータをキャプチャしている間、画面に「Profiling is in progress...」と表示されます。
手順2: アプリを操作する
プロファイリングがアクティブな状態でアプリを操作して、分析するレンダリング動作をキャプチャします。Reactレンダラーをトリガーする各ユーザー操作が、コミットとして記録されます。
手順3: プロファイリングを停止する
記録を停止するには、赤い記録ボタンをクリックします。プロファイラーは、キャプチャされたコミットをタイムラインに棒グラフとして表示します。
各バーはReactのコミットサイクルを表します。高さのある黄色のバーは、レンダリングに時間がかかっていることを示します。バーを選択すると、そのコミットでレンダリングされたコンポーネントを調べることができます。
手順4: 結果を分析する
プロファイラーには、記録されたデータを分析する2つのビューが用意されています。
[Flamegraph] ビュー
[Flamegraph] には、選択したコミットのコンポーネントツリーが表示されます。各バーは1つのコンポーネントを表します。バーの幅は、レンダリングにかかった時間を示します。右側のパネルには、コミットの詳細が表示されます。
- [Priority] - レンダリングの優先度(NormalまたはSync)。
- [Committed at] - コミットが発生した時点を、プロファイリングの開始からの相対時間で表します。
- [Durations] - レンダリング時間、レイアウトエフェクト、パッシブエフェクト。
- [What caused this update?] - 再レンダリングをトリガーしたコンポーネント。
より詳細なトレース分析については、Vegaアプリでのトレースの検査とUIレンダリングの問題の特定を参照してください。
[Ranked] ビュー
[Ranked] ビューには、コンポーネントの一覧がレンダリング時間順に表示されます。最も低速なコンポーネントが先頭になります。このビューを使用すると、レンダリングのコストが最も高いコンポーネントをすばやく特定できます。
再レンダリングの分析の詳細については、コンポーネントの再レンダリングに関する問題の調査とアプリのKPIの測定を参照してください。
[Network]
[Network] タブでは、HTTPトラフィックとHTTPSトラフィック(fetch呼び出し、XHRリクエスト、メディアセグメントなど)をキャプチャできます。これを使用して、リクエスト、レスポンス、ヘッダー、処理時間を確認したり、コードのどの行で各リクエストが発生したかを追跡したりできます。
[Network] タブでは、次の操作を行うことができます。
- アプリが実行したAPI呼び出しとその結果(成功/失敗)を確認する。
- アプリがサーバーから受信したデータを検査する。
- リクエストをトリガーしたコードを追跡する。
- リクエストの所要時間を測定し、時間がかかっている通信を特定する。
一覧でリクエストを選択すると、以下のサブタブでリクエストの詳細を確認できます。
[Headers]
[Headers] タブでは、URLやメソッドなど、正しいエンドポイントが呼び出されていることを確認できます。成功時のレスポンスは、200 OKのステータスコードによって確認できます。キャッシュ動作、コンテンツタイプ、サーバー情報は、レスポンスヘッダーで確認できます。また、Access-Control-Allow-Originヘッダーを確認して、クロスオリジンリソース共有(CORS)の問題をデバッグすることもできます。
[Preview]
[Preview] タブでは、構造化されたJSONレスポンスを折りたたみ可能なツリービューで参照できます。これにより、生のテキストを読み解かなくても、アプリが受信したデータの構造を確認して、予期しないnull値や不足しているフィールドを一目で特定できます。
[Response]
[Response] タブでは、行番号が付いた生のJSONペイロード全体を確認できます。このビューを使用して、レスポンスデータをコピーしてデバッグや比較を行ったり、APIから返される正確なデータ形式、フィールド名、値を確認したりできます。
[Initiator]
[Initiator] タブでは、ネットワークリクエストをトリガーしたコードを正確に特定できます。ユーザー操作からイベントハンドラーの実行、ネットワーク呼び出しに至るまでの完全なコールスタックが表示されるため、スタック内の任意のエントリを選択して、対応するソースの場所にジャンプできます。
[Timing]
[Timing] タブでは、リクエストの合計所要時間を測定し、停止時間やキューに入っている時間、コンテンツのダウンロード時間などをフェーズごとに分けて確認できます。停止時間が長い場合は、サーバーの遅延ではなく、接続設定のオーバーヘッドが発生していると考えられます。
リクエストの一覧とフィルター
リクエストの一覧には、すべてのリクエストが時系列で表示されます。[Fetch/XHR]、[JS]、[Img]、[Media]、[Other] などのタイプで一覧をフィルタリングし、転送されたデータ全体を追跡できます。タブ上部のタイムラインバーをスクロールすると、現在のウィンドウの外にあるリクエストを確認できます。
レスポンスのオーバーライド
変更されたレスポンスがアプリでどのように処理されるかをテストする場合は、リクエストのコンテキストメニューを開き、[Override headers] を選択して値を編集し、変更を保存します。これは、JSONリクエストとメディアリクエストの両方で利用できます。
メディアトラフィック
ストリーミングアプリの場合、[Media] フィルターではHTTPライブストリーミング(HLS)ビデオセグメント(.tsファイル)が表示され、[Other] フィルターではHTTPを介した動的適応型ストリーミング(DASH)チャンク(.m4sファイル)が表示されます。
[Network] タブの対応機能と非対応機能
次の表は、Vegaで検証済みの [Network] タブの機能をまとめたものです。
| カテゴリー | 機能 | ステータス |
|---|---|---|
| 監視 | Fetch/XHRリクエストのキャプチャ | 対応 |
| 監視 | [Headers]、[Preview]、[Response] の各ビュー | 対応 |
| 監視 | リクエストのイニシエーター(JSコールスタック) | 対応 |
| 監視 | リクエストごとの処理時間(停止/ダウンロード) | 対応 |
| 監視 | プロトコル、サイズ、所要時間 | 対応 |
| 監視 | メディアセグメントのリクエスト(HLS(.ts)/DASH(.m4s)) |
対応 |
| 監視 | SSL/HTTPS復号化(証明書の設定は不要) | 対応 |
| 監視 | ログのフィルタリング、検索、保存 | 対応 |
| 監視 | コンソール統合(リクエストとログの同時表示) | 対応 |
| 監視 | 列のカスタマイズ | 対応 |
| 操作 | ヘッダーとレスポンスのオーバーライド | 対応 |
| 操作 | fetchまたはcURLとしてコピー |
対応 |
| 操作 | セッションのエクスポート(HAR) | 対応 |
| 動作不可 - Charles Proxyを使用 | リクエストのブロック(URLまたはドメイン) | Vegaまたは標準のReact Nativeでは動作不可 |
| 動作不可 - Charles Proxyを使用 | リクエストの再送信(XHRの再送信) | Vegaまたは標準のReact Nativeでは動作不可 |
| DevTools非対応 - Charles Proxyを使用 | ライブブレークポイント | 利用不可 |
| DevTools非対応 - Charles Proxyを使用 | 別のホストへのリダイレクト(リモートマップ) | 利用不可 |
| DevTools非対応 - Charles Proxyを使用 | 帯域幅またはレイテンシの制限 | 利用不可 |
| DevTools非対応 - Charles Proxyを使用 | [Network] の一覧でのWebSocketフレーム表示 | 利用不可([Console] のみ) |
| 制約 | 自動化、CLI、ヘッドレス利用 | インタラクティブ操作のみ |
[Performance]
[Performance] タブでは、アプリのアクティビティを経時的に記録して視覚化できます。これを使用して、ドロップフレームの検出、ネットワークリクエスト・レンダリング・JavaScript実行の重複の把握、メインスレッドをブロックしている原因の特定などを行うことができます。
[Performance] タブでは、次の操作を行うことができます。
- アプリのアクティビティを経時的に記録して視覚化し、ドロップフレームや処理の遅延を特定する。
- ネットワークリクエスト、レンダリング、JavaScriptの実行がタイムライン上でどのように重複しているかを確認する。
- メインスレッドをブロックしている原因やUIがフリーズする原因を特定する。
- Reactのレンダリング、トランジション、Suspenseバウンダリのスケジューリングを把握する。
タイムラインには、CPUとネットワークの各レーン、[Scheduler] トラック([Blocking]、[Transition]、[Suspense]、[Idle])、[Components] トラックが表示されます。[Bottom-up]、[Call tree]、[Event log] の各ビューでは、記録中にどの処理に時間が費やされたかの内訳を確認できます。
より詳細なネイティブレベルの分析については、Vegaアプリでのトレースの検査を参照してください。
[Memory]
[Memory] タブでは、ヒープスナップショットをキャプチャして、アプリが使用しているメモリ量と、それを消費しているオブジェクトタイプを確認できます。スナップショットには、[Functions]、[Arrays]、[CodeBlocks] などのコンストラクターごとに保持メモリがグループ化されて表示されるため、どのオブジェクトタイプが最も多くのメモリを保持しているかを特定できます。
高度なリーク検出については、メモリリークの検出で、MemLabの使用方法に関するガイダンスを参照してください。
その他のタブ
React Native DevToolsには、その他のデバッグ機能と分析機能を提供する以下のタブもあります。
- [Console] - アプリからの
console.log、console.warn、console.errorの出力を表示します。React Native 0.83では、ログはMetroターミナルには表示されません。 - [Sources] - JavaScriptソースファイルを参照し、ブレークポイントやウォッチ式を使用したり、コールスタックを調べたりしてデバッグを行います。
既知の制限事項
- コンポーネントのハイライトとオーバーレイのエラー - デバイス上でコンポーネントを選択してハイライトすると、
TypeError: Cannot read property 'style' of nullというエラーがreact-devtools-coreで繰り返し発生する場合があります。これは、キャプチャされたプロファイラーデータには影響しません。コミット、[Ranked] ビュー、更新アトリビューションは引き続き正しくレンダリングされますが、デバイス上の要素ハイライト自体は機能しません。これはアプリのバグとして扱わないでください。 - 再読み込み操作でアプリがクラッシュする可能性がある - セッション中はDevTools内で再読み込みを行わないようにしてください。
- ネットワークリクエストの制御はサポートされない - ブロック操作と再送信操作は、UI上には登録されますが、Vega、Fire OS、標準のReact Nativeのいずれにおいても機能はしません。これは、ネットワークレスポンスのモック、WebSocketの検査、スロットリングは未実装であるというReact Native DevToolsのドキュメントの記載内容と一致しています。リダイレクト、スロットリング、ライブブレークポイントは一切利用できません。これらの機能を利用するには、Charles Proxyを使用してください。
接続に関する問題
DevToolsからデバイスへの接続が失われると、ダイアログに「DevTools is disconnected」というメッセージと理由が表示されます。再接続するには、[Reconnect DevTools] をクリックします。または、[Dismiss] をクリックすると、切断された状態で現在のデータを引き続き確認できます。
![React DevToolsの [Components] パネルのスクリーンショット。](https://m.media-amazon.com/images/G/01/mobile-apps/dex/vega/react-devtools/RN_disconnected._TTH_.png)
「Connection refused」エラーが表示される場合は、vega device start-port-forwarding --port 8081 --forward falseを使用してポート8081が正しく転送されていることを確認してください。
クラウド開発環境では、次のSSH構成オプションを追加します。
LocalForward 8081 127.0.0.1:8081
関連トピック
- コンポーネントの再レンダリングに関する問題の調査
- UIレンダリングの問題の特定
- Vegaアプリでのトレースの検査
- アプリのKPIの測定
- Charles Proxyによるネットワークトラフィックのモニタリング
- メモリリークの検出
- 開発者メニューのツールを使用してアプリをデバッグする方法
- 高速リフレッシュの設定
- AI活用開発に向けたAmazon Devices Builder Toolsのセットアップ
Last updated: 2026年8月17日

