0Pricing
Flutter Mobile Development · Ders

Gölgelendirici Isıtma ve Impeller'a Geçiş

Gölgelendiricileri önceden derleyip Impeller işleyicisini benimseyerek ilk çalıştırmadaki takılmaları ortadan kaldırın.

Gölgelendirici Isıtma ve Impeller'a Geçiş, CoddyKit'te ücretsiz bir Flutter Mobile Development dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Flutter Mobile Development öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Flutter Mobile Development kursu toplamda 4 dersten oluşur.

Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.

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.

Sıkça Sorulan Sorular

“Gölgelendirici Isıtma ve Impeller'a Geçiş” dersi ücretsiz mi?

Evet — “Gölgelendirici Isıtma ve Impeller'a Geçiş” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Flutter Mobile Development kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Flutter Mobile Development kursu toplamda 4 dersten oluşur.

“Gölgelendirici Isıtma ve Impeller'a Geçiş” dersinde ne öğreneceğim?

Gölgelendiricileri önceden derleyip Impeller işleyicisini benimseyerek ilk çalıştırmadaki takılmaları ortadan kaldırın. Flutter Mobile Development ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

Flutter Mobile Development öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Flutter Mobile Development, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.

“Gölgelendirici Isıtma ve Impeller'a Geçiş” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu Flutter Mobile Development dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Flutter Mobile Development dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

  1. Üç Ağaç: Widget, Element ve RenderObject
  2. DevTools Zaman Çizelgesi ile Takılmaları Profilleme
  3. RepaintBoundary, Sabit Widget'lar ve Yeniden Oluşturma Budama
  4. Gölgelendirici Isıtma ve Impeller'a Geçiş
← Flutter Mobile Development Sayfasına Dön