Google Play uygulamasının yirmi yıllık geçmişini Jetpack Compose'a taşıma

Merhaba.

Adım Can.

Ben Google Play Store ekibinden katılıyorum.

Bu, meslektaşım Kirill.

Bugün, View ve Fragment sistemindeki birçok kodu Compose'a nasıl taşıdığımızdan bahsedeceğiz.

Haydi başlayalım.

Peki bu geçiş nasıl gerçekleşti ve ölçeği neydi?

Uygulamamızın kod tabanı, 2007'den bu yana organik olarak büyüdü.

Birkaç milyon satır üretim kodumuz, 200 ekranımız ve bu ekranların çoğunda kullanılan 500 benzersiz kullanıcı arayüzü bileşenimiz var.

2020'de geliştirici hızı, güvenilirlik ve performansın istediğimiz hedeflere ulaşmadığını fark ettik.

Bu nedenle modern bir kullanıcı arayüzü teknoloji yığını kullanmaya karar verdik.

Birçok farklı kitaplığı değerlendirdik.

O dönemde AndroidX'teki bazı arkadaşlarımızla Compose hakkında konuşuyorduk. Compose'u kullanmaya ve Compose'un ilk büyük iş ortağı olmaya karar verdik.

Nasıl geçti?

Altı yıl sonra, Play Store uygulamasındaki kullanıcı gösterimlerinin %97'si yalnızca Compose ekranlarında gerçekleşiyor.

Pardon, 2020'den beri tüm telefon ve büyük ekran geliştirme çalışmaları yalnızca Compose'a taşındı.

Hatta XR, TV, Auto ve Wear gibi genişletilmiş form faktörlerimiz bile 2025'ten itibaren Compose'a geçti.

Compose, bu başarının en önemli destekçilerinden biri oldu ve bu nedenle daha fazla benimsemeye devam ettik.

Haftada iki kez yeni Compose sürümlerini kullanmamıza yardımcı olan çok güçlü ve kapsamlı bir test paketleri vardı.

Alfa derlemelerini ve yeni API'lerini kullanmak, yeni hata düzeltmelerinden ve performans iyileştirmelerinden yararlanmamıza, yeni API'lerden bazılarını keşfetmemize ve yeni kullanıcı deneyimleri sunmamıza yardımcı oluyor.

Özellikle performans açısından Compose, tüm ana ekranlarımızda uygulamamız için sürekli olarak takılma performansı sağladı.

Bu sayfa; arama sonuçları sayfası, ana sayfa ve ayrıntılar sayfasıdır.

Performans, takılma ve yükleme gecikmesi, hem işletmemiz hem de kullanıcı deneyimimiz için çok önemli metriklerdir.

Son 14 ayda %30'luk bir iyileşme gördük.

Peki, bu noktaya nasıl geldik?

Asıl konuşmak istediğimiz konu bu.

Şimdi taşıma planından bahsedelim.

Bu nedenle Google Play, çok adımlı bir yaklaşım benimsedi.

Tüm yumurtalarımızı tek bir sepete koymak istemedik.

Riskleri ve işletmemizi nasıl etkilediğini anlamak ve tam anlamıyla kullanmaya başlamadan önce güven kazanmak için birkaç adım attık.

Bunları emekleme, yürüme, hafif tempo koşu ve koşu olarak adlandıracağım.

Bu nedenle, emekleme aşaması bizim için Compose'a alışmaktan ibaretti.

Düşük trafiğe sahip bir sayfayla başladık.

Bu sayfa, ayarlar sayfası, üçüncü taraf lisansları gibi bir sayfa olabilir.

Asıl hedefiniz, Compose kitaplığına aşinalık kazanmaktır.

Satırlar, sütunlar, metinler, resimler ve benzeri her şeye alışmak için bu alıştırmayı yapabilirsiniz.

Ardından, tüm uygulama altyapınızı taşımaya ve Compose'un çalışma şeklini anlamaya başlamanız gerekir.

Bu, gösterim günlüğü, tıklama günlüğü, tema oluşturma olabilir. Aynı zamanda veri yüklemeyi de yeniliyorduk.

Yani tüm bu unsurlar bir araya geliyor.

Faydalı bulduğumuz bir diğer şey de tüm ekranlarımızın tutarlı görünmesini sağlamaktı. Compose'daki tema nesnelerimizin doğrudan XML stilleri, tipografi, renkler ve diğer her şeyle eşleştiğini kontrol etmek için bazı birim testleri ve işlevsel testler oluşturduk.

Biraz alışıp kendimizi rahat hissettikten sonra yürümeye karar verdik.

Bizim için bu, trafiği çok yüksek bir ekranda daha küçük bir bileşeni alıp bu tür bir taşıma işleminin nasıl göründüğünü değerlendirmekti.

RecyclerView'da bulunan bir öğeyi kullanmanızı öneririz. Bu sayede, View ve Compose sistemi arasındaki uyumluluk sorunlarını anlayabilir, performansı ve takılmaları ölçebilirsiniz.

Bileşenin kendisinin çok karmaşık olması gerekmez ancak düzenleri, metinleri, resimleri ve bu tür şeyleri kullanan bir şey olmasını istersiniz. Normalde göreceğiniz şeylerin birkaç farklı örneği.

Bu alanda dikkat etmeniz ve muhtemelen beklemeniz gereken bir şey, takılma ve gecikme süresinde bir miktar artış olmasıdır. Bu artış hafif olacaktır ancak bunun nedeni artık iki yığın çalıştırmanızdır.

Tamamen Compose'da olan bir oluşturma yığınınız ve Görünümler'de olan bir oluşturma yığınınız var.

Bu nedenle, bellek aşımı ve fazladan sınıf yükleme gibi sorunlar yaşanabilir.

Ancak Compose'u daha fazla kullandıkça bu durum ortadan kalkar.

Bu süre zarfında gerçekten ihtiyacınız olursa ekranı hafifçe ısıtarak düzeltmeye çalışabilir ve kısa vadede bu maliyeti azaltabilirsiniz.

Yürüyüşten sonra hafif tempoda koşuya geçiyoruz.

Bu, çok rahat olduğumuzda geçerlidir.

Trafiği yoğun bir sayfada tek bir bileşen yerine trafiği yoğun sayfanın tamamını yapın.

Bu projede gezinme kitaplığını ve parçaları kullanmaya devam ettik ancak her bir ekranı tamamen Compose'da uyguladık.

Fragment'ın ComposeView'un kendisini döndürmesini sağladık.

Bu sayede gecikme ve takılma sorunları azalır.

Bahsettiğim bellek çakışması ve sınıf yükleme sorunlarını o kadar sık yaşamazsınız.

Compose'un kendisi de ComposeView düzeyinde bir miktar önbelleğe alma işlemi yapar.

Dolayısıyla, tutarlı görünen ve aynı simgelere sahip olabilecek bir grup kart içeren bir RecyclerView'unuz varsa tüm bu simge ayrıştırma ve kaynak kullanımı, ComposeView'daki her şey arasında paylaşılır.

Sonra koşuya geçtik.

Bu aşamada tüm gücünüzle çalışırsınız.

Uygulamanızdaki trafiğin büyük bir kısmı Compose'dan gelmeye başladığında bir üst seviyeye geçtik.

Ekranların üstünde Etkinlik var.

Bu nedenle ComposeView'u etkinlik köküne taşıyın.

Kodunuzun büyük bir kısmı da nispeten benzer görünecektir.

Bir ekrandan diğerine geçmek istediğinizi söylemek için hâlâ bir navigasyon talimatı vermeye çalışıyorsunuz.

Ancak Fragment işlemleri yapmak yerine Composable işlevini çağırıyorsunuz.

Bunu Nav2 veya Nav3 kitaplığının üzerinde yapabilirsiniz.

Bizim durumumuzda, tüm ekranlarımızı taşımamıştık.

Çok sayıda olduğunu söylemiştim.

Bu nedenle, Fragment tabanlı bir ekran oluşturabileceğiniz ve bunu yapmak için Compose'un AndroidFragment sarmalayıcılarından yararlanabileceğiniz Fragment uyumluluğu oluşturduk.

Tekrar söylemek gerekirse, takılma ve gecikme işletmemiz için önemli. Bu nedenle, bu konuda sınırları zorlamaya devam ediyoruz. Ekranlar arasında önbelleğe alma özelliğimiz olduğu ve bellek çakışması sorununu çok daha az yaşadığımız için bu konuda iyileştirmeler görmeye devam edeceksiniz.

Ancak yeni özellikler de elde edersiniz.

Sağdaki GIF'te, ekranlar arasında paylaşılan öğe geçişleri yapabileceğiniz bir örnek gösterilmektedir.

Bir ekrandan diğerine geçerken büyüttüğümüz bir resim var ve bu resim süreklilik sağlıyor.

Bu geçişi yaparken Compose'un tüm animasyon esnekliğinden de yararlanabilirsiniz.

Şimdi sözü Kirill'e bırakıyorum. Kirill, diğer özelliklerden bahsedecek.

Teşekkürler, Can.

Bir süredir üzerinde çalıştığım, benim için çok önemli bir konudan bahsetmek istiyorum: Android uygulamaları için tema ve stil oluşturma.

Görünüm dünyasında Java kodu ve biraz sonra Kotlin kodu vardı. Ardından X-- XML kaynakları, renkler, dizeler, boyutlar, düzenler, temalar ve stiller gibi kaynaklar vardı.

Bu sistemde tüm XML kaynakları, APK'ya dahil edilen bir kaynak tablosunda derleniyordu ve bu tablo büyük ölçüde statikti.

Kullanıcı arayüzü hiyerarşisinin üstüne özel stil uygulamak için çalışma zamanında dinamik olarak kullanabileceğiniz bir API Resources.Theme.applyStyle vardı.

En büyük sınırlama, bu işlemi içeriğinizi şişirmeden önce yapmanız gerekmesiydi. Yani, bu stili mevcut bir kullanıcı arayüzü parçasına dinamik olarak uygulamak istiyorsanız tüm etkinliği kaldırıp yeniden oluşturmanız gerekiyordu. Bu da kullanıcı deneyimi açısından pek iyi değildi.

Ayrıca, önceden derlenmiş bu XML bloklarını uyguladığı için, deneme işaretlerinize veya diğer iş ihtiyaçlarınıza göre birden fazla koşullu dinamik yer paylaşımını birleştirmeniz zorlaşıyordu.

XML dünyasındaki stil hiyerarşisi için doğru bir zihinsel model oluşturmak biraz zordu.

Son olarak, Android Studio'da veya başka bir geliştirme aracında Java dünyası, kod dünyası ve XML dünyası arasındaki boşluğu doldurmanıza olanak tanıyan tek bir birleşik görünüm yoktu.

Ayrıca, doğru zihinsel modeli oluşturmak ve stilimin neden uygulanmadığını, neden yanlış rengi aldığımı vb. anlamak için hata ayıklamak biraz zordu.

Yeni dünyada, yani Compose dünyasında, özellikle Materyal Tasarım sistemi ve Compose Material kitaplığı için, ancak diğer tasarım sistemleri için de geçerli olan bir şey var. Materyal Tasarım sistemi için, ekranınızdaki kullanıcı arayüzü hiyerarşinizin en üstüne uyguladığınız bir MaterialTheme Composable'ımız var ve bu MaterialTheme'i kullanıcı arayüzünüzün daha küçük bir parçası üzerinde bir katman olarak da uygulayabilirsiniz.

Sağdaki ekrana bakarsanız üstte Play Points Altın seviyesini görebilirsiniz. Bu, ilerleme göstergesi ve birkaç metin içeren küçük bir karttır.

Bu Material Theme katmanını, GitHub'da kullanabileceğiniz Material Color Utilities kitaplığı tarafından oluşturulan özel bir renk şemasıyla uygularız.

Tohum olarak bu kahverengimsi, sarı, altın rengini iletiyoruz ve bu kartın uygulamasında kullandığımız birincil üzerinde birincil, ikincil üzerinde ikincil olmak üzere tüm Material renk jetonları spektrumunu oluşturuyor.

Bu sayede Android geliştiricileri, dinamik tema özelliğinin tüm olanaklarından yararlanabilir.

Her şey kodla, Kotlin'de yapılır. Bu sayede, tüm sistemin nasıl çalıştığına dair doğru zihinsel modeli oluşturmak ve hata ayıklamak çok daha kolaydır.

Dahili olarak bu yer paylaşımları, hiyerarşinizde uygulamayı seçtiğiniz belirli kullanıcı arayüzü düğümlerine CompositionLocal olarak eklenir.

Performansla ilgili dikkat edilmesi gerekenler: Material Color Utilities kitaplığıyla tam renk şeması oluşturmak ücretsiz değildir.

Bu, belirli bir ek yük getirir.

Dolayısıyla, birden fazla renk şeması gerektiren karmaşık bir tasarımınız varsa (ör. bento kutusu gibi bir yapı) ve çalışma zamanında birden fazla renk şeması oluşturuyorsanız bu durum gecikmeye ve takılmaya neden olabilir.

Böylece, a, performansınızı nasıl etkilediğini ölçmeye başlayabilir ve b, bu ek yükün bir kısmını çalışma zamanından derleme zamanına aktarabilirsiniz.

Derleme sırasında aynı Material Color Utilities kitaplığını kullanarak bu renk şemalarını markanızın veya ürününüzün ihtiyaçlarına göre önceden oluşturabilir ve bu ek yükü derleme zamanına aktarabilirsiniz.

Kullanıcı arayüzü hiyerarşi ağacında yer paylaşımlarının tam olarak nerede olduğunu takip eden yerel oluşturma öğeleri çok daha ucuzdur ancak yine de ücretsiz değildir.

Yani, bunlardan kaç tane kullandığınıza bağlı olarak, onlarca, yüzlerce, birikmeye başlar.

Bir noktada, tüm bu birleştirilmiş oluşturma yerellerinin maliyetine bakmaya başlamak istersiniz.

Bu, Compose'un gerçek dinamik çalışma zamanı temalandırma özelliklerinden bahsettiğim şeye bir örnektir.

Burada dört kadranımız var, aynı görseller, aynı etkinlik kartı diyelim.

Tüm kartı kaplayan bir hero resmimiz var. Sol üstte bir etiket, sağ altta bir düğme ve birkaç metin var.

Her bir kadranın sağ tarafında, her bir öğe için tasarım spesifikasyonu olarak kullanılan renk jetonlarının açıklamasını görürsünüz.

Kart uygulaması bu dördü için de tamamen aynıdır.

Tek fark, kartı sarmalayan Materyal Teması Oluşturma yer paylaşımının, resmin baskın rengine (mavi, mor, sarı ve kırmızı) göre dinamik olarak oluşturulan bir renk şemasıyla oluşturulması veya yapılandırılmasıdır.

Diğer her şey aynı kalır.

Etkinliğinizi silip yeniden oluşturmanız gerekmez.

Deneme işaretlerinize veya diğer işletme ihtiyaçlarınıza göre koşullu olarak uygulayabilirsiniz.

Ayrıca, daha önce de söylediğim gibi, uygulamanıza renk özelleştirmeleri uygulamanın çok daha dinamik, gerçekten dinamik bir dünyasıdır.

Şimdi bir sonraki bölüm için sözü Jon'a bırakıyorum.

Evet.

Kirill'in bahsettiği esnekliklerden biri de bu.

Şimdi de güvenilirlik ve hızdan bahsedelim.

Bu nedenle, tüm geliştiriciler ve işletmeler hızlı bir şekilde yüksek kaliteli kod oluşturmak ister.

Şimdi, Compose'un Google Play'in bunu yapmasına nasıl yardımcı olduğuna bakalım.

Öncelikle, büyük bir diyagram olduğunu biliyorum. Mimari basitliğinin, hem insanlar hem de aracılar olmak üzere tüm kod yazarları ve bakımını yapanlar için büyük faydaları vardır.

Bu konuya çok fazla girmeyeceğim ancak Compose'un ortaya koymaya çalıştığı zihinsel model şeylerinden biri tek yönlü veri akışıyla ilgili ve ekibimiz üzerinde gerçekten büyük bir etkisi oldu.

İşleyiş şeklini bilmeyenler için temel olarak bir veri kaynağınız vardır.

Veri kaynağı, veri sağlar.

Bu veriler, kullanıcı arayüzü modeli olarak çıkardığımız belirli bir kullanıcı arayüzüne dönüştürülebilir.

Ardından Compose, bu durumdaki bir değer özelliğini çağırarak bunu kolayca gözlemleyebilir.

Bu, diyagramın üst tarafındaki oklarla gösteriliyor.

Ardından etkinlikler ters yönde ilerler.

Yani bir kullanıcı bir düğmeyi tıklarsa bu işlem kullanıcı arayüzü dönüştürücüsüne geri döner, veri kaynağını günceller, yeni bir değer yayınlar, dönüşümler çalışır ve bu döngüyü elde edersiniz.

Yani her şey bu nispeten basit döngü üzerinden ilerler.

Bu sayede hazırlık zamanı kısalıyor.

Ana iş parçacığına veya diğer iş parçacıklarına yapılan tüm bu çağrıların nerede gerçekleştiği artık bilinmiyor.

Genel bir döngü izler.

Compose, veri gözlemini son derece kolaylaştırır ve veriler, mimari katmanlar genelinde güçlü tutarlılık garantilerine sahiptir.

Zihinsel model, ekibimizdeki doğru kaynaklarla ilgili birçok görüşmeyi azalttı ve çeşitli yarışma durumlarını tamamen ortadan kaldırdı.

Bizim için bir diğer büyük avantaj da önceki model-görünüm-denetleyici mimarimize kıyasla, veri kaynaklarının ve kullanıcı arayüzü dönüşümlerinin paralel olarak yürütülmesinin çok daha kolay hale gelmesi oldu.

Bu sayede, mağazadaki yükleme gecikme süremizi 50 ms kadar iyileştirdik.

Bu bizim için oldukça etkileyiciydi.

Tek yönlü veri akışıyla birlikte Compose'un diğer büyük avantajı, açıklayıcı kullanıcı arayüzüyle ilgilidir.

Kirill bu konuya biraz değindi.

Google Play geliştiricileri de bu özellikten çok memnun kaldı.

Kullanıcı arayüzü kontrol akışı artık tek bir dosyada.

Sağ tarafta oldukça basit bir örnek görebilirsiniz.

@Composable
fun PurchaseRow(onClick: () -> Unit, modifier: Modifier) {
  Row(modifier) {
    Text("20% off sale")
    if (LocalExpts.current.useButtonV2) {
      ButtonV2("Buy", onClick = onClick)
    } else {
      ButtonV1("Buy", onClick = onClick)
    }
  }
}

Bir deneme işaretine göre iki düğme uygulaması arasında geçiş yapıyoruz.

Birden fazla görünüm dosyası, parça dosyası ve XML dosyası okumak yerine, yukarıdan aşağıya doğru okuyabilirsiniz. Bu da işinizi çok daha kolaylaştırır.

İç içe yerleştirilmiş composable'ların maliyeti, iç içe yerleştirilmiş görünüm hiyerarşilerine kıyasla çok daha düşük. Bu sayede, performans için her küçük ayrıntıyı optimize etmek zorunda kalmadan kodumuzu daha okunabilir hale getirmek için doğal bir şekilde düzenleyebildik.

Gördüğümüz diğer avantajlar ise yaşam döngüsü geri çağırmalarının çok daha basit olması ve endişelenmeniz gerekenlerin sayısının azalmasıdır.

Yani görünüm yaşam döngüsü, parça yaşam döngüsü, etkinlik yaşam döngüsü yerine tek kullanımlık efekt, yan etki elde edersiniz ve yerleştirdiğiniz yere bağlı olarak çok tutarlı bir şekilde hareket eder.

Bu bizim için çok büyük bir avantaj oldu.

Bence bu iki mimari değişiklik, LLM'lerin temelini oluşturdu ve oldukça yüksek kaliteli kodlar üretmesini sağladı.

Birçoğunuzun bunu en sevdiğiniz LLM ile denediğinden veya yaptığından eminim.

Renkler ve tipografiyle açıklama eklenmiş bir ekran görüntüsü alıp bunu modele besleyebilirsiniz. Model, satırlar, sütunlar, metinler ve düğmeler oluşturabilir ve bunu oldukça iyi bir şekilde yapar.

Ancak bazı sınırlamaları vardır.

Google Play'in asıl gördüğü şey, kod tabanınızı anlamadığıdır, değil mi?

Daha önce oluşturduğunuz ve yeniden kullanması gereken bileşenleri bilmez, tasarım jetonlarının adlarını bilmez.

Yalnızca sabit kodlu renkler ve dizeler sağlar.

Hangi içerik cihazdan, hangi içerik sunucudan gelmeli? Ya da yalnızca devasa bir sütun oluşturmak yerine LazyList'i kullanarak performanslı olmasını nasıl sağlayabilirim?

Bu sorunlardan bazılarını çözmek için ekran görüntülerine biraz daha fazla meta veri ekledik.

Yani kullanıcı arayüzü adları, bileşenlerin nerede başlayıp nerede bittiğini bilmemiz için sınırlayıcı kutular, renklerin ve tipografinin semantik adları için tasarım jetonları, beceriler ve ayrıca performansla ilgili bu hususları dikkate alabilmesi için bunun nereye yerleştirileceğini belirten bazı istemler.

Ardından, hangi içeriğin dinamik, hangisinin statik olduğunu belirtebilmeniz için çok üst düzey bir işlev imzası da eklemeniz gerekir.

Böylece, daha önce sahip olduğumuz bir şeyi sonraya taşımış olursunuz.

Diyagramda çok fazla gürültüye neden olacağı için sınırlayıcı kutuları buraya eklemedim.

Ancak bu sabit kodlu renklerin ve tipografi adlarının, büyük başlık ve yüzeyde ile değiştirildiğini görebilirsiniz.

Kart başlığı ve simge rozeti gibi bileşen adları açıkça belirtilmiştir.

Böylece bu dosyalar kod tabanınızda bulunabilir.

Bizim için de bunların çoğu ortak tasarım kitaplıklarından geliyor. Kirill birazdan bu konudan bahsedecek.

Bu nedenle, tüm bu ürünleri her zaman özel olarak etiketlemezsiniz.

Bunu, en alttaki gibi bir yöntem imzasıyla (OfferCard) eşlersiniz. Böylece başlığın, endDate ve resmin dinamik olduğunu anlar.

Bunları sabit kodlamamalıyız.

Bu semantik adlarla birlikte, Kirill'in bahsettiği tüm farklı renk uygulamalarına geçiş yapabiliriz.

Böylece çok daha fazla kod üretiyoruz.

Kaliteyi nasıl koruduğumuzdan bahsetmesi için sözü Kirill'e bırakıyorum.

Doğru.

Teşekkürler, Can.

LLM ve temsilci destekli geliştirme konusuna devam edersek, ilk olarak UX tasarımı tarafında başlıyoruz.

Tasarım aracınız ne olursa olsun (Figma veya başka bir araç), tüm tasarımcıların kullandığı ortak bir şablonunuz olmalıdır. Bu şablonda, seçtiğiniz tasarım sisteminden renk, tipografi ve şekil token'ları bulunmalıdır.

Belki de Material'dır.

Belki de özel tasarım sisteminizdir.

Renk jetonları için özel olarak, bu şablonların açık ve koyu mod arasında geçiş yapmak ve birkaç yıl önce Android düzeyinde kullanıma sunulan normal, orta ve yüksek kontrast modları arasında geçiş yapmak için yerleşik desteğe sahip olmasını istiyorsunuz.

Böylece tasarımcılar, tasarım özelliklerinin nasıl tepki verdiğini görmek için bu farklı kombinasyonlar arasında hızlıca geçiş yapabilir.

Ardından, tasarım tamamlanıp uygulama tarafına aktarılırken, dışa aktarma hattında her rengin, her tipografi öğesinin, her şeklin sabit kodlanmış bir RGB değeri, sabit kodlanmış bir yazı tipi ailesi veya yazı tipi boyutu yerine eşleşen bir jeton kullandığını izleyebilmek istersiniz.

Son olarak, Google Play ölçeğinde çok faydalı bulduğumuz bir şey var. Çeşitli ekranlarımızda kullanılan onlarca değil, birkaç yüz bileşen, küme, kart ve kapsayıcımız var.

Tüm bunları tek bir yerde, yani bileşen kataloğunda takip etmenin ve ardından bu bileşen kataloğu üzerinde eğitilmiş özel bir temsilciye sahip olmanın faydalı olduğunu gördük.

Bu temsilci, yeni bir ekran, yeni bir kullanıcı yolculuğu veya yeni bir ürün alanı başlattığınızda çok işe yarar. İlk tasarım keşiflerinden (ör. slaytlar veya Figma spesifikasyonları) elde ettiğiniz bilgileri bu temsilciye aktarabilirsiniz. Temsilci, mevcut bileşenleri hızlıca belirleyerek yeniden tasarlanmalarını, yeniden tanımlanmalarını ve sıfırdan uygulanmalarını önler.

Bu da tasarım ve uygulama maliyetlerini önemli ölçüde azaltır.

Uygulama tarafında ise temel ve özel Lint kurallarına çok fazla ağırlık veriyoruz.

Özellikle bahsetmek istediğim birkaç temel Lint kuralı var. Bunlardan biri, gecikmeye ve takılmaya neden olabilecek gereksiz yeniden oluşturma kaynaklarını belirlemeye yardımcı olan FrequentlyChangingValueDetector. Diğeri ise Material Compose Scaffold bileşenini kullandığımız ancak gelen dolguları yok saydığımız durumları işaretleyen ScaffoldPaddingDetector.

Gecikmeye ve takılmaya neden olmaz ancak bazı durumlarda, hata ayıklaması çok zor olan, kenardan kenara veya katlama, açma gibi belirli durumlarda düzen yanlış hizalamalarına yol açabilir.

Son olarak, BoxWithConstraints'in belirli performansla ilgili dikkat edilmesi gereken noktaları vardır.

Her şeyi düzgün bir şekilde yerleştirmek için iki kare gerekebilir.

Bu kullanımı tamamen engellemiyoruz ancak Lint uyarısı olarak işaretliyoruz. Böylece, ilgili ekran üzerinde çalışan geliştirici, BoxWithConstraints'i kullanmak için belirli bir seçim yaptığını bilir veya bu belirli düzen için başka bir şey kullanmayı tercih edebilir.

Tema otomasyonu için yine renk, tipografi ve şekil jetonları kullanılır.

Sabit kodlu renklerin ve sabit kodlu tipografinin kullanımını engelleyen bir Lint kuralımız var.

Material 2 bileşenlerinin kullanımını işaretleyen bir Lint kuralımız var.

Yalnızca en yeni ve en iyi sürüm olan Material 3'ü kullanmak istiyoruz. Bu sürüm, geçen yıl ve bu yıl kullanıma sunulan yeni etkileyici bileşenleri de içeriyor.

Örneğin, kullanıcıların eski XML dosyalarından renkleri okumasını engelleyen özel bir Lint kuralımız var.

Yeni ekranlar için öncelikli olarak ve yalnızca Compose'u kullanmak istiyoruz.

Ayrıca, özellikle Materyal Tasarım sistemindeki Text composable'ları, stil ve renk için yedeklere sahiptir.

Bunu yerel içerik renginden ve yerel tipografiden okurlar ancak buna güvenmek istemiyoruz.

Her metnin, tasarım spesifikasyonundaki belirli stili, tipografi stilini ve belirli rengi bilinçli olarak kullanmasını istiyoruz.

Bu, kullandığımız bir Lint kuralıdır.

Son olarak, ScaffoldPaddingDetector'a benzer şekilde, sahip olduğumuz her Composable işlevin giriş değiştiricisini kullanmasını zorunlu kılan özel bir Lint kuralımız var.

Yine, yeni kullanımların yanlış yerleştirilmesini veya gelen arka plana saygı gösterilmemesini ya da her neyse, bunu önlemek için.

Bu sunumdan çıkarmanızı istediğimiz üç ana nokta bunlardır.

İlk olarak, 2026'nın sonunda Compose'un ölçekte kendini kanıtlamış, olgun bir kullanıcı arayüzü araç seti olduğunu düşünüyoruz.

Android'in kendisi de Compose önceliklidir.

Bu yılın başlarında Google I/O'da, tüm kullanıcı arayüzü kitaplıklarının ve tüm temsilci akışlarının öncelikli olarak Compose'u desteklediğini duyurmuştuk.

Jon'un sunumun başlarında bahsettiği gibi, emekleme, yürüme, koşma ve koşma aşamalarını takip ederek, özellikle büyük kod tabanlarını kademeli olarak taşımanızı öneririz. Bu sayede geliştirici akışları ve temsilci akışları için hızınızı artırabilirsiniz.

Bugün vaktinizi bize ayırdığınız için teşekkür ederiz. Birkaç dakika içinde Jon ile birlikte dışarıda olacağız ve sorularınızı yanıtlayacağız.

Zaman ayırdığınız için tekrar teşekkür ederiz.