Flutter Mobil Uygulama Geliştirmede Görsel Bellek Bütçesi Yönetimi

Flutter mobil uygulama geliştirmede görsel maliyetini ölçmek

Görsel belleğinin kaba üst sınırını hesaplayın: decode edilmiş RGBA bitmap yaklaşık genişlik x yükseklik x 4 bayt tutar. Örneğin kaynak dosyası 1080 x 1920 olan tek bir görsel yaklaşık 7.9 MiB yer kaplar; ekrandaki kart onu 180 x 320 mantıksal pikselde gösterse bile varsayılan akış kaynak çözünürlükte decode edebilir. Flutter DevTools'ta Memory sekmesindeki allocation profile ile Image, ImmutableBuffer ve codec ile ilişkili artışları arayın. Raster grafiğinde kaydırma sırasında yükselen kare sürelerini eşleştirmek için Performance sekmesinde aynı etkileşimi kaydedin. Amaç, örneğin p95 raster süresini 21 ms'den 10 ms'ye indirmek gibi ölçülebilir bir kabul kriteri belirlemektir; yalnızca görselin ekranda açılması yeterli bir sonuç değildir.

Hedef fiziksel boyutta decode ile Flutter görsel maliyetini düşürmek

cacheWidth bir dosya indirme parametresi değildir; codec'e daha küçük bir hedef decode boyutu iletmeye çalışır. Ağdan yine 4K JPEG indiriyorsanız indirme süresi ve transfer maliyeti devam eder. Ayrıca aynı URL'nin 96, 180 ve 360 cacheWidth ile kullanılması, ImageCache içinde üç farklı ImageProvider anahtarı oluşturabilir. Bu nedenle liste, detay ve tam ekran görüntüleyici için bilinçli boyut sınıfları tanımlayın. Thumbnail bileşenini sınırsız LayoutBuilder sonuçlarıyla kullanmak yerine 160, 320 ve 640 gibi sınıflara yuvarlamak anahtar patlamasını önler:

int imageBucket(int physicalWidth) {
  if (physicalWidth <= 160) return 160;
  if (physicalWidth <= 320) return 320;
  return 640;
}

Web hedefinde tarayıcı decode hattı nedeniyle cacheWidth ve cacheHeight her zaman native hedeflerdeki gibi uygulanmaz. Bu platformda asıl çözüm, uygun boyutlu dosyayı CDN'den istemektir.

ImageCache için ölçülebilir bellek sınırı belirlemek

ImageCache sınırı sert bir proses belleği tavanı değildir. Ekranda dinleyicisi bulunan canlı görseller, live image olarak tutulabilir ve LRU adayları gibi hemen boşaltılamaz. Bu nedenle sayfa geçişinde global olarak clearLiveImages çağırmak, geçici olarak grafiği düzeltse bile geri dönülen ekranda yeniden decode ve görüntü titremesi oluşturabilir. Bunun yerine route sahipliğini doğrulayın: özel bir ImageStream kullandıysanız listener'ı dispose içinde kaldırın. Geliştirme ortamında cache davranışını görünür kılmak için şu sayaçları loglayabilirsiniz:

final cache = PaintingBinding.instance.imageCache;
debugPrint('pending=${cache.pendingImageCount} '
    'live=${cache.liveImageCount} '
    'cached=${cache.currentSize} '
    'bytes=${cache.currentSizeBytes}');

pendingImageCount değerinin ağ kötüleştiğinde sürekli yüksek kalması, bellekten çok eşzamanlı indirme ve decode kuyruğu problemine işaret eder.

Flutter state management ile gereksiz görsel yeniden kurulumlarını ayırmak

State içine ImageProvider, ImageStreamCompleter veya BuildContext koymayın. Bunlar test edilebilir veri state'i yerine framework yaşam döngüsünü taşır ve provider anahtar eşitliğini belirsizleştirir. State'te yalnızca CDN yolu, dosya sürümü ve seçilmiş image bucket gibi serileştirilebilir alanlar tutun. URL sürümlendirmesi için CDN'nin ETag davranışını bozmadan immutable dosya adı kullanmak daha öngörülebilirdir:

String thumbnailUrl(String assetId, int bucket, String version) {
  return 'https://cdn.example.com/products/$assetId-$bucket.webp?v=$version';
}

version yalnızca piksel içeriği değiştiğinde değişmelidir. Her state emisyonunda zaman damgası eklemek, NetworkImage anahtarını değiştirir, cache isabetini sıfırlar ve ölçümlerde sahte bellek kaçağı görünümü yaratır.

Cross platform mobil uygulama geliştirme için CDN varyantları

Bir flutter kursu veya dart programlama eğitimi projesinde bu stratejiyi test edilebilir hale getirmek için URL üretimini saf fonksiyon yapın ve DPR sınırlarını birim testle koruyun. Özellikle 1.5 ve 2.625 gibi tam sayı olmayan DPR değerlerinde floor kullanmak bulanık görüntü üretirken, ceil gereğinden büyük decode maliyeti yaratabilir; round çoğu kart tasarımında makul dengedir. Test örneği şöyledir:

test('320 logical pixels at 2.625 DPR selects 640 bucket', () {
  final physical = (320 * 2.625).round();
  expect(imageBucket(physical), 640);
});

Bu yaklaşım, görsel boru hattını tasarım kararlarından bağımsız ölçülebilir kurallara dönüştürür.

Sık Sorulan Sorular

Flutter mobil uygulama geliştirmede ImageCache kaç MB olmalı?

Sabit bir sayı seçmeyin. Hedef cihazda flutter run --profile ile aynı kaydırma senaryosunu çalıştırın, görünür görsel bucket'larının width x height x 4 hesabını yapın ve ImageCache.maximumSizeBytes değerini bu bütçeye göre ayarlayın. Başlangıç için 80 << 20 gibi açık bir sınır koyup DevTools Memory'de External belleğin plato yapıp yapmadığını ölçün.

Flutter state management değişince görseller neden yeniden indiriliyor?

Genellikle NetworkImage anahtarı değişiyordur. URL'ye her state emisyonunda timestamp eklemek veya aynı görseli farklı cacheWidth değerleriyle oluşturmak ayrı cache girdileri üretir. Selector, BlocSelector veya Riverpod select ile kartı yalnızca thumbnailUrl değiştiğinde rebuild edin ve CDN URL'sindeki version alanını yalnızca gerçek içerik değişiminde güncelleyin.

Cross platform mobil uygulama geliştirmede cacheWidth webde yeterli mi?

Hayır. Web'de görsel decode işlemi tarayıcının hattındadır ve cacheWidth native hedeflerdeki kadar belirleyici olmayabilir. CDN'den w=320 gibi boyutlandırılmış varyant isteyin, tarayıcı Network panelinde indirilen byte sayısını doğrulayın ve native uygulamada ayrıca DevTools Memory ile decode belleğini ölçün.

Flutter eğitimi projelerinde büyük görseller için en kritik test nedir?

Gerçek cihazda profile modunda tekrarlı kaydırma testidir. İlk ve onuncu kaydırma sonrasında DevTools Memory snapshot alın, Performance kaydında raster p95'i karşılaştırın ve adb shell dumpsys meminfo ile süreç belleğini doğrulayın. Debug modunda alınan ölçüm, assertions ve farklı çalışma davranışı nedeniyle kabul kriteri olmamalıdır.