Flutter hot reload, incremental compile ve build sürelerini azaltma rehberi

Ölçme ilk adımı: hot reload, incremental compile ve build sürelerini sayısallaştırma

Problemi çözmeden önce sayısallaştırın: 'time' ile lokal build süresini, DevTools Timeline ile incremental compile gecikmesini ve CI pipeline loglarıyla tam rebuild sıklığını ölçün. Örnek komut:

time flutter build apk --release -t lib/main.dart

Bu komut size tam build süresini verir; CI'de aynı dizinde cache yoksa ölçümü tekrarlayın ve farkı kaydedin.

Incremental compile ve hot reload için frontend_server üretim süresini görmek için verbose log alın:

flutter run -v --hot > run_verbose.log 2>&1 && grep -E "kernel_snapshot|kernel_blob|Incremental compile" run_verbose.log

Loglardaki kernel oluşturma süreleri (ms) incremental derleyicinin darboğazını gösterir. Bu ölçümü değişiklik öncesi/sonrası karşılaştırarak 'before/after' tabloları oluşturun (örneğin CSV).

Neden ölçmek: Flutter'ın JIT incremental pipeline'i (hot reload) kernel deltas üretir; delta büyüklüğü ve kernel derleme zamanı, kaynak değişikliğinin hangi dosyalarda olduğuna göre değişir. Bu yüzden önce hangi dosya değişikliklerinin tam rebuild tetiklediğini görmek gerekir. Logtaki 'Recompiled xx libraries' satırı size hangi kütüphanelerin yeniden derlendiğini söyler.

Kod ve kaynak düzeniyle incremental compile optimizasyonu (const, dosya bölme, import sınırları)

Dart'ta const kullanımını genişleterek Widget yeniden oluşturma maliyetini ve kernel delta büyüklüğünü azaltabilirsiniz. Özellikle stateless subtree'leri const olarak işaretlemek incremental compiler'in AST farkını küçültür. Uygulamada örnek:

class ItemTile extends StatelessWidget { const ItemTile({Key? key, required this.label}) : super(key: key); final String label; @override Widget build(BuildContext context) => Text(label); }

Bu şekilde const ile inşa edilen widget'lar hot reload sırasında genellikle daha az yeniden derlenir.

Büyük tek dosyaları mantıksal parçalara ayırmak (feature-based packages / lib/src/feature) incremental compile avantajı sağlar: değişiklik tek bir kütüphaneyi etkiler, tüm uygulama değil. Örnek proje yapısı:

lib/ - main.dart lib/app/ - app.dart lib/features/checkout/ - checkout_page.dart checkout_widgets.dart

Bu düzen, frontend_server'ın yeniden derleyeceği modül sayısını sınırlar.

Import/part edge case: 'part' kullanımı dosya içi tek AST oluşturur; küçük değişiklikler tüm part dosyaları için yeniden derlemeye neden olabilir. Bu yüzden paylaşılan kodlar için 'import' tercih edin. Kontrol aracı olarak grep ile part kullanımını bulun:

grep -R "part '" lib/ || true

Gradle, artifact cache ve CI tarafı: cross platform mobil uygulama geliştirme için pipeline iyileştirmeleri

Android tarafında Gradle ayarları ile CI build sürelerini ciddi şekilde kısaltabilirsiniz. Önerilen gradle.properties satırları (CI ve geliştirici makinelerinde):

org.gradle.daemon=true org.gradle.parallel=true org.gradle.configureondemand=true org.gradle.caching=true org.gradle.jvmargs=-Xmx4g

Bu konfigürasyon, Gradle daemon'un yeniden başlatılmasını azaltır ve task-level cache ile yeniden derlemeleri atlatır.

CI cache stratejisi: .gradle, ~/.gradle/caches ve Flutter'in .pub-cache dizinlerini cache'leyin. GitLab CI örneği (cache snippet):

cache: key: "flutter-cache" paths: - .pub-cache/ - .gradle/ - build/

Bu sayede native artifact'ler yeniden indirilmez ve 'flutter build' süreleri azalır.

Neden mekanizma çalışır: Gradle build cache, task'lar için aynı girişler tekrarlandığında çıktıyı yeniden kullanır; Flutter tarafında ise .pub-cache paket indirimi ve Gradle cache sayesinde dexing/linking maliyetleri atlanır. Ölçüm: CI pipeline'da cache olmadığı koşulda geçen süre ile cache varlığındaki süreyi kaydedin; örnek: full build 420s -> cache sonrası 95s gibi tablo oluşturun.

DevTools ile bottleneck teşhisi: timeline, CPU profiler ve kernel delta analizi - uygulamalı adımlar

DevTools Timeline ile hot reload sırasında hangi adım ne kadar sürdüğünü görün. Adımlar: 1) Uygulamayı debug ile başlatın

flutter run --start-paused --machine

2) 'dart devtools' başlatın

dart pub global activate devtools dart pub global run devtools

3) Timeline kaydını alıp 'Frame' ve 'Event' sürelerini inceleyin. Timeline'da 'Dart Compilation' ve 'Raster' blokları hot reload gecikmelerinin kaynağıdır.

CPU profiler ile JIT derleme sürecindeki functions'ları bulun: DevTools Profiler'da 'CPU samples' alın ve 'kernel' veya 'dart:frontend' gibi sembolleri arayın. Eğer CPU kullanımı yüksekse, kaynak dosya granülerliği (birden fazla küçük dosya yerine büyük dosya) veya paket bağımlılıklarının yeniden çözümü tetikleniyor olabilir. İlgili komut:

flutter attach --debug-uri=http://127.0.0.1:8181

ardından DevTools'ta bağlanıp profile alın.

Pratik ipucu: 'kernel_blob.bin' dosyasına yazılan delta boyutlarını izleyin. Verbose logta 'Wrote kernel file' sonrası yazılan byte sayısı, hot reload payload'ını gösterir. Log extraction örneği:

grep -oP "Wrote kernel blob.*\K\d+(?= bytes)" run_verbose.log | awk '{sum+= $1} END {print sum " bytes total"}'

Bu sayede değişikliklerin network veya device-apply maliyetini sayısallaştırabilirsiniz.

State design ve runtime edge-case'leri: state management seçimleri ve hot reload etkileşimi

Flutter state management tercihleriniz hot reload davranışını etkiler. Örneğin Riverpod/Provider gibi DI tabanlı çözümler, hot reload sonrası provider'ların yeniden oluşturulma kurallarına göre state kaybı veya korunması yaşayabilir. Deneysel test: global state'in korunup korunmadığını görmek için basit bir sayaç ekleyin ve hot reload yapın:

class Counter extends ChangeNotifier { int value = 0; void inc(){ value++; notifyListeners(); } }

Provider ile sarılı uygulamada hot reload sonrası Counter instance'ının aynı kalıp kalmadığını kontrol edin.

Edge-case: static initializer veya top-level final değişiklikleri hot reload ile eklenmeyebilir; bu durumlarda tam restart gereklidir. Yani hot reload, tüm runtime başlangıç kodlarını yeniden çalıştırmaz; native taraf (Android/iOS) veya tooling değişiklikleri (gradle, plugin) her zaman full restart gerektirir. Kontrol adımı: native plugin eklediğinizde

flutter clean && flutter run

komutunu kullanın ve bunun full rebuild yaptığını doğrulayın.

Eğitim ve ekip alıştırması: Bu konuları takım içinde pekiştirmek için bir 'flutter kursu' formatında kısa test senaryoları oluşturun (hot reload preserve, full restart gerektiren değişiklikler, provider reinit). Bir 'dart programlama eğitimi' modülü olarak, incremental compiler davranışını öğretirken yukarıdaki grep/log komutlarını kullanın.

Sık Sorulan Sorular

flutter hot reload neden bazen çok yavaş çalışıyor ve nasıl sayısallaştırırım?

Hot reload gecikmesini sayısallaştırmak için verbose log alın:

flutter run -v --hot > verbose.log 2>&1

Logta 'kernel_blob' ve 'Recompiled' satırlarını grep ile çıkarın. Ayrıca tam build süresi için

time flutter build apk --release -t lib/main.dart

çalıştırın. Bu iki ölçümleri CI/yerel arasında karşılaştırarak dar boğazı tespit edin.

CI'de flutter build sürelerini azaltmak için hangi cache'leri saklamalıyım?

.gradle ve pub cache başlıca yerlerdir. Örnek GitLab cache:

cache: paths: - .pub-cache/ - .gradle/

Ayrıca Android build cache ve Gradle daemon parametrelerini gradle.properties içine koyun:

org.gradle.caching=true org.gradle.daemon=true

Bu ayarlar native artifact tekrarlarını önler.

flutter state management hot reload ile state kaybına nasıl yol açar ve nasıl önlerim?

Hot reload sınıf tanımlarını injekte eder ama top-level initializer'ları tekrar çalıştırmaz; bu nedenle global singletons veya static initializers değiştiyse state kaybı ya da tutarsızlık görülebilir. Kullanarak test edin:

flutter run && /* increment counter in UI */ hot reload

Provider/Riverpod kullanıyorsanız provider'ları sınırlandırın veya state restoration API'lerini aktive edin. Ayrıca state'inizi mümkünse immutable ve reconstructible şekilde tasarlayın.