Debugging Flutter apps programmatically

This doc describes debugging features that you can enable in code. For a full list of debugging and profiling tools, see the Debugging page.

このページはコードを書くときに利用できるdebugging(デバッグ)につい説明します。デバッグとプロファイルについての全てのリストが欲しい場合は、Dbuggingのページをご覧ください。

Logging

Note:You can view logs in DevTools’ Logging view or in your system console. This sections shows how to set up your logging statements.

注意:ログはDevToolのLogging viewで見ることができます。このセクションではlogging文を追加する方法を見ていきます。

You have two options for logging for your application. The first is to use stdout and stderr. Generally, this is done using print() statements, or by importing dart:io and invoking methods on stderr and stdout. For example:

アプリケーションのログを見るためには二つの方法(オプション)があります。

一つ目の方法はstroutとstrerrを使う方法です。

一般的にはこれはprint()文を使えばできます。

あるいは、dart:ioをインポートして、stdoutとstderrメソッドを実行する方法もあります。

例えば、

stderr.writeln('print me');

If you output too much at once, then Android sometimes discards some log lines. To avoid this, use debugPrint(), from Flutter’s foundation library. This is a wrapper around print that throttles the output to a level that avoids being dropped by Android’s kernel.

一度に出力しすぎると、Androidがログ行を無視することがあります。それを防ぐためには、FlutterのfoundationライブラリのdebugPrint()メソッドを使いましょう。

これは、Androidのカーネルによってドロップされないレベルに出力を調整する、print()のラッパーです。

The other option for application logging is to use the dart:developer log() function. This allows you to include a bit more granularity and information in the logging output. Here’s an example:

import 'dart:developer' as developer;

void main() {
  developer.log('log me', name: 'my.app.category');

  developer.log('log me 1', name: 'my.other.category');
  developer.log('log me 2', name: 'my.other.category');
}

You can also pass application data to the log call. The convention for this is to use the error: named parameter on the log() call, JSON encode the object you want to send, and pass the encoded string to the error parameter.

アプリケーションデータをログ呼び出しに渡すこともできます。

log()の呼び出しで、error:という名の名前付き引数を使うのが慣例的な方法です。

log（）呼び出しでerror：namedパラメータを使用し、送信するオブジェクトをJSONでエンコードし、エンコードされた文字列をerrorパラメータに渡すことです。

import 'dart:convert';
import 'dart:developer' as developer;

void main() {
  var myCustomObject = ...;

  developer.log(
    'log me',
    name: 'my.app.category',
    error: jsonEncode(myCustomObject),
  );
}

If viewing the logging output in DevTool’s logging view, the JSON encoded error param is interpreted as a data object and rendered in the details view for that log entry.

DevToolのログビューでログ出力を表示する場合、JSONでエンコードされたエラーパラメータはデータオブジェクトとして解釈され、そのログエントリの詳細ビューに表示されます。

参考

https://flutter.dev/docs/testing/code-debugging#logging

Setting breakpoints

 Note: You can set breakpoints in DevTools’ Debugger, or in the built-in debugger of your IDE. If you want to set breakpoints programmatically, use the following instructions.

注意:DevToolsのDebuggerでブレイクポイントをセットすることができます。あるいは、あなたの使うIDEの組み込みdebuggerでもできます。ブレイクポイントをプログラムを使ってセットしたい場合は以下の方法を参考にしてください。

You can insert programmatic breakpoints using the debugger() statement. To use this, you have to import the dart:developer package at the top of the relevant file.

プログラムによりブレイクポイントをセットするには、debugger()文(メソッド)を使います。そのためには関連するファイルの先頭でdart:developerパッケージをインポートする必要があります。

The debugger() statement takes an optional when argument that you can specify to only break when a certain condition is true, as in the following example:

debugger()文にはオプショナル(省略可能)なwhenアーギュメント(引数)が用意されています。whenアーギュメントは条件がtrueになる時だけプログラムをブレイク(止める)します。

以下の例をご覧ください。

import 'dart:developer';

void someFunction(double offset) {
  debugger(when: offset > 30.0);
  // ...
}

offsetの値が30.0を超える場合のみブレイクポイントが挿入されてプログラムの実行が止まる、と。

参考

https://flutter.dev/docs/testing/code-debugging#setting-breakpoints

Debug flags: application layers

Each layer of the Flutter framework provides a function to dump its current state or events to the console (using debugPrint).

Flutterフレームワークの各レイヤーは、現在の状態またはイベントをコンソールにダンプする機能を提供します（debugPrintを使用します）。

dump : (…に)投げ捨てる、どさりと下ろす、投棄する、(…を)(無責任に)放り出す、やっかい払いする、(外国市場へ)投げ売りする、ダンピングする、転嫁する、(…を)打ち出す

ダンプ (dump)

エラー内容やデバッグ中の値を出力するときは「ダンプ」と表現することが多いです。

Widget tree

To dump the state of the Widgets library, call debugDumpApp().

ウィジェットライブラリの状態をダンプ(出力)するにはdebugDumpApp()メソッドを呼び出します。(この「状態」は、Stateful,Statelessなどのアプリの状態変数のことではないみたい。)

You can call this more or less any time that the application is not in the middle of running a build phase (in other words, not anywhere inside a build() method),

これは、アプリケーションがビルドフェーズの実行中でないときに（つまり、build（）メソッドの外）多かれ少なかれ呼び出すことができます。

if the app has built at least once and is in debug mode (in other words, any time after calling runApp()).

アプリが少なくとも1回ビルドされ、デバッグモードになっている場合（つまり、runApp（）を呼び出した後はいつでも）。

For example, the following application:

例えば以下のアプリケーションで、

import 'package:flutter/material.dart';

void main() {
  runApp(
    MaterialApp(
      home: AppHome(),
    ),
  );
}

class AppHome extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Material(
      child: Center(
        child: TextButton(
          onPressed: () {
            debugDumpApp();
          },
          child: Text('Dump App'),
        ),
      ),
    );
  }
}

The previous app outputs something like the following (the precise details vary by the version of the framework, the size of the device, and so forth):

このアプリは(TextButtonを押すと)次のようなものを出力します（正確な詳細はフレームワークのバージョン、デバイスのサイズなどによって異なります）。

I/flutter ( 6559): WidgetsFlutterBinding - CHECKED MODE
I/flutter ( 6559): RenderObjectToWidgetAdapter<RenderBox>([GlobalObjectKey RenderView(497039273)]; renderObject: RenderView)
I/flutter ( 6559): └MaterialApp(state: _MaterialAppState(1009803148))
I/flutter ( 6559):  └ScrollConfiguration()
I/flutter ( 6559):   └AnimatedTheme(duration: 200ms; state: _AnimatedThemeState(543295893; ticker inactive; ThemeDataTween(ThemeData(Brightness.light Color(0xff2196f3) etc...) → null)))
I/flutter ( 6559):    └Theme(ThemeData(Brightness.light Color(0xff2196f3) etc...))
I/flutter ( 6559):     └WidgetsApp([GlobalObjectKey _MaterialAppState(1009803148)]; state: _WidgetsAppState(552902158))
I/flutter ( 6559):      └CheckedModeBanner()
I/flutter ( 6559):       └Banner()
I/flutter ( 6559):        └CustomPaint(renderObject: RenderCustomPaint)
...
...

This is the “flattened” tree, showing all the widgets projected through their various build functions.

これは「フラット化された」ツリーであり、さまざまなビルド機能を通じて投影されたすべてのウィジェットを示しています。

(This is the tree you obtain if you call toStringDeep() on the root of the widget tree.)

（これは、ウィジェットツリーのルートでtoStringDeep（）を呼び出した場合に取得するツリーです。）

You’ll see a lot of widgets in there that don’t appear in your application’s source, because they are inserted by the framework’s widgets’ build functions.

フレームワークのウィジェットのビルド(build)関数によって挿入されるため、アプリケーションのソースに表示されないウィジェットが多数表示されます。

For example, InkFeature is an implementation detail of the Material widget.

例えば、InkFeatureウィジェットは、Materialウィジェットの実装の詳細です。

(Materialクラスの定義内でInkFeatureウィジェットが使用されている、ということ。)

Since the debugDumpApp() call is invoked when the button changes from being pressed to being released,

ボタンが「押された状態」から「(指が)離された状態」に変わると、debugDumpApp（）メソッドが呼び出されるため、

it coincides with the TextButton object calling setState() and thus marking itself dirty.

これは、TextButtonがsetState（）を呼び出してそれ自体をダーティとマークするのと一致します。

That is why, when you look at the dump you should see that specific object marked as “dirty”.

そのため、ダンプを見ると、「ダーティ(dirty)」とマークされた特定のオブジェクトが表示されます。

Flutterで「”dirty”とマークされる」ということは、「書き換えられる(リビルドされる)」、ということ。

You can also see what gesture listeners have been registered;

また、どのジェスチャリスナーが登録されているかを確認できます。

in this case, a single GestureDetector is listed, and it is listening only to a “tap” gesture

この場合、単一のGestureDetectorがリストされ、「タップ(tap)」ジェスチャのみをリッスンしています。

(“tap” is the output of a TapGestureDetector’s toStringShort function).

“tap”は、TapGestureDetectorのtoStringShort関数の出力です。

If you write your own widgets, you can add information by overriding debugFillProperties(). Add DiagnosticsProperty objects to the method’s argument, and call the superclass method. This function is what the toString method uses to fill in the widget’s description.

独自のウィジェットを作成する場合は、debugFillProperties（）をオーバーライドして情報を追加できます。

DiagnosticsPropertyオブジェクトを(debugFillProperties)メソッドの引数に追加し、スーパークラスメソッドを呼び出します。 この関数は、toStringメソッドがウィジェットの説明を入力するために使用するものです。

参考

https://flutter.dev/docs/testing/code-debugging#widget-tree

Render tree

If you are trying to debug a layout issue, then the Widgets layer’s tree might be insufficiently detailed.

レイアウトの問題をデバッグしようとしている場合は、ウィジェットレイヤーのツリーの詳細では不十分な場合もあります。

In that case, you can dump the rendering tree by calling debugDumpRenderTree().

その場合、debugDumpRenderTree（）を呼び出すことでレンダリングツリーをダンプ(出力)できます。

As with debugDumpApp(), you can call this more or less any time except during a layout or paint phase.

debugDumpApp（）と同様に、レイアウトまたはペイントフェーズを除いて、いつでもこれ(debugDumpRenderTreeメソッド)を呼び出すことができます。

As a general rule, calling it from a frame callback or an event handler is the best solution.

原則として、フレームコールバックまたはイベントハンドラーから呼び出すのが最善の解決策です。

To call debugDumpRenderTree(), you need to add import 'package:flutter/rendering.dart'; to your source file.

debugDumpRenderTree()メソッドを呼び出すためには、ソースファイルに

import ‘package:flutter/rendering.dart’;

↑のコードを追加してインポートする必要があります。

The output for the previous tiny example would look something like the following:

一つ前の簡単な例の出力は、下記のようになります。

I/flutter ( 6559): RenderView
I/flutter ( 6559):  │ debug mode enabled - android
I/flutter ( 6559):  │ window size: Size(1080.0, 1794.0) (in physical pixels)
I/flutter ( 6559):  │ device pixel ratio: 2.625 (physical pixels per logical pixel)
I/flutter ( 6559):  │ configuration: Size(411.4, 683.4) at 2.625x (in logical pixels)
I/flutter ( 6559):  │
I/flutter ( 6559):  └─child: RenderCustomPaint
I/flutter ( 6559):    │ creator: CustomPaint ← Banner ← CheckedModeBanner ←
I/flutter ( 6559):    │   WidgetsApp-[GlobalObjectKey _MaterialAppState(1009803148)] ←
I/flutter ( 6559):    │   Theme ← AnimatedTheme ← ScrollConfiguration ← MaterialApp ←
I/flutter ( 6559):    │   [root]
I/flutter ( 6559):    │ parentData: <none>
I/flutter ( 6559):    │ constraints: BoxConstraints(w=411.4, h=683.4)
I/flutter ( 6559):    │ size: Size(411.4, 683.4)
...
...

This is the output of the root RenderObject object’s toStringDeep() function.

これは、ルートのRenderObjectオブジェクトのtoStringDeep（）関数の出力です。

When debugging layout issues, the key fields to look at are the size and constraints fields. The constraints flow down the tree, and the sizes flow back up.

レイアウトの問題をデバッグする場合、確認する重要なフィールドはサイズフィールドと制約フィールドです。 制約はツリーを下に流れ、サイズは上に戻ります。

↑の原則はFlutterのレイアウトの重要なものなので覚えておくべきだと思います。

For example, in the previous dump you can see that the window size, Size(411.4, 683.4), is used to force all the boxes down to the RenderPositionedBox to be the size of the screen, with constraints of BoxConstraints(w=411.4, h=683.4).

たとえば、前のダンプでは、ウィンドウサイズSize（411.4、683.4）をBoxConstraints（w = 411.4、 h = 683.4）と共に使用して、RenderPositionedBoxまでのすべてのボックスを画面のサイズに強制しています。

The RenderPositionedBox, which the dump says was created by a Center widget (as described by the creator field), sets its child’s constraints to a loose version of this: BoxConstraints(0.0<=w<=411.4, 0.0<=h<=683.4). The child, a RenderPadding, further inserts these constraints to ensure there is room for the padding, and thus the RenderConstrainedBox has a loose constraint of BoxConstraints(0.0<=w<=395.4, 0.0<=h<=667.4). This object, which the creator field tells us is probably part of the TextButton’s definition, sets a minimum width of 88 pixels on its contents and a specific height of 36.0. (This is the TextButton class implementing the Material Design guidelines regarding button dimensions.)

ダンプが（作成者フィールドで説明されているように）Centerウィジェットによって作成されたと言うRenderPositionedBoxは、子の制約を次の緩いバージョンに設定します：BoxConstraints（0.0 <= w <= 411.4、0.0 <= h <= 683.4 ）。 子であるRenderPaddingは、これらの制約をさらに挿入して、パディングの余地があることを確認します。したがって、RenderConstrainedBoxには、BoxConstraints（0.0 <= w <= 395.4、0.0 <= h <= 667.4）の緩い制約があります。 このオブジェクトは、作成者フィールドがおそらくTextButtonの定義の一部であると示しており、コンテンツの最小幅を88ピクセル、特定の高さを36.0に設定しています。 （これは、ボタンの寸法に関するマテリアルデザインガイドラインを実装するTextButtonクラスです。）

The inner-most RenderPositionedBox loosens the constraints again, this time to center the text within the button. The RenderParagraph picks its size based on its contents. If you now follow the sizes back up the chain, you’ll see how the text’s size is what influences the width of all the boxes that form the button, as they all take their child’s dimensions to size themselves.

最も内側のRenderPositionedBoxは再び制約を緩め、今度はボタン内のテキストを中央に配置します。 RenderParagraphは、その内容に基づいてサイズを選択します。 チェーンの後ろのサイズをたどると、テキストのサイズがボタンを形成するすべてのボックスの幅にどのように影響するかがわかります。これらのボックスはすべて、子のサイズを使用してサイズを決定します。

Another way to notice this is by looking at the “relayoutSubtreeRoot” part of the descriptions of each box, which essentially tells you how many ancestors depend on this element’s size in some way. Thus the RenderParagraph has a relayoutSubtreeRoot=up8, meaning that when the RenderParagraph is dirtied, eight ancestors also have to be dirtied because they might be affected by the new dimensions.

If you write your own render objects, you can add information to the dump by overriding debugFillProperties(). Add DiagnosticsProperty objects to the method’s argument, and call the superclass method.

工事中🏗

参考

https://flutter.dev/docs/testing/code-debugging#render-tree

Layer tree

If you are trying to debug a compositing issue, you can use debugDumpLayerTree(). For the previous example, it would output:

compositingの問題をデバッグしようとしている場合は、debugDumpLayerTree（）を使用できます。 前の例では、次のように出力されます。

I/flutter : TransformLayer
I/flutter :  │ creator: [root]
I/flutter :  │ offset: Offset(0.0, 0.0)
I/flutter :  │ transform:
I/flutter :  │   [0] 3.5,0.0,0.0,0.0
I/flutter :  │   [1] 0.0,3.5,0.0,0.0
I/flutter :  │   [2] 0.0,0.0,1.0,0.0
I/flutter :  │   [3] 0.0,0.0,0.0,1.0
I/flutter :  │
I/flutter :  ├─child 1: OffsetLayer
I/flutter :  │ │ creator: RepaintBoundary ← _FocusScope ← Semantics ← Focus-[GlobalObjectKey MaterialPageRoute(560156430)] ← _ModalScope-[GlobalKey 328026813] ← _OverlayEntry-[GlobalKey 388965355] ← Stack ← Overlay-[GlobalKey 625702218] ← Navigator-[GlobalObjectKey _MaterialAppState(859106034)] ← Title ← ⋯
I/flutter :  │ │ offset: Offset(0.0, 0.0)
I/flutter :  │ │
I/flutter :  │ └─child 1: PictureLayer
I/flutter :  │
I/flutter :  └─child 2: PictureLayer

This is the output of calling toStringDeep on the root Layer object.

これは、ルートLayerオブジェクトでtoStringDeepを呼び出した結果です。

The transform at the root is the transform that applies the device pixel ratio; in this case, a ratio of 3.5 device pixels for every logical pixel.

ルートでのTransformは、デバイスのピクセル比を適用するTransformです。 この場合、論理ピクセルごとに3.5デバイスピクセルの比率です。

The RepaintBoundary widget, which creates a RenderRepaintBoundary in the render tree, creates a new layer in the layer tree. This is used to reduce how much needs to be repainted.

レンダーツリーにRenderRepaintBoundaryを作成するRepaintBoundaryウィジェットは、レイヤーツリーに新しいレイヤーを作成します。 これは、再描画が必要な量を減らすために使用されます。

参考

https://flutter.dev/docs/testing/code-debugging#layer-tree

Semantics tree

工事中🏗

Scheduling

工事中🏗

Debug flags: layout

You can also debug a layout problem visually, by setting debugPaintSizeEnabled to true.

debugPaintSizeEnabledをtrueに設定することで、レイアウトの問題を視覚的にデバッグすることもできます。

This is a boolean from the rendering library.

renderingライブラリで定義されているもので、bool値です。

It can be enabled at any time and affects all painting while it is true.

それ(debugPaintSizeEnabled)はいつでも有効にすることができ、それがtrueである間、すべてのペイントに影響します。

The easiest way to set it is at the top of your void main() entry point. See an example in the following code:

これを設定する最も簡単な方法は、void main（）エントリポイントの上部で設定する方法です。 次のコードの例を参照してください。

//add import to rendering library
import 'package:flutter/rendering.dart';

void main() {
  debugPaintSizeEnabled=true;
  runApp(MyApp());
}

When it is enabled, all boxes get a bright teal border, padding (from widgets like Padding) is shown in faded blue with a darker blue box around the child, alignment (from widgets like Center and Align) is shown with yellow arrows, and spacers (from widgets like Container when they have no child) are shown in gray.

有効にすると、すべてのボックスに明るい青緑色の境界線が表示され、パディング（Paddingなどのウィジェットから）は色あせた青で表示され、子の周りに濃い青のボックスが表示され、配置（CenterやAlignなどのウィジェットから）は黄色の矢印で表示されます。 スペーサー（子がない場合のContainerなどのウィジェットから）は灰色で表示されます。

The debugPaintBaselinesEnabled flag does something similar but for objects with baselines. The alphabetic baseline is shown in bright green and the ideographic baseline in orange.

debugPaintBaselinesEnabledフラグは、ベースラインを持つオブジェクトに対して同様のことを行います。 アルファベットのベースラインは明るい緑色で表示され、表意文字のベースラインはオレンジ色で表示されます。

The debugPaintPointersEnabled flag turns on a special mode whereby any objects that are being tapped get highlighted in teal. This can help you determine whether an object is somehow failing to correctly hit test (which might happen if, for instance, it is actually outside the bounds of its parent and thus not being considered for hit testing in the first place).

debugPaintPointersEnabledフラグは、タップされているオブジェクトが青緑色で強調表示される特別なモードをオンにします。 これは、オブジェクトが何らかの理由で正しくヒットテストに失敗しているかどうかを判断するのに役立ちます（たとえば、オブジェクトが実際にその親の境界外にあり、そもそもヒットテストの対象と見なされていない場合に発生する可能性があります）。

工事中🏗

All of these flags only work in debug mode. In general, anything in the Flutter framework that starts with “debug...” only works in debug mode.

これらのフラグはすべて、デバッグモードでのみ機能します。 一般に、「debug …」で始まるFlutterフレームワークのすべては、デバッグモードでのみ機能します。

参考

https://flutter.dev/docs/testing/code-debugging#debug-flags-layout

Debugging animations

Note: The easiest way to debug animations is to slow them down. You can do this using the Slow Animations button in DevTools’ Inspector view, which slows down the animation by 5x. If you want more control over the amount of slowness, use the following instructions.

注意:アニメーションをデバッグする最も簡単な方法は、アニメーションの速度を落とすことです。 これは、DevToolsのインスペクタービューの[Slow Animations]ボタンを使用して行うことができます。これにより、アニメーションが5倍遅くなります。 速度の低下をより細かく制御したい場合は、次の手順を使用してください。

Set the timeDilation variable (from the scheduler library) to a number greater than 1.0, for instance, 50.0. It’s best to only set this once on app startup.

timeDilation変数（スケジューラライブラリから）を1.0より大きい数値（たとえば、50.0）に設定します。 これは、アプリの起動時に1回だけ設定することをお勧めします。

If you change it on the fly, especially if you reduce it while animations are running, it’s possible that the framework will observe time going backwards, which will probably result in asserts and generally interfere with your efforts.

オンザフライで変更した場合、特にアニメーションの実行中に変更した場合、フレームワークが時間の逆戻りを監視する可能性があります。これにより、アサートが発生し、通常は作業が妨げられます。

参考

https://flutter.dev/docs/testing/code-debugging#debugging-animations

Debug flags: performance

Note: You can achieve similar results to some of these debug flags using DevTools. Some of the debug flags aren’t particularly useful. If you find a flag that has functionality you would like to see added to DevTools, please file an issue.

注：DevToolsを使用すると、これらのデバッグフラグの一部と同様の結果を得ることができます。 一部のデバッグフラグは特に有用ではありません。 DevToolsに追加してほしい機能を備えたフラグを見つけた場合は、問題を報告してください。

Flutter provides a wide variety of debug flags and functions to help you debug your app at various points along the development cycle.

Flutterは、開発サイクルのさまざまな時点でアプリをデバッグするのに役立つさまざまなデバッグフラグと関数を提供します。

To use these features, you must compile in debug mode.

これらの機能を使用するには、デバッグモードでコンパイルする必要があります。

The following list, while not complete, highlights some of flags (and one function) from the rendering library for debugging performance issues.

次のリストは、完全ではありませんが、パフォーマンスの問題をデバッグするためのレンダリングライブラリのいくつかのフラグ（および1つの関数）を示しています。

You can set these flags either by editing the framework code, or by importing the module and setting the value in your main() method, following by a hot restart.

これらのフラグを設定するには、フレームワークコードを編集するか、モジュールをインポートしてmain（）メソッドに値を設定し、その後ホットリスタートします。

debugDumpRenderTree()

Call this function when not in a layout or repaint phase to dump the rendering tree to the console.

レイアウトまたは再描画(repaint)フェーズでないときにこの関数を呼び出して、レンダリングツリーをコンソールにダンプします。

debugPaintLayerBordersEnabled

PENDING

debugRepaintRainbowEnabled

You can enable this flag in the Flutter inspector by selecting the Highlight Repaints button. If any static widgets are rotating through the colors of the rainbow (for example, a static header), those areas are candidates for adding repaint boundaries.

debugPrintMarkNeedsLayoutStacks

Enable this flag if you’re seeing more layouts than you expect (for example, on the timeline, on a profile, or from a print statement inside a layout method). Once enabled, the console is flooded with stack traces showing why each render object is being marked dirty for layout. You can use the debugPrintStack() method from the services library to print your own stack traces on demand, if this kind of approach is useful to you.

debugPrintMarkNeedsPaintStacks

Similar to debugPrintMarkNeedsLayoutStacks, but for excess painting. You can use the debugPrintStack() method from the services library to print your own stack traces on demand, if this kind of approach is useful to you.

参考

https://flutter.dev/docs/testing/code-debugging#debug-flags-performance

Tracing Dart code performance

Note: You can use the DevTools Timeline view to perform traces. You can also import and export trace files into the Timeline view, but only files generated by DevTools.

注：DevToolsタイムラインビューを使用してトレースを実行できます。 トレースファイルをタイムラインビューにインポートおよびエクスポートすることもできますが、DevToolsによって生成されたファイルのみです。

To perform custom performance traces programmatically and measure wall/CPU time of arbitrary segments of Dart code similar to what would be done on Android with systrace, use dart:developer Timeline utilities to wrap the code you want to measure such as:

プログラムでカスタムパフォーマンストレースを実行し、systraceを使用してAndroidで実行されるのと同様に、Dartコードの任意のセグメントのウォール/ CPU時間を測定するには、dart：developerタイムラインユーティリティを使用して、次のように測定するコードをラップします。

import 'dart:developer';

Timeline.startSync('interesting function');
// iWonderHowLongThisTakes();
Timeline.finishSync();

Then open your app’s Observatory’s timeline page, check the ‘Dart’ recording option and perform the function you want to measure.

次に、アプリのObservatoryのタイムラインページを開き、[Dart]記録オプションをオンにして、測定する関数を実行します。

工事中🏗

参考

https://flutter.dev/docs/testing/code-debugging#tracing-dart-code-performance

Performance overlay

 Note: You can toggle display of the performance overlay on your app using the Performance Overlay button in the Flutter inspector. If you prefer to do it in code, use the following instructions.

注：Flutterインスペクターの[パフォーマンスオーバーレイ]ボタンを使用して、アプリのパフォーマンスオーバーレイの表示を切り替えることができます。 コードで実行する場合は、次の手順を使用してください。

You can programmatically enable the PerformanceOverlay widget by setting the showPerformanceOverlay property to true on the MaterialApp, CupertinoApp, or WidgetsApp constructor:

MaterialApp、CupertinoApp、またはWidgetsAppコンストラクターでshowPerformanceOverlayプロパティをtrueに設定することにより、プログラムでPerformanceOverlayウィジェットを有効にできます。

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      showPerformanceOverlay: true,
      title: 'My Awesome App',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(title: 'My Awesome App'),
    );
  }
}

(If you’re not using MaterialApp, CupertinoApp, or WidgetsApp, you can get the same effect by wrapping your application in a stack and putting a widget on your stack that was created by calling PerformanceOverlay.allEnabled().)

（MaterialApp、CupertinoApp、またはWidgetsAppを使用していない場合は、アプリケーションをStackにラップし、PerformanceOverlay.allEnabled（）を呼び出して作成したウィジェットをスタックに配置することで同じ効果を得ることができます。）

For information on how to interpret the graphs in the overlay, see The performance overlay in Profiling Flutter performance.

オーバーレイのグラフを解釈する方法については、「フラッターパフォーマンスのプロファイリング」のパフォーマンスオーバーレイを参照してください。

Widget alignment grid

You can programmatically overlay a Material Design baseline grid on top of your app to help verify alignments by using the debugShowMaterialGrid argument in the MaterialApp constructor.

MaterialAppコンストラクターのdebugShowMaterialGrid引数を使用して、アプリの上にマテリアルデザインのベースライングリッドをプログラムでオーバーレイし、配置を確認することができます。

In non-Material applications, you can achieve a similar effect by using a GridPaper widget directly.

Materialを使用しないアプリケーションでは、GridPaperウィジェットを直接使用して同様の効果を実現できます。

参考

https://flutter.dev/docs/testing/code-debugging