Animasyon yumuşaklığı metriğine doğru

Animasyonları ölçme, animasyon kareleri ve genel sayfa düzgünlüğü hakkında bilgi edinin.

Kaydırma veya animasyonlar sırasında "takılan" veya "donan" sayfalarla karşılaşmış olabilirsiniz. Bu deneyimlerin sorunsuz olduğunu belirtmek isteriz. Bu tür sorunları çözmek için Chrome ekibi, Chromium'daki oluşturma ardışık düzeni teşhisini sürekli olarak iyileştirmenin yanı sıra animasyon algılamayla ilgili laboratuvar araçlarımıza daha fazla destek eklemek için çalışmaktadır.

Son zamanlarda kaydedilen bazı ilerlemeleri paylaşmak, somut araçlar sunmak ve gelecekteki animasyon düzgünlüğü metrikleriyle ilgili fikirleri tartışmak istiyoruz. Her zaman olduğu gibi, geri bildirimlerinizi bizimle paylaşmanızdan memnuniyet duyarız.

Bu yayında üç ana konu ele alınacaktır:

• Animasyonlara ve animasyon karelerine hızlı bir bakış.
• Genel animasyonun düzgün çalışmasının ölçümüyle ilgili mevcut düşüncelerimiz.
• Laboratuvar araçlarında yararlanabileceğiniz pratik öneriler.

Animasyon nedir?

Animasyonlar sayesinde içeriklere hayat vermiş olursunuz. Animasyonlar, özellikle kullanıcı etkileşimlerine yanıt olarak içeriği hareket ettirerek deneyimin daha doğal, anlaşılır ve eğlenceli görünmesini sağlayabilir.

Ancak kötü uygulanmış animasyonlar veya sadece çok fazla animasyon eklemek, deneyimin kalitesini düşürebilir ve kesinlikle hiç eğlenceli olmamalarına neden olabilir. Muhtemelen hepimiz çok fazla "yararlı" geçiş efekti ekleyen bir arayüzle etkileşimde bulunmuşuzdur. Bu efektler, düşük performans seçeneklerini deneyimlemeye zararlı hale gelir. Bu nedenle bazı kullanıcılar, dikkate almanız gereken bir kullanıcı tercihi olan azaltmayı tercih edebilir.

Animasyonlar nasıl çalışır?

Özetle, oluşturma ardışık düzeni birkaç sıralı aşamadan oluşur:

1. Stil: Öğelere uygulanan stilleri hesaplar.
2. Düzen: Her bir öğe için geometriyi ve konumu oluşturun.
3. Boya: Her öğenin piksellerini katmanlara yerleştirin.
4. Bileşik: Katmanları ekrana çizin.

Animasyonları tanımlamanın birçok yolu olsa da tümü temelde aşağıdakilerden biri aracılığıyla çalışır:

• Düzen özelliklerini ayarlama.
• paint özelliklerini ayarlama.
• Bileşik özellikleri ayarlama.

Bu aşamalar sıralı olduğundan animasyonları, ardışık düzende daha aşağılarda bulunan özellikler açısından tanımlamak önemlidir. Güncelleme, süreçte ne kadar erken gerçekleşirse maliyetler o kadar fazla olur ve sorunsuz olma olasılığı düşer. (Daha fazla ayrıntı için Oluşturma performansı bölümüne bakın.)

Düzen özelliklerini canlandırmak kolay olsa da, bu maliyetler hemen görünmese bile bunu yapmanın bazı maliyetleri vardır. Animasyonlar, mümkün olduğunda birleşik özellik değişiklikleri açısından tanımlanmalıdır.

Bildirim temelli CSS animasyonları tanımlamak veya Web Animasyonları kullanmak ve birleşik özellikleri canlandırdığınızdan emin olmak, düzgün ve verimli animasyonlar sağlamak için harika bir ilk adımdır. Ancak yine de etkili web animasyonlarının bile performans sınırları olduğundan tek başına bu düzgün çalışma garantisi vermez. Bu nedenle ölçüm yapmak her zaman önemlidir.

Animasyon kareleri nedir?

Bir sayfanın görsel temsilinde yapılan güncellemelerin görünmesi zaman alır. Görsel bir değişiklik, sonunda kullanıcının ekranında oluşturulacak yeni bir animasyon çerçevesine yol açar.

Görüntüler belirli aralıklarla güncellendiğinden görsel güncellemeler toplu olarak işlenir. Birçok ekran, saniyede 60 kez (yani 60 Hz) gibi sabit bir zaman aralığında güncelleme yapar. Daha modern bazı ekranlar daha yüksek yenileme hızları sunabilir (90-120 Hz giderek yaygınlaşıyor). Bu ekranlar, genellikle gerektiğinde yenileme hızları arasında aktif bir şekilde uyum sağlayabilir ve hatta tamamen değişken kare hızları sunabilir.

Oyun veya tarayıcı gibi tüm uygulamaların hedefi, tüm bu toplu görsel güncellemeleri işlemek ve verilen süre içinde, her seferinde görsel olarak eksiksiz bir animasyon karesi oluşturmaktır. Bu hedefin, ağdan hızlı bir şekilde içerik yükleme veya JavaScript görevlerini verimli bir şekilde yürütme gibi diğer önemli tarayıcı görevlerinden tamamen ayrı olduğunu unutmayın.

Bir noktada, tüm görsel güncellemeleri ekran tarafından belirlenen son tarih içinde tamamlamak çok zor hale gelebilir. Böyle bir durumda tarayıcı bir kare bırakır. Ekranınız kararmaz, yalnızca kendini tekrar eder. Aynı görsel güncellemeyi bir süre daha görürsünüz. Bu, önceki kare fırsatında sunulan animasyon karesinin aynısıdır.

Bu durum aslında çok sık olur. Özellikle web platformunda yaygın olarak görülen statik veya belge benzeri içerik başta olmak üzere, algılanması bile mümkün değildir. Atlanan kareler, yalnızca animasyonlar gibi önemli görsel güncellemeler olduğunda belirgindir. Bu güncellemelerde, yumuşak hareketi göstermek için animasyon güncellemelerinin düzenli bir şekilde yayınlanması gerekir.

Animasyon karelerini neler etkiler?

Web geliştiricileri, bir tarayıcının görsel güncellemeleri hızlı ve verimli bir şekilde oluşturma ve sunma becerisini önemli ölçüde etkileyebilir.

Bazı örnekler:

• Hedef cihazda kodu hızlı bir şekilde çözmek için çok büyük veya kaynak yoğun içerik kullanmak.
• Çok fazla GPU belleği gerektiren çok fazla katman kullanılması.
• Fazlasıyla karmaşık CSS stilleri veya web animasyonları tanımlama.
• Hızlı oluşturma optimizasyonlarını devre dışı bırakan tasarım karşıt kalıplarını kullanma
• Ana iş parçacığında çok fazla JS çalışır, bu da görsel güncellemeleri engelleyen uzun görevlere yol açar.

Peki bir animasyon karesi son tarihini kaçırdığında ve karenin düşmesine neden olduğunda bunu nasıl anlayabilirsiniz?

requestAnimationFrame() anketleri kullanabilirsiniz ancak bu yöntemin bazı dezavantajları vardır. requestAnimationFrame() veya "rAF", tarayıcıya bir animasyon gerçekleştirmek istediğinizi bildirir ve oluşturma ardışık düzeninin bir sonraki boyama aşamasından önce bunu yapma fırsatı ister. Geri çağırma işleviniz beklediğiniz zamanda çağrılmazsa bu, bir boyamanın yürütülmediği ve bir veya daha fazla karenin atlandığı anlamına gelir. Yoklama yaparak ve rAF'nin ne sıklıkta çağrıldığını sayarak bir tür "saniyedeki kare sayısı" (FPS) metriği hesaplayabilirsiniz.

let frameTimes = [];
function pollFramesPerSecond(now) {
  frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
  requestAnimationFrame(pollFramesPerSecond);
  console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);

requestAnimationFrame() anketlerini kullanmak birkaç nedenden dolayı iyi bir fikir değildir:

• Her komut dosyasının kendi yoklama döngüsünü oluşturması gerekir.
• Kritik yolu engelleyebilir.
• rAF yoklaması hızlı olsa bile requestIdleCallback() sürekli kullanıldığında uzun boşta kalma blokları (tek bir kareyi aşan bloklar) programlamasını engelleyebilir.
• Benzer şekilde, uzun boşta kalma bloklarının olmaması, tarayıcının diğer uzun süreli görevleri (daha uzun çöp toplama ve diğer arka plan işleri veya spekülatif çalışmalar gibi) programlamasını engeller.
• Yoklama açılır ve kapatılırsa çerçeve bütçesinin aşıldığı durumları kaçırırsınız.
• Tarayıcının değişken güncelleme sıklığı kullandığı durumlarda (ör. güç veya görünürlük durumu nedeniyle) yoklama yanlış pozitif sonuçları bildirir.
• En önemlisi, aslında tüm animasyon güncellemelerini yakalamıyor.

Ana iş parçacığında çok fazla iş yapılması, animasyon karelerini görme özelliğini etkileyebilir. Ana iş parçacığında (düzen gibi) çok fazla iş olduğunda rAF odaklı bir animasyonun nasıl karelerin atlanmasına, daha az rAF geri çağırmasına ve daha düşük FPS'ye yol açtığını görmek için JankSample'a göz atın.

Ana iş parçacığı takılıp kaldığında görsel güncellemeler takılmaya başlar. Çok kötü!

Birçok ölçüm aracı, ana iş parçacığının zamanında verim sağlaması ve animasyon karelerinin sorunsuz çalışmasını sağlama özelliğine kapsamlı olarak odaklanmıştır. Ancak öykünün bütün uzunluğu bundan ibaret değildir. Aşağıdaki örneği inceleyin:

Yukarıdaki videoda düzenli olarak uzun görevleri ana iş parçacığına ekleyen bir sayfa gösterilmektedir. Bu uzun görevler, sayfanın belirli türde görsel güncellemeler sağlama becerisini tamamen mahvetmiştir ve sol üst köşede requestAnimationFrame() FPS'nin 0 olarak bildirildiği bir düşüş görebilirsiniz.

Yine de bu uzun görevlere rağmen sayfa sorunsuz bir şekilde kaymaya devam ediyor. Bunun nedeni, modern tarayıcılarda tamamen birleştirici tarafından yönlendirilen kaydırmanın genellikle iş parçacıklı olmasıdır.

Bu, aynı anda ana iş parçacığında birçok atlanmış çerçeveyi, ancak yine de birleştirici iş parçacığında başarıyla teslim edilmiş birçok kaydırma çerçevesinin bulunduğu bir örnektir. Uzun görev tamamlandıktan sonra, ana iş parçacığı boyama güncellemesinin herhangi bir görsel değişikliği olmaz. RAF anketi, karenin 0'a düşmesini önermiştir, ancak görsel olarak kullanıcı bu farkı fark edemez!

Animasyon karelerinde hikaye o kadar basit değildir.

Animasyon çerçeveleri: Önemli güncellemeler

Yukarıdaki örnek, hikayenin sadece requestAnimationFrame() olmadığını gösterir.

Peki animasyon güncellemeleri ve animasyon kareleri ne zaman önemlidir? Üzerinde düşündüğümüz ve bunlarla ilgili geri bildirim almak istediğimiz bazı kriterler şunlar:

• Ana ve birleştirici ileti dizisi güncellemeleri
• Boyama güncellemeleri eksik
• Animasyonları algılama
• Nitelik mi nicelik mi?

Ana ve birleştirici ileti dizisi güncellemeleri

Animasyon çerçevesi güncellemeleri boole değildir. Karelerin yalnızca tamamen bırakılması veya tamamen gösterilmesi söz konusu değildir. Animasyon karesinin kısmen sunulmasının birçok nedeni vardır. Başka bir deyişle, aynı anda bazı eski içeriklere sahip olabilir ve aynı zamanda bazı yeni görsel güncellemelere sahip olabilir.

Bunun en yaygın örneği, tarayıcının çerçeve son tarihi içinde yeni bir ana iş parçacığı güncellemesi oluşturamadığı, ancak yeni bir birleştirici iş parçacığı güncellemesine sahip olduğu (önceki iş parçacığı kaydırma örneği gibi) durumdur.

Bileşik özellikleri canlandırmak için bildirim temelli animasyonların kullanılmasının önemli bir nedeni, bunu yapmanın bir animasyonun, ana iş parçacığı meşgul olsa bile tamamen birleştirici iş parçacığı tarafından yönlendirilmesini sağlamasıdır. Bu tür animasyonlar, verimli ve paralel olarak görsel güncellemeler üretmeye devam edebilir.

Öte yandan, ana iş parçacığı güncellemesinin nihayet sunum için uygun hale geldiği, ancak bunun için birkaç kare son tarihini kaçırdığı durumlar da olabilir. Tarayıcıda bazı yeni güncellemeler olacak ancak bu, en son olmayabilir.

Genel olarak, yeni görsel güncellemeler olmadan bazı yeni görsel güncellemeler içeren çerçeveleri kısmi çerçeve olarak değerlendiririz. Kısmi kareler oldukça yaygındır. İdeal olarak, kısmi güncellemeler en azından animasyonlar gibi en önemli görsel güncellemeleri içerir, ancak bu yalnızca animasyonlar birleştirici iş parçacığı tarafından yönlendirildiğinde gerçekleşir.

Boyama güncellemeleri eksik

Diğer bir kısmi güncelleme türü de resim gibi medyaların, kare sunumu için zamanında kod çözmeyi ve pikselleştirmeyi tamamlamadığı durumdur.

Veya bir sayfa tamamen statik olsa bile, hızlı kaydırma sırasında tarayıcılar görsel güncellemelerin gerisinde kalabilir. Bunun nedeni, görünür görüntü alanının ötesindeki içeriğin piksel işlemlerinin GPU belleğinden tasarruf etmek için silinebilmesidir. Piksellerin oluşturulması zaman alır ve büyük bir kaydırmadan (parmak hareketi gibi) sonra her şeyin oluşturulması bir kareden daha uzun sürebilir. Bu, genellikle dama tahtası olarak bilinir.

Her kare oluşturma fırsatıyla, en son görsel güncellemelerin ne kadarının gerçekte ekrana geldiğini izlemek mümkündür. Bunu yapabilme yeteneğinin birçok karede (veya zaman) ölçülmesi genellikle çerçeve işleme hızı olarak bilinir.

GPU gerçekten takılıysa tarayıcı (veya platform) görsel güncellemeleri deneme hızını bile azaltmaya başlayabilir ve bu nedenle etkili kare hızları azalır. Bu teknik olarak atlanan kare güncellemelerinin sayısını azaltabilecek olsa da görsel olarak daha düşük kare işleme hızı olarak görünecektir.

Ancak düşük kare işleme hızı türlerinin hepsi kötü değildir. Sayfa çoğunlukla boştaysa ve etkin animasyon yoksa düşük kare hızı görsel açıdan yüksek bir kare hızı kadar caziptir (ve pilden tasarruf edebilir!).

Peki çerçeve işleme hızı ne zaman önemlidir?

Animasyonları algılama

Yüksek kare işleme hızı, özellikle önemli animasyonların olduğu dönemlerde önemlidir. Farklı animasyon türleri, belirli bir iş parçacığından (ana, birleştirici veya çalışan) gelen görsel güncellemelere bağlı olur. Bu nedenle, görsel güncellemesi, son tarihe kadar güncellemesini sağlayan iş parçacığına bağlıdır. Söz konusu iş parçacığının güncellemesine bağlı olan etkin bir animasyon olduğunda, belirli bir iş parçacığının yumuşaklığı etkilediğini söyleriz.

Bazı animasyon türlerini tanımlamak ve tespit etmek, diğerlerine göre daha kolaydır. Bildirim temelli animasyonlar veya kullanıcı tarafından yönlendirilen animasyonlar, animasyona uygun stil özelliklerinde periyodik güncellemeler olarak uygulanan JavaScript destekli animasyonlara kıyasla daha net bir şekilde tanımlanır.

requestAnimationFrame() kullanılsa bile her rAF çağrısının mutlaka bir görsel güncelleme veya animasyon ürettiğini varsayamazsınız. Örneğin, rAF yoklamayı yalnızca kare hızını takip etmek için kullanmak (yukarıda gösterildiği gibi), görsel bir güncelleme olmadığından akıcılık ölçümlerini etkilememelidir.

Nitelik mi nicelik mi?

Son olarak, animasyonların ve animasyon karesi güncellemelerinin algılanması hâlâ hikayenin yalnızca bir parçasıdır, çünkü animasyon güncellemelerinin miktarını değil, yalnızca animasyon güncellemelerinin miktarını yakalar.

Örneğin, bir video izlerken 60 fps'lik sabit bir kare hızı görebilirsiniz. Teknik olarak bu süreç sorunsuzdur ancak videonun kendisinde düşük bit hızı veya ağ arabelleğe alma sorunları olabilir. Bu, doğrudan animasyon düzgünlüğü metrikleri tarafından yakalansa da kullanıcı için yine de sarsıcı olabilir.

Ya da, <canvas> özelliğinden yararlanan (hatta sabit bir kare hızı sağlamak için ekran dışı tuval gibi teknikler kullanılarak bile) bir oyun, animasyon kareleri açısından teknik olarak mükemmel bir akıcılığa sahip olabilir. Tüm bunları yaparken de sahneye yüksek kaliteli oyun öğeleri yükleyemez veya oluşturma yapıları sergileyemez.

Tabii bir sitede de çok kötü animasyonlar olabilir 🙂

Yani, kendi zamanlarında çok havalılardı sanırım.

Tek bir animasyon karesinin durumları

Kareler kısmen sunulabileceği veya atlanan kareler pürüzsüzlüğü etkilemeyen şekillerde gerçekleşebileceği için, her bir karenin bir tamlık veya pürüzsüzlük puanına sahip olduğunu düşünmeye başladık.

Tek bir animasyon çerçevesinin durumunu en iyiden en kötüye doğru sıralanmış şekilde yorumladığımız yöntemler şu şekildedir:

Bu durumları bir puana dönüştürmek mümkündür. Bu puanı yorumlamanın bir yolu da puanın kullanıcı tarafından gözlemlenebilir olma olasılığı şeklinde değerlendirmektir. Atılan tek bir kare çok gözlemlenebilir olmayabilir, ancak bir dizi pürüzsüzlüğü etkileyen birçok atlanmış kare dizisi elbette gözlemlenebilir.

Hepsini bir araya getirmek: Atlanan Karelerin Yüzdesi metriği

Bazen her animasyon karesinin durumunu ayrıntılı bir şekilde incelemek gerekebilir, ancak bir deneyim için sadece hızlı bir "bir bakışta" puanı atamak da yararlı olur.

Kareler kısmen sunulabileceği ve tamamen atlanan çerçeve güncellemeleri bile pürüzsüzlüğü etkilemeyebileceği için yalnızca kare saymaya daha az, tarayıcının önemli olduğunda güncellemeleri görsel olarak tamamlayamadığı içeriğe daha çok odaklanmak isteriz.

Zihinsel model şu şekilde değiştirilmelidir:

1. Saniyedeki Kare Sayısı -
2. Eksik ve önemli animasyon güncellemelerini algılama,
3. Belirli bir dönemdeki Düşüş Yüzdesi.

Önemli olan önemli güncellemeleri bekleme süresidir. Bunun, kullanıcıların uygulamada web içeriğinin sorunsuzluğunu doğal bir şekilde deneyimleme şekline uygun olduğunu düşünüyoruz. Şimdiye kadar aşağıdakileri bir başlangıç metrik grubu olarak kullanıyoruz:

• Ortalama Ayrılma Yüzdesi: Tüm zaman çizelgesi boyunca boşta olmayan tüm animasyon kareleri için
• Atılan Karelerin Yüzdesi için En Kötü Durum: 1 saniyelik kayan zaman aralıkları üzerinden ölçülen
• Atılan Kare Yüzdesi'nin 95. yüzdelik dilimi: 1 saniyelik kayan zaman aralıkları üzerinden ölçülür.

Bu puanları bugün bazı Chrome geliştirici araçlarında bulabilirsiniz. Bu metrikler yalnızca genel kare işleme hızına odaklansa da kare gecikmesi gibi başka faktörleri de değerlendiriyoruz.

Geliştirici araçlarında kendiniz deneyin!

Performans HUD'si

Chromium'da, bir bayrağın (chrome://flags/#show-performance-metrics-hud) arkasında gizlenmiş düzenli bir Performans HUD'si vardır. Burada, Önemli Web Verileri gibi şeyler için canlı skorları ve zaman içinde Atılan Karelerin Yüzdesi'ne göre animasyon yumuşaklığıyla ilgili birkaç deneysel tanımı bulabilirsiniz.

Çerçeve Oluşturma İstatistikleri

Yeni animasyon karelerinin canlı görünümünü görmek için Oluşturma ayarları üzerinden DevTools'da "Kare Oluşturma İstatistikleri"ni etkinleştirin. Bu kareler, kısmi güncellemeleri tamamen bırakılan kare güncellemelerinden ayırt etmek için renk kodludur. Bildirilen fps yalnızca tam olarak sunulan kareler içindir.

Geliştirici Araçları performans profili kayıtlarında Çerçeve Görüntüleyici

Geliştirici Araçları Performans panelinde uzun süredir bir Çerçeveler görüntüleyicisi bulunuyor. Ancak bu durum, modern oluşturma ardışık düzeninin işleyiş şekliyle biraz uyuşmuyordu. En son Chrome Canary'de bile, yakın zamanda çok sayıda iyileştirme yapıldı. Bu iyileştirmelerin, animasyon sorunlarının giderilmesini büyük ölçüde kolaylaştıracağını düşünüyoruz.

Bugün, çerçeve görüntüleyicideki karelerin vsync sınırlarıyla daha iyi hizalandığını ve duruma göre renklerle kodlandığını göreceksiniz. Yukarıda özetlenen tüm nüanslar için henüz tam bir görselleştirme yapmış olmasa da, yakın gelecekte daha fazla nüans eklemeyi planlıyoruz.

Chrome izleme

Son olarak, ayrıntıları derinlemesine incelemek için tercih edilen bir araç olan Chrome İzleme sayesinde yeni Perfetto kullanıcı arayüzü (veya about:tracing) aracılığıyla "Web içeriği oluşturma" izini kaydedebilir ve Chrome'un grafik ardışık düzenini derinlemesine inceleyebilirsiniz. Göz korkutucu bir görev olabilir, ancak bunu kolaylaştırmak için son zamanlarda Chromium'a eklenen birkaç şey var. Bir Çerçevenin Yaşamı belgesinde mevcut olanlara genel bir bakış bulabilirsiniz.

İzleme etkinlikleri aracılığıyla şunları kesin olarak belirleyebilirsiniz:

• Çalışan animasyonlar (TrackerValidation adlı etkinlikler kullanılarak).
• Animasyon karelerinin tam zaman çizelgesini alma (PipelineReporter adlı etkinlikler kullanılarak).
• Kötü animasyon güncellemeleri için animasyonunuzun daha hızlı çalışmasını tam olarak neyin engellediğini bulun (PipelineReporter etkinlikleri içindeki etkinlik dökümlerini kullanarak).
• Giriş odaklı animasyonlar için görsel güncelleme almanın ne kadar sürdüğünü görün (EventLatency adlı etkinlikler kullanılarak).

Sırada ne var?

Web Vitals girişimi, web'de mükemmel kullanıcı deneyimleri oluşturmak için metrik ve rehberlik sağlamayı hedefler. Toplam Engelleme Süresi (TBT) gibi laboratuvar tabanlı metrikler, potansiyel etkileşim sorunlarının tespit edilmesi ve teşhis edilmesi için son derece önemlidir. Animasyon yumuşaklığı için de laboratuvar tabanlı benzer bir metrik tasarlamayı planlıyoruz.

Animasyon karesi verilerine göre kapsamlı bir metrik tasarlamaya yönelik fikirler üzerinde çalışmaya devam ederken sizi bilgilendireceğiz.

Gelecekte, hem alandaki hem de laboratuvardaki gerçek kullanıcılar için animasyonun düzgünliğinin iyi bir şekilde ölçülmesini mümkün kılan API'ler tasarlamak istiyoruz. Güncellemeler için bizi takip etmeye devam edin.

Geri bildirim

Animasyon yumuşaklığını ölçmek için Chrome'da kullanıma sunulan tüm son iyileştirmeler ve geliştirici araçlarıyla ilgili heyecan duyuyoruz. Lütfen bu araçları deneyin, animasyonlarınızı karşılaştırın ve bize bu araçların nereye yönlendirdiğini bildirin.

Yorumlarınızı, konu satırında "[Smoothness Metrics]" yazarak web-vitals-feedback Google grubuna gönderebilirsiniz. Düşüncelerinizi öğrenmek için sabırsızlanıyoruz.