Flutter WebAssembly: CanvasKit, skwasm ve Yayına Alma

[WBK AI]

Bir Flutter web uygulaması hızlı yüklenip büyük bir liste açıldığında veya veri filtrelenirken yavaşlayabilir. WebAssembly’ye derlemek bu işlerin bir kısmında yardımcı olabilir; ancak değişen yalnızca dosya biçimi değildir. Bu yazıda Dart derleyicisiyle çizim motorunu ayırıyor, WasmGC’nin hangi belleği yönettiğini açıklıyor ve üretime çıkmadan önce neleri kontrol etmeniz gerektiğine bakıyoruz.


TL;DR

• Anlamlı karşılaştırma JavaScript + CanvasKit ile Wasm + skwasm arasındadır. CanvasKit zaten Skia için WebAssembly kullanır.
• WasmGC, Wasm GC türleriyle temsil edilen Dart nesnelerini tarayıcının yönetmesini sağlar. Her Skia tahsisini veya GPU kaynağını otomatik olarak serbest bırakmaz.
• Çok iş parçacıklı çizimin ek sunucu koşulları vardır. Wasm çalıştırmak ile birden fazla iş parçacığında çizim yapmak aynı özellik değildir.
• Bu yazıda doğrulanmış üretim benchmarkı yoktur. Önceki rakamları neden kaldırdığımızı ve güvenilir bir karşılaştırmanın nasıl yapılabileceğini aşağıda açıklıyoruz.

İki derleme yolu: Wasm kullanan ve kullanmayan değil​

WebAssembly (Wasm), tarayıcıların derleyip çalıştırabildiği ikili bir komut biçimidir. Ek bir çalışma hedefidir; bütün tarayıcı API’lerinin yerini almaz ve daha hızlı açılış garantisi vermez. Flutter, Dart uygulama kodunu dart2js ile JavaScript’e veya dart2wasm ile Wasm’a derleyebilir. Çizim motoru, yani renderer, ayrı bir katmandır: CanvasKit ve skwasm, tarayıcıda Skia tabanlı çizim sağlar.

Katman	JavaScript derlemesi	Wasm derlemesi
Dart derleyicisi	dart2js	dart2wasm
Uygulama kodu	JavaScript; nesneleri tarayıcı yönetir	Wasm; yönetilen Dart nesneleri için WasmGC kullanılır
Çizim motoru	CanvasKit: Skia’nın Wasm derlemesi	skwasm: koşullar uygunsa çok iş parçacıklı çalışabilen, Skia tabanlı Wasm renderer
Release komutu	flutter build web	flutter build web --wasm

Uygulama kodunun çalışması ve çizim ayrı katmanlardır

Dar ekranda sütunları karşılaştırmak için tabloya odaklanıp yatay kaydırabilirsiniz.

Wasm derleme komutu bir JavaScript geri dönüş sürümü de üretir. Oluşturulan loader ve gerekli dosyalar eksiksiz yayımlandığında Flutter, Wasm yolu uygun değilse JavaScript + CanvasKit’i seçebilir. Wasm derlemesinde başlangıç ve tarayıcı entegrasyonu için hâlâ JavaScript gerekir; sonuç JavaScript’ten tamamen bağımsız bir uygulama değildir. Ayrıntılar için Flutter Wasm rehberine ve Dart derleyici belgelerine bakabilirsiniz.

Mimari şemayı göster

Bu bir mimari şema, süre ölçümü değil. Yukarıdaki tablo aynı bilgilerin metin karşılığını içerir. Tam boy sürümü açmak için görseli seçebilirsiniz.

WasmGC neyi değiştiriyor, neyi değiştirmiyor?​

WasmGC, WebAssembly’ye yönetilen yapı ve dizi türleri ekler. Derleyici, dilin nesnelerini bu türlerle temsil ederek erişilebilirlik takibini ve kullanılmayan nesnelerin temizlenmesini çalışma ortamına bırakabilir. Böylece dart2wasm, bu nesneler için ayrı bir çöp toplayıcıyı paketlemek yerine tarayıcı motorunun GC altyapısından yararlanır. V8 ekibinin açıklaması, avantajların yanında uygulama tercihlerini ve sınırlamaları da anlatır.

Yine de farklı bellek türleri vardır. WasmGC’nin yönettiği Dart nesneleri; bir C++ modülünün adreslenebilir bayt alanındaki, yani lineer belleğindeki tahsislerle veya tarayıcı ve GPU’nun sahip olduğu grafik kaynaklarıyla aynı şey değildir. Skia ile ilgili handle, surface ve buffer’ların yaşam döngüleri devam eder. Örneğin Flutter’ın skwasm surface uygulaması, native kaynakları açıkça serbest bırakır.

Eski mimariyi “çift çöp toplayıcı maliyeti” diye açıklamak bu ayrımı gizler. Lineer bellekte tahsis yapılması, erişilebilir nesneleri izleyen ikinci bir çöp toplayıcı bulunduğu anlamına gelmez. Benzer biçimde WasmGC; elde tutulan referanslar, uygulama önbellekleri veya bırakılmayan grafik kaynakları yüzünden oluşan sızıntıları önlemez.

Tarayıcıyla iletişimin maliyeti hâlâ var​

Tarayıcı olaylarını işlerken ve DOM’a erişirken interop maliyeti devam eder. Bazı çağrılar ucuz olabilir; ancak tür dönüşümleri, metinler, callback’ler ve veri kopyalama zaman harcayabilir. WasmGC, DOM’a sıfır maliyetli bir köprü kurmaz. Yoğun JSON ayrıştırma da ana iş parçacığını meşgul edebilir; kodu Wasm’a derlemek işi kendiliğinden bir worker’a taşımaz.

Geçişten önce bağımlılıkları kontrol edin. Flutter, Wasm uyumlu tarayıcı entegrasyonu için dart:html veya package:js gibi desteklenmeyen eski yaklaşımlar yerine dart:js_interop ve package:web kullanımını önerir. Geçiş adımları resmî interop rehberinde açıklanıyor.

Tarayıcı desteği Flutter sürümüne bağlı​

Bir tarayıcının WasmGC desteklemesi, belirli bir Flutter derlemesinin Wasm yolunu seçeceğini veya sorunsuz çalıştıracağını kanıtlamaz. Gereken Wasm özellikleri, grafik desteği, motor kısıtları ve loader ayarları birlikte değerlendirilmelidir. Güncel uyumluluk belgesini kullandığınız SDK sürümüyle birlikte okuyun.

Sürüm kapsamı: Aşağıdaki loader davranışı Flutter 3.47.0 kaynak koduyla doğrulandı; yaşayan belgelerde anlatılan her sürüm için geçerli değildir. Bu sürümün loader’ı WasmGC’yi, WebGL kullanılabilirliğini ve tarayıcı motoru izin listesini kontrol eder. Varsayılan liste Wasm seçimi için Blink’e izin verirken Gecko ve WebKit’i kapalı tutar. Sabit sürüme ait tarayıcı ortamı ve derleme seçimi kodları bu ayrımı gösteriyor.

• Chrome / Chromium tabanlı tarayıcılar: 3.47.0’da Blink varsayılan olarak izinlidir; diğer çalışma zamanı kontrollerinin de geçmesi gerekir.
• Firefox: Bu sürümde Gecko için Wasm seçimi varsayılan olarak açık değildir. Tarayıcının WasmGC desteği tek başına loader kararını değiştirmez.
• Safari / WebKit: 3.47.0’da WebKit için de aynı varsayılan kısıt geçerlidir. Geçmişteki bir WasmGC sürüm numarasına dayanmak yerine hedeflediğiniz macOS ve iOS ortamlarını test edin.

wasmAllowList seçeneği seçim politikasını değiştirir; tarayıcıya eksik özellik eklemez ve uyumluluğu kanıtlamaz. Listeyi ancak uygulamanızı test ettikten sonra genişletin. JavaScript geri dönüş yolunu da deneyin; loader, modüller ve varlıklar aynı derlemeye ait olacak şekilde bütün çıktıyı yayımlayın. Başlatma rehberi loader ayarlarını açıklıyor; sonraki SDK sürümlerinde varsayılanlar değişebilir.

Derleme ve yayın öncesi sunucu kontrolleri​

Önce araç zincirinin sürümünü kaydedin, ardından release derlemesini oluşturun:

flutter --version
flutter build web --wasm --release

Gerçek çalıştırmada hangi uygulama hedefinin seçildiğini kontrol edin. Derleme sırasında belirlenen bu bayrağı bir tanılama ekranında gösterebilirsiniz. Ağ panelinde .wasm dosyası görmek tek başına yeterli değildir; CanvasKit de Wasm indirir:


const isWasm = bool.fromEnvironment('dart.tool.dart2wasm');

Çok iş parçacıklı çizim için cross-origin isolation​

Cross-origin isolation, paylaşılan bellek için kullanılan SharedArrayBuffer gibi özelliklere erişim sağlayan, tarayıcının uyguladığı bir güvenlik durumudur. WasmGC ile eş anlamlı değildir. Desteklenen ortamlarda skwasm, çok iş parçacıklı çizimin koşulları sağlanmıyorsa tek iş parçacığında çalışabilir. Bu özellik, Dart uygulama mantığının otomatik olarak paralel çalışması anlamına da gelmez.

Çok iş parçacıklı yol için HTTPS veya uygun, güvenilir bir yerel geliştirme adresi kullanın ve izolasyonu yapılandırın. Olası bir HTTP yanıt başlığı çifti aşağıda gösteriliyor. Bunlar Nginx veya LiteSpeed yapılandırma direktifleri değil, yanıt başlıklarının değerleridir:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Desteklendiği ortamlarda credentialless diğer bir COEP seçeneğidir. Belirli cross-origin no-cors kaynaklarının CORP izni olmadan yüklenebilmesini, istekte kimlik bilgilerini göndermeyerek sağlar. CORS modundaki istekler için CORS’u devre dışı bırakmaz; her durumda require-corp seçeneğinden daha güvenli değildir. Kaynaklarınıza ve hedef tarayıcılarınıza uygun politikayı seçin. Yayından önce fontları, görselleri, gömülü içerikleri ve açılır pencereyle çalışan giriş akışlarını test edin. MDN COEP referansı ve web.dev izolasyon rehberi bu davranışları açıklıyor.


window.crossOriginIsolated

Sonucun true olması izolasyonu doğrular; uygulamanın skwasm seçtiğini veya bir çizim worker’ı başlattığını göstermez. Yüklenen derlemeyi ve worker etkinliğini ayrıca inceleyin. Permissions Policy ve gömülme kısıtları da izole özelliklere erişimi etkileyebilir.

Modülleri doğru başlıklarla sunun​

Akışlı derlemenin doğru çalışabilmesi için .wasm dosyalarını Content-Type: application/wasm ile gönderin. Brotli veya gzip’i uygun Content-Encoding başlığıyla yapılandırın; sıkıştırılmış dosyayı yeniden adlandırmak yeterli değildir. Yayındaki sunucuda varlık yollarını, CDN yanıtlarını ve önbellek geçersizleştirmeyi kontrol edin. MIME gereksinimi akışlı modül başlatma referansında açıklanıyor.

Önceki benchmark tablosu neden kaldırıldı?​

Ölçümlerin durumu

Önceki sürümde Subara Web’e ait üretim sonuçları sunuluyordu. Bu incelemede rakamları destekleyen ham trace’lere, tekrarlanabilir bir benchmarka veya yeterli test ortamı bilgisine ulaşamadık. Bu nedenle tabloyu ve üretim performansı iddialarını kaldırdık. Bu düzenleme için yeni bir karşılaştırmalı benchmark çalıştırılmadı.


Subara’nın açık deposu kontrol edildi; fakat uygulama deposunun bulunması belirli bir süre ölçümünün kanıtı değildir. Tekrarlanabilir yapılandırması verilmediği için 4G test koşulu iddiası da çıkarıldı. Yeni bir karşılaştırma için web’de çalışmaya hazır bir uygulama, sabit bir commit ve aşağıdaki test kaydı gerekir.

Yükleme, çalışma ve çizimi ayrı ölçün​

TTI (Time to Interactive), sayfanın güvenilir biçimde etkileşime hazır hâle gelmesini ölçen tarihsel bir metriktir. Lighthouse 10’dan kaldırılmıştır; sessizce “ilk Flutter karesi” olarak yeniden tanımlanmamalıdır. Uygulamaya özel başlangıç testi yapacaksanız, ilk veri yüklendikten sonra filtrenin kullanılabilmesi gibi gözlenebilir bir hazır olma olayı seçin. Başlangıç ve bitiş koşullarını yazın; uygun yerlerde güncel, kullanıcı odaklı metriklerden yararlanın. Ayrıntılar web.dev’in TTI belgesinde bulunuyor.

Kare süresi (frame time), kare üretiminin veya sunumunun bir aşamasıyla ilişkili süreyi anlatır; trace’in hangi aşamayı ölçtüğünü belirtin. p95 ve p99, yüzdelik değerlerdir: gözlemlerin yaklaşık %95’i veya %99’u verilen sürede ya da altında kalır. Ortalamaya göre en yavaş kareler hakkında daha fazla bilgi verirler, ancak her karenin süresini göstermezler.

120 Hz ekranda yenileme aralığı yaklaşık 8,33 ms, 60 Hz ekranda ise 16,67 ms olur. p99’un 120 Hz aralığının altında kalması sürekli 120 FPS kanıtı değildir: kalan kuyrukta bütçe aşılabilir ve tek bir ölçüm aşaması bütün sunum sürecini kapsamayabilir. Bu aralıklar ekran yenileme hızından hesaplanır; uygulamalarımızdan alınmış benchmark sonuçları değildir.

Tekrarlanabilir karşılaştırma kontrol listesi​

1. Girdileri sabitleyin: Aynı uygulama commit’ini, veriyi, fontları, varlıkları ve release ayarlarını kullanın. Flutter/Dart ve tarayıcı sürümlerini; cihazı, CPU/GPU’yu, işletim sistemini ve ekran yenileme hızını kaydedin.
2. İki derlemeyi de kontrol edin: Çalışma sırasında JavaScript + CanvasKit ve Wasm + skwasm yollarını doğrulayın. Çizimin tek veya çok iş parçacıklı olduğunu kaydedin; aksi hâlde derleyici ile renderer değişikliklerinin etkileri birbirine karışır.
3. Önbellek durumlarını ayırın: Soğuk başlangıcı açıkça tanımlayın; örneğin temiz bir profil ve temizlenmiş depolama/önbellek. Sıcak başlangıçta belirtilen önbellekler yeniden kullanılır; bu tekrarları ayrı tutun. HTTP önbelleklerini, varsa service worker’ı ve tekrarları etkileyebilen kalıcı tarayıcı derleme önbelleklerini belirtin.
4. Ağ kısıtlamasını tanımlayın: Network throttling, bant genişliği ve gecikme sınırlarını taklit eder. İndirme/yükleme hızını, gecikmeyi, kullanılan aracı ve CPU kısıtlamasının ayrıca uygulanıp uygulanmadığını yazın. “4G” etiketi tek başına tam bir test yapılandırması değildir.
5. Tekrarlarla veri toplayın: Örnek sayısını, başarısız çalıştırmaları, test sırasını ve değişkenliği kaydedin. Başlangıç için medyanı; kare süreleri için p95/p99’u, bütçeyi aşan kareleri ve senaryo süresini raporlayın. JavaScript heap’i, WasmGC nesneleri, lineer bellek kapasitesi ve GPU belleğini açıklamasız tek bir tahsis metriğinde birleştirmeyin.
6. Kanıtı paylaşın: Test betiğini, ham süreleri, tarayıcı performans trace’lerini ve derleme kimliklerini ekleyin. “Hazır” durumunun anlamını ve araçların hangi bellek alanlarını görebildiğini de kapsayan ölçüm sınırlarını yazın.

İndirme boyutu ayrı bir ölçümdür. Tek bir renderer modülünü uygulamanın tamamıyla değil, aynı yükleme aşamasında gerçekten aktarılan sıkıştırılmış baytları karşılaştırın. Dart’ın daha hızlı çalışması CPU’ya yüklenen bir filtreye yardımcı olabilir; ancak ağ aktarımının veya yavaş bir API’nin belirlediği açılışı gözle görülür biçimde hızlandırmayabilir.

Wasm derlemesini ne zaman yayımlamalısınız?​

Dart kodunun çalışması ölçülebilir bir darboğazsa, bağımlılıklar uyumluysa ve hedef tarayıcı kitlesi istenen çizim yolunu destekliyorsa Wasm’ı değerlendirmek anlamlıdır. Sunucu ve tarayıcı koşulları uygunsa çok iş parçacıklı skwasm da çizim yüküne yardımcı olabilir. Bu iki kazanımı ayrı ölçün.

Beklemenin büyük bölümü API yanıtlarından, görsel çözmeden, ağır efektlerden veya varlık dağıtımından kaynaklanıyorsa daha az fark bekleyin. Metin ağırlıklı, herkese açık sayfalarda uygulama odaklı bir renderer’ın ürüne uygun olup olmadığını da değerlendirin; Flutter’ın web rehberi bu ayrımı yapıyor.

Pratik karar, daha etkileyici derleyici adına değil; başlangıç, etkileşim, bellek ve uyumluluk bütçelerinizi karşılayan derlemeye dayanmalı. Önce geri dönüş yolunu ve sunucu entegrasyonlarını doğrulayın. Ardından Wasm’ın gerçekten karşılaştığınız darboğazı değiştirip değiştirmediğine trace’lerle karar verin. Native platformlarda çizim farklı bir yol izler; bunu Impeller yazısında ayrıca ele alıyoruz.

Kaynaklar ve inceleme kapsamı​

Teknik inceleme: 26 Ekim 2026. Loader’a özgü bilgiler Flutter 3.47.0’a sabitlenmiştir. Yaşayan Flutter ve Dart belgelerinde daha yeni sürümlere ait açıklamalar da bulunur; kendi SDK’nıza uyan bölümleri kullanın. TR ve EN sürümleri aynı teknik kapsama, ölçüm durumuna ve önerilere sahiptir.

• Flutter Wasm desteği ve Dart Wasm derlemesi — derleme, geri dönüş ve interop gereksinimleri.
• Flutter 3.47.0 loader ve tarayıcı ortamı — sürüme özgü çalışma zamanı seçimi.
• V8: GC kullanan dilleri WasmGC’ye taşıma — yönetilen nesneler ve lineer bellek ayrımı.
• MDN: COEP ve web.dev: cross-origin isolation — politika davranışı ve yayına etkileri.
• Flutter başlatma süreci, TTI’ın durumu ve Wasm akışlı modül başlatma — tanılama ve ölçüm ayrıntıları.