0Pricing
Flutter Mobile Development · Урок

Профилирование рывков с помощью временной шкалы DevTools

Записывайте графики кадров и находите затратные этапы построения и растеризации в DevTools.

«Профилирование рывков с помощью временной шкалы DevTools» — бесплатный урок Flutter Mobile Development на CoddyKit. Это урок 2 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Flutter Mobile Development, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Flutter Mobile Development содержит 4 уроков всего.

Части этого урока еще не переведены и отображаются на английском.

What 'Jank' Actually Means

Jank is any visible stutter caused by Flutter missing a frame deadline. On a 60Hz display the engine has roughly 16.7ms per frame; on 120Hz devices only 8.3ms.

  • If the UI thread or the raster thread runs over budget, the frame is dropped and the user sees a hitch.
  • Profiling jank means finding which frames are slow and which phase (build/layout/paint vs. rasterization) ate the time.

The DevTools Performance view (the Timeline) is the primary tool for this investigation.

Always Profile in Profile Mode

Never trust timings from a debug build. Debug mode disables JIT optimizations, asserts run, and the Dart VM is slower, so numbers are meaningless.

  • Run with flutter run --profile on a real device, not a simulator.
  • Profile mode keeps service extensions (so DevTools works) but uses AOT-compiled, release-grade code.
  • Simulators use your Mac's CPU/GPU and hide real raster cost.
// Launch the app in profile mode from the terminal:
//   flutter run --profile -d <deviceId>
//
// List attached physical devices first:
//   flutter devices
//
// Then open DevTools at the printed URL and select the
// Performance tab to capture the timeline.
void main() {
  // The flag matters: assert() bodies are stripped in profile/release.
  bool inDebug = false;
  assert(() {
    inDebug = true;
    return true;
  }());
  print(inDebug ? 'debug build' : 'profile/release build');
}

The Two Threads Behind Every Frame

Each frame is produced by two cooperating threads, and the Timeline shows both as separate tracks:

  • UI thread (Dart): runs your build(), layout, and paint phases, then records a list of drawing commands.
  • Raster thread (formerly 'GPU thread'): takes those commands and turns them into actual pixels via Skia/Impeller.

A frame is only smooth if both tracks finish inside the budget. A bar over budget on either track is a dropped frame.

Reading the Frame Chart

The Frames chart at the top of the Performance view shows one bar per rendered frame.

  • Each bar is split into a blue UI portion and a teal Raster portion.
  • The horizontal line marks your target budget (16.7ms or 8.3ms).
  • Bars that cross the line are highlighted; tap one to load its detailed timeline events below.

Color tells you the culprit immediately: tall blue = expensive build/layout; tall teal = expensive rasterization (shaders, large images, clips).

Drilling Into the Timeline Events

Selecting a janky frame populates the Timeline Events flame chart. On the UI track you will typically see this nesting:

  • Frame → Animate → Build → Layout → Paint

The widest box is your hotspot. A wide Build box usually means too much work in build(); a wide Layout means expensive constraint resolution (deep trees, intrinsic sizing).

On the Raster track look for PipelineConsume and GPU rasterization spans.

A Classic Cause of Wide Build Bars

Rebuilding a large subtree on every animation tick is the most common build-phase jank. Here a whole list rebuilds because the parent's setState is called 60 times a second.

  • The fix is to push state down or use const constructors so subtrees are skipped.
  • In the Timeline you would see a wide Build box shrink dramatically after the fix.
// ANTI-PATTERN: every tick rebuilds the entire list.
class _BadClock extends State<BadClock>
    with SingleTickerProviderStateMixin {
  late final AnimationController _c =
      AnimationController(vsync: this, duration: const Duration(seconds: 1))
        ..repeat();

  @override
  Widget build(BuildContext context) {
    return AnimatedBuilder(
      animation: _c,
      builder: (_, __) {
        // BAD: builds 1000 rows on every frame.
        return ListView(children: [
          for (var i = 0; i < 1000; i++) ExpensiveRow(i),
        ]);
      },
    );
  }
}

Isolate Work With const and Subtree Rebuilds

The corrected version restricts the rebuild to only the part that animates. Everything else is const and is skipped by the framework's element diffing.

  • Pass static children through the child: parameter of AnimatedBuilder so they are built once.
  • After this change the Build box in the Timeline becomes a thin sliver.
// FIXED: only the rotating widget rebuilds each tick.
Widget build(BuildContext context) {
  return AnimatedBuilder(
    animation: _c,
    // Built once, reused every frame.
    child: const _StaticList(),
    builder: (context, child) {
      return RotationTransition(
        turns: _c,
        child: child, // const subtree, not rebuilt
      );
    },
  );
}

Diagnosing Raster-Thread Jank

When the teal Raster portion is the tall one, the UI thread is fine but the GPU is struggling to paint. Common causes:

  • saveLayer calls from opacity, clips, or blend modes over large areas.
  • Expensive shader compilation on first use (shader jank), visible as a one-off spike.
  • Large, unscaled images decoded at full resolution.

DevTools offers debugging toggles to confirm these: enable Track Widget Rebuilds, Highlight Repaints, and Render Layer Borders from the Performance view.

Programmatic saveLayer Hotspots

A wrapping Opacity widget forces a saveLayer, which is one of the most expensive raster operations. Prefer cheaper alternatives:

  • For a single image, use the opacity parameter of Image or an AnimatedOpacity only when needed.
  • For solid colors, bake the alpha into the Color instead of wrapping in Opacity.
// EXPENSIVE: Opacity triggers saveLayer on the raster thread.
Widget bad() => Opacity(
      opacity: 0.5,
      child: Container(color: Colors.blue, width: 300, height: 300),
    );

// CHEAP: fold the alpha straight into the color, no saveLayer.
Widget good() => Container(
      color: Colors.blue.withOpacity(0.5),
      width: 300,
      height: 300,
    );

Adding Your Own Timeline Markers

To attribute time to your code rather than framework internals, wrap suspicious sections in Timeline.timeSync from dart:developer. These appear as named spans in the DevTools Timeline.

  • Markers are no-ops in release mode, so they are safe to leave in.
  • Use them to confirm whether a slow frame is your parsing/computation versus Flutter's layout.
import 'dart:developer';

List<int> parsePayload(List<int> raw) {
  // This named span shows up on the UI track in DevTools.
  return Timeline.timeSync('parsePayload', () {
    final out = <int>[];
    for (final b in raw) {
      out.add(b * 2 + 1);
    }
    return out;
  });
}

void main() {
  final result = parsePayload(List<int>.generate(8, (i) => i));
  print(result);
}

A Repeatable Profiling Workflow

Turn ad-hoc poking into a method you can repeat for every regression:

  • 1. Run in --profile on a representative physical device.
  • 2. Reproduce the janky interaction while recording the Frames chart.
  • 3. Tap the tallest over-budget bar; note whether it is blue (UI) or teal (Raster).
  • 4. Open Timeline Events, find the widest box, and read its name.
  • 5. Apply a targeted fix (const subtree, remove saveLayer, precache, etc.), then re-record and compare.

You can also compute the budget yourself from the display refresh rate to know exactly which bars are over the line.

// Frame budget in milliseconds for a given refresh rate.
double frameBudgetMs(int refreshHz) => 1000 / refreshHz;

bool isJanky(double frameMs, int refreshHz) =>
    frameMs > frameBudgetMs(refreshHz);

void main() {
  for (final hz in [60, 90, 120]) {
    final budget = frameBudgetMs(hz);
    print('${hz}Hz budget = ${budget.toStringAsFixed(2)}ms');
  }
  // A 19ms frame is fine at 60Hz? No - it's over the 16.67ms budget.
  print('19ms @60Hz janky: ${isJanky(19, 60)}');
}

Quick Check: Diagnosing the Bar

You record a scroll and see frames where the teal raster portion is well over the budget line while the blue UI portion stays tiny. What is the most likely cause and first fix?

Recap

You learned how to profile jank with the DevTools Timeline:

  • Jank is a missed frame deadline (16.7ms at 60Hz, 8.3ms at 120Hz); always measure in profile mode on a real device.
  • Every frame has a UI thread (build/layout/paint) and a Raster thread (pixels). The Frames chart colors them blue and teal.
  • Tall blue = expensive build/layout, fixed by const subtrees and narrower rebuilds. Tall teal = costly rasterization, fixed by removing saveLayer and shrinking images.
  • Drill into Timeline Events to find the widest box, and add Timeline.timeSync markers to attribute time to your own code.
  • Follow a repeatable record → identify thread → find widest box → fix → re-measure loop.

Часто задаваемые вопросы

Урок «Профилирование рывков с помощью временной шкалы DevTools» бесплатный?

Да — полный текст урока «Профилирование рывков с помощью временной шкалы DevTools» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Flutter Mobile Development, подпишись на CoddyKit PRO. Курс Flutter Mobile Development содержит 4 уроков всего.

Чему я научусь в уроке «Профилирование рывков с помощью временной шкалы DevTools»?

Записывайте графики кадров и находите затратные этапы построения и растеризации в DevTools. Ты практикуешь Flutter Mobile Development с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Flutter Mobile Development?

Предыдущий опыт не требуется. Flutter Mobile Development на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 2 из 4.

Сколько времени занимает урок «Профилирование рывков с помощью временной шкалы DevTools»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Flutter Mobile Development?

Да. Каждый урок Flutter Mobile Development включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. Три дерева: Widget, Element и RenderObject
  2. Профилирование рывков с помощью временной шкалы DevTools
  3. RepaintBoundary, константные виджеты и сокращение перестроений
  4. Прогрев шейдеров и миграция на Impeller
← Назад к Flutter Mobile Development