Flutter ile onlarca uygulama geliştirmiş bir ekip olarak net söyleyelim: Flutter yavaş değildir, yavaş yazılan Flutter vardır. Kullanıcının "uygulama takılıyor" dediği o anlar, yani jank, neredeyse her zaman ölçülebilir ve düzeltilebilir birkaç kök nedene iner. Bu yazıda kendi projelerimizde uyguladığımız jank avı rutinini, en sık yakaladığımız suçluları ve performansı kalıcı kılan süreç disiplinini paylaşıyoruz; hepsi gerçek proje deneyiminden süzülmüş, yarın sabah uygulayabileceğiniz notlar.
Önce ölç, sonra dokun
Performans işinde en pahalı hata tahminle optimizasyon yapmak. İlk adım her zaman DevTools: Performance sekmesinde frame grafiğine bakın; 16 milisaniyeyi (120Hz cihazlarda 8ms) aşan kareler kırmızı bayraktır. Timeline'da hangi fazın şiştiğine bakın: build mi, layout mu, paint mi, yoksa raster thread mi? Teşhis farklıysa tedavi de farklı.
En sık yakaladığımız beş suçlu
- Gereksiz rebuild: setState ile koca sayfayı yeniden çizmek. Çözüm: state'i olabildiğince aşağı itmek, const constructor kullanmak, Riverpod/Provider ile sadece değişen parçayı dinlemek.
- Build metodunda iş yapmak: JSON parse, sıralama, filtreleme build içinde yapılıyorsa her frame'de tekrar çalışır. Bu işler state katmanına, ağır olanlar compute() ile isolate'e taşınmalı.
- Boyutsuz görseller: 4000 piksellik fotoğrafı 80 piksellik avatara basmak. cacheWidth/cacheHeight verin, sunucudan doğru boyut isteyin, listelerde thumbnail kullanın.
- Shader derleme takılmaları: Modern Flutter sürümlerinde Impeller motoru bu derdi büyük ölçüde çözdü; hâlâ eski bir sürümdeyseniz güncellemek başlı başına performans yatırımı.
- Sonsuz listelerde ListView yerine Column: shrinkWrap ve Column kombinasyonları tüm listeyi tek seferde inşa eder. ListView.builder ve mümkünse itemExtent şart.
Release modda test edin
Sahada sık gördüğümüz bir yanılgı: debug modda kasıyor diye panik yapmak. Debug modda JIT çalışır ve assertions açıktır; gerçek performans ancak profile/release modda, gerçek cihazda ölçülür. Alt segment bir Android cihazı test parkurunuzda mutlaka bulundurun; ofisteki amiral gemisi telefon, kullanıcınızın cebindeki gerçeği yansıtmaz.
Açılış süresi ve algılanan performans
Jank kadar önemli bir başlık da uygulamanın açılış süresi. Kullanıcı araştırmalarının ortak bulgusu net: açılışı uzun süren uygulama, daha ilk hafta siliniyor. Sahada en çok işe yarayan müdahaleler şunlar: main() içinde await zinciriyle sıralanan başlatma işlemlerini gözden geçirip gerçekten ekran çizilmeden önce şart olmayanları (uzak konfigürasyon, analitik, bildirim kaydı) sonraya ertelemek; ilk ekranı ağ cevabı beklemeden önbellekten çizip veriyi arkadan tazelemek; deferred loading ile nadir kullanılan ağır modülleri açılış paketinden çıkarmak. Bir de algılanan performans meselesi var: aynı süre, iskelet ekran (skeleton) ve yumuşak geçişlerle çok daha kısa hissettirilir. Boş beyaz ekrana bakan kullanıcı iki saniyeyi uzun bulur; içeriğin şekillendiğini gören kullanıcı aynı iki saniyeyi fark etmez bile.
Performans bir özellik değil, süreçtir
Biz her sprint sonunda kritik ekranlar için frame süresi ölçümünü CI'a bağlıyoruz; regresyon varsa PR birleşmiyor. Uygulamanız büyüdükçe performans bütçesi koymak (örneğin ana liste ekranı ortalama 10ms altında kalacak) ekibi disiplinde tutuyor. Rich Design olarak 2010'dan beri mobil uygulama geliştiriyoruz; mevcut Flutter uygulamanızda takılma, geç açılma veya batarya şikayetleri varsa bize ulaşın, bir performans denetimiyle kök nedenleri raporlayalım.