ساخت‌های Android اعلانی و آماده عامل با Lightbuild

سلام به همه.

نام من خوان سباستین اویدو است.

من مدیر محصول در تیم «تجربه توسعه‌دهنده Android» هستم.

من اینجا با اسکات هستم و امروز خوشحالیم که نگاهی اولیه به Lightbuild، یک تجربه ساخت آزمایشی جدید برای برنامه‌های Android، را با شما به‌اشتراک بگذاریم.

من زمینه این پروژه، فلسفه پشت آن، و اینکه چرا معتقدیم اکنون زمان مناسبی برای بازنگری در نحوه پیکربندی پروژه‌های Android است را بررسی خواهم کرد.

همچنین توضیح خواهم داد که چگونه این رویکرد جدید ما را برای آینده توسعه برنامه Android آماده می‌کند.

بیایید با چند بافت درباره نحوه عملکرد چیزها درحال‌حاضر شروع کنیم.

Gradle و اسکریپت‌های ساخت امری به توسعه‌دهندگان این امکان را می‌دهند که تقریباً هر چیزی را درباره ساخت‌هایشان به‌صورت برنامه‌ریزی‌شده تعریف کنند.

برای مثال، می‌توانید منطقی داشته باشید که کدهای نسخه را به‌طور پویا براساس سابقه Git محاسبه کند، یا تکلیف سفارشی‌ای تعریف کنید که دارایی‌ها را تبدیل کند.

// 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،‏ AGP یا افزایه Android Gradle وجود دارد که موتور چندمنظوره Gradle را می‌گیرد و آن را با زنجیره ابزار Android سازگار می‌کند.

Gradle و AGP باهم سیستم پویایی را تشکیل می‌دهند که تجربه پیکربندی ساخت را برای میلیون‌ها برنامه تولیدی امروزی تقویت می‌کند.

به‌دلیل این انعطاف‌پذیری، ابزارهای توسعه ما در یک چرخه عمر معماری خاص عمل می‌کنند.

وقتی پروژه‌ای را باز می‌کنید، شاخه‌ها را عوض می‌کنید، یا فایل ساخت را ویرایش می‌کنید، IDE باید نقشه واضح و درک روشنی از پیکربندی پروژه شما داشته باشد تا بتواند ویژگی‌هایی مانند تکمیل کد و پیمایش کد را تقویت کند.

چون فایل‌های ساخت به زبان امری و تورینگ کامل نوشته شده‌اند، تنها راه کلی برای اینکه IDE بداند پیکربندی چیست، اجرای اسکریپت‌های ساخت است.

درطول همگام‌سازی IDE، سیستم ساخت از فاز پیکربندی عبور می‌کند.

این مرحله اسکریپت‌های ساخت را ارزیابی می‌کند، منطق افزونه را اجرا می‌کند، و مدل پروژه را می‌سازد.

این کار نمای Android Studio از پروژه شما را با پیکربندی واقعی پروژه شما هم‌تراز می‌کند.

به‌عنوان توسعه‌دهنده، چیزی که بیش‌از همه برایتان اهمیت دارد ارائه برنامه Android عالی و رساندن آن به دست کاربران است.

اما مدیریت اسکریپت‌های ساخت، به‌روز نگه داشتن AGP، و همگام نگه داشتن پروژه با IDE زمان و تلاش می‌برد.

چندین طرح در Google و اکوسیستم گسترده‌تر وجود دارد که برای بهبود تجربه توسعه‌دهنده در این زمینه تلاش می‌کنند.

ابتکارهایی مانند Declarative Gradle و زنجیره ابزار Kotlin با هدف جایگزینی اسکریپت‌های ساخت اجرایی با پیکربندی ساخت اعلانی انجام می‌شوند.

در Android Studio، «دستیار ارتقای AGP» را داریم که شما را در تغییرات لازم برای رفتن از یک نسخه AGP به نسخه دیگر راهنمایی می‌کند.

همچنین مهارت ارتقایی ارائه می‌دهیم که نمایندگان می‌توانند آن را نصب و دنبال کنند تا AGP را ارتقا دهند.

علاوه‌براین، ما درحال سرمایه‌گذاری در حوزه‌هایی مانند همگام‌سازی مرحله‌ای و همگام‌سازی انعطاف‌پذیر هستیم تا توسعه‌دهندگان تجربه بهتری هنگام همگام‌سازی و وارد کردن پروژه‌های خود داشته باشند.

هرکدام از این تلاش‌ها بخشی از پازل را هدف قرار می‌دهد تا توسعه‌دهندگان بتوانند زمان بیشتری را صرف ایجاد برنامه‌هایشان کنند و زمان کمتری را صرف ساختن پروژه‌هایشان، مدیریت فایل‌های ساخت، و همگام‌سازی پروژه‌هایشان کنند.

در کنار این تلاش‌ها، سؤال گسترده‌تری از خودمان پرسیدیم.

چه می‌شد اگر نحوه پیکربندی پروژه‌ها را از پایه بازطراحی می‌کردیم؟

وقتی به نحوه معماری برنامه‌های مدرن Android درحال‌حاضر نگاه می‌کنیم، شاهد تغییر عمده‌ای به‌سمت مدولارسازی سنگین هستیم.

پایگاه‌های کد بزرگ اغلب ده‌ها یا حتی صدها واحد دارند: واحدهای میانای کاربر، واحدهای ویژگی، واحدهای دامنه، و واحدهای داده.

و اگرچه برنامه ریشه ممکن است گاهی به بسته‌بندی سفارشی نیاز داشته باشد، اکثریت قریب به اتفاق آن ماژول‌های کتابخانه از یک الگوی تکرارپذیر استاندارد پیروی می‌کنند.

آن‌ها درواقع نیازی به داشتن کد اجرایی دلخواه در فایل‌های ساخت خود ندارند.

تنها چیزی که نیاز دارند روشی واضح برای بیان ساختار و وابستگی‌هایشان است.

این مشاهده ما را به ایجاد Lightbuild سوق داد.

Lightbuild بر دو ستون استوار است.

اول اینکه، از نحو اعلانی برای پیکربندی استفاده می‌کند که باعث جداسازی واضح بین پیکربندی ساخت و منطق می‌شود.

و دوم اینکه، ازطریق حل‌وفصل وابستگی پیش‌از موعد، تجربه همگام‌سازی سریع IDE را ارائه می‌دهد.

هریک از این ستون‌ها را با جزئیات بررسی خواهم کرد تا بتوانید ببینید که چگونه بر گردش کار روزانه شما تأثیر می‌گذارند.

بیایید با ستون پیکربندی ساخت اعلانی شروع کنیم.

به فایل سمت راست صفحه نگاه کنید.

این نشان‌دهنده پیکربندی یک ماژول در امروز است.

// 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)
  ...

ازآنجایی‌که این فایل کد اجرایی است، می‌تواند تعاریف متغیر محلی، فراخوانی‌های توابع کمکی سفارشی یا افزایه‌های قراردادی، دستورهای شرطی، و تعاریف وظیفه درون‌خطی داشته باشد.

برای اینکه IDE بداند این پیکربندی به چه چیزی منتهی می‌شود، درواقع باید اسکریپت را اجرا کند.

اکنون به فایل در سمت چپ صفحه‌نمایش نگاه کنید.

این پیکربندی Lightbuild برای یک واحد مشابه است.

# 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

این فایل صرفاً داده‌های اعلانی است.

هیچ تعریف متغیر محلی، هیچ فراخوانی برای توابع کمکی سفارشی، و هیچ عبارت شرطی یا تعریف تکلیف درون‌خطی وجود ندارد.

نوع ماژول، هدف‌های کیت توسعه نرم‌افزار آن، و وابستگی‌های آن را به‌وضوح بیان می‌کند.

اگر مهندس جدیدی به تیم شما بپیوندد و این فایل را باز کند، هیچ اصطلاح ساخت سفارشی‌ای برای رمزگشایی نخواهد داشت و هر ماژول Lightbuild در هر پروژه Lightbuild از همان زبان فوراً خوانا استفاده می‌کند.

درحالی‌که جداسازی بین پیکربندی و منطق برای خوانایی انسان عالی است، برای گردش‌های کاری با کمک عامل حتی تحول‌آفرین‌تر است.

وقتی توسعه‌دهندگان از عوامل به‌عنوان بخشی از گردش کار خود استفاده می‌کنند، این عوامل باید بتوانند پیکربندی ساخت را بخوانند و اصلاح کنند.

بااین‌حال، آن‌ها راهی برای پیش‌بینی عوارض جانبی تغییر پیکربندی ندارند، جز اینکه واقعاً پروژه را بسازند.

افزودن یک خط به فایل پیکربندی ممکن است با متغیر محاسبه‌شده پویا در جای دیگری از پروژه یا با افزونه قراردادی تداخل داشته باشد.

در Lightbuild، پیکربندی پروژه شما یک نمودار داده‌های قطعی و ایستا است.

این یعنی عامل‌ها می‌توانند آن گراف را بازرسی کنند، توپولوژی ماژول را درک کنند، و آن را بااستفاده از یک طرح‌واره شناخته‌شده اصلاح کنند.

یک عامل می‌تواند فهرست واحدها، فهرست وابستگی‌ها و نسخه‌های آن‌ها را ببیند، وابستگی‌ها را به‌روز کند، یا حتی به‌سادگی با خواندن و نوشتن داده‌های ساختاریافته، یک واحد ویژگی کاملاً جدید اضافه کند.

این ویژگی پیکربندی پروژه شما را به یک شهروند درجه یک برای گردش‌های کاری با کمک عامل تبدیل می‌کند.

Another detail that I want to highlight at this point is the fact that Lightbuild is not a plug-in to a build system, but it is an interface to the build engine.

نسخه Lightbuild، پیش‌نمایشی که امروز منتشر می‌کنیم، از Gradle در پشت صحنه به‌عنوان موتور اجرایی خود استفاده می‌کند.

اما رویکرد معماری‌ای که با Lightbuild دنبال کردیم باعث می‌شود که Android Studio، یعنی IDE، پروژه را به‌عنوان پروژه Lightbuild ببیند و با آن رفتار کند.

اکنون بیایید به ستون دوم بپردازیم که کاملاً درباره بهره‌وری و جریان توسعه‌دهنده است: همگام‌سازی سریع IDE.

حتی وقتی توسعه‌دهندگان از عامل‌ها به‌عنوان بخشی از گردش کار خود استفاده می‌کنند، Android Studio همچنان ابزاری ضروری برای کارهای تعاملی باقی می‌ماند، مثلاً برای بررسی پیش‌نمایش‌های Compose UI یا گام‌به‌گام پیش رفتن در کد در اشکال‌زدا به‌عنوان بخشی از بررسی مشکل، یا تحلیل عملکرد با نمایه‌ساز.

چون پیکربندی پروژه شما یک نمودار داده قطعی و ایستا است، IDE نیازی به گذراندن مرحله ارزیابی اسکریپت یا اجرای کد افزونه برای درک پروژه شما ندارد.

چه پروژه‌ای را باز کنید، چه فایل ساختی را ویرایش کنید، یا بین شاخه‌ها جابه‌جا شوید، IDE می‌تواند آن اطلاعات را به‌سرعت پردازش کند و شما را مستقیماً به ابزارهایتان برساند.

یکی از دلایلی که این سرعت و قابلیت اطمینان را ممکن می‌سازد، نحوه مدیریت وابستگی‌ها توسط Lightbuild است.

معمولاً وقتی وابستگی‌ای را اعلام می‌کنید، سیستم ساخت باید از درخت وابستگی‌های متعدی عبور کند تا اطلاعات نسخه را جمع‌آوری کند و تداخل‌ها را حل کند.

در Lightbuild، هرگاه وابستگی‌های شما تغییر کند، این ابزار به‌طور خودکار اطلاعات وابستگی انتقالی را محاسبه می‌کند و آن را در فایل resolved.deps در داخل هر دایرکتوری ماژول می‌نویسد.

این کار باعث می‌شود که وقتی پروژه دوباره در آینده باز می‌شود یا بازسازی می‌شود، نه IDE و نه ابزار ساخت نیازی به محاسبه مجدد اطلاعات وابستگی انتقالی نداشته باشند.

توصیه می‌کنیم این فایل‌ها را در کنترل منبع بررسی کنید تا وقتی تغییرات را برای بازبینی به هم‌تیمی‌هایتان ارسال می‌کنید، آن‌ها بتوانند دو کار انجام دهند: ببینند آیا تغییری در اطلاعات وابستگی انتقالی ایجاد شده است یا نه، و به‌علاوه، دستگاه‌هایشان نیازی به محاسبه مجدد اطلاعات وابستگی انتقالی نداشته باشد.

علاوه‌براین، با بررسی این اطلاعات در کنترل منبع، این امکان را فراهم می‌کنید که شما، هم‌تیمی‌هایتان، و خطوط لوله CI/CD شما بتوانید هربار با نسخه‌های وابستگی یکسان بسازید.

با خوشحالی اعلام می‌کنیم که Lightbuild به‌عنوان نسخه پیش‌نمای اولیه در Android Studio Canary و همچنین ازطریق ابزارهای CLI مستقل دردسترس است.

لطفاً به‌خاطر داشته باشید که این نسخه Lightbuild آزمایشی است، بنابراین همه ویژگی‌های لازم برای ساخت و نگهداری برنامه تولید را ندارد.

لطفاً همچنان از AGP و Gradle برای برنامه‌های تولیدی‌تان استفاده کنید و Lightbuild را در پروژه‌های آزمایشی و نمایشی امتحان کنید.

می‌توانید همین امروز با رفتن به goo.gle/lightbuild شروع کنید و ما مشتاقانه منتظر دریافت بازخورد شما هستیم تا بتوانید به ما در شکل دادن به محصول درحین تکامل آن کمک کنید.

اکنون ارائه را به اسکات می‌سپارم تا Lightbuild را در عمل به شما نشان دهد.

متشکرم، خوان.

نام من اسکات مایرز است.

من مهندس روابط توسعه‌دهندگان Android هستم و مدتی است که روی Lightbuild کار می‌کنیم و خوشحالیم که به شما نشان دهیم چگونه می‌توانید امروز به آن دسترسی پیدا کنید و با آن کار کنید.

بنابراین، اولین کاری که باید انجام دهید این است که به پیوندی که خوان ذکر کرد، goo.gle/lightbuild، بروید یا فقط Lightbuild را جستجو کنید.

و باید شما را به این صفحه اسناد ببرد که تمام مراحل لازم برای شروع را دارد، ازجمله نصب نسخه Canary از Android Studio، چون به‌خاطر داشته باشید که این هنوز در پیش‌نمایش است و هنوز در نسخه پایدار Android Studio نیست.

همچنین، یک Lightbuild CLI وجود دارد که می‌توانید آن را نصب کنید تا از مزایای کامل تجربه عاملی با Lightbuild بهره‌مند شوید.

بنابراین، وقتی آن را راه‌اندازی کردید، مثل من که اینجا در رایانه‌ام دارم، جدیدترین نسخه Android Studio Canary را اجرا می‌کنم.

و اکنون می‌خواهم مراحل ایجاد یک پروژه نمایشی Lightbuild را گام‌به‌گام توضیح دهم و به شما نشان دهم که چگونه می‌توانید این کار را انجام دهید، حتی همین امروز.

بنابراین، ابتدا به جادوی پروژه جدید می‌روم.

من «فعالیت خالی» را انتخاب می‌کنم و روی «بعدی» کلیک می‌کنم.

و اکنون می‌بینید که این صفحه جزئیات پروژه معمولی است، اما در پایین اینجا، گزینه جدیدی وجود دارد.

در بخش زبان پیکربندی ساخت، می‌توانید Lightbuild را انتخاب کنید.

و قبل‌از اینکه روی «پایان» ضربه بزنید، به شما یادآوری می‌کند که این ویژگی آزمایشی است.

و بلافاصله خواهید دید که پروژه ما با IDE همگام‌سازی شده و آماده کار است.

اکنون بیایید نگاهی به ساختار پروژه یک پروژه Lightbuild معمولی بیندازیم.

بنابراین، این فقط الگوی پیش‌فرض Android است که هنگام ایجاد یک برنامه جدید دریافت می‌کنید.

فقط می‌گوید «سلام، دنیا!»

بنابراین روش ساده‌ای برای شروع است.

و خواهید دید که در سطح ریشه پروژه ما در اینجا، فایلی به‌نام project.lightbuild.yaml داریم.

این کار تنظیمات سراسری را برای کل پروژه به ما می‌دهد.

بنابراین، می‌توانید نامی برای پروژه‌تان انتخاب کنید، همه پیمانه‌های پروژه‌تان را فهرست کنید، بگویید وابستگی‌هایتان را از کدام مخزن‌های خارجی می‌گیرید، و سپس نسخه‌هایی را که به‌طور سراسری اعمال می‌شوند، به بخش‌های مختلف پروژه‌تان در اینجا اضافه کنید.

بنابراین، می‌بینیم که دو واحد در اینجا داریم، app و app-core.

و دلیلش این است که همه پروژه‌های Lightbuild حداقل دو ماژول دارند.

و دلیل آن این است که باید حداقل یک واحد برنامه و حداقل یک واحد کتابخانه داشته باشد.

و تا چند ثانیه دیگر به دلیل آن می‌پردازم.

بنابراین، ابتدا بیایید نگاهی به این ماژول برنامه بیندازیم.

اگر آن را در اینجا ازهم باز کنم، می‌بینید که در سطح ریشه واحد، یک فایل lightbuild.yaml وجود دارد که هر واحدی آن را خواهد داشت.

در اینجا، برخی اطلاعات پایه وجود دارد.

ما روی پلاتفرم Android کار می‌کنیم، بدیهی است.

و این ماژول از نوع برنامه است.

می‌توانید نسخه‌های هدف کیت توسعه نرم‌افزار، شناسه برنامه‌تان، و غیره را فهرست کنید و سپس همه پیمانه‌هایی را که این پیمانه برنامه به آن‌ها وابسته است فهرست کنید.

اکنون، آنچه درباره این ماژول برنامه جالب است و کمی با الگوی استاندارد Android متفاوت است، این است که چیزی در پوشه منبع وجود ندارد.

بنابراین، در Lightbuild، پیمانه‌های برنامه حاوی هیچ کد منبعی نیستند.

دلیل آن این است که این ماژول برنامه قرار نیست خیلی تغییر کند، اما ساخت آن کمی زمان می‌برد.

بنابراین، اگر همه کد برنامه‌تان را در مدول‌های کتابخانه‌تان نگه دارید، هر ساخت سریع‌تر انجام می‌شود زیرا مجبور نیست همه چیز را در مدول برنامه دوباره محاسبه و بسته‌بندی کند.

بنابراین، در مرحله بعد بیایید نگاهی به ماژول app-core بیندازیم، که ماژول کتابخانه‌ای است که این ماژول برنامه به آن وابسته است.

و می‌بینید که این ماژول واقعاً کد منبع دارد.

منطق اصلی ما در اینجا قرار دارد.

فقط می‌گوید «سلام، دنیا!»

و اگر به فایل lightbuild.yaml در این ماژول نگاه کنم، می‌توانید ببینید که از نوع کتابخانه است.

و در اینجا همچنین برخی‌از شماره‌های نسخه کیت توسعه نرم‌افزار را تنظیم می‌کند، اما همه وابستگی‌های خارجی را که داریم، در این ماژول فهرست می‌کند.

و همچنین واحد و آزمایش‌های ابزاری ما را اعلام می‌کند.

بنابراین در ادامه، بیایید نگاهی به فایل دیگری بیندازیم که ممکن است در اینجا متوجه آن شده باشید، و خوان کمی درباره آن صحبت کرد، یک فایل resolved.deps در داخل هر ماژول وجود دارد.

و این فایلی است که به‌طور خودکار توسط Lightbuild تولید شده است.

بنابراین، این یعنی نباید آن را به‌صورت دستی ویرایش کنید، اما این فایل حاوی فهرستی از همه وابستگی‌های حل‌شده در این ماژول خواهد بود.

بنابراین، همه وابستگی‌ها و وابستگی‌های انتقالی شما ازقبل اینجا هستند.

بنابراین، این بدان معناست که وقتی برنامه شما در IDE باز می‌شود یا وقتی می‌خواهید ساخت را انجام دهید، لازم نیست در آن زمان این موضوع را بفهمید زیرا قبلاً از قبل مشخص شده و در پروژه شما بررسی شده است.

در ادامه، بیایید نگاهی به نمونه‌ای از نحوه بهبود تجربه توسعه‌دهنده با همگام‌سازی پروژه توسط Lightbuild بیندازیم.

بنابراین، اکنون به سطح ریشه project.lightbuild.yaml برگشته‌ام، تنظیمات سراسری در اینجا که همه ماژول‌های برنامه‌ام را فهرست می‌کند.

و معمولاً، وقتی درحال ویرایش فایل‌های پیکربندی یا پیکربندی ساخت هستید، متوجه می‌شوید که دکمه همگام‌سازی‌ای نشان داده می‌شود که پردازش همه آن‌ها مدتی طول می‌کشد، به‌دلیل فرایندهایی که خوان توضیح می‌داد که در آن باید با اجرای همه اسکریپت‌های ساخت شما و سپس همگام‌سازی آن مدل با IDE، ساخت جزئی انجام دهد.

بنابراین، بیایید یک تغییر نسبتاً بزرگ برای این پروژه کوچک انجام دهیم.

فقط یکی از ماژول‌ها را حذف می‌کنیم.

و می‌توانید ببینید که این ماژول، قبل‌از اینکه دکمه ذخیره را بزنم، توسط IDE شناسایی شده است، زیرا می‌توانید تشخیص دهید که در اینجا پررنگ است.

دایرکتوری منبع و دایرکتوری‌های آزمایش را تشخیص داد.

و به‌محض اینکه پس‌از اعمال آن تغییر روی «ذخیره» کلیک کردم، می‌بینید که این ماژول فوراً از پروژه حذف می‌شود.

و اگر دوباره آن تغییر را واگرد کنم و ذخیره را بزنم، به همان سرعت برمی‌گردد.

بنابراین، این نمونه‌ای از همگام‌سازی سریع IDE است که Lightbuild به پروژه‌های شما می‌آورد.

بنابراین، علاوه‌براین، می‌توانید همه فرمان‌های معمولی را که در «استودیو Android» به آن‌ها عادت دارید انجام دهید.

می‌توانید دکمه اجرا را بزنید.

این ابزار برنامه‌تان را کامپایل می‌کند و آن را در اینجا اجرا می‌کند.

این برنامه نمایشی خاص خیلی بزرگ نیست، اما بزرگ‌نمایی می‌کنم تا نشان دهم که می‌گوید «سلام Android».

می‌توانید آزمایش‌هایتان را مثل همیشه با رفتن به فایل آزمایشی و اجرای آن از حاشیه به این صورت اجرا کنید.

و درواقع Lightbuild را در پشت صحنه برای اجرای این آزمایش‌ها فراخوانی می‌کند.

بنابراین، همه این‌ها همان‌طور که انتظار دارید کار می‌کند.

اما در ادامه می‌خواهم نشان دهم که اگر در «استودیو Android» نباشید و از جریان عاملی دیگری استفاده کنید، چگونه می‌توانید از Lightbuild استفاده کنید.

و برای این کار، خط فرمان را داریم.

بنابراین، در «میانای خط فرمان» برای Lightbuild، فقط فرمان راهنمای پایه را اجرا می‌کنم.

و بله، همه غلط‌های املایی که امروز در این پروژه می‌بینید کار من است.

بنابراین، Lightbuild چندین فرمان مختلف خواهد داشت که در آن تعبیه شده‌اند، مانند «اوه، متأسفم، من این را خارج از یک پروژه اجرا می‌کنم».

مدام این را به من می‌گوید.

بله، نسخه نمایشی زنده.

بنابراین، ابتدا، قبل‌از اینکه هرگونه فرمان Lightbuild را اجرا کنم، اجازه دهید یک پروژه Lightbuild ایجاد کنم.

و برای این کار، از android create استفاده می‌کنم که ابزار خط فرمان استاندارد ما برای ایجاد الگوهای پروژه جدید است.

از الگوی empty-activity-lightbuild استفاده خواهم کرد و نام برنامه‌ام را Lightbuild Demo می‌گذارم و آن را در دایرکتوری خروجی نسخه نمایشی قرار می‌دهم.

بسیار خوب، حالا اگر وارد آن دایرکتوری شوم و lightbuild -h را تایپ کنم، همه فرمان‌های مختلفی را که Lightbuild دردسترس دارد خواهم دید.

بنابراین چیزهای زیادی داریم که انتظار دارید: ساخت، پاک‌سازی، آزمایش.

اما چند مورد جدید هم وجود دارد.

یک فرمان حل‌وفصل وجود دارد که درواقع وابستگی‌های پروژه شما را اجرا می‌کند و آن فایل‌های resolved.deps را که قبلاً نشان دادم تولید می‌کند.

و یک فرمان پُرسمان وجود دارد که به شما و نمایندگان شما اجازه می‌دهد ساختار پروژه‌تان را بهتر درک کنید.

پس، اول، چرا آن فرمان پُرسمان جدید را نشان ندهم؟

بنابراین، اگر فقط بااستفاده از خط فرمان به ساختار این پروژه نگاه کنم، همان ساختاری است که در نسخه نمایشی «استودیو Android» داشتم.

اما این اطلاعات زیادی درباره نحوه چیدمان پروژه‌ام به من نمی‌دهد.

بنابراین، اگر پرسمان lightbuild را انجام دهم و مثلاً به این ماژول برنامه نگاه کنم، از این نحو خاص استفاده خواهم کرد تا بگویم: «همه چیزهایی را که تحت این ماژول برنامه است به من نشان بده.»

و این جدول خوب از اهداف مختلف را به من می‌دهد که می‌توانم در ماژول برنامه بسازم.

بنابراین، این فایل APK و AAB را هم برای اشکال‌زدایی و هم برای انتشار باینری‌ها دارد.

و اگر فقط هدف برنامه را اجرا کنم، همه چیز را می‌سازد.

و همچنین راهی برای مشخص کردن خروجی به‌عنوان JSON وجود دارد.

و به این ترتیب اوه، ببخشید.

Again, all of my typos are real today.

بگذارید از راهنمای تعاملی Lightbuild استفاده کنم تا مطمئن شوم این کار را درست انجام می‌دهم.

ها…

بله، باید کار کند.

بسیار خوب.

خب، اگر کسی می‌تواند به من بگوید که کجای کارم اشتباه است، بعداز این صحبت با من صحبت کند.

ولی به‌هرحال، به‌جای این جدول، می‌توانید فرمان‌های Lightbuild را به‌صورت JSON هم برونداد کنید که برای عامل‌هایتان آسان‌تر است.

--format json…

اوه، قالب.

اوه، متأسفم.

متشکریم.

این بازخورد زنده توسعه‌دهنده است.

متشکریم.

بسیارخوب، بله، و همچنین آن فرمان خروجی وجود دارد که می‌توانم آن را هم نمایش دهم، شاید با کمک شما.

بنابراین اگر فایل‌ها را به‌جای هدف‌ها برونداد کنم، این کار مکان‌های همه دودویی‌های مختلف را در ساخت من نشان می‌دهد.

بنابراین این فقط راهی است برای شما و عامل‌هایتان تا بتوانید بااستفاده از Lightbuild، پروژه‌تان را از خط فرمان کاوش کنید و بهتر درک کنید.

سپس، بدیهی است که آن فرمان lightbuild resolve که قبلاً ذکر کردم، همه فایل‌های resolved.deps شما را تولید خواهد کرد.

آن یکی هم چند ویژگی اضافی دارد.

مثلاً، این پارامتر وابستگی‌های قفل‌شده وجود دارد، و با آن، به‌جای اینکه فقط این فایل‌ها را تولید کند، درواقع فقط محتوای فایل‌ها را با وابستگی‌هایی که در پیکربندی ساخت خود اعلام کرده‌اید مقایسه می‌کند.

و اگر تفاوتی وجود داشته باشد، به شما اطلاع می‌دهد و ساخت را ناموفق می‌کند.

بنابراین، از این نظر، این فایل‌های وابستگی‌های حل‌شده می‌توانند به‌عنوان فایل‌های قفل عمل کنند، مثلاً اگر برنامه‌تان را در سیستم CI/CD برای تولید می‌سازید، می‌خواهید بدانید که آیا وابستگی‌ها درطول آن ساخت تغییر می‌کنند یا نه.

همچنین، Lightbuild یک ویژگی آزمایشی داخلی دارد و شما می‌توانید تمام آزمایش‌ها را تحت این ماژول کتابخانه، مثلاً مستقیماً از خط فرمان، اجرا کنید.

و یک چیز دیگر هم هست که می‌خواهم نشان دهم.

فقط اینکه راهنمایی هم دردسترس است که فهرست کاملی از همه ساختارها، پارامترها، و فرمان‌های فرعی را که می‌توانید استفاده کنید دراختیارتان قرار می‌دهد.

این برای عامل شما دردسترس است، بنابراین این همان خروجی برای عامل است.

بسیار خوب.

خب، حالا که چند پروژه ساده را با Lightbuild دیدیم، می‌خواهم نشان دهم که یک پروژه کمی بلندپروازانه‌تر چگونه است.

بنابراین ما یک برنامه نمونه داریم که توسط تیم Android دردسترس قرار گرفته است و «اکنون در Android» نام دارد که برخی از جدیدترین ویژگی‌های Android را به شما ارائه می‌دهد، نحوه استفاده از آن‌ها را به شما نشان می‌دهد، و برخی از روال‌های مطلوب را نشان می‌دهد.

این برنامه بسیار ماژولار است.

به نظرم به ۳۲ واحد مختلف تقسیم شده است.

بنابراین، این همان چیزی است که در GitHub می‌بینید.

اما من به Android Studio برمی‌گردم، جایی که قبلاً از عاملم استفاده کرده‌ام.

I was using Gemini Argon to convert the Now in Android project over to Lightbuild.

بنابراین، این چیزی نیست که ما منتشر کرده باشیم، این فقط کاری است که من خودم انجام دادم.

و می‌توانید ببینید که اگرچه این پروژه در project.lightbuild.yaml من همه این ماژول‌های مختلف را دارد، اما همچنان به‌طور باورنکردنی سریع باز می‌شود و به‌سرعت با این IDE همگام‌سازی می‌شود.

نکته دیگری که باید درباره این پروژه خاص به آن توجه کنید این است که از برخی طعم‌های ساخت یا پیکربندی‌های ساخت ویژه استفاده می‌کرد تا هم ساخت نمایشی و هم ساخت تولید داشته باشد که هرکدام روش کمی متفاوتی برای ارائه برنامه داشتند.

نسخه نمایشی از منابع داده داخلی استفاده می‌کند و نسخه تولیدی درواقع به شبکه می‌رود و داده‌ها را استخراج می‌کند.

بنابراین برای انجام این کار با Lightbuild، روشی که چیزهایی مانند پیکربندی‌های ساخت مختلف یا نسخه‌های ویژه محصول را مدیریت می‌کند این است که به ماژول برنامه خود می‌روید و مشخص می‌کنید که این ماژول برنامه، برای مثال، برنامه نمایشی است.

بنابراین، به همه مؤلفه‌های اصلی متکی خواهد بود، اما تنظیمات ویژه‌ای را نیز فقط برای نسخه نمایشی برنامه دریافت می‌کند.

بنابراین، به این روش می‌توانید چند واحد برنامه داشته باشید.

هرکدام می‌تواند مثلاً نسخه پولی یا رایگان برنامه‌تان باشد.

و همچنان از مزایای ماژول برنامه که یک پوسته خالی بدون کد است و بسیار سریع‌تر ساخته می‌شود بهره‌مند می‌شوید، و هر زمان که کتابخانه‌های شما تغییر کند، فقط آن‌ها باید دوباره همگردانی شوند تا برنامه شما دوباره ساخته شود.

بیایید نگاهی بیندازیم و ببینیم آیا این برنامه «اکنون در Android» با Lightbuild و همه ۳۲ ماژول مختلف آن با موفقیت ساخته می‌شود یا نه.

بله، اینجاست.

و می‌خواهم اشاره کنم که چیزهای بیشتری که از انجام آزمایش‌هایی مانند این یاد گرفتیم این بود که Lightbuild همیشه از هر ویژگی ساخت تکی که ممکن است نیاز داشته باشید پشتیبانی نمی‌کند.

برای مثال، برنامه Now in Android برای استفاده از Hilt به افزونه Hilt متکی است و Lightbuild هنوز از این نوع چیزها پشتیبانی نمی‌کند.

بنابراین، نماینده من توانست راه‌حلی برای آن پیدا کند و همچنان پشتیبانی Hilt را بدون تغییر چندانی در کد پروژه اضافه کند.

مثلاً، همه کدهای موجود در همه این ماژول‌ها با مخزن اصلی یکسان است.

اما این چیزی است که باید-- قطعاً باید هنگام آزمایش و نمایش Lightbuild توسط خودتان درنظر داشته باشید، این است که همه چیز در پروژه فعلی شما ازنظر پیکربندی ساخت پشتیبانی نخواهد شد.

به همین دلیل است که Lightbuild هنوز در مرحله پیش‌نمایش است و همچنان در «استودیو Android» نسخه Canary قرار دارد.

و با این، می‌خواهم به اسلایدها برگردم.

و بله، فقط برای جمع‌بندی هر آنچه در اینجا صحبت کردیم، Lightbuild را به‌خاطر بسپارید، این یک پلاتفرم ساخت جدید برای Android است که درحال‌حاضر آزمایشی است.

این ابزار دارای پیکربندی ساخت اعلانی است، بنابراین هیچ کد اجرایی را در پیکربندی‌های ساخت خود اجرا نمی‌کنید و این امر ویژگی‌های عالی زیادی را با همگام‌سازی سریع IDE و ساخت‌های کارآمدتر باز می‌کند.

این مدل از پشتیبانی عامل هوش مصنوعی درجه یک برخوردار است، در خط فرمان، همه آن ویژگی‌هایی را دارد که امروز به من کمک کردید نمایش دهم.

بنابراین از شما دعوت می‌کنیم آن را امتحان کنید و برای پروژه‌های آزمایشی و نمایشی از آن استفاده کنید.

من و خوان و برخی‌از مهندسان تیم هم در غرفه «هوش مصنوعی عامل‌گرا» خواهیم بود تا به هر سؤالی که دارید پاسخ دهیم.

بنابراین بسیار سپاس‌گزاریم.