0Pricing
Flutter Mobile Development · Lección

Calentamiento de shaders y migración a Impeller

Elimine el jank de los shaders durante la primera ejecución precompilándolos y adoptando el renderizador Impeller.

Calentamiento de shaders y migración a Impeller es una lección gratuita de Flutter Mobile Development en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Flutter Mobile Development, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Flutter Mobile Development incluye 4 lecciones en total.

Partes de esta lección aún no han sido traducidas y se muestran en inglés.

Why First-Run Jank Happens

The first time a Flutter app draws a particular effect, the GPU backend has to compile the underlying shader program on the device. With the legacy Skia backend this compilation happens lazily, right in the middle of the frame that needs it.

  • A shader compile can take tens of milliseconds.
  • That blows the 16ms budget of a 60fps frame, producing a visible stutter called shader jank.
  • It is worst on the very first run because nothing is cached yet.

Animations, page transitions, and BackdropFilter blurs are the usual culprits.

Where the Time Goes

A jank frame caused by shader compilation shows up clearly in DevTools' Performance view as a tall raster-thread bar with a ShaderCompilation event.

To reproduce and measure it reliably, run in profile mode (never debug mode, which is much slower and misleading):

  • Profile mode gives release-like performance with tracing hooks.
  • The DevTools timeline marks shader compile events so you can confirm the root cause before optimizing.
// Run the app in profile mode to capture realistic frame timings.
// flutter run --profile

// Then open DevTools > Performance and look for
// 'ShaderCompilation' events on the raster thread.
// flutter run --profile --trace-skia

The Skia Warm-Up Strategy

On the legacy Skia backend, the classic fix is shader warm-up: collect the shaders your app uses into a bundle, then precompile them at startup before the user interacts.

Flutter generates this bundle for you with the --cache-sksl flag, which records SkSL (Skia Shader Language) programs while you exercise the app:

// 1. Run in profile mode, capturing SkSL while you navigate every screen
//    and trigger every animation that might cause jank.
// flutter run --profile --cache-sksl --purge-persistent-cache

// 2. In the running app, press 'M' in the terminal to write the
//    captured shaders to a JSON file, e.g. flutter_01.sksl.json

Bundling the Captured Shaders

Once you have the captured .sksl.json file, you bundle it into the release build. Flutter precompiles those shaders during the engine warm-up phase, so they are ready before the first frame the user sees.

  • Capture on a physical device similar to your target hardware.
  • Re-capture whenever the UI changes significantly.
// Bundle the captured SkSL into a release build:
// flutter build apk --bundle-sksl-path flutter_01.sksl.json
// flutter build ios --bundle-sksl-path flutter_01.sksl.json

// The engine warms up these shaders at launch,
// eliminating compile stalls during animations.

Why Skia Warm-Up Is a Band-Aid

SkSL warm-up works, but it has real downsides that motivated a deeper fix:

  • The capture is device- and driver-specific; a bundle from one GPU may not cover another.
  • You must remember to re-capture after UI changes, or jank silently returns.
  • It only covers the shaders you happened to exercise during capture.

The Flutter team's permanent answer is a new rendering engine that does not compile shaders at runtime at all: Impeller.

How Impeller Eliminates the Problem

Impeller precompiles a small, fixed set of shaders at engine build time rather than at runtime. Instead of generating arbitrary shaders per draw call, it composes effects from these known-ahead-of-time programs.

  • No runtime shader compilation means no first-run shader jank by design.
  • It uses Metal on iOS and Vulkan on modern Android.
  • Because shaders are known ahead of time, --cache-sksl warm-up is unnecessary and unsupported with Impeller.

Impeller's Default Status

Impeller is now the default renderer on iOS and on modern Android (devices supporting Vulkan), as of recent stable Flutter releases. On older Android hardware without Vulkan, the engine falls back to an OpenGL backend automatically.

Most apps get the benefit with no code change. The migration work is about verifying visual correctness and handling the few edge cases where Impeller and Skia differ.

Toggling Impeller Per Platform

You control Impeller through native platform manifests, not Dart code. This lets you opt in, opt out, or compare against Skia during migration testing.

On iOS, set the flag in Info.plist; on Android, in AndroidManifest.xml:

<!-- ios/Runner/Info.plist -->
<key>FLTEnableImpeller</key>
<true/>

<!-- android/app/src/main/AndroidManifest.xml (inside <application>) -->
<meta-data
    android:name="io.flutter.embedding.android.EnableImpeller"
    android:value="true" />

Custom Shaders Still Need Warm-Up

If you ship your own GLSL fragment shaders via FragmentProgram, those are your code and are not part of Impeller's built-in set. Compiling or loading them on demand can still stall a frame.

The fix is to load and warm them up during app startup, before they are first used in an animation:

import 'package:flutter/material.dart';

class ShaderCache {
  static FragmentProgram? ripple;

  // Call during startup so the program is ready before first paint.
  static Future<void> warmUp() async {
    ripple = await FragmentProgram.fromAsset('shaders/ripple.frag');
  }
}

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await ShaderCache.warmUp();
  runApp(const MyApp());
}

Pre-Rendering Expensive Effects

Even with shaders precompiled, the very first build of an expensive widget can still cost more than later builds. A common technique is to render the heavy effect off-screen during a splash or warm-up frame so the work is done before the user navigates to it.

You can drive a one-frame warm-up render after the first frame is committed:

import 'package:flutter/material.dart';
import 'package:flutter/scheduler.dart';

void scheduleWarmUp(VoidCallback warmUpExpensiveEffects) {
  // Runs once after the first frame is rendered,
  // so warm-up work does not block startup paint.
  SchedulerBinding.instance.addPostFrameCallback((_) {
    warmUpExpensiveEffects();
  });
}

Measuring the Win

Always confirm the improvement with data, not vibes. Compare the worst frame raster time before and after, on a real device, in profile mode.

You can compute simple statistics from captured frame timings to verify that the 99th-percentile frame now fits the budget:

void main() {
  // Raster times in milliseconds captured before the warm-up fix.
  final frames = <double>[8.1, 7.9, 42.6, 8.0, 9.3, 8.2, 7.7];

  frames.sort();
  final worst = frames.last;
  final p50 = frames[frames.length ~/ 2];
  const budget = 16.0; // 60fps frame budget

  print('p50: ${p50}ms  worst: ${worst}ms');
  print(worst > budget
      ? 'Jank present: worst frame exceeds ${budget}ms'
      : 'All frames within budget');
}

Quick Check

You migrate a C1-level app from Skia to Impeller to fix first-run shader jank. What happens to your existing SkSL warm-up bundle and why?

Recap

You now know how to eliminate first-run shader jank in Flutter:

  • Diagnose shader compilation stalls in DevTools' Performance view using profile mode.
  • Skia warm-up with --cache-sksl and --bundle-sksl-path precompiles captured SkSL, but is device-specific and brittle.
  • Impeller is the permanent fix: it precompiles a fixed shader set at build time, so there is no runtime compilation and no shader jank by design. It is the default on iOS and modern (Vulkan) Android.
  • Toggle Impeller via Info.plist and AndroidManifest.xml; drop your SkSL bundle once migrated.
  • Custom FragmentProgram shaders still need explicit startup warm-up.
  • Always measure worst-frame raster time on a real device to confirm the win.

Preguntas frecuentes

¿La lección «Calentamiento de shaders y migración a Impeller» es gratis?

Sí — el texto completo de «Calentamiento de shaders y migración a Impeller» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Flutter Mobile Development, actualiza a CoddyKit PRO. El curso de Flutter Mobile Development incluye 4 lecciones en total.

¿Qué aprenderé en «Calentamiento de shaders y migración a Impeller»?

Elimine el jank de los shaders durante la primera ejecución precompilándolos y adoptando el renderizador Impeller. Practicas Flutter Mobile Development con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Flutter Mobile Development?

No se requiere experiencia previa. Flutter Mobile Development en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.

¿Cuánto tiempo toma la lección «Calentamiento de shaders y migración a Impeller»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Flutter Mobile Development?

Sí. Cada lección de Flutter Mobile Development incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Los tres árboles: Widget, Element y RenderObject
  2. Análisis de jank con la línea de tiempo de DevTools
  3. RepaintBoundary, widgets Const y poda de reconstrucciones
  4. Calentamiento de shaders y migración a Impeller
← Volver a Flutter Mobile Development