Composition: özü, Compose'ta UI ağacı oluşturma

Jetpack Compose'ta Composition Nedir

Composition, Composable işlevlerin yürütülmesi sürecidir ve kullanıcı arayüzünün düğümlerden oluşan bir ağaç olarak dahili temsiliyle sonuçlanır. Bu ağaçtaki her düğüm, yerleşik bir bileşene (Text, Button, Image) veya kullanıcı tanımlı bir Composable işlev çağrısına karşılık gelir. Composition doğrudan Android View nesneleri oluşturmaz — daha sonra Layout ve Drawing aşamaları tarafından işlenen soyut bir açıklama oluşturur.

Composition'ın temel özelliği yeniden başlatılabilirliğidir. Kompozisyondaki her Composable işlev, giriş parametreleri veya okuduğu durum nesneleri değiştiğinde herhangi bir zamanda yeniden başlatılabilir. Sistem tüm ağacı yeniden başlatmaz — yalnızca değişen verilere gerçekten bağımlı olan işlevleri yeniden başlatır.

Teknik olarak Composition, Composer aracılığıyla yönetilir — Kotlin derleyicisinin her Composable işleve yerleştirdiği dahili bir motor. Composer, slotlara (konum grupları) hangi işlevlerin hangi parametrelerle ve hangi sırayla çağrıldığına dair bilgileri yazar. Sonraki çağrılarda Composer, yeni verileri depolanan verilerle karşılaştırır ve yeniden başlatıp başlatmamaya karar verir.

Composition Sırasında UI Ağacı Nasıl Oluşturulur

UI ağacı oluşturma süreci, bir Activity veya Fragment içinde setContent yönteminin çağrılmasıyla başlar. Bu yöntem, ilk Composition'ı oluşturur ve kök Composable işlevini yürütmeye başlar. Ardından her iç içe geçmiş Composable işlev, ağaca kendi düğümlerini ekleyerek bir hiyerarşi oluşturur: Row, Text ve Button içerir, Column, Image ve Card içerir, vb.

Her ağaç düğümü, kaynak koddaki konumuna dayalı benzersiz bir konum anahtarı alır. Bu anahtar, sonraki yürütmeler sırasında düğümü tanımlamak için kullanılır. Konum anahtarı, Composable işlev çağrılarının sırasının koşullara bağlı olmamasının nedenidir: bir çalıştırmada A -> B çağrılırsa ve bir sonrakinde B -> A çağrılırsa, Compose eski ve yeni düğümleri eşleştiremez.

@Composable
fun AppScreen() {
    Column {                     // Column düğümü (konum 1)
        HeaderSection()            // HeaderSection düğümü (konum 2)
        ContentSection()           // ContentSection düğümü (konum 3)
        FooterSection()            // FooterSection düğümü (konum 4)
    }
}

@Composable
fun HeaderSection() {
    Row {                       // Row düğümü (konum 2.1)
        Text("Başlık")         // Text düğümü (konum 2.2)
        Icon(...)                // Icon düğümü (konum 2.3)
    }
}

Bu örnekte, her çağrı koddaki sıraya göre bir konum alır. Column (konum 1) üç alt düğüm içerir (konum 2, 3, 4). HeaderSection iki alt düğüm daha ekler (2.1, 2.2, 2.3). Bir sonraki yeniden oluşturmada ContentSection, HeaderSection'dan önce çağrılırsa, Composer düğümleri doğru şekilde eşleştiremez — dolayısıyla kural: Composable işlev çağrılarının sırası istikrarlı olmalıdır.

Composition'da Durum Yönetimi

Composition'daki durum, State<T> türündeki nesneler aracılığıyla yönetilir. Bir Composable işlev, yetki devredilmiş bir özellik (by) aracılığıyla State'ten bir değer okuduğunda, bu State'e bir bağımlılık kaydeder. Değer değiştiğinde, bu State'i okuyan tüm işlevler bir sonraki kompozisyon aşamasında yeniden başlatılmak üzere işaretlenir.

Bağımlılık kaydetme mekanizmasına anlık görüntü sistemi denir. State her değiştiğinde, bir anlık görüntü tüm değişiklikleri kaydeder ve hangi işlevlerin bu State'e bağlı olduğunu Composer'a bildirir. Anlaşılması önemlidir: Composable olmayan kod içinde (örneğin, bir onClick lambda'sında) State okumak bağımlılık kaydetmez — yalnızca bir Composable işlev içinde veya kompozisyon bağlamında yürütülen lambdalarda okuma bağımlılık kaydeder.

Anlık görüntü sistemi işlemsel olarak çalışır: tek bir olay içindeki birden çok State değişikliği, birden çok yeniden oluşturmayı önleyen tek bir işlemde birleştirilir. Bu, özellikle jestleri işlerken önemlidir: tek bir hareket birden çok State nesnesini değiştirir, ancak Compose yalnızca bir yeniden oluşturma gerçekleştirir.

@Composable
fun StateExample() {
    var text by remember { mutableStateOf("Hello") }
    var isVisible by remember { mutableStateOf(true) }

    Column {
        Text(text)  // metne bağımlılık kaydeder

        if (isVisible) {  // isVisible'a bağımlılık kaydeder
            TextField(value = text, onValueChange = { text = it })
        }

        Button(onClick = { isVisible = !isVisible }) {
            Text(if (isVisible) "Gizle" else "Göster")
        }
    }
}

Metni değiştirmek yalnızca Column, Text ve TextField'ın yeniden oluşturulmasını tetikler. Column, Button ve isVisible koşulu değişmeden kalır. Yeniden oluşturmanın bu izolasyonu, tüm ekranı yeniden çizen sistemlere kıyasla Compose'un önemli bir avantajıdır. Her Composable işlev, yalnızca doğrudan okuduğu State nesnelerini izler.

Composition vs Recomposition: Temel Farklar

Composition ve Recomposition, Composable işlevleri yürütmenin iki farklı modudur. Composition, ekran oluşturulduğunda bir kez gerçekleşir: sistem tüm Composable işlevleri başlangıç değerleriyle yürütür ve ilk UI ağacını oluşturur. Recomposition, veriler değiştiğinde birden çok kez gerçekleşir: sistem yalnızca değişen duruma bağımlı olan işlevleri yeniden başlatır.

Mod Composition, tüm ağaç düğümlerini etkinleştirir, her işlev için slotlar ayırır ve tüm alt öğeleri kaydeder. Recomposition seçici olarak çalışır: Compose, her işlevin yeni ve eski parametre değerlerini karşılaştırır ve değişmemişlerse — işlev yürütülmez (atlanır).

Composition ve Recomposition maliyet açısından farklılık gösterir. İlk Composition, tam ağaç oluşturma ve slot tahsisi gerektirdiği için daha pahalıdır. Recomposition daha ucuzdur, özellikle çoğu işlev kararlıysa — parametreleri equals ile karşılaştırılır ve Compose çağrılarını atlar. Maksimum performans için, çoğu yeniden oluşturmanın mümkün olduğunca az işlevi etkilemesi hedeflenmelidir.

CompositionLocal: Ağaç Boyunca Veri İletme

CompositionLocal, kompozisyon ağacı boyunca örtük olarak veri iletmek için bir mekanizmadır. Bir parametrenin onu doğrudan kullanmayan düzinelerce iç içe Composable işlev aracılığıyla iletilmesi gerektiğinde sorunu çözer. Açık bir parametre zinciri yerine, veriler en üst düzeyde ayarlanır ve CompositionLocal.current aracılığıyla herhangi bir iç içe işlevde okunur.

MaterialTheme, CompositionLocal'ın en bilinen örneğidir. Tüm Compose bileşenleri, renkleri, tipografiyi ve şekilleri MaterialTheme.colorScheme, MaterialTheme.typography, MaterialTheme.shapes aracılığıyla okur, parametreler aracılığıyla almaz. Geliştiriciler, geçerli kullanıcı, yerelleştirme ayarları veya ekran yapılandırması gibi veriler için kendi CompositionLocal'larını oluşturabilir.

Önemli bir sınırlama: CompositionLocal, sık sık değişen veriler (kaydırma konumu, giriş alanındaki metin) için kullanılmamalıdır. CompositionLocal okuyan bir bileşen, değer her değiştiğinde yeniden başlar, bu nedenle dinamik veriler için açık parametreler veya State kullanmak daha iyidir. CompositionLocal, nadiren veya hiç değişmeyen yapılandırma verileri için idealdir.

val LocalUser = compositionLocalOf<User?> { null }

@Composable
fun AppRoot(user: User, content: @Composable () -> Unit) {
    CompositionLocalProvider(LocalUser.provides(user)) {
        content()
    }
}

@Composable
fun UserAvatar() {
    val user = LocalUser.current  // açık parametre olmadan okuma
    AsyncImage(model = user?.avatarUrl, contentDescription = "Avatar")
}

CompositionLocalProvider, LocalUser.current'in belirtilen değeri döndürdüğü bir kapsam oluşturur. UserAvatar, parametreyi ara işlevler aracılığıyla açıkça iletmeden kullanıcıyı okur. Bu, verilerin yalnızca birkaç yaprak düğümde gerekli olduğu derin hiyerarşilerde özellikle değerlidir.