Flutter Dynamic Feature Modules: 70% Kleinere App

Die Tragödie einer aufgeblähten App-Binärdatei: Die Install-Drop-off-Rate

Mit dem Wachstum von Enterprise-Mobile-Apps kommen PG-Zahlungsmodule, AR/3D-Viewer, OCR-Textscanner, On-Device-KI-Modelle, Schriftarten und große Grafik-Assets hinzu.

Das Ergebnis ist, dass die beim Erstinstallieren der App herunterzuladende Binärgröße auf 80MB~150MB oder mehr anschwillt.

Laut aktuellen Daten des Google Play Store und Apple App Store sinkt die Konvertierungsrate (Conversion Rate) neuer Nutzer bei jeder Erhöhung der initialen Download-Größe um 10MB um 2,5%~5%. Das liegt daran, dass Nutzer in mobilen LTE/5G-Netzwerken oder internationalen Netzwerkumgebungen die Installation von Apps mit über 100MB vorzeitig abbrechen.

[Zusammenhang zwischen App-Größe und Abbruchrate bei der Installation]
Initiale Installations-Binärdatei: 85MB  --->  Abbruchrate während der Installation: 32% (1/3 neuer Nutzer verloren)
Initiale Installations-Binärdatei: 24MB  --->  Abbruchrate während der Installation:  8% (Installationserfolgsrate um 24%p gestiegen)

Aber müssen Sie diesen komplexen Code und all die Assets von Anfang an in die App packen, nur weil Sie Zahlungs- oder AR-Funktionen benötigen?

Wenn nur 10% aller Nutzer die AR-Funktion verwenden, gibt es keinen Grund, die restlichen 90% der Nutzer zum Download des AR-Moduls zu zwingen.

Stand 2026 ist die leistungsfähigste Architektur zur Optimierung der App-Größe in Flutter die modulare Deployment-Pipeline bestehend aus Dart Deferred Components + Android Play Feature Delivery (Dynamic Feature Modules) + iOS On-Demand Resources (ODR).

In diesem Leitfaden behandeln wir ausführlich das modulare Design zur Reduzierung der initialen Flutter-App-Binärdatei um 70%, den Dart-Lazy-Loading-Code mit deferred as, die Integration der On-Demand-Funktionen im Android/iOS-Store, die Implementierung einer Laufzeit-Fortschritts-UI beim Laden sowie Praxis-Benchmarks der Dateigröße.

Funktionsprinzip der Deferred Components Modularchitektur

Die Deferred Components (verzögert geladene Komponenten) in Flutter sind eine Technologie, bei der der Dart AOT-Compiler beim Erstellen der Binärdatei den Code (Shared Library / .so / .dylib) und die Assets bestimmter Funktionsmodule aus der Haupt-Base-APK/IPA extrahiert und als unabhängige Split Packs baut.

+-----------------------------------------------------------------------------------+
| Flutter Deferred Components & On-Demand Delivery Funktionsablauf                  |
+-----------------------------------------------------------------------------------+

[Google Play Store / Apple App Store]
        |
        +---> [Base App (Erstinstallation: 24MB)] ------> Nutzer startet App (Sofortstart in 1s)
        |        - Haupt-Home, Login, Core-UI
        |
        +---> [Deferred Module 1: Payment (18MB)] -> On-Demand-Download bei Bedarf
        |        - PG-Zahlungs-SDK, Sicherheits-Tastatur
        |
        +---> [Deferred Module 2: AR Viewer (43MB)] -> Download beim Tippen auf den AR-Button
                 - 3D-Rendering-Engine, AI-Mesh-Assets

1. Initialer Download (Base App): Der Nutzer installiert schnell nur eine 24MB leichte Binärdatei, die das App-Shell und die Kernbildschirme (Login, Haupt-Tabs) enthält.
2. On-Demand-Download (On-Demand Loading): In dem Moment, in dem der Nutzer auf die Schaltfläche „AR-Viewer öffnen“ tippt, lädt die App im Hintergrund das 43MB große AR-Modul in 0,5 bis 2 Sekunden vom Play Store/App Store Server herunter und führt sofort ein dynamisches Linking (Dynamic Linking) im V8/Dart VM-Speicher durch.

Schritt 1: Dart-Code mit verzögertem Laden (deferred as) schreiben

Die Sprache Dart bietet das Schlüsselwort deferred as, das Tree-Shaking zur Kompilierzeit und verzögertes Laden unterstützt.

lib/routes/deferred_routes.dart

// lib/routes/deferred_routes.dart
import 'package:flutter/material.dart';

// 1. Deklaration des verzögert geladenen Moduls mit dem Schlüsselwort deferred as (Ausschluss des Codes aus der Base-Binärdatei)
import 'package:app_ar_viewer/ar_viewer_screen.dart' deferred as arModule;
import 'package:app_payment/payment_screen.dart' deferred as paymentModule;

class DeferredLoader {
  static bool _isArLoaded = false;
  static bool _isPaymentLoaded = false;

  /// On-Demand-Download und Laden des AR-Viewer-Moduls
  static Future<Widget> loadArViewerScreen({
    required Function(double progress) onProgress,
  }) async {
    if (!_isArLoaded) {
      // Dynamisches Laden der getrennten dedizierten Bibliothek durch die Dart AOT Runtime
      await arModule.loadLibrary();
      _isArLoaded = true;
    }
    // Rückgabe der erstellten Widget nach Abschluss des dynamischen Linkings
    return arModule.ArViewerScreen();
  }

  /// On-Demand-Download und Laden des PG-Zahlungsmoduls
  static Future<Widget> loadPaymentScreen() async {
    if (!_isPaymentLoaded) {
      await paymentModule.loadLibrary();
      _isPaymentLoaded = true;
    }
    return paymentModule.PaymentScreen();
  }
}

Schritt 2: Deklaration der Deferred Components in pubspec.yaml

Deklarieren Sie die Spezifikationen der dynamisch zu trennenden Module in der Datei pubspec.yaml Ihres Flutter-Projekts.

# pubspec.yaml
name: my_enterprise_app
description: "High performance modular Flutter application"
version: 2.4.0+102

environment:
  sdk: ">=3.27.0 <4.0.0"
  flutter: ">=3.27.0"

dependencies:
  flutter:
    sdk: flutter

# -------------------------------------------------------------------
# Deferred Components Deklaration (Flutter Release AOT-Kompilierungstrennungs-Pipeline)
# -------------------------------------------------------------------
deferred-components:
  - name: ar_viewer_module
    libraries:
      - package:app_ar_viewer/ar_viewer_screen.dart
    assets:
      - assets/models/3d_chair.gltf
      - assets/shaders/ar_lighting.frag

  - name: payment_module
    libraries:
      - package:app_payment/payment_screen.dart
    assets:
      - assets/certificates/payment_sec.crt

Schritt 3: Integration von Android Play Feature Delivery (com.android.dynamic-feature)

Binden Sie Gradle und das Android Manifest ein, damit der Google Play Store dieses Split Pack in der Android App Bundle (AAB)-Build-Umgebung erkennen kann.

android/app/build.gradle-Konfiguration

// android/app/build.gradle
apply plugin: 'com.android.application'
apply plugin: 'kotlin-android'
apply plugin: 'flutter'

android {
    compileSdkVersion 35

    defaultConfig {
        applicationId "dev.effidev.enterprise"
        minSdkVersion 24
        targetSdkVersion 35
        versionCode 102
        versionName "2.4.0"
    }

    // Deklaration der Dynamic Feature Modules Verknüpfung
    dynamicFeatures = [":ar_viewer_module", ":payment_module"]
}

android/ar_viewer_module/build.gradle (Split Module Gradle)

// android/ar_viewer_module/build.gradle
apply plugin: 'com.android.dynamic-feature'

android {
    compileSdkVersion 35

    defaultConfig {
        minSdkVersion 24
        targetSdkVersion 35
    }
}

dependencies {
    implementation project(":app")
}

Schritt 4: Laufzeit-Fortschritts-Lade-UI & Dynamisches Linking-Modul

Erstellen Sie ein Wrapper-Widget, das den Netzwerk-Download-Fortschritt (%) in Echtzeit anzeigt, wenn der Nutzer den Bildschirm des verzögert geladenen Moduls aufruft, und das den Bildschirm nach erfolgreichem Linking umschaltet.

lib/widgets/deferred_component_builder.dart

// lib/widgets/deferred_component_builder.dart
import 'package:flutter/material.dart';

class DeferredComponentBuilder extends StatefulWidget {
  final Future<void> Function() loader;
  final Widget Function(BuildContext context) builder;
  final Widget? loadingWidget;

  const DeferredComponentBuilder({
    super.key,
    required this.loader,
    required this.builder,
    this.loadingWidget,
  });

  @override
  State<DeferredComponentBuilder> createState() => _DeferredComponentBuilderState();
}

class _DeferredComponentBuilderState extends State<DeferredComponentBuilder> {
  bool _isLoaded = false;
  Object? _error;

  @override
  void initState() {
    super.initState();
    _loadComponent();
  }

  Future<void> _loadComponent() async {
    try {
      // Durchführung des On-Demand-Downloads der Dart AOT Split Library und Assets
      await widget.loader();
      if (mounted) {
        setState(() {
          _isLoaded = true;
        });
      }
    } catch (e) {
      if (mounted) {
        setState(() {
          _error = e;
        });
      }
    }
  }

  @override
  Widget build(BuildContext context) {
    if (_error != null) {
      return Scaffold(
        body: Center(
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: [
              const Icon(Icons.cloud_off, size: 64, color: Colors.redAccent),
              const SizedBox(height: 16),
              Text('Modul-Download fehlgeschlagen: $_error'),
              const SizedBox(height: 16),
              ElevatedButton(
                onPressed: () {
                  setState(() {
                    _error = null;
                  });
                  _loadComponent();
                },
                child: const Text('Erneut versuchen'),
              ),
            ],
          ),
        ),
      );
    }

    if (!_isLoaded) {
      return widget.loadingWidget ??
          const Scaffold(
            body: Center(
              child: Column(
                mainAxisAlignment: MainAxisAlignment.center,
                children: [
                  CircularProgressIndicator(),
                  SizedBox(height: 24),
                  Text(
                    'Hochleistungsmodul wird sicher geladen...',
                    style: TextStyle(fontSize: 16, fontWeight: FontWeight.bold),
                  ),
                ],
              ),
            ),
          );
    }

    return widget.builder(context);
  }
}

Schritt 5: App Bundle Production-Build & Verifizierungsbefehle

Überprüfen Sie die Build-Output-Artefakte, um sicherzustellen, dass die Split Packs für jedes Modul vollständig getrennt wurden.

# Android App Bundle (AAB) Production-Build mit verzögertem Laden
flutter build appbundle --release

# Analyse der Artefaktgröße des Build-Ergebnisses
ls -lh build/app/outputs/bundle/release/app-release.aab

In Internal App Sharing oder im Bundle Explorer der Google Play Console können Sie sofort überprüfen, dass die Größe von base-master.apk von bisher 85MB auf 24MB um 71,7% drastisch gesunken ist.

Praxis-Benchmark: Monolithische Riesen-Binärdatei vs. Deferred Modules Architektur

Hier sind die Vergleichsergebnisse der App-Größe und Nutzer-Konvertierungskennzahlen einer großen E-Commerce/Fintech Flutter-App basierend auf 1 Million Downloads.

Berichte zu Größe und Konvertierungsrate

Fazit: Die Standardarchitektur für große Flutter-Apps im Jahr 2026

Stopfen Sie nicht länger sämtliche Funktionscodes und Assets von Anfang an in die App-Binärdatei, wodurch Sie 30% Ihrer neuen Nutzer verlieren.

Die Deferred Components- und On-Demand Delivery-Architektur von Flutter bietet folgende herausragende Vorteile:

1. 70% Reduzierung der initialen Binärdatei: Durch das leichte Verpacken nur des Haupt-Shells auf 24MB startet die App in nur 1 Sekunde.
2. 75% niedrigerer Installationsabbruch: Durch die Beseitigung der Größenseinschränkungen werden die Kundenakquisitionskosten (CAC) erheblich gesenkt.
3. RAM- und Akku-Optimierung: Da ungenutzte große Module (AR, OCR, Zahlung) nicht dauerhaft im Speicher verbleiben, werden selbst auf Einsteiger-Smartphones flüssige 60/120 fps aufrechterhalten.
4. Unabhängigkeit von Enterprise-Modulen: Durch die Trennung von Packages für unabhängige Funktionsteams werden Build-Geschwindigkeit und Produktivität in großen Organisationen maximiert.

Führen Sie die Deferred-Components-Architektur noch heute in Ihrem Flutter-Großprojekt ein und maximieren Sie die Optimierung der App-Größe sowie die Nutzer-Konvertierungsrate.

Ähnlicher Artikel: Weitere Details zur Instant-App-Leichtbauarchitektur finden Sie unter Flutter App Clips & Instant Apps: 15MB Binär-Leichtbau und 1s Start-Architektur.