Lightbuild ile açıklayıcı, temsilciye hazır Android derlemeleri

Herkese merhaba.

Adım Juan Sebastian Oviedo.

Android Geliştirici Deneyimi Ekibi'nde ürün müdürü olarak çalışıyorum.

Bugün Scott ile birlikte, Android uygulamaları için yeni ve deneysel bir derleme deneyimi olan Lightbuild'e erken bir bakış sunmaktan heyecan duyuyoruz.

Bu projenin bağlamını, arkasındaki felsefeyi ve Android projelerinin yapılandırılma şeklini yeniden düşünmek için neden doğru zamanın geldiğini düşündüğümüzü ele alacağım.

Ayrıca bu yeni yaklaşımın bizi Android uygulama geliştirmenin geleceğine nasıl hazırladığını da ele alacağım.

Öncelikle, mevcut durum hakkında bilgi verelim.

Gradle ve zorunlu derleme komut dosyaları, geliştiricilere derlemeleriyle ilgili hemen her şeyi programatik olarak tanımlama olanağı sunar.

Örneğin, Git geçmişine göre sürüm kodlarını dinamik olarak hesaplayan bir mantık kullanabilir veya öğeleri dönüştüren özel bir görev tanımlayabilirsiniz.

// build.gradle.kts
android {

  compileSdk = 37

  buildTypes {

    debug {

      // Custom logic in build script
      val commit = providers.exec {
        commandLine("git", "rev-parse",
                    "--short", "HEAD")
      }.standardOutput.asText.get()
       .trim()

      versionNameSuffix = "-$commit"

    }

  }

}

Gradle'ın yanı sıra, Gradle'ın genel amaçlı motorunu alıp Android araç zincirine uyarlayan AGP veya Android Gradle eklentisi de vardır.

Gradle ve AGP, günümüzde milyonlarca üretim uygulamasının derleme yapılandırması deneyimini destekleyen dinamik bir sistem oluşturur.

Bu esneklik nedeniyle geliştirici araçlarımız belirli bir mimari yaşam döngüsü içinde çalışır.

Bir projeyi açtığınızda, dallar arasında geçiş yaptığınızda veya bir derleme dosyasını düzenlediğinizde IDE'nin proje yapılandırmanızın net bir haritasına ve net bir anlayışına sahip olması gerekir. Böylece kod tamamlama ve kodda gezinme gibi özellikleri destekleyebilir.

Derleme dosyaları, Turing-complete özellikli bir dilde yazıldığından IDE'nin yapılandırmayı öğrenmesinin tek genel yolu, derleme komut dosyalarını çalıştırmaktır.

IDE senkronizasyonu sırasında derleme sistemi bir yapılandırma aşamasından geçer.

Derleme komut dosyalarınızı değerlendirir, eklenti mantığını yürütür ve proje modelini oluşturur.

Bu işlem, Android Studio'nun projenizle ilgili görünümünü gerçek proje yapılandırmanızla uyumlu hale getirir.

Geliştiriciler olarak en çok önem verdiğiniz şey, mükemmel bir Android uygulaması sunmak ve bunu kullanıcılarınıza ulaştırmaktır.

Ancak derleme komut dosyalarını yönetmek, AGP'yi güncel tutmak ve projeyi IDE ile senkronize etmek zaman ve çaba gerektirir.

Hem Google'da hem de daha geniş ekosistemde bu alandaki geliştirici deneyimini iyileştirmeye yönelik çeşitli girişimler var.

Declarative Gradle ve Kotlin araç zinciri gibi girişimler, yürütülebilir derleme komut dosyalarını açıklayıcı derleme yapılandırmasıyla değiştirmeyi amaçlar.

Android Studio'da, AGP'nin bir sürümünden diğerine geçmek için gereken değişiklikler konusunda size yol gösteren AGP Yükseltme Asistanı bulunur.

Ayrıca, temsilcilerin AGP'yi yükseltmek için yükleyip uygulayabileceği bir yükseltme becerisi de sunuyoruz.

Ayrıca, geliştiricilerin projelerini senkronize ederken ve içe aktarırken daha iyi bir deneyim yaşamaları için aşamalı senkronizasyon ve esnek senkronizasyon gibi alanlara yatırım yapıyoruz.

Bu çalışmaların her biri, geliştiricilerin uygulamalarını oluşturmaya daha fazla, projelerini oluşturmaya, derleme dosyalarını yönetmeye ve projelerini senkronize etmeye daha az zaman ayırabilmesi için yapbozun bir parçasını hedefliyor.

Bu çalışmaların yanı sıra kendimize daha kapsamlı bir soru sorduk.

Projelerin yapılandırılma şeklini sıfırdan yeniden tasarlasaydık nasıl olurdu?

Günümüzdeki modern Android uygulamalarının mimarisine baktığımızda, yoğun modülerleştirmeye doğru büyük bir geçiş olduğunu görüyoruz.

Büyük kod tabanlarında genellikle onlarca, hatta yüzlerce modül bulunur: kullanıcı arayüzü modülleri, özellik modülleri, alan modülleri ve veri modülleri.

Kök uygulamanın zaman zaman özel paketlemeye ihtiyacı olsa da bu kitaplık modüllerinin büyük çoğunluğu standartlaştırılmış, tekrarlanabilir bir kalıba uyar.

Derleme dosyalarında rastgele yürütülebilir kod bulunması gerekmez.

Tek ihtiyaçları, yapılarını ve bağımlılıklarını net bir şekilde ifade etmektir.

Bu gözlem, Lightbuild'i geliştirmemize yol açtı.

Lightbuild iki temel üzerine kuruludur.

İlk olarak, yapılandırma için bildirim temelli bir söz dizimi kullanır. Bu sayede, derleme yapılandırması ile mantık arasında net bir ayrım sağlar.

İkinci olarak, önceden bağımlılık çözümü sayesinde hızlı bir IDE senkronizasyonu deneyimi sunar.

Günlük iş akışınızı nasıl etkilediklerini görebilmeniz için bu temel unsurların her birini ayrıntılı olarak ele alacağım.

Bildirim temelli derleme yapılandırmasıyla başlayalım.

Ekranın sol tarafındaki dosyaya bakın.

Bu, bir modülün mevcut yapılandırmasını temsil eder.

// build.gradle.kts

plugins {
   alias(libs.plugins.android.library)
   alias(libs.plugins.kotlin.compose)
}

val gitCommit = providers.exec {
   commandLine("git", "rev-parse", "--short", "HEAD")
}.standardOutput.asText.get().trim()

android {
   namespace = "com.example.app"
   compileSdk = 37

   defaultConfig {
       minSdk = 24
       buildConfigField("String", "GIT_COMMIT",
                        "\"$gitCommit\"")
   }
   buildFeatures {
        compose = true
        buildConfig = true
   }
}

dependencies {
  implementation(platform(libs.androidx.compose.bom))
  implementation(libs.androidx.compose.ui)
  implementation(libs.androidx.compose.ui.graphics)
  ...

Bu dosya yürütülebilir kod olduğundan yerel değişken tanımları, özel yardımcı işlevlere veya kural eklentilerine çağrılar, koşullu ifadeler ve satır içi görev tanımları içerebilir.

IDE'nin bu yapılandırmanın neyi çözdüğünü bilmesi için komut dosyasını çalıştırması gerekir.

Şimdi ekranın sağ tarafındaki dosyaya bakın.

Bu, benzer bir modülün Lightbuild yapılandırmasıdır.

# lightbuild.yaml

group: "com.example"
version: "1.0.0"

platform: android
type: library

android:
 namespace: "com.example.app"
 compileSdk:
   version:
     release:
       apiLevel: 37
 minSdk:
   version:
     release:
       apiLevel: 24
 dependencies:
   maven:
     - androidx.core:core-ktx:1.10.1
     - androidx.lifecycle:lifecycle-runtime-ktx:2.6.1
     - androidx.activity:activity-compose:1.8.0

Bu dosya tamamen bildirim amaçlı veriler içerir.

Yerel değişken tanımları, özel yardımcı işlevlere yapılan çağrılar, koşullu ifadeler veya satır içi görev tanımları yoktur.

Modülün türünü, SDK hedeflerini ve bağımlılıklarını açıkça belirtir.

Ekibinize yeni bir mühendis katılır ve bu dosyayı açarsa çözmesi gereken özel derleme deyimleri olmaz. Her Lightbuild projesindeki her Lightbuild modülü, hemen okunabilen aynı dili kullanır.

Yapılandırma ve mantık arasındaki ayrım, insanlar tarafından okunabilirliği artırmanın yanı sıra temsilci destekli iş akışları için de daha dönüştürücü bir etkiye sahiptir.

Geliştiriciler iş akışlarında temsilcileri kullanmaya başladıkça bu temsilcilerin derleme yapılandırmasını okuyabilmesi ve değiştirebilmesi gerekir.

Ancak projeyi gerçekten derlemeden yapılandırma değişikliğinin yan etkilerini tahmin etmenin bir yolu yoktur.

Yapılandırma dosyasına tek bir satır eklemek, projenin başka bir yerindeki dinamik olarak hesaplanan bir değişkenle veya bir kural eklentisiyle çakışabilir.

Lightbuild'de projenizin yapılandırması, deterministik ve statik bir veri grafiğidir.

Bu sayede temsilciler, grafiği inceleyebilir, modül topolojisini anlayabilir ve bilinen bir şemayı kullanarak değiştirebilir.

Temsilci, yapılandırılmış verileri okuyup yazarak modül listesini, bağımlılık listesini ve sürümlerini görebilir, bağımlılıkları güncelleyebilir, hatta yepyeni bir özellik modülü ekleyebilir.

Projenizin yapılandırmasını, temsilci destekli iş akışları için birinci sınıf bir vatandaş haline getirir.

Bu noktada vurgulamak istediğim bir diğer ayrıntı da Lightbuild'in bir derleme sisteminin eklentisi değil, derleme motorunun arayüzü olmasıdır.

Bugün yayınladığımız Lightbuild önizleme sürümü, yürütme motoru olarak Gradle'ı kullanır.

Ancak Lightbuild ile izlediğimiz mimari yaklaşım, IDE olan Android Studio'nun projeyi Lightbuild projesi olarak görmesini ve ele almasını sağlar.

Şimdi, geliştirici üretkenliği ve akışıyla ilgili olan ikinci temel unsuru inceleyelim: hızlı IDE senkronizasyonu.

Geliştiriciler iş akışlarının bir parçası olarak temsilcileri kullansa da Android Studio, etkileşimli görevler için önemli bir araç olmaya devam ediyor. Örneğin, Oluştur kullanıcı arayüzü önizlemelerini incelemek, bir sorunu araştırırken hata ayıklayıcıda kodda adım adım ilerlemek veya profil oluşturucu ile performansı analiz etmek için Android Studio'yu kullanabilirsiniz.

Projenizin yapılandırması deterministik, statik bir veri grafiği olduğundan IDE'nin projenizi anlamak için bir komut dosyası değerlendirme aşamasından geçmesi veya eklenti kodu yürütmesi gerekmez.

İster bir proje açın, ister bir derleme dosyasını düzenleyin veya dallar arasında geçiş yapın, IDE bu bilgileri hızlıca işleyebilir ve sizi doğrudan araçlarınıza yönlendirebilir.

Bu hız ve güvenilirliğin mümkün olmasının nedenlerinden biri, Lightbuild'in bağımlılıkları işleme şeklidir.

Normalde bir bağımlılık beyan ettiğinizde derleme sisteminin, sürüm bilgilerini toplamak ve çakışmaları çözmek için geçişli bağımlılıklar ağacından geçmesi gerekir.

Lightbuild'de bağımlılıklarınız her değiştiğinde araç, geçişli bağımlılık bilgilerini otomatik olarak hesaplar ve her modül dizinindeki bir resolved.deps dosyasına yazar.

Bu sayede, proje gelecekte tekrar açıldığında veya yeniden derlendiğinde ne IDE'nin ne de derleme aracının bu geçişli bağımlılık bilgilerini yeniden hesaplaması gerekir.

Bu dosyaları kaynak denetimine eklemenizi öneririz. Böylece, değişiklikleri ekip arkadaşlarınıza incelemeleri için gönderdiğinizde, geçişli bağımlılık bilgilerinde herhangi bir değişiklik olup olmadığını görebilirler ve makinelerinin bu geçişli bağımlılık bilgilerini yeniden hesaplaması gerekmez.

Ayrıca, bu bilgileri kaynak denetimine ekleyerek sizin, ekip arkadaşlarınızın ve CI/CD ardışık düzenlerinizin her seferinde aynı bağımlılık sürümleriyle derleme yapmasını sağlarsınız.

Lightbuild'in Android Studio Canary'de ve bağımsız CLI araçları aracılığıyla erken erişim olarak kullanılabileceğini duyurmaktan heyecan duyuyoruz.

Lightbuild'in bu sürümü deneysel olduğundan, bir üretim uygulaması oluşturmak ve sürdürmek için ihtiyacınız olan tüm özelliklere sahip değildir.

Lightbuild'i demo ve deneysel projelerde denerken üretim uygulamalarınız için AGP ve Gradle'ı kullanmaya devam edin.

goo.gle/lightbuild adresine giderek hemen kullanmaya başlayabilirsiniz. Ürünü geliştirirken şekillendirmemize yardımcı olacak geri bildirimlerinizi bekliyoruz.

Şimdi sunumu Scott'a devrediyorum. Lightbuild'i uygulamalı olarak gösterecek.

Teşekkürler, Can.

Adım Scott Myers.

Android Geliştirici İlişkileri Mühendisi olarak bir süredir Lightbuild üzerinde çalışıyoruz. Bugün bu aracı nasıl kullanabileceğinizi ve deneyebileceğinizi göstermekten heyecan duyuyoruz.

Bu nedenle, ilk olarak Juan'ın bahsettiği goo.gle/lightbuild bağlantısına gitmeniz veya Lightbuild'i aramanız gerekir.

Bu bağlantı sizi, başlamak için gereken tüm adımları içeren bu doküman sayfasına yönlendirecek. Bu adımlar arasında Android Studio'nun Canary sürümünü yüklemek de var. Unutmayın, bu özellik henüz önizleme aşamasında, Android Studio'nun kararlı sürümünde henüz mevcut değil.

Ayrıca Lightbuild ile temsilci tabanlı deneyimin tüm avantajlarından yararlanmak için yükleyebileceğiniz bir Lightbuild CLI da vardır.

Bu kurulumu tamamladıktan sonra, benim makinemde olduğu gibi en son Android Studio Canary sürümünü çalıştırabilirsiniz.

Şimdi bir demo Lightbuild projesi oluşturma adımlarını inceleyelim. Bu adımları bugün bile uygulayabilirsiniz.

Öncelikle Yeni Proje sihirbazına gideceğim.

Boş Etkinlik'i seçip İleri'yi tıklayacağım.

Şimdi bunun normal proje ayrıntıları ekranı olduğunu göreceksiniz ancak alt kısımda yeni bir seçenek var.

Derleme yapılandırması dili bölümünde Lightbuild'i seçebilirsiniz.

"Bitir"e basmadan önce bu özelliğin deneysel olduğunu hatırlatır.

Projemizin IDE ile senkronize edildiğini ve çalışmaya hazır olduğunu hemen göreceksiniz.

Şimdi tipik bir Lightbuild projesinin proje yapısına göz atalım.

Bu, yeni bir uygulama oluştururken gördüğünüz varsayılan Android şablonudur.

Sadece "Hello, world!" yazıyor.

Bu nedenle, başlamak için basit bir yöntemdir.

Projemizin kök düzeyinde project.lightbuild.yaml adlı bir dosya olduğunu göreceksiniz.

Bu sayede tüm projemiz için genel ayarları elde ederiz.

Yani projenize bir ad verebilir, projenizdeki tüm modülleri listeleyebilir, bağımlılıklarınızı hangi harici depolardan çektiğinizi belirtebilir ve ardından projenizin farklı bölümlerine genel olarak uygulanan sürümleri burada belirtebilirsiniz.

Burada app ve app-core olmak üzere iki modülümüz olduğunu görüyoruz.

Bunun nedeni, tüm Lightbuild projelerinde en az iki modül bulunmasıdır.

Bunun nedeni, en az bir uygulama modülü ve en az bir kitaplık modülü olması gerektiğidir.

Bunun nedenini birazdan açıklayacağım.

Öncelikle bu uygulama modülüne göz atalım.

Burada genişlettiğimde, modülün kök düzeyinde her modülde bulunan bir lightbuild.yaml dosyası olduğunu görürsünüz.

Burada bazı temel bilgiler yer alır.

Android platformu üzerinde çalışıyoruz.

Bu modül, uygulama türündedir.

SDK hedef sürümlerinizi, uygulama kimliğinizi vb. listeleyebilir ve ardından bu uygulama modülünün bağlı olduğu tüm modülleri listeleyebilirsiniz.

Bu uygulama modülünün standart Android şablonundan biraz farklı olan ilginç bir özelliği, kaynak klasöründe hiçbir şey olmamasıdır.

Bu nedenle, Lightbuild'de uygulama modülleri kaynak kodu içermez.

Bunun nedeni, bu uygulama modülünün çok sık değişmeyecek olması ancak derlenmesinin biraz zaman almasıdır.

Dolayısıyla, tüm uygulama kodunuzu kitaplık modüllerinizde tutarsanız her derleme daha hızlı gerçekleşir. Çünkü uygulama modülündeki her şeyi yeniden hesaplaması ve yeniden paketlemesi gerekmez.

Şimdi de bu uygulama modülünün bağlı olduğu kitaplık modülü olan app-core modülüne göz atalım.

Bu modülde kaynak kodu olduğunu görebilirsiniz.

Ana mantığımız burada yer alıyor.

Sadece "Hello, world!" yazıyor.

Bu modüldeki lightbuild.yaml dosyasına bakarsak türünün kitaplık olduğunu görebilirsiniz.

Burada bazı SDK sürüm numaralarını da ayarlıyor ancak bu modülde sahip olduğumuz tüm harici bağımlılıkları listeliyor.

Ayrıca birim ve enstrümantasyon testlerimizi de tanımlar.

Şimdi burada fark etmiş olabileceğiniz başka bir dosyaya göz atalım. Juan da bundan biraz bahsetmişti. Her modülün içinde bir resolved.deps dosyası var.

Bu dosya, Lightbuild tarafından otomatik olarak oluşturulur.

Bu nedenle, dosyayı manuel olarak düzenlememeniz gerekir. Dosyada, bu modüldeki tüm çözümlenmiş bağımlılıkların listesi yer alır.

Yani tüm bağımlılıklarınız ve geçişli bağımlılıklarınız zaten burada.

Yani uygulamanız IDE'de açıldığında veya derleme yapacağınız zaman bunu çözmeniz gerekmez. Çünkü bu işlem önceden yapılmış ve projenize eklenmiştir.

Şimdi de Lightbuild'in proje senkronizasyonuyla geliştirici deneyimini nasıl iyileştirdiğine dair bir örneğe bakalım.

Şimdi kök düzeyindeki project.lightbuild.yaml dosyama geri döndüm. Burada uygulamamdaki tüm modülleri listeleyen genel ayarlar bulunuyor.

Normalde yapılandırma veya derleme yapılandırması dosyalarını düzenlerken bir senkronizasyon düğmesi görürsünüz. Juan'ın bahsettiği işlemler nedeniyle bu düğmeye basıldığında tüm işlemlerin tamamlanması biraz zaman alır. Bu işlemler, tüm derleme komut dosyalarınızı çalıştırarak kısmi bir derleme yapmayı ve ardından bu modeli IDE ile senkronize etmeyi içerir.

Bu küçük proje için oldukça büyük bir değişiklik yapalım.

Modüllerden birini sileceğiz.

Kaydet düğmesine basmadan önce bu modülün IDE tarafından tanındığını görebilirsiniz. Çünkü burada kalın harflerle yazıldığını görebilirsiniz.

Kaynak dizini ve test dizinlerini tanıdı.

Değişikliği yaptıktan sonra kaydet düğmesine bastığımda bu modülün projeden anında kaldırıldığını görebilirsiniz.

Bu değişikliği tekrar geri alıp kaydet'i tıklarsam aynı hızda geri yüklenir.

Lightbuild'in projelerinize getirdiği hızlı IDE senkronizasyonuna bir örnek verdik.

Ayrıca Android Studio'da alışık olduğunuz tüm normal komutları da kullanabilirsiniz.

Çalıştır düğmesine basabilirsiniz.

Uygulamanızı derleyip burada çalıştırır.

Bu demo uygulaması çok büyük değil ancak "Hello Android" yazdığını göstermek için yakınlaştıracağım.

Testlerinizi normalde yaptığınız gibi test dosyanıza gidip bu şekilde boşluktan çalıştırabilirsiniz.

Bu testleri çalıştırmak için arka planda Lightbuild'i çağırıyor.

Yani tüm bunlar beklediğiniz gibi çalışır.

Şimdi de Android Studio'da değilseniz ve başka bir temsilci tabanlı akış kullanıyorsanız Lightbuild'i nasıl kullanacağınızı göstermek istiyorum.

Bunun için komut satırını kullanırız.

Lightbuild'in komut satırı arayüzünde temel yardım komutunu çalıştıracağım.

Bu projede gördüğünüz tüm yazım hataları bana ait.

Lightbuild'de yerleşik olarak bulunan birkaç farklı komut olacak. Örneğin, "Oh, sorry, I'm running this outside of a project." (Pardon, bunu bir projenin dışında çalıştırıyorum.)

Sürekli bunu söylüyor.

Evet, canlı demo.

Öncelikle Lightbuild komutlarını çalıştırmadan önce bir Lightbuild projesi oluşturayım.

Bunun için yeni proje şablonları oluşturmaya yönelik standart komut satırı aracımız olan android create'i kullanacağım.

empty-activity-lightbuild şablonunu kullanacağım ve uygulamama Lightbuild Demo adını verip demo çıkış dizinine yerleştireceğim.

Şimdi bu dizine girip lightbuild -h yazarsam Lightbuild'in kullanabileceği tüm farklı komutları görürüm.

Bu nedenle, beklediğiniz birçok şey var: derleme, temizleme, test etme.

Ancak birkaç yeni özellik daha var.

Projenizin bağımlılıklarını çalıştıran ve daha önce gösterdiğim resolved.deps dosyalarını oluşturan bir çözümleme komutu vardır.

Ayrıca, sizin ve temsilcilerinizin projenizin yapısını daha iyi anlamanızı sağlayan bir sorgu komutu da vardır.

Öncelikle yeni sorgu komutunu göstereyim.

Komut satırını kullanarak bu projenin yapısına bakarsam Android Studio demosundakiyle aynı olduğunu görürüm.

Ancak bu, projemin nasıl düzenlendiği hakkında bana pek bir şey söylemiyor.

Lightbuild sorgusu yapıp bu uygulama modülüne bakarsam ve "Bu uygulama modülündeki her şeyi göster" demek için bu özel söz dizimini kullanırsam

Uygulama modülünde oluşturabileceğim farklı hedeflerin yer aldığı bu güzel tabloyu gösteriyor.

Bu nedenle, hem hata ayıklama hem de sürüm ikili dosyaları için APK'lar ve AAB'ler içerir.

Yalnızca uygulama hedefini çalıştırırsam her şeyi derler.

Çıkışı JSON olarak belirtmenin bir yolu da vardır.

Böylece, pardon.

Yine, bugün yaptığım tüm yazım hataları gerçek.

Bu işlemi doğru şekilde yaptığımı kontrol etmek için etkileşimli Lightbuild yardımını kullanayım.

İlginç…

Evet, çalışıyor olması gerekir.

İşte böyle.

Neyi yanlış yaptığımı söyleyebilecek biri varsa lütfen bu konuşmadan sonra benimle iletişime geçsin.

Ancak bu tablo yerine Lightbuild komutlarınızı JSON olarak da çıkarabilirsiniz. Bu, temsilcileriniz için daha kolaydır.

--format json…

Biçim.

Pardon.

Teşekkür ederiz.

Bu, canlı geliştirici geri bildirimidir.

Teşekkür ederiz.

Evet, doğru. Bir de çıkış komutu var. Belki sizin yardımınızla onu da gösterebilirim.

Yani hedefler yerine dosyaları çıkış olarak alırsam derlememdeki tüm farklı ikili dosyaların konumlarını görebilirim.

Bu sayede siz ve temsilcileriniz, Lightbuild'i kullanarak komut satırından projenizi daha iyi keşfedebilir ve anlayabilirsiniz.

Daha sonra, daha önce bahsettiğim lightbuild resolve komutuyla tüm resolved.deps dosyalarınızı oluşturabilirsiniz.

Bu sürümde bazı ek özellikler de bulunur.

Örneğin, kilitli bağımlılıklar parametresi var. Bu parametre sayesinde, yalnızca bu dosyaları oluşturmak yerine, dosyaların içeriğini derleme yapılandırmanızda beyan ettiğiniz bağımlılıklarla karşılaştırır.

Herhangi bir fark varsa sizi bilgilendirir ve derleme başarısız olur.

Bu şekilde, çözümlenmiş bağımlılık dosyaları kilit dosyaları olarak kullanılabilir. Örneğin, uygulamanızı üretim için bir CI/CD sisteminde oluşturuyorsanız bu derleme sırasında herhangi bir bağımlılığın değişip değişmediğini bilmek istersiniz.

Ayrıca Lightbuild'de yerleşik bir test özelliği de var. Bu kitaplık modülündeki tüm testleri doğrudan komut satırından çalıştırabilirsiniz.

Göstermek istediğim bir şey daha var.

Ayrıca, kullanabileceğiniz tüm parametrelerin ve alt komutların tüm derlemelerinin eksiksiz bir listesini sunan yardım özelliği de vardır.

Bu, temsilciniz için kullanılabilir. Bu nedenle, temsilcinin çıkışı budur.

İşte böyle.

Lightbuild ile bazı basit projeleri gördüğümüze göre, şimdi biraz daha iddialı bir projenin nasıl göründüğünü göstermek istiyorum.

Android ekibi tarafından sunulan Now in Android adlı örnek bir uygulamamız var. Bu uygulama, en yeni Android özelliklerinden bazılarını sunuyor, bunları nasıl kullanacağınızı gösteriyor ve bazı en iyi uygulamaları paylaşıyor.

Bu, son derece modüler bir uygulamadır.

Sanırım 32 farklı modüle ayrılmış.

GitHub'da bu şekilde görünür.

Ancak Android Studio'ya geri döneceğim. Burada, temsilcimi önceden kullandım.

Now in Android projesini Lightbuild'e dönüştürmek için Gemini Argon'u kullanıyordum.

Yani bu yayınladığımız bir şey değil, sadece kendi başıma yaptığım bir şey.

project.lightbuild.yaml projemde tüm bu farklı modüller olmasına rağmen inanılmaz hızlı açıldığını ve bu IDE ile çok hızlı bir şekilde senkronize edildiğini görebilirsiniz.

Bu projeyle ilgili dikkat etmeniz gereken bir diğer nokta da hem demo hem de prod derlemesi oluşturmak için bazı derleme varyantları veya özel derleme yapılandırmaları kullanmasıdır. Bu derlemelerin her biri, uygulamayı biraz farklı bir şekilde sunar.

Demo sürümünde yerleşik veri kaynakları kullanılırken üretim sürümü ağa bağlanıp verileri çeker.

Lightbuild'de farklı derleme yapılandırmaları veya ürün türleri gibi öğeleri yönetmek için uygulama modülünüze gidip bu uygulama modülünün, örneğin demo uygulaması olduğunu belirtirsiniz.

Bu nedenle, tüm temel bileşenleri kullanır ancak uygulamanın yalnızca demo sürümü için özel ayarları da alır.

Bu sayede birden fazla uygulama modülünüz olabilir.

Her biri, uygulamanızın ücretli veya ücretsiz sürümünü temsil edebilir.

Ayrıca, uygulama modülünün içinde kod bulunmayan boş bir kabuk olmasının avantajlarından yararlanmaya devam edersiniz. Bu sayede, uygulama modülü çok daha hızlı oluşturulur ve kitaplıklarınız değiştiğinde uygulamanızı yeniden oluşturmak için yalnızca bu kitaplıkların yeniden derlenmesi gerekir.

Şimdi de Now in Android uygulamasının 32 farklı modülünün tamamıyla Lightbuild kullanılarak başarıyla derlenip derlenmediğine bakalım.

Evet, işte burada.

Bu tür denemelerden öğrendiğimiz bir diğer şey de Lightbuild'in ihtiyacınız olabilecek her derleme özelliğini her zaman desteklemediğidir.

Örneğin, Now in Android uygulaması, Hilt'i kullanmak için bir Hilt eklentisine ihtiyaç duyar. Lightbuild henüz bu tür bir desteğe sahip değildir.

Temsilcim, bu sorunu çözmek için bir geçici çözüm buldu ve projedeki kodun çoğunu değiştirmeden Hilt desteğini ekledi.

Örneğin, tüm bu modüllerdeki kodlar orijinal depodakiyle aynı.

Ancak Lightbuild'i kendiniz denerken ve demo yaparken kesinlikle aklınızda bulundurmanız gereken bir şey var: Mevcut projenizdeki her şey derleme yapılandırması açısından desteklenmeyecek.

Bu nedenle Lightbuild, Android Studio Canary'de hâlâ önizleme aşamasında.

Şimdi slaytlara geri dönelim.

Evet, konuştuklarımızı özetlemek gerekirse Android için yeni bir derleme platformu olan Lightbuild'i unutmayın. Şu anda deneysel aşamada.

Bildirim temelli bir derleme yapılandırması vardır. Bu sayede, derleme yapılandırmalarınızda yürütülebilir kod çalıştırmazsınız. Bu da hızlı IDE senkronizasyonu ve daha verimli derlemeler gibi birçok harika özelliğin kilidini açar.

Birinci sınıf yapay zeka ajanı desteği sunuyor. Komut satırında, bugün göstermeme yardımcı olduğunuz tüm özellikler var.

Bu nedenle, sizi bu özelliği denemeye ve demo ve deneysel projeler için kullanmaya davet ediyoruz.

Juan ve ben, ekibimizdeki mühendislerle birlikte sorularınızı yanıtlamak için ajan tabanlı yapay zeka standında olacağız.

Çok teşekkür ederim.