← Back to list

Flutter’da WebView ve Harita Gömme Derdi: Hybrid Composition++ ile Tanışın

WebView, harita ya da native bir video oynatıcıyı Flutter uygulamasına gömmek hiçbir zaman tam anlamıyla “sorunsuz” olmadı. Flutter 3.44…

AbdullahTaş · 2026-05-21 10:39 · 5 claps · 4.7 min read
#flutter #flutter-app-development #dart #mobile-app-development #webview
Open on Medium ↗
Wiki topics: VIS · Visual & Graphic Design 📱 · Mobile Development

Flutter’da WebView ve Harita Gömme Derdi: Hybrid Composition++ ile Tanışın

WebView, harita ya da native bir video oynatıcıyı Flutter uygulamasına gömmek hiçbir zaman tam anlamıyla “sorunsuz” olmadı. Flutter 3.44, bu eski meseleye Hybrid Composition++ adında yeni bir çözüm getiriyor. Bu yazıda nasıl çalıştığını, eski yöntemlerden farkını ve projenize bugün nasıl ekleyebileceğinizi konuşacağız.

Neden bu kadar zor bir iş?

Flutter’ın render mimarisi tek bir prensibe yaslanır: ekrandaki her pikseli Flutter’ın kendisi çizer. Widget ağacınız Impeller motoruna gider, oradan doğrudan GPU’ya. Flutter’ın platformlar arası tutarlılığının ve hızının altında bu basit kural yatar.

Ama bir WebView Flutter'a ait değildir. Onu Android'in kendi WebView bileşeni çizer. Yani ekranda artık iki ayrı çizim otoritesi vardır: bir yanda kendi arayüzünü çizen Flutter motoru, diğer yanda native bileşeni çizen Android.

İşin zor kısmı bu ikisini birleştirip her karede senkron tutmaktır. Senkronizasyon bir an için kaçtığında sonucu hemen görürsünüz — kaydırma sırasında native view Flutter içeriğinin arkasında kalır, ekran titrer, metin girişi bozulur ya da CPU gereksiz yere ısınır. Yıllardır geliştiricilerin platform view’lardan çekindiği nokta tam olarak burası.

HCPP’den Önce;

Hybrid Composition++’ı anlamak için kendinden öncekileri tanımak gerekiyor, çünkü HCPP bu üç yöntemin biriktirdiği derslerin üzerine kuruldu.

Virtual Display, en eski yaklaşım. Native view ekran dışında sanal bir ekrana çizilir, sonra bir texture olarak Flutter sahnesine taşınır. Tüm dönüşümler — döndürme, ölçekleme, opaklık — sorunsuz çalışır. Ama native view aslında gerçek ekranda olmadığı için sadakat sorunları çıkar ve ekstra grafik buffer’ları belleğe pahalıya mal olur.

Hybrid Composition (HC), native view’ı normal şekilde çizip Flutter içeriğini bir texture’a alır; ikisini Android’in SurfaceFlinger'ı birleştirir. Native view sadakati en iyi seviyededir, WebView ve SurfaceView düzgün davranır. Bedeli ise Flutter'ın kendi performansının düşmesi — birleştirme yükü Flutter'ın UI thread'ine biner.

Texture Layer Hybrid Composition (TLHC) bunun tersini yapar: native view’ı texture’a alır, Flutter’ı doğrudan ekrana çizer. Flutter render’ı en iyi seviyededir ve tüm dönüşümler çalışır. Karşılığında kaydırma takılır, SurfaceView sorun çıkarır, metin büyüteci bozulur.

Kısacası üçünde de bir köşe hep eksik kalıyordu:

Yöntem Performans Sadakat Asıl derdi Virtual Display İyi Düşük Bellek maliyeti Hybrid Composition Düşük En iyi Flutter performansı düşer Texture Layer HC İyi İyi Kaydırma takılır

HCPP işte bu eksik köşeyi kapatmak için geldi.

HCPP’nin fikri: işi işletim sistemine bırakmak

Hybrid Composition++’ın temel fikri sade ve bir o kadar da yerinde: iki çizim otoritesini Flutter birleştirmeye uğraşmasın — bu işi zaten bunun için tasarlanmış olan Android’in kendisi yapsın.

Flutter motoru, native view’ları kendi içine almaya ya da offscreen buffer’larla boğuşmaya çalışmak yerine, layer compositing’i doğrudan işletim sistemine devreder. Bunu üç modern Android teknolojisiyle yapar.

İlki Vulkan. HCPP, Vulkan’ın düşük seviyeli GPU erişimini kullanarak kareleri birleştirirken araya giren gereksiz katmanları ortadan kaldırır.

İkincisi hardware buffer swapchain’leri. Flutter arayüzü ve native view içeriği donanım buffer’larına yazılır; bu buffer’lar GPU ile CPU arasında kopyalanmadan doğrudan paylaşılır.

Asıl sihir ise üçüncüsünde, **SurfaceControl transaction'larında**. SurfaceControl, Android'in farklı görsel katmanları tek bir atomik transaction içinde güncellemesini sağlayan bir API. HCPP, Flutter arayüzünün ve native view'ın güncellemelerini aynı transaction'a koyar. Bunun pratik anlamı şu: Flutter karesi ile native view karesi ekrana ya birlikte düşer ya da hiç düşmez. Aradaki "yarım kare" gecikmesi ortadan kalkar — ki ekran titremesinin kökü tam olarak buydu.

Sonuçta elinize akıcı kaydırma, doğru çalışan dokunmatik girdi ve eski yöntemlerin en çok zorlandığı SurfaceView için sağlam bir destek geçer.

En sevindirici kısım: yeni API yok

HCPP’nin geliştirici tarafında en güzel yanı, mevcut kodunuza dokunmanızı gerektirmemesi. Ayrı bir Dart API’si getirmez; halihazırda kullandığınız PlatformViewLink ve AndroidViewSurface yapısı olduğu gibi çalışır:

Widget build(BuildContext context) {
  const String viewType = '<platform-view-type>';
  const Map<String, dynamic> creationParams = <String, dynamic>{};
  return PlatformViewLink(
    viewType: viewType,
    surfaceFactory: (context, controller) {
      return AndroidViewSurface(
        controller: controller as AndroidViewController,
        gestureRecognizers: const <Factory<OneSequenceGestureRecognizer>>{},
        hitTestBehavior: PlatformViewHitTestBehavior.opaque,
      );
    },
    onCreatePlatformView: (params) {
      return PlatformViewsService.initSurfaceAndroidView(
        id: params.id,
        viewType: viewType,
        layoutDirection: TextDirection.ltr,
        creationParams: creationParams,
        creationParamsCodec: const StandardMessageCodec(),
        onFocus: () => params.onFocusChanged(true),
      )
        ..addOnPlatformViewCreatedListener(params.onPlatformViewCreated)
        ..create();
    },
  );
}

Daha da iyisi, webview_flutter ve google_maps_flutter gibi yaygın paketler zaten bu mekanizmayı kullandığı için, HCPP'yi açtığınızda onlar da otomatik olarak yeni moddan faydalanır. Paketlerin güncellenmesini beklemenize gerek kalmaz.

Nasıl açılır?

İki yolu var. Geliştirme ve test sırasında komut satırı flag’i en pratiği:

flutter run --enable-hcpp
flutter test --enable-hcpp

Tek dikkat edilecek nokta, bu flag’in flutter build ile çalışmaması — yalnızca run ve test için geçerli.

Release build’lerde ise AndroidManifest.xml dosyasında <application> bloğunun içine bir satır ekliyorsunuz:

<application>
    <meta-data
        android:name="io.flutter.embedding.android.EnableHcpp"
        android:value="true" />
</application>

Gereksinimler ve neden production’da açmak risksiz

HCPP modern donanıma yaslanıyor: Android 14 (API 34) ve üzeri ile Vulkan destekli bir cihaz gerekiyor.

Peki kullanıcının cihazı bunları karşılamıyorsa? İşte HCPP’yi bugünden açmayı güvenli kılan kısım burası: cihaz gereksinimleri karşılamadığında Flutter, uygulamanızın hâlihazırda kullandığı platform view stratejisine sessizce geri döner. Yani manifest’e o satırı eklemek “tüm kullanıcılarımı Android 14'e zorluyorum” demek değildir. Yeni cihazlar HCPP’nin akıcılığını alır, eskiler eskisi gibi çalışmaya devam eder — ve siz bunun için tek satır ek kod yazmazsınız.

HCPP şu an deneysel bir özellik ve henüz varsayılan değil. Birkaç noktayı bilmekte fayda var;

En dikkat çekeni karmaşık overlay yığını sorunu. Şu dört katman üst üste kesiştiğinde görüntü doğru çizilmeyebiliyor: Flutter canvas, üzerine bir platform view, onun üzerine bir overlay ve en üstte şeffaf bir platform view. Bu özel desene düşüyorsanız overlay hiyerarşinizi yeniden düzenlemeniz gerekir.

Bunun dışında API 34 katı bir alt sınır; daha eski cihazlarda HCPP hiç devreye girmez. Vulkan desteklemeyen cihazlar da aynı şekilde eski yönteme düşer. Son olarak, SurfaceView veya SurfaceTexture içeren platform view'larda çizimden sonra manuel olarak invalidate() çağırmanız gerekebilir.

Pratikte en çok nerede parlıyor?

HCPP’nin farkını en net hissettireceği yer, WebView’ın yoğun ve etkileşimli kullanıldığı ekranlar. Akla gelen ilk örnek 3D Secure ödeme doğrulaması.

3D Secure ekranı tipik olarak bir WebView içinde açılır; kullanıcı içeride form doldurur, sayfayı kaydırır, SMS kodunu girer. Eski Hybrid Composition modunda bu ekran kaydırmada takılabilir ya da klavye girişinde tuhaf davranabilirdi — ve bu, ödeme gibi kritik bir akışta kullanıcı güvenini doğrudan zedeler. HCPP ile aynı WebView, hiçbir kod değişikliği olmadan, native transaction senkronizasyonu sayesinde akıcı kaydırma ve doğru girdi davranışı kazanır. WebView gömen e-ticaret, ödeme ve içerik uygulamaları bu yeniliğin ilk büyük kazananları olacak.

Bugün ne yapmalı?

Hybrid Composition++, Flutter’ın platform view hikâyesinde bugüne kadarki en olgun adım. “Birleştirme işini Flutter değil, işletim sistemi yapsın” fikri basit ama doğru; ve SurfaceControl, Vulkan, hardware buffer gibi modern Android yeteneklerini tam anlamıyla kullanıyor.

Şu an deneysel olsa da yön belli — HCPP ileride varsayılan render modu olacak. Otomatik fallback mekanizması sayesinde bugünden test etmek, hatta production’da açmak risksiz.

Uygulamanızda WebView, harita ya da başka bir native view kullanıyorsanız yapılacaklar şöyle özetlenebilir: Android 14 yüklü bir cihazda flutter run --enable-hcpp ile çalıştırın, kaydırma ve girdi davranışını eski moduyla karşılaştırın, karmaşık overlay yığını sorununa düşmüyorsanız manifest'e flag'i ekleyip erkenden faydalanmaya başlayın.

Platform view’ların yıllardır süren “akıcılık mı, sadakat mi?” ikilemi nihayet geride kalıyor. Flutter ekosistemi için sessiz ama gerçek bir kazanç.

Kaynaklar: Flutter 3.44 sürüm notları · Hosting native Android views — Flutter Docs


메타데이터
post_id
a1c384db5042
slug
flutterda-webview-ve-harita-gömme-derdi-hybrid-composition-ile-tanışın-a1c384db5042
url
https://medium.com/@abdullahtas/flutterda-webview-ve-harita-g%C3%B6mme-derdi-hybrid-composition-ile-tan%C4%B1%C5%9F%C4%B1n-a1c384db5042
canonical_url
https://medium.com/@abdullahtas/flutterda-webview-ve-harita-g%C3%B6mme-derdi-hybrid-composition-ile-tan%C4%B1%C5%9F%C4%B1n-a1c384db5042
author_url
https://medium.com/@abdullahtas
status
ok
fetched_at
2026-06-20 20:29:01