Mobil uygulama geli\u015ftirmenin karma\u015f\u0131k d\u00fcnyas\u0131nda, Flutter, deklaratif kullan\u0131c\u0131 aray\u00fcz\u00fc yakla\u015f\u0131m\u0131 ve “her \u015fey bir widget’t\u0131r” felsefesiyle g\u00fc\u00e7l\u00fc bir \u00e7\u00f6z\u00fcm sunuyor. Peki, bu widget’lar ne anlama geliyor ve uygulaman\u0131z\u0131n kalbindeki kaynak koduna kadar nas\u0131l bir yolculuk yap\u0131yorlar? Bu makalede, Flutter’\u0131n temel yap\u0131 ta\u015flar\u0131ndan ba\u015flayarak, ekran\u0131n\u0131zdaki her pikselin nas\u0131l olu\u015ftu\u011funu anlamak i\u00e7in derinlemesine bir ke\u015ffe \u00e7\u0131kaca\u011f\u0131z.<\/p>\n
G\u00fcn\u00fcm\u00fcz mobil uygulama pazar\u0131nda kullan\u0131c\u0131 deneyimi (UX) ve performans, bir uygulaman\u0131n ba\u015far\u0131s\u0131n\u0131 do\u011frudan etkileyen en kritik fakt\u00f6rler aras\u0131nda yer al\u0131yor. Geli\u015ftiriciler, hem iOS hem de Android platformlar\u0131nda tutarl\u0131 ve y\u00fcksek performansl\u0131 uygulamalar olu\u015fturmak i\u00e7in s\u00fcrekli yeni yollar ar\u0131yorlar. \u0130\u015fte tam da bu noktada Google’\u0131n kullan\u0131c\u0131 aray\u00fcz\u00fc (UI) ara\u00e7 tak\u0131m\u0131 Flutter devreye giriyor. Flutter, Dart programlama diliyle yaz\u0131lm\u0131\u015f, tek bir kod taban\u0131ndan hem mobil hem de web ve masa\u00fcst\u00fc uygulamalar\u0131 geli\u015ftirmeye olanak tan\u0131yan a\u00e7\u0131k kaynakl\u0131 bir framework (yaz\u0131l\u0131m \u00e7er\u00e7evesidir).<\/p>\n
Flutter’\u0131n en temel ve ay\u0131rt edici \u00f6zelliklerinden biri, “her \u015fey bir widget’t\u0131r” felsefesidir. Bir d\u00fc\u011fmeden (button) bir metin alan\u0131na (text field), bir d\u00fczenleyiciye (layout manager) kadar her \u015fey, hatta uygulaman\u0131n kendisi bile bir widget’t\u0131r. Bu yakla\u015f\u0131m, geli\u015ftiricilere son derece esnek ve mod\u00fcler bir yap\u0131 sunar. Widget’lar, kullan\u0131c\u0131 aray\u00fcz\u00fcn\u00fcn g\u00f6r\u00fcn\u00fcm\u00fcn\u00fc ve etkile\u015fimini tan\u0131mlayan de\u011fi\u015fmez (immutable) yap\u0131land\u0131rmalard\u0131r. Yani bir widget olu\u015fturulduktan sonra \u00f6zellikleri de\u011fi\u015ftirilemez; e\u011fer bir de\u011fi\u015fiklik gerekiyorsa, Flutter yeni bir widget olu\u015fturur ve eskisinin yerine koyar. Bu deklaratif (bildirimsel) yakla\u015f\u0131m, uygulaman\u0131n durumunu y\u00f6netmeyi ve UI’\u0131 g\u00fcncelle\u015ftirmeyi \u00e7ok daha \u00f6ng\u00f6r\u00fclebilir ve kolay hale getirir.<\/p>\n
Peki, bu widget’lar\u0131n ne oldu\u011funu anlamak neden bu kadar \u00f6nemli? \u00c7\u00fcnk\u00fc Flutter’\u0131n i\u00e7 i\u015fleyi\u015fini ve performans optimizasyonlar\u0131n\u0131 kavraman\u0131n anahtar\u0131, widget mimarisini derinlemesine bilmekten ge\u00e7er. Widget’lar sadece ekranda g\u00f6rd\u00fc\u011f\u00fcn\u00fcz g\u00f6rsel elemanlar de\u011fildir; ayn\u0131 zamanda uygulaman\u0131z\u0131n durumunu, etkile\u015fimlerini ve hatta performans\u0131n\u0131 do\u011frudan etkileyen soyut yap\u0131lard\u0131r. Widget’lar\u0131n nas\u0131l bir araya geldi\u011fini, nas\u0131l g\u00fcncellendi\u011fini ve nihayetinde ekran\u0131n\u0131zdaki piksellere nas\u0131l d\u00f6n\u00fc\u015ft\u00fc\u011f\u00fcn\u00fc anlamak, daha verimli, \u00f6l\u00e7eklenebilir ve hatas\u0131z Flutter uygulamalar\u0131 geli\u015ftirmenizi sa\u011flar. Bu temel anlay\u0131\u015f, karma\u015f\u0131k kullan\u0131c\u0131 aray\u00fczleri olu\u015ftururken kar\u015f\u0131la\u015f\u0131lan sorunlar\u0131 \u00e7\u00f6zmenize, uygulaman\u0131z\u0131n ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc (lifecycle) y\u00f6netmenize ve hatta nadir performans darbo\u011fazlar\u0131n\u0131 gidermenize yard\u0131mc\u0131 olacakt\u0131r. Dolay\u0131s\u0131yla, Flutter ile ger\u00e7ekten ustala\u015fmak istiyorsan\u0131z, widget’lar\u0131n derinliklerine inmek ka\u00e7\u0131n\u0131lmaz bir ad\u0131md\u0131r.<\/p>\n
Flutter’\u0131n “her \u015fey bir widget’t\u0131r” felsefesi, uygulama geli\u015ftirme yakla\u015f\u0131m\u0131n\u0131 k\u00f6kten de\u011fi\u015ftirir. Geleneksel imperatif (emredici) UI geli\u015ftirme yakla\u015f\u0131mlar\u0131nda, bir aray\u00fcz eleman\u0131n\u0131 de\u011fi\u015ftirmek istedi\u011finizde, mevcut eleman\u0131 bulur ve \u00f6zelliklerini do\u011frudan manip\u00fcle edersiniz. \u00d6rne\u011fin, bir metin kutusunun rengini de\u011fi\u015ftirmek i\u00e7in o metin kutusuna referans al\u0131r ve rengini ayarlars\u0131n\u0131z. Ancak Flutter, deklaratif (bildirimsel) bir yakla\u015f\u0131mla \u00e7al\u0131\u015f\u0131r. Bu ne anlama geliyor? Deklaratif UI’da, uygulaman\u0131z\u0131n mevcut durumuna g\u00f6re kullan\u0131c\u0131 aray\u00fcz\u00fcn\u00fcn nas\u0131l g\u00f6r\u00fcnmesi gerekti\u011fini “bildirirsiniz”. Flutter ise bu bildirimi al\u0131r ve UI’\u0131 o duruma getirmek i\u00e7in gerekli t\u00fcm i\u015flemleri kendi ba\u015f\u0131na halleder.<\/p>\n
Bu felsefenin merkezinde widget’lar bulunur. Bir widget, uygulaman\u0131z\u0131n kullan\u0131c\u0131 aray\u00fcz\u00fcn\u00fcn bir b\u00f6l\u00fcm\u00fcn\u00fc tan\u0131mlayan de\u011fi\u015fmez (immutable) bir yap\u0131land\u0131rmad\u0131r. Yani, bir widget olu\u015fturulduktan sonra, onun \u00f6zellikleri (rengi, boyutu, metni vb.) de\u011fi\u015ftirilemez. E\u011fer bir widget’\u0131n \u00f6zelliklerinin de\u011fi\u015fmesi gerekiyorsa, Flutter asl\u0131nda yeni bir widget \u00f6rne\u011fi olu\u015fturur ve eskisinin yerine koyar. Bu, UI’\u0131n her zaman uygulaman\u0131n g\u00fcncel durumunu do\u011fru bir \u015fekilde yans\u0131tmas\u0131n\u0131 sa\u011flar ve hata olas\u0131l\u0131\u011f\u0131n\u0131 azalt\u0131r.<\/p>\n
Flutter’da iki ana widget t\u00fcr\u00fc bulunur:<\/p>\n
StatelessWidget<\/code> (Durumsuz Widget)<\/strong>: Ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, bu widget’lar kendi i\u00e7lerinde herhangi bir durumu (state) bar\u0131nd\u0131rmazlar. Yani, olu\u015fturulduktan sonra g\u00f6r\u00fcn\u00fcmleri de\u011fi\u015fmez. Genellikle statik metinler, ikonlar veya sabit g\u00f6r\u00fcn\u00fcml\u00fc d\u00fc\u011fmeler gibi elemanlar i\u00e7in kullan\u0131l\u0131rlar. \u00d6rne\u011fin, bir Text<\/code> widget’\u0131 veya bir Icon<\/code> widget’\u0131 bir StatelessWidget<\/code>‘t\u0131r.<\/li>\nStatefulWidget<\/code> (Durumlu Widget)<\/strong>: Bu widget’lar, ya\u015fam d\u00f6ng\u00fcleri boyunca de\u011fi\u015febilen bir duruma sahiptirler. Kullan\u0131c\u0131 etkile\u015fimleri (d\u00fc\u011fmeye t\u0131klama, metin giri\u015fi) veya harici veri de\u011fi\u015fiklikleri sonucunda g\u00f6r\u00fcn\u00fcmleri g\u00fcncellenebilir. Bir StatefulWidget<\/code>, bir State<\/code> nesnesi ile e\u015fle\u015ftirilir. Bu State<\/code> nesnesi, widget’\u0131n durumunu y\u00f6netir ve setState()<\/code> metodu \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda widget’\u0131n yeniden \u00e7izilmesini (rebuild) tetikler. \u00d6rne\u011fin, bir saya\u00e7 uygulamas\u0131 veya bir form giri\u015fi i\u00e7in StatefulWidget<\/code> kullan\u0131l\u0131r.<\/li>\n<\/ul>\nHer iki widget t\u00fcr\u00fc de bir build<\/code> metodu i\u00e7erir. Bu metod, widget’\u0131n kendi alt widget’lar\u0131n\u0131 (child widgets) nas\u0131l olu\u015fturaca\u011f\u0131n\u0131 ve bir araya getirece\u011fini tan\u0131mlar. Bu sayede, t\u00fcm Flutter uygulamas\u0131, i\u00e7 i\u00e7e ge\u00e7mi\u015f widget’lardan olu\u015fan bir a\u011fa\u00e7 (widget tree) yap\u0131s\u0131 olarak temsil edilir. Bu a\u011fa\u00e7, uygulaman\u0131n g\u00f6rsel hiyerar\u015fisini ve bile\u015fenler aras\u0131ndaki ili\u015fkileri g\u00f6sterir. \u00d6rne\u011fin, bir Center<\/code> widget’\u0131 bir Text<\/code> widget’\u0131n\u0131 sarmalayabilir, bu da Text<\/code> widget’\u0131n\u0131n ekran\u0131n ortas\u0131nda g\u00f6r\u00fcnmesini sa\u011flar. Bu hiyerar\u015fik yap\u0131, Flutter’\u0131n UI’\u0131 verimli bir \u015fekilde d\u00fczenlemesine ve boyamas\u0131na olanak tan\u0131r.<\/p>\nWidget’lar, do\u011frudan ekrandaki piksellerle ilgilenmezler. Bunun yerine, Flutter’\u0131n i\u00e7 mekanizmalar\u0131na, yani Element<\/code> ve RenderObject<\/code> katmanlar\u0131na bir “yap\u0131land\u0131rma” (configuration) sa\u011flarlar. Element<\/code>‘lar, widget a\u011fac\u0131n\u0131 y\u00f6netir ve widget’lar ile RenderObject<\/code>‘lar aras\u0131nda bir k\u00f6pr\u00fc g\u00f6revi g\u00f6r\u00fcrken, RenderObject<\/code>‘lar ise ekran \u00fczerinde ger\u00e7ek d\u00fczenleme ve boyama i\u015flemlerini ger\u00e7ekle\u015ftirirler. Bu katmanl\u0131 mimari, Flutter’\u0131n performans\u0131n\u0131 ve esnekli\u011fini sa\u011flayan temel ta\u015flardan biridir. \u0130\u015fte basit bir StatelessWidget<\/code> \u00f6rne\u011fi:<\/p>\n\nimport 'package:flutter\/material.dart';\n\nclass MySimpleApp extends StatelessWidget {\n @override\n Widget build(BuildContext context) {\n return MaterialApp(\n home: Scaffold(\n appBar: AppBar(\n title: const Text('Merhaba Flutter'),\n ),\n body: const Center(\n child: Text(\n 'Bu bir StatelessWidget \u00f6rne\u011fidir!',\n style: TextStyle(fontSize: 24, fontWeight: FontWeight.bold),\n ),\n ),\n ),\n );\n }\n}<\/code><\/pre>\n<\/div>\nYukar\u0131daki \u00f6rnekte, MySimpleApp<\/code> bir StatelessWidget<\/code>‘t\u0131r. \u0130\u00e7inde bir MaterialApp<\/code>, Scaffold<\/code>, AppBar<\/code>, Center<\/code> ve Text<\/code> widget’lar\u0131n\u0131 bar\u0131nd\u0131r\u0131r. Her biri, uygulaman\u0131n g\u00f6rsel yap\u0131s\u0131n\u0131n bir par\u00e7as\u0131n\u0131 tan\u0131mlayan de\u011fi\u015fmez yap\u0131land\u0131rmalard\u0131r. Bu yakla\u015f\u0131m, karma\u015f\u0131k UI’lar\u0131 k\u00fc\u00e7\u00fck, y\u00f6netilebilir ve tekrar kullan\u0131labilir par\u00e7alara b\u00f6lerek geli\u015ftirme s\u00fcrecini \u00f6nemli \u00f6l\u00e7\u00fcde h\u0131zland\u0131r\u0131r ve basitle\u015ftirir.<\/p>\nWidget’tan Element’e Ge\u00e7i\u015f: Flutter’\u0131n Kalbi Nas\u0131l At\u0131yor?<\/h2>\n
Flutter’da widget’lar, kullan\u0131c\u0131 aray\u00fcz\u00fcn\u00fcn g\u00f6r\u00fcn\u00fcm\u00fcn\u00fc ve etkile\u015fimini tan\u0131mlayan soyut “yap\u0131land\u0131rma” (configuration) nesneleridir. Ancak bu widget’lar, do\u011frudan ekranda g\u00f6r\u00fcnen piksellerle ilgilenmezler. Bu noktada devreye Flutter’\u0131n \u00fc\u00e7 ana a\u011fac\u0131ndan ikincisi olan Element<\/code> a\u011fac\u0131 girer. Bir widget olu\u015fturuldu\u011funda, Flutter motoru (engine) bu widget’\u0131 kullanarak bir Element<\/code> \u00f6rne\u011fi olu\u015fturur. Bu Element<\/code>, widget ile ekran \u00fczerindeki ger\u00e7ek boyama ve d\u00fczenleme i\u015flerini yapan RenderObject<\/code> aras\u0131nda bir k\u00f6pr\u00fc g\u00f6revi g\u00f6r\u00fcr.<\/p>\nElement<\/code>‘lar, widget a\u011fac\u0131n\u0131n ger\u00e7ek “canl\u0131” temsilcileridir. Bir widget de\u011fi\u015fmez (immutable) olmas\u0131na ra\u011fmen, bir Element<\/code> de\u011fi\u015febilir (mutable). Yani, ayn\u0131 Element<\/code> \u00f6rne\u011fi, farkl\u0131 widget yap\u0131land\u0131rmalar\u0131n\u0131 bar\u0131nd\u0131rabilir. Flutter, bir widget a\u011fac\u0131n\u0131 yeniden olu\u015fturmas\u0131 gerekti\u011finde (\u00f6rne\u011fin, setState()<\/code> \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda), mevcut Element<\/code> a\u011fac\u0131n\u0131 yeni widget a\u011fac\u0131yla kar\u015f\u0131la\u015ft\u0131r\u0131r. E\u011fer eski ve yeni widget’lar ayn\u0131 “t\u00fcrde” (runtimeType) ise ve ayn\u0131 “anahtara” (key) sahiplerse, Flutter mevcut Element<\/code>‘\u0131 yeniden kullan\u0131r ve sadece i\u00e7indeki widget referans\u0131n\u0131 g\u00fcnceller. Bu, Flutter’\u0131n “diffing” algoritmas\u0131n\u0131n temelidir ve performans\u0131 art\u0131rmak i\u00e7in \u00e7ok \u00f6nemlidir \u00e7\u00fcnk\u00fc t\u00fcm a\u011fac\u0131 ba\u015ftan olu\u015fturmak yerine sadece de\u011fi\u015fen k\u0131s\u0131mlar\u0131 g\u00fcnceller.<\/p>\nHer Element<\/code>, ayn\u0131 zamanda bir BuildContext<\/code>‘tir. BuildContext<\/code>, widget a\u011fac\u0131ndaki bir widget’\u0131n konumunu temsil eden bir handle’d\u0131r. Bu, bir widget’\u0131n a\u011fa\u00e7taki di\u011fer widget’lara eri\u015fmesini veya yukar\u0131 do\u011fru a\u011fa\u00e7ta bir parent widget’\u0131n sa\u011flad\u0131\u011f\u0131 verilere ula\u015fmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, Theme.of(context)<\/code> veya MediaQuery.of(context)<\/code> gibi yayg\u0131n kullan\u0131mlar, BuildContext<\/code>‘in a\u011fa\u00e7taki konumu sayesinde ilgili verilere eri\u015fimi m\u00fcmk\u00fcn k\u0131lar. BuildContext<\/code>‘in \u00f6nemi, widget’lar\u0131n ba\u011f\u0131ms\u0131z birimler olsalar da, uygulaman\u0131n genel yap\u0131s\u0131 i\u00e7inde birbirleriyle ileti\u015fim kurmalar\u0131n\u0131 ve ortak verilere eri\u015fmelerini sa\u011flamas\u0131ndan gelir.<\/p>\nBir StatefulWidget<\/code> \u00f6rne\u011fi \u00fczerinden Element<\/code>‘\u0131n rol\u00fcn\u00fc daha net anlayabiliriz. Bir StatefulWidget<\/code>, asl\u0131nda iki par\u00e7adan olu\u015fur: StatefulWidget<\/code>‘\u0131n kendisi (de\u011fi\u015fmez yap\u0131land\u0131rma) ve ona ba\u011fl\u0131 olan State<\/code> nesnesi (de\u011fi\u015febilir durum). Flutter, bir StatefulWidget<\/code> i\u00e7in bir StatefulElement<\/code> olu\u015fturur. Bu StatefulElement<\/code>, widget’\u0131n \u00f6mr\u00fc boyunca State<\/code> nesnesini tutar. State<\/code> nesnesi i\u00e7inde setState()<\/code> metodu \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda, StatefulElement<\/code>, kendisini ve alt\u0131ndaki widget’lar\u0131 yeniden olu\u015fturmas\u0131 gerekti\u011fini i\u015faretler. Bu i\u015flem, Flutter’\u0131n build<\/code> metodunu tekrar \u00e7a\u011f\u0131rmas\u0131na ve UI’\u0131 g\u00fcncellemesine neden olur.<\/p>\n\u00d6rnek bir senaryo d\u00fc\u015f\u00fcnelim: Bir kullan\u0131c\u0131n\u0131n bir d\u00fc\u011fmeye t\u0131klayarak bir sayac\u0131n de\u011ferini art\u0131rd\u0131\u011f\u0131 basit bir uygulama. Bu durumda:<\/p>\n
\n- Kullan\u0131c\u0131 d\u00fc\u011fmeye t\u0131klar.<\/li>\n
- D\u00fc\u011fme widget’\u0131n\u0131n
onPressed<\/code> callback’i tetiklenir ve bu da saya\u00e7 widget’\u0131n\u0131n State<\/code> nesnesindeki setState()<\/code> metodunu \u00e7a\u011f\u0131r\u0131r.<\/li>\nsetState()<\/code> metodu, Flutter framework’\u00fcne saya\u00e7 widget’\u0131n\u0131n durumunun de\u011fi\u015fti\u011fini ve yeniden olu\u015fturulmas\u0131 gerekti\u011fini bildirir.<\/li>\n- Flutter, saya\u00e7 widget’\u0131n\u0131n ba\u011fl\u0131 oldu\u011fu
StatefulElement<\/code>‘\u0131 yeniden olu\u015fturulacak olarak i\u015faretler.<\/li>\n- Bir sonraki frame’de, Flutter bu
StatefulElement<\/code>‘\u0131n build<\/code> metodunu tekrar \u00e7a\u011f\u0131r\u0131r. Bu metod, yeni saya\u00e7 de\u011feriyle g\u00fcncellenmi\u015f bir Text<\/code> widget’\u0131 d\u00f6nd\u00fcr\u00fcr.<\/li>\n- Flutter, eski
Text<\/code> widget’\u0131 ile yeni Text<\/code> widget’\u0131n\u0131 kar\u015f\u0131la\u015ft\u0131r\u0131r. Sadece metin i\u00e7eri\u011fi de\u011fi\u015fti\u011fi i\u00e7in, mevcut TextElement<\/code>‘\u0131 yeniden kullan\u0131r ve sadece metin i\u00e7eri\u011fini g\u00fcnceller. Bu, t\u00fcm a\u011fac\u0131n yeniden \u00e7izilmesini engeller ve performans\u0131 art\u0131r\u0131r.<\/li>\n<\/ol>\nBu s\u00fcre\u00e7, Flutter’\u0131n deklaratif UI yakla\u015f\u0131m\u0131n\u0131n temelini olu\u015fturur. Widget’lar sadece birer blueprint (taslak) iken, Element<\/code>‘lar bu blueprint’leri hayata ge\u00e7iren ve a\u011fac\u0131n verimli bir \u015fekilde g\u00fcncellenmesini sa\u011flayan mekanizmalard\u0131r. Bu sayede Flutter, karma\u015f\u0131k ve dinamik kullan\u0131c\u0131 aray\u00fczlerini bile y\u00fcksek performansla ve ak\u0131c\u0131 bir \u015fekilde render edebilir.<\/p>\nRenderObject: Ekrandaki Piksel Dans\u0131 Nas\u0131l Ba\u015flar?<\/h2>\n
Widget’lar birer yap\u0131land\u0131rma, Element<\/code>‘lar ise bu yap\u0131land\u0131rmalar\u0131n canl\u0131 temsilcileriydi. Peki, bu soyut yap\u0131lar ekranda nas\u0131l ger\u00e7ek piksellere d\u00f6n\u00fc\u015f\u00fcyor? \u0130\u015fte bu noktada Flutter’\u0131n \u00fc\u00e7\u00fcnc\u00fc ana a\u011fac\u0131 olan RenderObject<\/code> a\u011fac\u0131 devreye giriyor. RenderObject<\/code>‘lar, Flutter’\u0131n d\u00fc\u015f\u00fck seviyeli boyama (painting) ve d\u00fczen (layout) sisteminin temelini olu\u015fturur. Bir widget’\u0131n g\u00f6rsel \u00f6zelliklerini (boyut, konum, renk, \u015fekil vb.) y\u00f6neten ve bunlar\u0131 ekrana \u00e7izmekten sorumlu olan nesnelerdir.<\/p>\nHer Element<\/code>, kendisine ba\u011fl\u0131 bir RenderObject<\/code>‘a sahiptir (baz\u0131 istisnalar d\u0131\u015f\u0131nda, \u00f6rne\u011fin StatelessElement<\/code> ve StatefulElement<\/code> do\u011frudan bir RenderObject<\/code>‘a sahip olmay\u0131p, alt\u0131ndaki Element<\/code>‘lar\u0131n RenderObject<\/code>‘lar\u0131n\u0131 kullan\u0131r). Bir RenderObject<\/code>‘\u0131n temel g\u00f6revleri \u015funlard\u0131r:<\/p>\n\n- D\u00fczen (Layout)<\/strong>: Bir
RenderObject<\/code>, kendisine ayr\u0131lan alan\u0131 ve alt\u0131ndaki RenderObject<\/code>‘lar\u0131n boyutlar\u0131n\u0131 ve konumlar\u0131n\u0131 belirlemekten sorumludur. Flutter’\u0131n constraint-based (k\u0131s\u0131tlamaya dayal\u0131) layout sistemi, her RenderObject<\/code>‘\u0131n parent’\u0131ndan ald\u0131\u011f\u0131 k\u0131s\u0131tlamalar (minimum ve maksimum geni\u015flik\/y\u00fckseklik) dahilinde kendi boyutunu belirlemesini ve \u00e7ocuklar\u0131na k\u0131s\u0131tlamalar iletmesini sa\u011flar. Bu tek ge\u00e7i\u015fli (single-pass) layout sistemi, son derece verimlidir.<\/li>\n- Boyama (Painting)<\/strong>: Bir
RenderObject<\/code>, kendi i\u00e7eri\u011fini ve alt\u0131ndaki RenderObject<\/code>‘lar\u0131n i\u00e7eri\u011fini ekrana \u00e7izmekten sorumludur. Bu \u00e7izim i\u015flemleri, Flutter’\u0131n grafik motoru Skia (Google Chrome ve Android’de de kullan\u0131lan y\u00fcksek performansl\u0131 2D grafik motoru) arac\u0131l\u0131\u011f\u0131yla do\u011frudan GPU’ya (grafik i\u015flem birimi) g\u00f6nderilir. Bu, Flutter’\u0131n yerel (native) uygulamalara yak\u0131n bir performans sunmas\u0131n\u0131n temel nedenlerinden biridir.<\/li>\n- Hit Test (Etkile\u015fim Tespiti)<\/strong>: Bir
RenderObject<\/code>, kullan\u0131c\u0131 etkile\u015fimlerinin (dokunma, t\u0131klama vb.) hangi g\u00f6rsel eleman \u00fczerinde ger\u00e7ekle\u015fti\u011fini tespit etmekten de sorumludur. Bu sayede, \u00f6rne\u011fin bir d\u00fc\u011fmeye t\u0131kland\u0131\u011f\u0131nda do\u011fru widget’\u0131n tetiklenmesi sa\u011flan\u0131r.<\/li>\n<\/ul>\nRenderObject<\/code> a\u011fac\u0131, widget a\u011fac\u0131n\u0131n g\u00f6rsel temsilidir ve ekran \u00fczerindeki her \u015feyin nas\u0131l g\u00f6r\u00fcnece\u011fini ve nerede duraca\u011f\u0131n\u0131 belirler. Widget’lar “ne \u00e7izilece\u011fini” s\u00f6ylerken, RenderObject<\/code>‘lar “nas\u0131l \u00e7izilece\u011fini” ve “nereye \u00e7izilece\u011fini” belirler. \u00d6rne\u011fin, bir Container<\/code> widget’\u0131, arka plan rengi, kenar bo\u015fluklar\u0131 (padding) ve kenarl\u0131k (border) gibi g\u00f6rsel \u00f6zelliklere sahiptir. Bu Container<\/code> widget’\u0131, arka planda bir RenderPadding<\/code>, RenderDecoratedBox<\/code> gibi birden fazla RenderObject<\/code>‘a d\u00f6n\u00fc\u015febilir. Bir Column<\/code> veya Row<\/code> widget’\u0131 ise, i\u00e7indeki elemanlar\u0131 dikey veya yatay olarak d\u00fczenleyen bir RenderFlex<\/code> nesnesine kar\u015f\u0131l\u0131k gelir.<\/p>\nVaka Analizi: Duyarl\u0131 Tasar\u0131m ve RenderObject’lar\u0131n Rol\u00fc<\/strong><\/p>\nModern uygulamalar, farkl\u0131 ekran boyutlar\u0131na ve y\u00f6nlendirmelerine (dikey\/yatay) uyum sa\u011flamak zorundad\u0131r. Flutter’da duyarl\u0131 (responsive) tasar\u0131m, b\u00fcy\u00fck \u00f6l\u00e7\u00fcde RenderObject<\/code>‘lar\u0131n layout yetenekleri sayesinde m\u00fcmk\u00fcn olur. \u00d6rne\u011fin, bir uygulamada geni\u015f ekranda iki s\u00fctunlu, dar ekranda tek s\u00fctunlu bir d\u00fczenleme yapmak istedi\u011finizi varsayal\u0131m. Bunu LayoutBuilder<\/code> widget’\u0131n\u0131 kullanarak yapabiliriz:<\/p>\n\nimport 'package:flutter\/material.dart';\n\nclass ResponsiveLayout extends StatelessWidget {\n @override\n Widget build(BuildContext context) {\n return Scaffold(\n appBar: AppBar(\n title: const Text('Duyarl\u0131 Tasar\u0131m \u00d6rne\u011fi'),\n ),\n body: LayoutBuilder(\n builder: (BuildContext context, BoxConstraints constraints) {\n if (constraints.maxWidth > 600) {\n \/\/ Geni\u015f ekran d\u00fczeni (iki s\u00fctun)\n return Row(\n children: [\n Expanded(\n child: Container(\n color: Colors.blueAccent,\n child: const Center(child: Text('Sol Panel', style: TextStyle(color: Colors.white, fontSize: 20))),\n ),\n ),\n Expanded(\n child: Container(\n color: Colors.greenAccent,\n child: const Center(child: Text('Sa\u011f Panel', style: TextStyle(color: Colors.white, fontSize: 20))),\n ),\n ),\n ],\n );\n } else {\n \/\/ Dar ekran d\u00fczeni (tek s\u00fctun)\n return Column(\n children: [\n Expanded(\n child: Container(\n color: Colors.blueAccent,\n child: const Center(child: Text('\u00dcst Panel', style: TextStyle(color: Colors.white, fontSize: 20))),\n ),\n ),\n Expanded(\n child: Container(\n color: Colors.greenAccent,\n child: const Center(child: Text('Alt Panel', style: TextStyle(color: Colors.white, fontSize: 20))),\n ),\n ),\n ],\n );\n }\n },\n ),\n );\n }\n}<\/code><\/pre>\n<\/div>\nYukar\u0131daki \u00f6rnekte, LayoutBuilder<\/code>, kendisine gelen BoxConstraints<\/code> (k\u0131s\u0131tlamalar) nesnesini kullanarak mevcut widget’\u0131n maksimum geni\u015fli\u011fini (constraints.maxWidth<\/code>) \u00f6\u011frenir. Bu bilgiye dayanarak, geni\u015f ekranda bir Row<\/code> (sat\u0131r) widget’\u0131 d\u00f6nd\u00fcr\u00fcrken, dar ekranda bir Column<\/code> (s\u00fctun) widget’\u0131 d\u00f6nd\u00fcr\u00fcr. Arka planda, bu Row<\/code> ve Column<\/code> widget’lar\u0131, ilgili RenderFlex<\/code> (veya benzeri) RenderObject<\/code>‘lar\u0131na d\u00f6n\u00fc\u015f\u00fcr. Bu RenderObject<\/code>‘lar, parent’lar\u0131ndan ald\u0131klar\u0131 k\u0131s\u0131tlamalar do\u011frultusunda kendi boyutlar\u0131n\u0131 ve \u00e7ocuklar\u0131n\u0131n boyutlar\u0131n\u0131 hesaplar, b\u00f6ylece UI otomatik olarak farkl\u0131 ekran boyutlar\u0131na uyum sa\u011flar. Bu, RenderObject<\/code>‘lar\u0131n layout yeteneklerinin ne kadar g\u00fc\u00e7l\u00fc ve esnek oldu\u011funun bir g\u00f6stergesidir.<\/p>\nFlutter’\u0131n RenderObject<\/code> katman\u0131, uygulamalar\u0131n sadece h\u0131zl\u0131 de\u011fil, ayn\u0131 zamanda g\u00f6rsel olarak da do\u011fru ve tutarl\u0131 olmas\u0131n\u0131 sa\u011flar. Widget’lar ve Element<\/code>‘lar soyutlamay\u0131 sa\u011flarken, RenderObject<\/code>‘lar bu soyutlamalar\u0131 somutla\u015ft\u0131rarak ekrandaki her pikselin do\u011fru bir \u015fekilde yerle\u015ftirilmesini ve boyanmas\u0131n\u0131 temin eder. Bu \u00fc\u00e7l\u00fc yap\u0131 \u2013 Widget, Element, RenderObject \u2013 Flutter’\u0131n e\u015fsiz performans ve esneklik mimarisinin temelini olu\u015fturur.<\/p>\nBuild Metodu ve Widget A\u011fac\u0131n\u0131n G\u00fcncellenmesi: Yeniden Olu\u015fturma Sanat\u0131<\/h2>\n
Flutter’\u0131n deklaratif (bildirimsel) kullan\u0131c\u0131 aray\u00fcz\u00fc (UI) yakla\u015f\u0131m\u0131n\u0131n merkezinde build<\/code> metodu bulunur. Her StatelessWidget<\/code> ve StatefulWidget<\/code>, bir build<\/code> metodu tan\u0131mlar. Bu metodun temel g\u00f6revi, mevcut duruma (state) ve BuildContext<\/code>‘e g\u00f6re bir widget a\u011fac\u0131 d\u00f6nd\u00fcrmektir. Ancak bu metodun ne zaman ve neden \u00e7a\u011fr\u0131ld\u0131\u011f\u0131, Flutter’\u0131n performans optimizasyonlar\u0131n\u0131 anlamak i\u00e7in kritik \u00f6neme sahiptir.<\/p>\nBir widget’\u0131n build<\/code> metodu, a\u015fa\u011f\u0131daki durumlarda \u00e7a\u011fr\u0131labilir:<\/p>\n\n- Widget ilk kez olu\u015fturuldu\u011funda.<\/li>\n
- Bir
StatefulWidget<\/code>‘\u0131n State<\/code> nesnesindeki setState()<\/code> metodu \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda.<\/li>\n- Widget’\u0131n ba\u011f\u0131ml\u0131 oldu\u011fu bir
InheritedWidget<\/code> g\u00fcncellendi\u011finde.<\/li>\n- Widget’\u0131n parent’\u0131 yeniden olu\u015fturuldu\u011funda (ve parent, child’\u0131n\u0131 yeni bir widget ile yeniden yap\u0131land\u0131rd\u0131\u011f\u0131nda).<\/li>\n
- Sistem ayarlar\u0131 de\u011fi\u015fti\u011finde (\u00f6rne\u011fin, cihaz\u0131n temas\u0131 de\u011fi\u015fti\u011finde veya dil ayar\u0131 g\u00fcncellendi\u011finde).<\/li>\n<\/ul>\n
En s\u0131k kar\u015f\u0131la\u015f\u0131lan senaryo, bir StatefulWidget<\/code>‘\u0131n durumunun de\u011fi\u015fmesi ve setState()<\/code>‘in \u00e7a\u011fr\u0131lmas\u0131d\u0131r. setState()<\/code> \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda, Flutter framework’\u00fcne widget’\u0131n durumunun de\u011fi\u015fti\u011fi ve UI’\u0131n g\u00fcncellenmesi gerekti\u011fi bildirilir. Ancak bu, t\u00fcm uygulaman\u0131n ba\u015ftan a\u015fa\u011f\u0131 yeniden \u00e7izildi\u011fi anlam\u0131na gelmez. Flutter, son derece verimli bir “diffing” (fark bulma) algoritmas\u0131 kullan\u0131r.<\/p>\nBu algoritma, yeni d\u00f6nd\u00fcr\u00fclen widget a\u011fac\u0131n\u0131 mevcut Element<\/code> a\u011fac\u0131yla kar\u015f\u0131la\u015ft\u0131r\u0131r. Kar\u015f\u0131la\u015ft\u0131rma s\u00fcreci \u015fu ad\u0131mlar\u0131 izler:<\/p>\n\n- T\u00fcr Kar\u015f\u0131la\u015ft\u0131rmas\u0131<\/strong>: E\u011fer yeni widget’\u0131n t\u00fcr\u00fc (runtimeType) eski widget’\u0131n t\u00fcr\u00fcyle ayn\u0131ysa, Flutter daha ileri bir kar\u015f\u0131la\u015ft\u0131rma yapar. E\u011fer t\u00fcrler farkl\u0131ysa, mevcut
Element<\/code> ve ona ba\u011fl\u0131 RenderObject<\/code> tamamen kald\u0131r\u0131l\u0131r ve yenisi olu\u015fturulur.<\/li>\n- Anahtar (Key) Kar\u015f\u0131la\u015ft\u0131rmas\u0131<\/strong>: E\u011fer widget’lar bir anahtara sahipse (
Key<\/code>), Flutter ayn\u0131 t\u00fcrdeki widget’lar\u0131n ayn\u0131 anahtara sahip olup olmad\u0131\u011f\u0131n\u0131 kontrol eder. Anahtarlar, \u00f6zellikle dinamik listelerde (ListView.builder<\/code> gibi) elemanlar\u0131n kimli\u011fini korumak i\u00e7in hayati \u00f6neme sahiptir. Anahtarlar sayesinde Flutter, elemanlar\u0131n s\u0131ras\u0131 de\u011fi\u015fse bile do\u011fru Element<\/code>‘lar\u0131 yeniden kullanabilir.<\/li>\n- Yeniden Yap\u0131land\u0131rma<\/strong>: E\u011fer t\u00fcr ve anahtar e\u015fle\u015fiyorsa, Flutter mevcut
Element<\/code>‘\u0131 yeniden kullan\u0131r ve yeni widget’\u0131n \u00f6zellikleriyle (props) g\u00fcnceller. Bu, en verimli senaryodur \u00e7\u00fcnk\u00fc yeni bir Element<\/code> veya RenderObject<\/code> olu\u015fturulmas\u0131na gerek kalmaz, sadece mevcut olan\u0131n yap\u0131land\u0131rmas\u0131 g\u00fcncellenir.<\/li>\n<\/ol>\nBu ak\u0131ll\u0131 kar\u015f\u0131la\u015ft\u0131rma mekanizmas\u0131, Flutter’\u0131n sadece de\u011fi\u015fen k\u0131s\u0131mlar\u0131 g\u00fcncellemesini sa\u011flar, bu da uygulaman\u0131n performans\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Geli\u015ftiriciler olarak, build<\/code> metodunun her \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda hafif ve h\u0131zl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak i\u00e7in dikkatli olmal\u0131y\u0131z. A\u011f\u0131r hesaplamalar veya karma\u015f\u0131k mant\u0131k, build<\/code> metodu d\u0131\u015f\u0131nda yap\u0131lmal\u0131d\u0131r.<\/p>\nPerformans \u0130pu\u00e7lar\u0131:<\/strong><\/p>\n\nconst<\/code> (sabit) Widget’lar Kullan\u0131n<\/strong>: E\u011fer bir widget’\u0131n \u00f6zellikleri hi\u00e7bir zaman de\u011fi\u015fmeyecekse, onu const<\/code> olarak tan\u0131mlay\u0131n. Flutter, const<\/code> widget’lar\u0131n sadece bir kez olu\u015fturulmas\u0131n\u0131 ve her build<\/code> \u00e7a\u011fr\u0131s\u0131nda yeniden kullan\u0131lmas\u0131n\u0131 garanti eder. Bu, performans i\u00e7in \u00e7ok b\u00fcy\u00fck bir kazan\u00e7t\u0131r.<\/li>\n- K\u00fc\u00e7\u00fck Widget’lara B\u00f6l\u00fcn<\/strong>: B\u00fcy\u00fck ve karma\u015f\u0131k widget’lar\u0131 daha k\u00fc\u00e7\u00fck, y\u00f6netilebilir par\u00e7alara ay\u0131r\u0131n. Bu sayede, sadece ilgili widget’\u0131n
build<\/code> metodu \u00e7a\u011fr\u0131l\u0131r ve t\u00fcm b\u00fcy\u00fck widget’\u0131n yeniden \u00e7izilmesi engellenir.<\/li>\nRepaintBoundary<\/code> Kullan\u0131m\u0131<\/strong>: Animasyonlar veya s\u0131k g\u00fcncellenen b\u00f6lgeler i\u00e7in RepaintBoundary<\/code> widget’\u0131n\u0131 kullanmak, Flutter’a bu b\u00f6lgenin ba\u011f\u0131ms\u0131z olarak yeniden boyanabilece\u011fini bildirir. Bu, di\u011fer b\u00f6lgelerin etkilenmeden kalmas\u0131n\u0131 sa\u011flayarak boyama performans\u0131n\u0131 art\u0131r\u0131r.<\/li>\n<\/ul>\n\u00d6rnek: Dinamik Bir Liste ve Performans Optimizasyonu<\/strong><\/p>\nBir al\u0131\u015fveri\u015f uygulamas\u0131ndaki \u00fcr\u00fcn listesini d\u00fc\u015f\u00fcnelim. Binlerce \u00fcr\u00fcn olabilir ve kullan\u0131c\u0131 listeyi kayd\u0131rd\u0131k\u00e7a yeni \u00fcr\u00fcnler y\u00fcklenmelidir. Bu senaryoda ListView.builder<\/code> kullan\u0131m\u0131 hayati \u00f6neme sahiptir:<\/p>\n\nimport 'package:flutter\/material.dart';\n\nclass ProductListScreen extends StatefulWidget {\n const ProductListScreen({super.key});\n\n @override\n State createState() => _ProductListScreenState();\n}\n\nclass _ProductListScreenState extends State {\n final List _products = List.generate(1000, (index) => '\u00dcr\u00fcn ${index + 1}');\n\n @override\n Widget build(BuildContext context) {\n return Scaffold(\n appBar: AppBar(\n title: const Text('\u00dcr\u00fcn Listesi'),\n ),\n body: ListView.builder(\n itemCount: _products.length,\n itemBuilder: (context, index) {\n \/\/ Her bir liste \u00f6\u011fesi i\u00e7in benzersiz bir anahtar kullanmak \u00f6nemlidir\n return ProductItem(productName: _products[index], key: ValueKey(_products[index]));\n },\n ),\n );\n }\n}\n\nclass ProductItem extends StatelessWidget {\n final String productName;\n\n const ProductItem({required this.productName, super.key});\n\n @override\n Widget build(BuildContext context) {\n return Card(\n margin: const EdgeInsets.symmetric(vertical: 8, horizontal: 16),\n child: Padding(\n padding: const EdgeInsets.all(16.0),\n child: Text(\n productName,\n style: const TextStyle(fontSize: 18),\n ),\n ),\n );\n }\n}<\/code><\/pre>\n<\/div>\nYukar\u0131daki \u00f6rnekte, ListView.builder<\/code> sadece ekranda g\u00f6r\u00fcnen ve yak\u0131n zamanda g\u00f6r\u00fclebilecek olan \u00f6\u011feleri olu\u015fturur. Bu, “lazy loading” (tembel y\u00fckleme) olarak bilinir. Her bir ProductItem<\/code> i\u00e7in ValueKey<\/code> kullan\u0131lmas\u0131, listenin elemanlar\u0131 yeniden s\u0131raland\u0131\u011f\u0131nda veya g\u00fcncellendi\u011finde Flutter’\u0131n do\u011fru Element<\/code>‘lar\u0131 yeniden kullanmas\u0131n\u0131 sa\u011flar. Bu sayede, binlerce \u00f6\u011fe i\u00e7eren bir liste bile ak\u0131c\u0131 bir \u015fekilde kayd\u0131r\u0131labilir. build<\/code> metodunun bu ak\u0131ll\u0131ca kullan\u0131m\u0131 ve Flutter’\u0131n arkas\u0131ndaki diffing algoritmalar\u0131, uygulaman\u0131n s\u00fcrekli olarak g\u00fcncel ve performansl\u0131 kalmas\u0131n\u0131 garantiler.<\/p>\nKaynak Koduna Derinlemesine Bak\u0131\u015f: Flutter Motoru Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h2>\n
Flutter’\u0131n sundu\u011fu ak\u0131c\u0131 deneyimin ve y\u00fcksek performans\u0131n ard\u0131nda, Dart programlama dili, Skia grafik motoru ve C++ ile yaz\u0131lm\u0131\u015f g\u00fc\u00e7l\u00fc bir Flutter motoru (engine) bulunur. Widget’lardan Element<\/code>‘lara ve RenderObject<\/code>‘lara kadar olan yolculuk, asl\u0131nda bu motorun nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamam\u0131z i\u00e7in bir \u00f6n haz\u0131rl\u0131kt\u0131. \u015eimdi, Flutter’\u0131n en alt katmanlar\u0131na, yani kaynak koduna inerek, uygulaman\u0131z\u0131n ekran\u0131n\u0131zda nas\u0131l canland\u0131\u011f\u0131n\u0131 daha detayl\u0131 inceleyelim.<\/p>\nFlutter motoru, uygulaman\u0131z\u0131n Dart kodunu \u00e7al\u0131\u015ft\u0131rmaktan, kullan\u0131c\u0131 aray\u00fcz\u00fcn\u00fc (UI) olu\u015fturmaktan, platforma \u00f6zg\u00fc servislerle (kamera, konum, bildirimler vb.) ileti\u015fim kurmaktan ve ekran\u0131 boyamaktan sorumludur. Bu motor, temelde \u00fc\u00e7 ana bile\u015fenden olu\u015fur:<\/p>\n
\n- Dart VM (Sanal Makine)<\/strong>: Flutter uygulamalar\u0131 Dart dilinde yaz\u0131l\u0131r. Dart, hem JIT (Just-in-Time) hem de AOT (Ahead-of-Time) derleme yeteneklerine sahip bir dildir. Geli\u015ftirme a\u015famas\u0131nda, Dart kodu genellikle JIT derleme ile \u00e7al\u0131\u015f\u0131r. Bu, Flutter’\u0131n me\u015fhur “hot reload” (an\u0131nda yeniden y\u00fckleme) \u00f6zelli\u011fini m\u00fcmk\u00fcn k\u0131lar. JIT derleme sayesinde, kodda yap\u0131lan k\u00fc\u00e7\u00fck de\u011fi\u015fiklikler an\u0131nda uygulamaya yans\u0131t\u0131l\u0131r, bu da geli\u015ftirme s\u00fcrecini inan\u0131lmaz derecede h\u0131zland\u0131r\u0131r. \u00dcretim (production) i\u00e7in uygulama derlendi\u011finde ise Dart kodu, AOT derleme ile do\u011frudan platformun yerel (native) makine koduna d\u00f6n\u00fc\u015ft\u00fcr\u00fcl\u00fcr. Bu AOT derleme, uygulamalar\u0131n \u00e7ok daha h\u0131zl\u0131 ba\u015flamas\u0131n\u0131 ve y\u00fcksek performansla \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar, \u00e7\u00fcnk\u00fc \u00e7al\u0131\u015fma zaman\u0131nda (runtime) derleme maliyeti olmaz.<\/li>\n
- Skia Grafik Motoru<\/strong>: Flutter, UI’\u0131 do\u011frudan kendi b\u00fcnyesindeki Skia grafik motorunu kullanarak \u00e7izer. Skia, Google taraf\u0131ndan geli\u015ftirilen y\u00fcksek performansl\u0131, a\u00e7\u0131k kaynakl\u0131 bir 2D grafik k\u00fct\u00fcphanesidir. Android, Google Chrome, Chrome OS gibi bir\u00e7ok Google \u00fcr\u00fcn\u00fcnde kullan\u0131l\u0131r. Flutter, Skia sayesinde UI’\u0131 do\u011frudan GPU’ya (grafik i\u015flem birimi) g\u00f6ndererek boyama yapar. Bu, platformun kendi UI bile\u015fenlerini kullanmak yerine, Flutter’\u0131n kendi bile\u015fenlerini s\u0131f\u0131rdan \u00e7izdi\u011fi anlam\u0131na gelir. Bu yakla\u015f\u0131m, platformlar aras\u0131nda g\u00f6rsel tutarl\u0131l\u0131\u011f\u0131 garanti eder ve UI performans\u0131n\u0131 art\u0131r\u0131r, \u00e7\u00fcnk\u00fc aradaki k\u00f6pr\u00fc katmanlar\u0131n\u0131n getirdi\u011fi performans d\u00fc\u015f\u00fc\u015flerinden etkilenmez.<\/li>\n
- C++ Katman\u0131<\/strong>: Dart VM ve Skia, Flutter motorunun C++ ile yaz\u0131lm\u0131\u015f ana katman\u0131nda bir araya gelir. Bu katman, i\u015fletim sistemiyle ileti\u015fim kurmaktan, giri\u015f olaylar\u0131n\u0131 (input events) y\u00f6netmekten (dokunma, klavye vb.), platform kanallar\u0131n\u0131 (Platform Channels) sa\u011flamaktan ve di\u011fer d\u00fc\u015f\u00fck seviyeli sistem servislerine eri\u015fimden sorumludur. \u00d6rne\u011fin, bir cihaz\u0131n kameras\u0131n\u0131 kullanmak veya GPS konumuna eri\u015fmek istedi\u011finizde, Dart kodunuz platform kanallar\u0131 arac\u0131l\u0131\u011f\u0131yla bu C++ katman\u0131na bir mesaj g\u00f6nderir. C++ katman\u0131 bu mesaj\u0131 al\u0131r, ilgili yerel (native) API’yi \u00e7a\u011f\u0131r\u0131r ve sonucu Dart taraf\u0131na geri iletir.<\/li>\n<\/ol>\n
Hot Reload’un Arka Plan\u0131<\/strong><\/p>\nFlutter’\u0131n geli\u015ftiriciler aras\u0131nda bu kadar pop\u00fcler olmas\u0131n\u0131n nedenlerinden biri olan hot reload, asl\u0131nda Dart’\u0131n JIT derleme yetene\u011fi ve Flutter motorunun ak\u0131ll\u0131 \u00e7al\u0131\u015fma \u015fekli sayesinde m\u00fcmk\u00fcn olur. Kodda bir de\u011fi\u015fiklik yapt\u0131\u011f\u0131n\u0131zda, JIT derleyici sadece de\u011fi\u015fen kodu derler ve bu kodu \u00e7al\u0131\u015fan Dart VM’ye enjekte eder. Flutter motoru, enjekte edilen yeni kodu fark eder ve sadece etkilenen widget’lar\u0131 (veya a\u011fac\u0131n ilgili b\u00f6l\u00fcm\u00fcn\u00fc) yeniden olu\u015fturur, uygulaman\u0131n durumunu (state) korur. Bu sayede, uygulaman\u0131n ba\u015ftan ba\u015flamas\u0131na gerek kalmadan de\u011fi\u015fiklikleri an\u0131nda g\u00f6rebilirsiniz.<\/p>\n
Vaka Analizi: Performans Kritik Bir Uygulaman\u0131n Kaynak Kod Seviyesinde Optimizasyonu<\/strong><\/p>\nDiyelim ki, y\u00fcksek \u00e7\u00f6z\u00fcn\u00fcrl\u00fckl\u00fc video d\u00fczenleme veya ger\u00e7ek zamanl\u0131 oyun gibi performans kritik bir Flutter uygulamas\u0131 geli\u015ftiriyorsunuz. Bu t\u00fcr senaryolarda, Flutter’\u0131n varsay\u0131lan mekanizmalar\u0131 bazen yeterli olmayabilir ve daha derinlemesine optimizasyonlar gerekebilir. \u0130\u015fte burada kaynak kod seviyesinde anlama devreye girer:<\/p>\n
\n- Isolates Kullan\u0131m\u0131<\/strong>: Dart, e\u015fzamanl\u0131l\u0131\u011f\u0131 (concurrency) sa\u011flamak i\u00e7in “isolates” ad\u0131 verilen ba\u011f\u0131ms\u0131z bellek alanlar\u0131na sahip \u00e7al\u0131\u015fanlar kullan\u0131r. A\u011f\u0131r hesaplamalar (\u00f6rne\u011fin, b\u00fcy\u00fck bir JSON dosyas\u0131n\u0131 ayr\u0131\u015ft\u0131rma veya karma\u015f\u0131k bir g\u00f6r\u00fcnt\u00fc i\u015fleme algoritmas\u0131 \u00e7al\u0131\u015ft\u0131rma) ana UI thread’ini (i\u015f par\u00e7ac\u0131\u011f\u0131) bloke edebilir ve uygulaman\u0131n donmas\u0131na neden olabilir. Bu t\u00fcr i\u015flemleri ayr\u0131 bir isolate’te \u00e7al\u0131\u015ft\u0131rmak, UI’\u0131n ak\u0131c\u0131 kalmas\u0131n\u0131 sa\u011flar.<\/li>\n
- Custom RenderObject Olu\u015fturma<\/strong>: \u00c7ok \u00f6zel ve y\u00fcksek performans gerektiren \u00e7izim ihtiya\u00e7lar\u0131n\u0131z varsa (\u00f6rne\u011fin, \u00f6zel bir grafik \u00e7izelgesi veya karma\u015f\u0131k bir animasyon), Flutter’\u0131n mevcut widget’lar\u0131 yerine kendi
RenderObject<\/code>‘unuzu olu\u015fturmay\u0131 d\u00fc\u015f\u00fcnebilirsiniz. Bu, Skia’ya do\u011frudan eri\u015fim sa\u011flayarak \u00e7izim \u00fczerinde tam kontrol sahibi olman\u0131z\u0131 ve performans\u0131 en \u00fcst d\u00fczeye \u00e7\u0131karman\u0131z\u0131 sa\u011flar. Ancak bu, olduk\u00e7a ileri d\u00fczey bir konudur ve dikkatli bir \u015fekilde yap\u0131lmal\u0131d\u0131r.<\/li>\n- Platform Kanallar\u0131n\u0131n Verimli Kullan\u0131m\u0131<\/strong>: E\u011fer yerel (native) platform API’lerini s\u0131k\u00e7a kullanman\u0131z gerekiyorsa, platform kanallar\u0131n\u0131n verimli bir \u015fekilde tasarland\u0131\u011f\u0131ndan emin olun. B\u00fcy\u00fck veri transferleri veya s\u0131k\u00e7a yap\u0131lan \u00e7a\u011fr\u0131lar performans darbo\u011fazlar\u0131na neden olabilir. Verileri s\u0131k\u0131\u015ft\u0131rmak, toplu \u00e7a\u011fr\u0131lar yapmak veya gerekirse yerel tarafta daha fazla i\u015flem yapmak gibi stratejiler izlenebilir.<\/li>\n<\/ol>\n
Flutter motorunun nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak, sadece daha iyi uygulamalar yazmakla kalmaz, ayn\u0131 zamanda kar\u015f\u0131la\u015f\u0131lan performans sorunlar\u0131n\u0131 te\u015fhis etme ve \u00e7\u00f6zme yetene\u011finizi de art\u0131r\u0131r. Widget’tan en alt katmandaki Skia ve C++’a kadar uzanan bu yolculuk, Flutter’\u0131n neden mobil geli\u015ftirme d\u00fcnyas\u0131nda bu kadar g\u00fc\u00e7l\u00fc bir oyuncu oldu\u011funu a\u00e7\u0131k\u00e7a ortaya koymaktad\u0131r.<\/p>\n
\u0130leri Seviye Kavramlar ve Optimizasyon Stratejileri<\/h2>\n
Flutter’\u0131n temel katmanlar\u0131n\u0131 anlad\u0131ktan sonra, uygulamalar\u0131n\u0131z\u0131 daha g\u00fc\u00e7l\u00fc, daha \u00f6l\u00e7eklenebilir ve daha performansl\u0131 hale getirmek i\u00e7in kullanabilece\u011finiz baz\u0131 ileri seviye kavramlara ve optimizasyon stratejilerine g\u00f6z atal\u0131m.<\/p>\n
InheritedWidget ve Ba\u011f\u0131ml\u0131l\u0131k Enjeksiyonu Nas\u0131l Kullan\u0131l\u0131r?<\/h3>\n
B\u00fcy\u00fck ve karma\u015f\u0131k uygulamalarda, verileri widget a\u011fac\u0131n\u0131n derinliklerine iletmek (prop drilling) bir sorun haline gelebilir. Her parent widget’\u0131n, sadece child’\u0131na iletece\u011fi verileri bilmesi ve bu verileri kendi alt a\u011fac\u0131na aktarmas\u0131, kodun okunabilirli\u011fini ve s\u00fcrd\u00fcr\u00fclebilirli\u011fini azalt\u0131r. \u0130\u015fte bu noktada InheritedWidget<\/code> devreye girer. InheritedWidget<\/code>, a\u011fac\u0131n belirli bir noktas\u0131nda veri sa\u011flayarak, alt\u0131ndaki t\u00fcm widget’lar\u0131n bu verilere do\u011frudan BuildContext<\/code> arac\u0131l\u0131\u011f\u0131yla eri\u015fmesini sa\u011flar.<\/p>\nInheritedWidget<\/code>, bir t\u00fcr ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu (dependency injection) mekanizmas\u0131 sunar. \u00d6rne\u011fin, bir uygulaman\u0131n tema verilerini (renkler, yaz\u0131 tipleri vb.) veya kullan\u0131c\u0131 oturum bilgilerini t\u00fcm alt widget’lara sa\u011flamak i\u00e7in kullan\u0131labilir. InheritedWidget<\/code>‘\u0131 kullanarak bir veri sa\u011flad\u0131\u011f\u0131n\u0131zda, bu verilere ba\u011f\u0131ml\u0131 olan alt widget’lar, context.dependOnInheritedWidgetOfExactType