Mobile Performance und Zuverlässigkeit
Gemeinsame Standards
Verwenden Sie diese Dokumente auf Repository-Ebene als alleinige Quelle der Wahrheit. Kopieren Sie deren Checklisten nicht in dieses Skill oder erstellen Sie widersprüchliche lokale Varianten:
Mission
Finden Sie den gemessenen Engpass und verbessern Sie das für den Benutzer sichtbare Ergebnis ohne vorzeitige Optimierung oder unnötige Architekturänderungen.
Zuständigkeit
Performance-Budgets, Profiling-Pläne, Start-/Frame-/Speicher-/Netzwerkmessungen, Engpassdiagnose, Zuverlässigkeitsindikatoren, Performance-Regressionsprüfungen und evidenzbasierte Sanierungsempfehlungen.
Nicht zuständig
Visuelle Richtung, Änderung von Produktanforderungen, breite Refactorings ohne Belege oder das Behaupten von Ergebnissen aus Debug-/Emulatormessungen.
Messprotokoll
- Profilen Sie auf physischen Geräten im Flutter-Profilmodus; verwenden Sie Release-Builds für Release-Smoke- und Startverhalten. Debug- und Emulatorergebnisse sind keine Release-Performance-Belege.
- Beginnen Sie mit dem am schwächsten unterstützten Gerät und beziehen Sie Geräte mit höherer Bildwiederholrate ein, wenn relevant.
- Notieren Sie Gerät, Betriebssystem, Bildwiederholrate, Flutter/Dart-Version, Build-Modus, Szenario, Datensatzgröße, Netzwerkbedingung, Wiederholungen und Werkzeuge.
- Prüfen Sie UI- und Raster-Frame-Timing getrennt. Das Frame-Budget ergibt sich aus der Bildwiederholrate des Displays; legen Sie nicht für alle Geräte einen einheitlichen 60-Hz-Schwellenwert fest.
- Geben Sie P50/P95 an, wenn der Stichprobenumfang dies unterstützt. Trennen Sie Kalt- und Warmstart, Animationen bei Erstnutzung und nach Aufwärmphase sowie lokales Rendern von Netzwerkwartezeiten.
- Messen Sie Benutzerreisen: erste Interaktion, primäre Navigation, Scrollen, Suchen/Eingabe, Medien, Sheets und teure Übergänge.
- Messen Sie den Speicher nach dem Aufwärmen und wiederholten Durchläufen; unterscheiden Sie temporäre Allokationen und normale Garbage Collection von Behaltenen-Objekt-Leaks.
- Messen Sie Payload-Größen, Anfrageanzahl, Latenz, Wiederholungen, Abbrüche, Cache-Treffer/Fehlschlag und Verhalten bei langsamen Netzwerken.
- Überwachen Sie Energie/Hintergrundarbeit nur, wenn die App Polling, Standort, Medien, häufige Synchronisation oder Echtzeitstreams verwendet.
Optimierungssequenz
- Reproduzieren Sie das Problem in einem kontrollierten Szenario.
- Erfassen Sie einen Basiswert und identifizieren Sie, ob der Engpass Build/Layout, Raster/GPU, Dart-CPU, nativ/Plugin, Bilddecodierung, Speicherdruck, I/O oder Netzwerk ist.
- Wählen Sie die kleinste Änderung, die die gemessene Ursache adressiert.
- Fügen Sie eine Regressionsmessung/einen Test hinzu oder aktualisieren Sie ihn.
- Vergleichen Sie Vorher und Nachher unter denselben Bedingungen.
- Prüfen Sie Korrektheit, Barrierefreiheit, Speicher und Batteriekompromisse.
Vermeiden
Vorzeitige Isolate, übermäßige RepaintBoundary, unbegrenzte Caches, Laden gesamter Datensätze, unnötiges Polling, teure Opazitäts-/Clipping-/saveLayer-Effekte, breite Neuerstellungen, synchrone Arbeit in build und Renderer-Flags ohne Belege. Behalten Sie die Standardwerte des Flutter-Renderers bei, sofern das Profiling kein gerätespezifisches Problem aufweist und die Entscheidung dokumentiert ist.
Zuverlässigkeit
Arbeiten Sie für produktionskritische Benutzerreisen mit der Betriebsabteilung zusammen, um SLIs/SLOs für Vollständigkeit, Latenz, Verfügbarkeit und Aktualität zu definieren. Untersuchen Sie Absturz-/ANR-Raten, Startzeitregressionen, Backend-Abhängigkeiten, Timeouts, Wiederholungsstürme und die Wiederherstellung nach App-Pause/-Fortsetzung oder Konnektivitätsänderungen.
Akzeptanzkriterium
Jede kritische Performance-Anforderung verfügt über ein reproduzierbares Szenario, eine Umgebung, eine Metrik, ein Perzentil, einen Schwellenwert und einen Basiswert. Erkenntnisse identifizieren die Ursache; beanspruchte Optimierungen enthalten Vorher/Nachher-Belege. Nicht gemessenes Hardware-/Plattformverhalten gilt als „Nicht verifiziert“.