Flutter Impeller Engine-Optimierung: 120fps mit Metal & Vulkan

Beim ersten Rendering-Moment einer Flutter-App war der Ruckler durch die Shader-Kompilierung (Shader Compilation Jank) lange Zeit eine große Herausforderung für Flutter-Entwickler. Unter der Skia-Engine trat beim ersten Erscheinen einer Animation oder einer benutzerdefinierten Grafik nach dem App-Start ein vorübergehender Frame-Drop auf, da Shader per JIT (Just-In-Time) kompiliert wurden.

Impeller, die vom Flutter-Team entwickelte Rendering-Engine der nächsten Generation, hat diese Architektur grundlegend verändert. Anstelle der JIT-Shader-Kompilierung zur Laufzeit führt sie eine AOT-Vorkompilierung (Ahead-Of-Time) ein und steuert moderne GPU-Grafik-APIs wie Metal auf iOS und Vulkan auf Android direkt an. Im Jahr 2026 ist Impeller nach der vollständigen Einführung auf iOS nun auch auf Android-Geräten ab API 29+ als Standard-Renderer fest etabliert.

Dieser Artikel behandelt ausführlich die interne Funktionsarchitektur der Impeller-Engine (Unterschiede zu Skia), die Pipeline-Struktur unter iOS Metal und Android Vulkan, die Draw-Call-Analyse mit Flutter DevTools sowie 5 praktische Rendering-Optimierungstechniken, um das Frame-Ziel von 8,33 ms auf High-Refresh-Rate-Geräten mit 120 Hz stabil zu erreichen.

Wichtigste Erkenntnisse

• Kern von Impeller: Eliminierung der JIT-Shader-Kompilierung → AOT-Vorkompilierung + direkte Anbindung an moderne GPU-APIs (Metal, Vulkan) reduzieren den Shader-Jank auf 0 ms.
• Leistungskennzahlen: 50 % schneller bei der Rasterisierung im Vergleich zu Skia, 30–50 % weniger Raster-Frame-Drops und 15–20 % geringerer GPU-Energieverbrauch.
• Unterstützung für 120 Hz Bildwiederholfrequenz: In einer 120-fps-Umgebung stehen pro Frame nur 8,33 ms zur Verfügung. Die Rechenzeit des UI-Threads und des Raster-Threads muss jeweils unter 8 ms gehalten werden.
• Impeller-spezifisches Profiling: Mit dem Impeller Inspector in Flutter DevTools 2026 können Sie Draw-Call-Batching, Texturspeicherzuweisung und die GPU-Timeline präzise analysieren.
• 5 Optimierungsregeln: Isolierung von CustomPainter-Layern (RepaintBoundary), Minimierung der Shader-Uniform-Übertragung, Verwendung von Texturatlassen, 100-prozentige Nutzung von const-Widgets und Testen des Vulkan-Fallback-Verhaltens.

Skia vs. Impeller: Warum wurde die Rendering-Engine komplett ersetzt?

Laut der offiziellen Flutter-Dokumentation wurde Impeller von Grund auf neu entwickelt, um direkt mit nativen Plattform-Grafik-APIs zu kommunizieren, ohne die Abstraktionsschicht von Skia zu durchlaufen.

Skia war eine hervorragende plattformübergreifende 2D-Pipeline. Aufgrund der Architektur, GLSL-Shader erst zur Laufzeit in Maschinencode umzuwandeln, waren beim ersten Rendern jedoch Frame-Spikes von 10–50 ms unvermeidbar. Impeller wählt stattdessen den Ansatz, alle MSL- (Metal Shading Language) und SPIR-V-Shader bereits beim Erstellen der Engine in Binärcode zu kompilieren, wodurch die Ursache von Jank von Grund auf beseitigt wird.

Impeller-Pipeline: Hardwarebeschleunigte Architektur mit Metal und Vulkan

Impeller besteht aus zwei Pipeline-Schichten:

1. AOT-Shader-Toolchain (impellerc): Beim Erstellen der Flutter-Engine werden .vert- und .frag-GLSL-Shader-Dateien eingelesen und in Metal-Bytecode für iOS oder in Vulkan-SPIR-V-Pipeline-State-Objects (PSO: Pipeline State Object) für Android kompiliert.
2. Impeller Runtime (HAL: Hardware Abstraction Layer): Sobald der Render-Baum zur Laufzeit empfangen wird, generiert diese Schicht sofort GPU-Command-Buffer und übergibt sie an die Metal-/Vulkan-Treiber.

[Flutter Dart UI Code] 
        │
        ▼
[DisplayList Builder] ──(Befehlsaufzeichnung)──► [Impeller HAL]
                                                        │
                       ┌────────────────────────────────┴────────────────┐
                       ▼                                                 ▼
             [iOS: Metal Backend]                             [Android: Vulkan Backend]
             • MTLCommandBuffer                               • VkCommandBuffer
             • MTLRenderPipelineState                         • VkPipeline / VkRenderPass
                       │                                                 │
                       ▼                                                 ▼
             [Apple Silicon GPU]                              [Adreno / Mali GPU]

Im Vulkan-Backend wird die Erstellung von VkRenderPass und VkCommandBuffer auf asynchronen Threads parallel verarbeitet. Dadurch verringert sich die Wartezeit, in der die CPU auf die GPU wartet, im Vergleich zu Skia um mehr als die Hälfte.

Budget für den 120-Hz-Modus: Das 8,33-ms-Ziel erreichen

Moderne iPhones (ProMotion 120Hz) und Android-Flaggschiff-Geräte aktualisieren den Bildschirm 120 Mal pro Sekunde. Während zu 60-Hz-Zeiten noch 16,6 ms pro Frame zur Verfügung standen, müssen in einer 120-Hz-Umgebung alle Berechnungen eines Frames innerhalb von 8,33 ms abgeschlossen sein.

60Hz Frame-Budget:  ├──────────────── 16.6ms ────────────────┤
120Hz Frame-Budget: ├────── 8.33ms ──────┤
                    ├─── UI-Thread ───┼─── Raster-Thread ───┤
                         (< 4.0ms)            (< 4.0ms)

Um in einer Impeller-Umgebung 120 fps zu erreichen, müssen sowohl der UI-Thread (Dart-Code-Ausführung) als auch der Raster-Thread (GPU-Befehlsübergabe) ihre Aufgaben jeweils innerhalb von 4 ms abschließen.

5 praktische Rendering-Optimierungstechniken

Selbst wenn Impeller den Shader-Jank beseitigt, können uneffizienter Dart-Code oder übermäßige Rebuilds weiterhin zu Frame-Drops führen. Sie sollten die folgenden 5 praktischen Optimierungsmuster anwenden, um 120 fps perfekt aufrechtzuerhalten.

1. Schwere CustomPainter-Layer mit RepaintBoundary isolieren

Beim Zeichnen komplexer Canvas-Grafiken oder Animationen führt ein Rebuild des übergeordneten Widgets dazu, dass der gesamte Canvas neu gezeichnet wird. Wenn Sie ein RepaintBoundary verwenden, isoliert Impeller diesen Layer in einem separaten GPU-Textur-Raster-Cache.

// Vorher: Bei Parent-Rebuild wird der gesamte CustomPainter neu gezeichnet
Widget build(BuildContext context) {
  return Column(
    children: [
      Text('Zähler: $counter'), // Bei Änderung des Zählers wird auch der Canvas neu gebaut!
      MyComplexGraphPainter(data: graphData),
    ],
  );
}

// Nachher: Layer-Isolierung mit RepaintBoundary — Wiederverwendung des GPU-Rasters
Widget build(BuildContext context) {
  return Column(
    children: [
      Text('Zähler: $counter'),
      RepaintBoundary(
        child: MyComplexGraphPainter(data: graphData),
      ),
    ],
  );
}

2. const-Widget-Deklaration und präzises Scoping von Selectors/Watch

Wenn der gesamte Widget-Baum neu gebaut wird, verbraucht der Dart-Thread das 4-ms-Budget im Handumdrehen. Bei der Verwendung von Zustandsverwaltungs-Paketen (Riverpod, Provider) sollten Sie den Scope so einschränken, dass nur bestimmte Widget-Teilbäume selektiv neu gebaut werden. Wie im Leitfaden zum automatischen Speicher-Dispose in Riverpod 3.0 erwähnt, ist es unerlässlich, mit dem select-Operator nur die benötigten Eigenschaften zu abonnieren.

// Riverpod-Beispiel: Nur name statt des gesamten User-Objekts abonnieren, um unnötige Rebuilds zu verhindern
Widget build(BuildContext context, WidgetRef ref) {
  final userName = ref.watch(userProvider.select((u) => u.name));
  return Text(userName);
}

3. Verwendung von SaveLayer minimieren (BorderRadius statt ClipRRect)

saveLayer weist die GPU an, einen separaten Offscreen-Buffer zuzuweisen, was eine der schwersten Operationen in der Impeller-Render-Pipeline darstellt. Wenn Sie Abrundungen mit DecoratedBox oder BoxDecoration anstelle von ClipRRect verarbeiten, verhindern Sie die Erstellung von Offscreen-Buffern.

// ❌ Uneffizient: Verursacht die Erstellung eines saveLayer Offscreen-Buffers
ClipRRect(
  borderRadius: BorderRadius.circular(16),
  child: Container(color: Colors.blue, height: 100),
)

// ✅ Optimiert: Single-Pass-Verarbeitung im Impeller Draw Call
Container(
  height: 100,
  decoration: BoxDecoration(
    color: Colors.blue,
    borderRadius: BorderRadius.circular(16),
  ),
)

4. Übertragung von Custom-Shader-Uniforms minimieren

Wenn Sie benutzerdefinierte GLSL-Shader verwenden, die mit dem Fragment Program von Flutter 3.x+ geschrieben wurden, führt die Übertragung großer Mengen von Float32Array-Uniform-Daten aus Dart in jedem Frame zu einem CPU-GPU-Bus-Engpass. Minimieren Sie die Anzahl der Uniform-Parameter und entwerfen Sie den Shader so, dass vorzugsweise nur Zeitinformationen (u_time) übergeben werden.

5. Vulkan-Geräte-Fallback-Kompatibilität überprüfen

Im Android-Ökosystem gibt es immer noch ältere Geräte (API 28 oder niedriger bzw. Einsteiger-Chipsätze), auf denen die Vulkan-Treiber-Implementierung mangelhaft ist oder gar nicht unterstützt wird. In solchen Fällen fällt Impeller automatisch auf das OpenGL-ES-Backend zurück.

# Impeller-Vulkan-Option auf einem physischen Android-Gerät erzwingen/deaktivieren
flutter run --profile --enable-impeller
flutter run --profile --no-enable-impeller # OpenGL-Fallback-Verhalten überprüfen

Frame-Drops mit dem DevTools Impeller Inspector nachverfolgen

Mit dem Impeller Inspector in Flutter DevTools können Sie die Ursachen von GPU-Rendering-Engpässen direkt visuell überprüfen.

# App im Profile-Modus ausführen und DevTools öffnen
flutter run --profile

So lesen Sie die DevTools-Timeline

1. UI Thread (Dart Execution): Überprüfen Sie die Ausführungszeit der Phasen Build, Layout und Paint. Wenn 4 ms überschritten werden, müssen Sie ein RepaintBoundary hinzufügen und Widgets aufteilen.
2. Raster Thread (Impeller GPU Command): Überprüfen Sie die Zeit von Impeller::RenderPass::Draw. Wenn 4 ms überschritten werden, kontrollieren Sie die Anzahl der saveLayer-Aufrufe und prüfen Sie, ob übermäßiges View-Clipping vorliegt.
3. GPU Frame Graph: Suchen Sie nach Frame-Spikes, die als rosa oder rote Balken angezeigt werden.

Wenn die Anzahl der Draw Calls auf einem einzelnen Bildschirm 100 überschreitet, sollten Sie Draw Calls mittels Texturatlas (Texture Atlas) oder gebündeltem Zeichnen über Canvas.drawPoints zusammenfassen (Batching). Im Praxisleitfaden für Speicherlecks und CPU-Profiling mit Flutter DevTools werden fortgeschrittene Timeline-Analysetechniken im Detail behandelt.

Häufig gestellte Fragen (FAQ)

Funktioniert Impeller auf allen Android-Geräten?

Auf Geräten mit Android API 29 (Android 10) oder höher und Unterstützung für Vulkan 1.1 arbeitet Impeller als Standard-Renderer. Auf älteren Chipsätzen ohne Vulkan-Unterstützung oder auf Geräten mit API 28 oder niedriger erfolgt automatisch ein Fallback auf das OpenGL-Backend von Impeller oder das Legacy-Skia-Backend, sodass Entwickler hierfür keine manuelle Handhabung benötigen.

Kann man auf iOS zur Skia-Engine zurückkehren?

Nein. Seit den neuesten Flutter-SDK-Versionen wurden die Skia-Flags für iOS vollständig entfernt. iOS-Apps laufen zu 100 % auf der Impeller-Engine (Metal-Backend).

Nimmt die App-Größe nach der Einführung von Impeller zu?

Da die Binärdatei des Impeller-Shader-Kompilers (impellerc) und AOT-kompilierte Shader-Pipeline-Dateien in das App-Bundle aufgenommen werden, erhöht sich die APK/IPA-Größe um etwa 2–3 MB. Die Vorteile, nämlich das Erreichen von 0 ms Shader-Jank und eine höhere Raster-Performance, überwiegen jedoch bei Weitem.

Gibt es Probleme bei der Kombination mit 3D-Bibliotheken von Drittanbietern (SceneKit, Unity)?

Da Impeller den Hardware-Kontext von Metal / Vulkan direkt teilt, ist die Integration von 3D-Engine-Rendering-Pipelines über das Texture-Widget deutlich nahtloser als zu Skia-Zeiten, und die Latenz bei der Textursynchronisation ist geringer.

Wird Impeller auch auf der Web-Plattform verwendet?

Nein. Flutter Web nutzt WebAssembly (Wasm) + CanvasKit oder die Skwasm-Engine. Impeller ist eine Engine, die speziell auf natives Rendering auf Mobilgeräten (iOS/Android) und Desktops spezialisiert ist. Hinweise zur Optimierung der Web-Performance finden Sie im Leitfaden zu Flutter Web Wasm + Skwasm.