บิลด์ Android ที่พร้อมใช้งาน Agent และเป็นแบบประกาศด้วย Lightbuild

สวัสดีทุกคน

ฉันชื่อ Juan Sebastian Oviedo

ฉันเป็นผู้จัดการผลิตภัณฑ์ในทีมประสบการณ์นักพัฒนาแอป Android

ผมอยู่กับ Scott และวันนี้เราตื่นเต้นที่จะได้แชร์ข้อมูลเบื้องต้นเกี่ยวกับ 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 และปรับให้เข้ากับ Toolchain ของ Android

Gradle และ AGP ร่วมกันสร้างระบบแบบไดนามิกที่ขับเคลื่อนประสบการณ์การกำหนดค่าบิลด์สำหรับแอปเวอร์ชันที่ใช้งานจริงหลายล้านแอปในปัจจุบัน

เนื่องจากความยืดหยุ่นนี้ เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเราจึงทำงานภายในวงจรสถาปัตยกรรมที่เฉพาะเจาะจง

เมื่อเปิดโปรเจ็กต์ เปลี่ยนสาขา หรือแก้ไขไฟล์บิลด์ IDE ต้องมีแผนผังที่ชัดเจนและความเข้าใจที่ชัดเจนเกี่ยวกับการกำหนดค่าโปรเจ็กต์ เพื่อให้สามารถขับเคลื่อนฟีเจอร์ต่างๆ เช่น การเติมโค้ดอัตโนมัติและการไปยังส่วนต่างๆ ของโค้ด

เนื่องจากไฟล์บิลด์เขียนด้วยภาษา Turing-complete ที่จำเป็น วิธีทั่วไปเพียงวิธีเดียวที่ IDE จะทราบว่าการกำหนดค่าคืออะไรคือการเรียกใช้สคริปต์บิลด์

ในระหว่างการซิงค์ IDE ระบบบิลด์จะเข้าสู่ระยะการกำหนดค่า

โดยจะประเมินสคริปต์บิลด์ ดำเนินการตรรกะของปลั๊กอิน และสร้างโมเดลโปรเจ็กต์

ซึ่งจะปรับมุมมองโปรเจ็กต์ของ Android Studio ให้สอดคล้องกับการกำหนดค่าโปรเจ็กต์จริง

ในฐานะนักพัฒนาแอป สิ่งที่คุณให้ความสำคัญมากที่สุดคือการนำเสนอแอป Android ที่ยอดเยี่ยมและส่งมอบแอปนั้นให้แก่ผู้ใช้

อย่างไรก็ตาม การจัดการสคริปต์บิลด์ การอัปเดต AGP ให้เป็นเวอร์ชันล่าสุด และการซิงค์โปรเจ็กต์กับ IDE นั้นต้องใช้เวลาและความพยายาม

ทั้ง Google และระบบนิเวศในวงกว้างมีโครงการริเริ่มหลายโครงการที่มุ่งปรับปรุงประสบการณ์ของนักพัฒนาแอปในด้านนี้

โครงการริเริ่มต่างๆ เช่น Declarative Gradle และ Toolchain ของ Kotlin มีเป้าหมายที่จะแทนที่สคริปต์บิลด์ที่เรียกใช้ได้ด้วยการกำหนดค่าบิลด์แบบประกาศ

ใน Android Studio เรามีผู้ช่วยอัปเกรด AGP ซึ่งจะแนะนำการเปลี่ยนแปลงที่จำเป็นในการเปลี่ยนจาก AGP เวอร์ชันหนึ่งไปเป็นอีกเวอร์ชันหนึ่ง

นอกจากนี้ เรายังมีทักษะการอัปเกรดที่ตัวแทนสามารถติดตั้งและทำตามเพื่ออัปเกรด AGP ได้ด้วย

นอกจากนี้ เรายังลงทุนในด้านต่างๆ เช่น การซิงค์แบบแบ่งระยะและการซิงค์ที่ยืดหยุ่น เพื่อให้นักพัฒนาแอปได้รับประสบการณ์ที่ดีขึ้นเมื่อซิงค์และนำเข้าโปรเจ็กต์

ความพยายามแต่ละอย่างเหล่านี้มุ่งเป้าไปที่ส่วนหนึ่งของปริศนา เพื่อให้นักพัฒนาแอปใช้เวลาสร้างแอปได้มากขึ้น และใช้เวลาสร้างโปรเจ็กต์ จัดการไฟล์บิลด์ และซิงค์โปรเจ็กต์น้อยลง

นอกเหนือจากความพยายามนี้ เรายังถามตัวเองด้วยคำถามที่กว้างขึ้น

จะเป็นอย่างไรหากเราปรับเปลี่ยนวิธีการกำหนดค่าโปรเจ็กต์ใหม่ตั้งแต่ต้น

เมื่อดูสถาปัตยกรรมของแอป Android สมัยใหม่ในปัจจุบัน เราจะเห็นการเปลี่ยนแปลงครั้งใหญ่ไปสู่การแยกโมดูลอย่างมาก

ฐานของโค้ดขนาดใหญ่มักมีโมเดลหลายสิบหรือหลายร้อยรายการ เช่น โมดูล UI, โมดูลฟีเจอร์, โมดูลโดเมน และโมดูลข้อมูล

และแม้ว่าแอปพลิเคชันรูทอาจต้องใช้แพ็กเกจที่กำหนดเองในบางครั้ง แต่โมดูลไลบรารีส่วนใหญ่จะใช้รูปแบบมาตรฐานที่ทำซ้ำได้

โดยไม่จำเป็นต้องมีโค้ดที่เรียกใช้ได้โดยไม่มีกฎเกณฑ์ในไฟล์บิลด์

สิ่งที่ต้องมีคือวิธีที่ชัดเจนในการระบุโครงสร้างและการขึ้นต่อกัน

การสังเกตการณ์ดังกล่าวทำให้เราสร้าง Lightbuild ขึ้นมา

Lightbuild มีเสาหลัก 2 ต้น

ประการแรก ระบบจะใช้ไวยากรณ์เชิงประกาศสำหรับการกำหนดค่า ซึ่งช่วยให้แยกการกำหนดค่าบิลด์และตรรกะออกจากกันอย่างชัดเจน

และประการที่ 2 คือมอบประสบการณ์การซิงค์ IDE ที่รวดเร็วผ่านการแก้ไขทรัพยากร Dependency ล่วงหน้า

เราจะอธิบายรายละเอียดของแต่ละเสาหลักเพื่อให้คุณเห็นว่าเสาหลักเหล่านี้ส่งผลต่อเวิร์กโฟลว์ประจำวันของคุณอย่างไร

มาเริ่มกันที่เสาหลักของการกำหนดค่าบิลด์แบบประกาศ

ดูไฟล์ทางด้านซ้ายของหน้าจอ

ซึ่งแสดงถึงการกำหนดค่าสำหรับโมดูลในปัจจุบัน

// 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 ทราบว่าการกำหนดค่านี้จะแก้ไขเป็นอะไร 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

ไฟล์นี้เป็นข้อมูลเชิงประกาศเท่านั้น

ไม่มีการกำหนดตัวแปรภายใน ไม่มีการเรียกใช้ฟังก์ชันตัวช่วยที่กำหนดเอง และไม่มีคำสั่งแบบมีเงื่อนไขหรือการกำหนดงานในบรรทัด

โดยจะระบุประเภทของโมดูล, เป้าหมาย SDK และทรัพยากร Dependency อย่างชัดเจน

หากมีวิศวกรใหม่เข้าร่วมทีมและเปิดไฟล์นี้ วิศวกรคนดังกล่าวจะไม่ต้องถอดรหัสสำนวนบิลด์ที่กำหนดเอง และโมดูล Lightbuild ทุกโมดูลในทุกโปรเจ็กต์ Lightbuild จะใช้ภาษาเดียวกันที่อ่านได้ทันที

แม้ว่าการแยกการกำหนดค่าและตรรกะออกจากกันจะช่วยให้มนุษย์อ่านได้ง่ายขึ้น แต่ก็ยังช่วยให้เวิร์กโฟลว์ที่ใช้ Agent Assist มีประสิทธิภาพมากขึ้นด้วย

เมื่อนักพัฒนาซอฟต์แวร์นำ Agent มาใช้เป็นส่วนหนึ่งของเวิร์กโฟลว์ Agent เหล่านั้นจะต้องอ่านและแก้ไขการกำหนดค่าบิลด์ได้

อย่างไรก็ตาม นักพัฒนาซอฟต์แวร์ไม่มีวิธีคาดการณ์ผลข้างเคียงของการเปลี่ยนแปลงการกำหนดค่านอกเหนือจากการสร้างโปรเจ็กต์จริง

การเพิ่มบรรทัดเดียวลงในไฟล์การกำหนดค่าอาจขัดแย้งกับตัวแปรที่คำนวณแบบไดนามิกที่อื่นในโปรเจ็กต์หรือกับปลั๊กอินแบบแผน

ใน Lightbuild การกำหนดค่าของโปรเจ็กต์คือกราฟข้อมูลแบบคงที่เชิงกำหนด

ซึ่งหมายความว่า Agent จะตรวจสอบกราฟดังกล่าว ทำความเข้าใจโทโพโลยีของโมดูล และแก้ไขโดยใช้สคีมาที่รู้จักได้

Agent สามารถดูรายการโมดูล รายการทรัพยากร Dependency และเวอร์ชันของทรัพยากรเหล่านั้น อัปเดตทรัพยากร Dependency หรือแม้แต่เพิ่มโมดูลฟีเจอร์ใหม่ได้ง่ายๆ เพียงแค่อ่านและเขียน Structured Data

ซึ่งจะทำให้การกำหนดค่าของโปรเจ็กต์เป็นองค์ประกอบหลักสำหรับเวิร์กโฟลว์ที่ใช้ Agent Assist

รายละเอียดอีกอย่างหนึ่งที่ฉันต้องการเน้นในจุดนี้คือ Lightbuild ไม่ใช่ปลั๊กอินสำหรับระบบบิลด์ แต่เป็นอินเทอร์เฟซสำหรับเครื่องมือบิลด์

Lightbuild เวอร์ชันตัวอย่างที่เราเปิดตัวในวันนี้ใช้ Gradle เป็นเครื่องมือดำเนินการเบื้องหลัง

อย่างไรก็ตาม แนวทางด้านสถาปัตยกรรมที่เราใช้กับ Lightbuild ทำให้ Android Studio ซึ่งเป็น IDE มองเห็นและจัดการโปรเจ็กต์เป็นโปรเจ็กต์ Lightbuild

ตอนนี้เรามาดูหลักสำคัญข้อที่ 2 ซึ่งเกี่ยวกับประสิทธิภาพการทำงานและขั้นตอนการทำงานของนักพัฒนาแอป นั่นคือการซิงค์ IDE ที่รวดเร็ว

แม้ว่านักพัฒนาแอปจะใช้ Agent เป็นส่วนหนึ่งของเวิร์กโฟลว์ แต่ Android Studio ก็ยังคงเป็นเครื่องมือที่จำเป็นสำหรับงานแบบอินเทอร์แอกทีฟ เช่น การตรวจสอบตัวอย่าง UI ของ Compose หรือการตรวจสอบโค้ดในโปรแกรมแก้ไขข้อบกพร่องเพื่อตรวจสอบปัญหา หรือการวิเคราะห์ประสิทธิภาพด้วยเครื่องมือวิเคราะห์ประสิทธิภาพ

เนื่องจากการกำหนดค่าของโปรเจ็กต์เป็นกราฟข้อมูลแบบคงที่และเชิงกำหนด IDE จึงไม่จำเป็นต้องผ่านขั้นตอนการประเมินสคริปต์หรือเรียกใช้โค้ดปลั๊กอินเพื่อทำความเข้าใจโปรเจ็กต์

ไม่ว่าคุณจะเปิดโปรเจ็กต์ แก้ไขไฟล์บิลด์ หรือเปลี่ยนสาขา IDE ก็สามารถประมวลผลข้อมูลนั้นได้อย่างรวดเร็วและนำคุณไปยังเครื่องมือที่ต้องการได้ทันที

เหตุผลหนึ่งที่ทำให้ความเร็วและความน่าเชื่อถือนี้เป็นไปได้คือวิธีที่ Lightbuild จัดการทรัพยากร Dependency

โดยปกติแล้ว เมื่อคุณประกาศทรัพยากร Dependency ระบบบิลด์จะต้องผ่านโครงสร้างของทรัพยากร Dependency แบบทรานซิทีฟเพื่อรวบรวมข้อมูลเวอร์ชันและแก้ไขข้อขัดแย้ง

ใน Lightbuild เมื่อใดก็ตามที่ทรัพยากร Dependency มีการเปลี่ยนแปลง เครื่องมือจะคำนวณข้อมูลทรัพยากร Dependency แบบสกรรมกริยาโดยอัตโนมัติและเขียนลงในไฟล์ resolved.deps ภายในไดเรกทอรีของแต่ละโมดูล

ซึ่งจะทำให้เมื่อเปิดโปรเจ็กต์อีกครั้งในอนาคตหรือมีการสร้างใหม่ ทั้ง IDE และเครื่องมือบิลด์จะไม่ต้องคำนวณข้อมูลความเกี่ยวข้องแบบทรานซิทีฟนั้นใหม่

เราขอแนะนำให้ตรวจสอบไฟล์เหล่านี้ในการควบคุมแหล่งที่มา เพื่อที่ว่าเมื่อคุณส่งการเปลี่ยนแปลงไปให้เพื่อนร่วมทีมตรวจสอบ เพื่อนร่วมทีมจะสามารถทำ 2 สิ่งนี้ได้ นั่นคือดูว่ามีการเปลี่ยนแปลงข้อมูลทรัพยากร Dependency แบบสกรรมกริยาหรือไม่ และเครื่องของเพื่อนร่วมทีมจะไม่ต้องคำนวณข้อมูลทรัพยากร Dependency แบบสกรรมกริยาซ้ำ

นอกจากนี้ การตรวจสอบข้อมูลนี้ในการควบคุมแหล่งที่มาจะช่วยให้คุณ เพื่อนร่วมทีม และไปป์ไลน์ CI/CD สามารถสร้างด้วยเวอร์ชันทรัพยากร Dependency เดียวกันได้ทุกครั้ง

เรายินดีที่จะประกาศว่า Lightbuild พร้อมให้ใช้งานเป็นเวอร์ชันตัวอย่างทดลองใช้ใน Android Studio Canary และผ่านเครื่องมือ CLI แบบสแตนด์อโลนด้วย

โปรดทราบว่า Lightbuild เวอร์ชันนี้เป็นเวอร์ชันทดลอง จึงไม่มีฟีเจอร์ทั้งหมดที่คุณต้องใช้ในการสร้างและดูแลรักษาแอปพลิเคชันเวอร์ชันที่ใช้งานจริง

โปรดใช้ AGP และ Gradle ต่อไปสำหรับแอปพลิเคชันเวอร์ชันที่ใช้งานจริงขณะลองใช้ Lightbuild ในโปรเจ็กต์เดโมและโปรเจ็กต์ทดลอง

คุณเริ่มต้นใช้งานได้ตั้งแต่วันนี้โดยไปที่ goo.gle/lightbuild และเราหวังว่าจะได้รับความคิดเห็นจากคุณเพื่อช่วยเราปรับปรุงผลิตภัณฑ์ให้ดียิ่งขึ้น

ตอนนี้ฉันจะส่งต่อการนำเสนอให้ Scott เพื่อให้เขาแสดงการทำงานของ Lightbuild ให้คุณดู

ขอบคุณ Juan

ฉันชื่อ Scott Myers

ผมเป็นวิศวกรฝ่ายลูกค้าสัมพันธ์ของนักพัฒนาแอป Android และเราได้พัฒนา Lightbuild มาระยะหนึ่งแล้ว และตื่นเต้นที่จะแสดงให้คุณเห็นว่าคุณสามารถลองใช้และทดลองเล่น Lightbuild ได้อย่างไรในวันนี้

สิ่งแรกที่คุณต้องทำคือไปที่ลิงก์ที่ Juan พูดถึง นั่นคือ goo.gle/lightbuild หรือจะค้นหา Lightbuild ก็ได้

และระบบจะนำคุณไปยังหน้าเอกสารประกอบนี้ซึ่งมีขั้นตอนทั้งหมดที่จำเป็นในการเริ่มต้นใช้งาน รวมถึงการติดตั้ง Android Studio เวอร์ชัน Canary เนื่องจากฟีเจอร์นี้ยังอยู่ในเวอร์ชันตัวอย่าง และยังไม่มีใน Android Studio เวอร์ชันเสถียร

นอกจากนี้ ยังมี Lightbuild CLI ที่คุณสามารถติดตั้งเพื่อรับสิทธิประโยชน์ทั้งหมดของประสบการณ์การใช้งานแบบ Agentic ด้วย Lightbuild

เมื่อตั้งค่าเสร็จแล้ว เช่นเดียวกับที่ฉันทำในเครื่องนี้ ฉันก็มี Android Studio Canary เวอร์ชันล่าสุดที่ทำงานอยู่

ตอนนี้ผมจะอธิบายขั้นตอนการสร้างโปรเจ็กต์ Lightbuild สาธิตจริงๆ และแสดงให้เห็นว่าคุณสามารถทำได้อย่างไรในวันนี้

ก่อนอื่น ฉันจะไปที่วิซาร์ด New Project

ฉันจะเลือก "กิจกรรมเปล่า" แล้วกด "ถัดไป"

ตอนนี้คุณจะเห็นว่านี่คือหน้าจอรายละเอียดโปรเจ็กต์ปกติ แต่ที่ด้านล่างนี้มีตัวเลือกใหม่

คุณเลือก Lightbuild ได้ในส่วนภาษาของการกำหนดค่าบิลด์

และจะช่วยเตือนคุณว่านี่เป็นการทดลองก่อนที่คุณจะกด "เสร็จสิ้น"

คุณจะเห็นทันทีว่าโปรเจ็กต์ของเราซิงค์กับ IDE และพร้อมใช้งานแล้ว

ตอนนี้เรามาดูโครงสร้างโปรเจ็กต์ของโปรเจ็กต์ Lightbuild ทั่วไปกัน

นี่เป็นเพียงเทมเพลต Android เริ่มต้นที่คุณจะได้รับเมื่อสร้างแอปพลิเคชันใหม่

ซึ่งมีข้อความว่า "Hello, world!"

ซึ่งเป็นวิธีเริ่มต้นที่ง่ายมาก

และคุณจะเห็นว่าที่ระดับรูทของโปรเจ็กต์ที่นี่ เรามีไฟล์ชื่อ project.lightbuild.yaml

ซึ่งจะทำให้เราได้การตั้งค่าส่วนกลางสำหรับทั้งโปรเจ็กต์

คุณสามารถตั้งชื่อโปรเจ็กต์ แสดงรายการโมดูลทั้งหมดในโปรเจ็กต์ ระบุที่เก็บภายนอกที่คุณดึงทรัพยากร Dependency มาใช้ แล้วระบุเวอร์ชันที่ใช้ทั่วโลกกับส่วนต่างๆ ของโปรเจ็กต์ที่นี่

เราจะเห็นว่ามี 2 โมดูลที่นี่ ได้แก่ app และ app-core

เนื่องจากโปรเจ็กต์ Lightbuild ทั้งหมดมีอย่างน้อย 2 โมดูล

เนื่องจากต้องมีโมดูลแอปอย่างน้อย 1 โมดูลและโมดูลไลบรารีอย่างน้อย 1 โมดูล

ซึ่งเราจะอธิบายเหตุผลในอีกสักครู่

ก่อนอื่น เรามาดูโมดูลแอปนี้กัน

หากขยายที่นี่ คุณจะเห็นว่าที่ระดับรูทของโมดูลมีไฟล์ lightbuild.yaml ซึ่งทุกโมดูลจะมี

ในนี้มีข้อมูลพื้นฐานบางอย่าง

เรากำลังพัฒนาแพลตฟอร์ม Android อยู่

และโมดูลนี้เป็นประเภทแอปพลิเคชัน

คุณสามารถระบุเวอร์ชันเป้าหมายของ SDK, รหัสแอปพลิเคชัน และอื่นๆ จากนั้นระบุโมดูลทั้งหมดที่โมดูลแอปพลิเคชันนี้ต้องใช้

สิ่งที่น่าสนใจเกี่ยวกับโมดูลแอปพลิเคชันนี้ซึ่งแตกต่างจากเทมเพลต Android มาตรฐานเล็กน้อยคือไม่มีอะไรอยู่ในโฟลเดอร์แหล่งที่มา

ดังนั้นใน Lightbuild โมดูลแอปพลิเคชันจึงไม่มีซอร์สโค้ดใดๆ

สาเหตุคือโมดูลแอปนี้จะไม่เปลี่ยนแปลงบ่อยนัก แต่ใช้เวลาในการสร้าง

ดังนั้น หากคุณเก็บโค้ดของแอปพลิเคชันทั้งหมดไว้ในโมดูลไลบรารี การบิลด์แต่ละครั้งจะเร็วขึ้นเพราะไม่ต้องคำนวณใหม่และแพ็กเกจทุกอย่างในโมดูลแอปอีกครั้ง

ต่อไปเรามาดูโมดูล app-core ซึ่งเป็นโมดูลไลบรารีที่โมดูลแอปพลิเคชันนี้ต้องใช้

และคุณจะเห็นว่าโมดูลนี้มีซอร์สโค้ดอยู่จริงๆ

ซึ่งมีตรรกะหลักของเราอยู่ที่นี่

ซึ่งมีข้อความว่า "Hello, world!"

และหากดูไฟล์ lightbuild.yaml ในโมดูลนี้ คุณจะเห็นว่าไฟล์เป็นประเภทไลบรารี

และที่นี่ก็มีการตั้งค่าหมายเลขเวอร์ชัน SDK บางรายการด้วย แต่จะแสดงรายการทรัพยากร Dependency ภายนอกทั้งหมดที่เรามีภายในโมดูลนี้

และยังประกาศการทดสอบหน่วยและการทดสอบการวัดคุมด้วย

ต่อไปเรามาดูไฟล์อื่นที่คุณอาจสังเกตเห็นที่นี่กัน Juan ได้พูดถึงเรื่องนี้ไปบ้างแล้วว่ามีไฟล์ resolved.deps อยู่ในทุกโมดูล

และนี่คือไฟล์ที่ Lightbuild สร้างขึ้นโดยอัตโนมัติ

ซึ่งหมายความว่าคุณไม่ควรแก้ไขไฟล์นี้ด้วยตนเอง แต่ไฟล์นี้จะมีรายการทรัพยากร Dependency ทั้งหมดที่ได้รับการแก้ไขภายในโมดูลนี้

ดังนั้น ทรัพยากร Dependency และทรัพยากร Dependency แบบสกรรมกริยาทั้งหมดจึงอยู่ที่นี่แล้ว

ซึ่งหมายความว่าเมื่อเปิดแอปพลิเคชันใน IDE หรือเมื่อคุณจะสร้างบิลด์ คุณไม่จำเป็นต้องคิดเรื่องนี้ในตอนนั้น เพราะมีการคิดไว้ล่วงหน้าและตรวจสอบในโปรเจ็กต์แล้ว

ต่อไป เรามาดูตัวอย่างว่า Lightbuild ช่วยปรับปรุงประสบการณ์ของนักพัฒนาแอปด้วยการซิงค์โปรเจ็กต์ได้อย่างไร

ตอนนี้ฉันกลับมาที่ระดับรูท project.lightbuild.yaml ซึ่งเป็นการตั้งค่าส่วนกลางที่แสดงโมดูลทั้งหมดในแอปพลิเคชันของฉัน

และโดยปกติแล้ว เมื่อคุณแก้ไขไฟล์การกำหนดค่าหรือไฟล์การกำหนดค่าบิลด์ คุณจะสังเกตเห็นว่ามีปุ่มซิงค์ปรากฏขึ้นซึ่งใช้เวลาสักครู่ในการประมวลผลทั้งหมด เนื่องจากกระบวนการที่ Juan อธิบายไว้ซึ่งต้องทำการบิลด์บางส่วนโดยเรียกใช้สคริปต์บิลด์ทั้งหมด แล้วซิงค์โมเดลนั้นกับ IDE

งั้นเรามาทำการเปลี่ยนแปลงครั้งใหญ่สำหรับโปรเจ็กต์เล็กๆ นี้กัน

เราจะลบโมดูลออก 1 โมดูล

และคุณจะเห็นว่าโมดูลนี้ IDE จะจดจำได้ก่อนที่ฉันจะกดปุ่มบันทึก เพราะคุณจะเห็นว่าโมดูลนี้เป็นตัวหนาที่นี่

โดยจะจดจำไดเรกทอรีต้นทางและไดเรกทอรีทดสอบ

และทันทีที่ฉันกดบันทึกหลังจากทำการเปลี่ยนแปลง คุณจะเห็นว่าโมดูลนี้หายไปจากโปรเจ็กต์ทันที

และหากฉันเลิกทำการเปลี่ยนแปลงนั้นอีกครั้งแล้วกดบันทึก ระบบก็จะกลับมาทำงานอย่างรวดเร็วเช่นกัน

นี่คือตัวอย่างการซิงค์ IDE ที่รวดเร็วซึ่ง Lightbuild มอบให้กับโปรเจ็กต์ของคุณ

นอกจากนี้ คุณยังใช้คำสั่งปกติทั้งหมดที่คุ้นเคยใน Android Studio ได้ด้วย

คุณสามารถกดปุ่มเรียกใช้

ระบบจะคอมไพล์แอปและเรียกใช้ที่นี่

แอปสาธิตนี้มีขนาดไม่ใหญ่มาก แต่ฉันจะซูมเข้าเพื่อแสดงให้เห็นว่าแอปนี้แสดงข้อความ "Hello Android"

คุณสามารถทำการทดสอบได้ตามปกติโดยไปที่ไฟล์ทดสอบ แล้วเรียกใช้จากแถบด้านข้างแบบนี้

และจริงๆ แล้วระบบจะเรียกใช้ Lightbuild เบื้องหลังเพื่อทำการทดสอบเหล่านี้

ดังนั้น ทุกอย่างจึงทำงานได้ตามที่คุณคาดหวัง

แต่ต่อไปเราอยากแสดงวิธีใช้ Lightbuild หากคุณไม่ได้อยู่ใน Android Studio และใช้โฟลว์ Agentic อื่นๆ

และเรามีบรรทัดคำสั่งสำหรับเรื่องนี้

ดังนั้นใน CLI สำหรับ Lightbuild ผมจะเรียกใช้คำสั่งช่วยเหลือพื้นฐาน

และใช่ คำที่พิมพ์ผิดทั้งหมดที่คุณเห็นในโปรเจ็กต์นี้ในปัจจุบันเป็นของฉันเอง

Lightbuild จะมีคำสั่งต่างๆ มากมายที่ติดตั้งมาในตัว เช่น อ้อ ขอโทษที ฉันกำลังเรียกใช้คำสั่งนี้นอกโปรเจ็กต์

มันบอกฉันแบบนั้นตลอดเลย

ใช่ การสาธิตแบบสด

ก่อนอื่น ก่อนที่จะเรียกใช้คำสั่ง Lightbuild ผมจะสร้างโปรเจ็กต์ Lightbuild ก่อน

และสำหรับเรื่องนั้น ผมจะใช้ android create ซึ่งเป็นเครื่องมือบรรทัดคำสั่งมาตรฐานของเราสำหรับการสร้างเทมเพลตโปรเจ็กต์ใหม่

ผมจะใช้เทมเพลต empty-activity-lightbuild และตั้งชื่อแอปว่า Lightbuild Demo แล้วใส่ไว้ในไดเรกทอรีเอาต์พุตเดโม

เอาล่ะ ตอนนี้ถ้าฉันเข้าไปในไดเรกทอรีนั้นและพิมพ์ lightbuild -h ฉันจะเห็นคำสั่งต่างๆ ทั้งหมดที่ Lightbuild มีให้ใช้งาน

เราจึงมีสิ่งต่างๆ มากมายที่คุณคาดหวัง เช่น บิลด์, ล้าง, ทดสอบ

แต่มีฟีเจอร์ใหม่ๆ เพิ่มเข้ามาด้วย

มีคำสั่ง Resolve ซึ่งจะทำงานผ่านทรัพยากร Dependency ของโปรเจ็กต์และสร้างไฟล์ resolved.deps ที่แสดงไว้ก่อนหน้านี้

และมีคำสั่งการค้นหา ซึ่งช่วยให้คุณและตัวแทนเข้าใจโครงสร้างของโปรเจ็กต์ได้ดียิ่งขึ้น

ก่อนอื่น เรามาดูคำสั่งการค้นหาใหม่กันก่อน

ดังนั้น หากฉันดูโครงสร้างของโปรเจ็กต์นี้โดยใช้บรรทัดคำสั่ง โครงสร้างดังกล่าวจะเหมือนกับโครงสร้างที่ฉันมีในการสาธิต Android Studio

แต่ข้อมูลนี้ไม่ได้บอกอะไรมากนักเกี่ยวกับเลย์เอาต์ของโปรเจ็กต์

ดังนั้น หากฉันทำการค้นหา Lightbuild และดูที่โมดูลแอปนี้ และฉันจะใช้ไวยากรณ์พิเศษนี้เพื่อบอกว่า "แสดงทุกอย่างที่อยู่ภายใต้โมดูลแอปนี้"

และแสดงตารางเป้าหมายต่างๆ ที่ฉันสามารถสร้างภายในโมดูลแอปได้

ดังนั้นจึงมี APK และ AAB สำหรับทั้งไบนารีการแก้ไขข้อบกพร่องและไบนารีรุ่น

และหากฉันเรียกใช้เป้าหมายแอป ระบบจะสร้างทุกอย่าง

นอกจากนี้ยังมีวิธีระบุเอาต์พุตเป็น JSON ด้วย

และด้วยวิธีนี้ โอ้ ขอโทษที

ขอย้ำอีกครั้งว่าการพิมพ์ผิดทั้งหมดของฉันในวันนี้เป็นเรื่องจริง

เดี๋ยวเราจะใช้ความช่วยเหลือแบบอินเทอร์แอกทีฟของ Lightbuild เพื่อให้แน่ใจว่าเราทำถูกต้อง

หืม…

ใช่ ควรจะใช้งานได้แล้ว

โอเค

ถ้าใครบอกได้ว่าฉันทำอะไรผิด ก็มาคุยกับฉันหลังการพูดคุยนี้ได้เลย

แต่ไม่ว่าอย่างไรก็ตาม คุณสามารถแสดงผลคำสั่ง Lightbuild เป็น JSON แทนตารางนี้ได้ ซึ่งจะช่วยให้ตัวแทนทำงานได้ง่ายขึ้น

--format json…

อ๋อ รูปแบบ

อ๋อ ขอโทษที

ขอขอบคุณ

นี่คือความคิดเห็นของนักพัฒนาแอปแบบเรียลไทม์

ขอขอบคุณ

โอเค ใช่ และยังมีคำสั่งเอาต์พุตที่ฉันสาธิตได้ด้วย อาจจะด้วยความช่วยเหลือของคุณ

ดังนั้นหากฉันแสดงผลไฟล์แทนเป้าหมาย ระบบจะแสดงตำแหน่งของไบนารีต่างๆ ทั้งหมดภายในบิลด์ของฉัน

ดังนั้นนี่จึงเป็นเพียงวิธีที่ช่วยให้คุณและ Agent สามารถสำรวจและทำความเข้าใจโปรเจ็กต์ได้ดียิ่งขึ้นจากบรรทัดคำสั่งโดยใช้ Lightbuild

จากนั้นก็จะมีคำสั่ง lightbuild resolve ที่ฉันพูดถึงก่อนหน้านี้ ซึ่งจะสร้างไฟล์ resolved.deps ทั้งหมด

ซึ่งมีฟีเจอร์เพิ่มเติมบางอย่างด้วย

เช่น มีพารามิเตอร์ทรัพยากร Dependency ที่ล็อกไว้ ดังนั้นแทนที่จะสร้างไฟล์เหล่านี้ขึ้นมา ระบบจะเปรียบเทียบเนื้อหาของไฟล์กับทรัพยากร Dependency ที่คุณประกาศไว้ในการกำหนดค่าบิลด์

และหากมีความแตกต่าง ระบบจะแจ้งให้คุณทราบและทำให้บิลด์ไม่สำเร็จ

ดังนั้น ไฟล์ทรัพยากร Dependency ที่ได้รับการแก้ไขเหล่านี้จึงทำหน้าที่เป็นไฟล์ล็อกได้ เช่น หากคุณกำลังสร้างแอปในระบบ CI/CD สำหรับเวอร์ชันที่ใช้งานจริง คุณอาจต้องการทราบว่าทรัพยากร Dependency มีการเปลี่ยนแปลงระหว่างการสร้างหรือไม่

นอกจากนี้ Lightbuild ยังมีฟีเจอร์ทดสอบในตัว และคุณยังสามารถเรียกใช้การทดสอบทั้งหมดภายใต้โมดูลไลบรารีนี้ได้ เช่น จากบรรทัดคำสั่งโดยตรง

และยังมีอีกสิ่งหนึ่งที่ฉันอยากจะแสดงให้เห็น

นอกจากนี้ยังมีฟีเจอร์ความช่วยเหลือที่จะแสดงรายการที่สมบูรณ์ของการสร้างพารามิเตอร์และคำสั่งย่อยทั้งหมดที่คุณใช้ได้

ซึ่งพร้อมใช้งานสำหรับ Agent ของคุณ ดังนั้นนี่คือเอาต์พุตสำหรับ Agent

โอเค

ตอนนี้เราได้เห็นโปรเจ็กต์ง่ายๆ ที่ใช้ Lightbuild แล้ว ต่อไปเราจะแสดงให้เห็นว่าโปรเจ็กต์ที่ซับซ้อนขึ้นมาหน่อยเป็นอย่างไร

เรามีแอปตัวอย่างที่ทีม Android จัดเตรียมไว้ให้ชื่อว่า Now in Android ซึ่งจะแสดงฟีเจอร์ล่าสุดบางส่วนของ Android พร้อมวิธีใช้และแนวทางปฏิบัติแนะนำบางส่วน

ซึ่งเป็นแอปพลิเคชันแบบโมดูลาร์สูง

โดยแบ่งออกเป็นโมดูลต่างๆ ประมาณ 32 โมดูล

นี่คือลักษณะของโค้ดใน GitHub

แต่ผมจะเปลี่ยนกลับไปใช้ Android Studio ซึ่งผมได้ใช้ Agent ไว้ล่วงหน้าแล้ว

ฉันใช้ Gemini Argon เพื่อแปลงโปรเจ็กต์ Android Now in Android เป็น Lightbuild

นี่ไม่ใช่สิ่งที่เราเผยแพร่ แต่เป็นสิ่งที่ฉันทำขึ้นเอง

และคุณจะเห็นว่าแม้ว่าโปรเจ็กต์นี้ใน project.lightbuild.yaml ของฉันจะมีโมดูลที่แตกต่างกันทั้งหมดเหล่านี้ แต่ก็ยังเปิดได้อย่างรวดเร็วอย่างไม่น่าเชื่อ และซิงค์กับ IDE นี้ได้อย่างรวดเร็วมาก

อีกสิ่งหนึ่งที่คุณควรสังเกตเกี่ยวกับโปรเจ็กต์นี้คือมีการใช้ตัวแปรบิลด์บางอย่างหรือการกำหนดค่าบิลด์พิเศษ เพื่อให้มีทั้งบิลด์เดโมและบิลด์เวอร์ชันที่ใช้งานจริง ซึ่งแต่ละบิลด์มีวิธีนำเสนอแอปที่แตกต่างกันเล็กน้อย

เวอร์ชันสาธิตจะใช้แหล่งข้อมูลในตัว ส่วนเวอร์ชันที่ใช้งานจริงจะเชื่อมต่อกับเครือข่ายและดึงข้อมูล

ดังนั้น หากต้องการทำเช่นนั้นด้วย Lightbuild วิธีที่ Lightbuild จัดการสิ่งต่างๆ เช่น การกำหนดค่าบิลด์หรือเวอร์ชันผลิตภัณฑ์ที่แตกต่างกัน คือคุณต้องเข้าไปที่โมดูลแอปพลิเคชัน แล้วระบุว่าโมดูลแอปพลิเคชันนี้เป็นแอปพลิเคชันเดโม เป็นต้น

ดังนั้นจึงต้องใช้คอมโพเนนต์หลักทั้งหมด แต่ก็ต้องดึงการตั้งค่าพิเศษสำหรับแอปเวอร์ชันเดโมโดยเฉพาะด้วย

ดังนั้น คุณจึงมีโมดูลแอปพลิเคชันได้หลายโมดูลด้วยวิธีนี้

แต่ละรายการอาจแสดงถึงแอปเวอร์ชันที่ต้องซื้อหรือเวอร์ชันฟรี เป็นต้น

และคุณยังคงได้รับประโยชน์จากโมดูลแอปพลิเคชันที่เป็นเชลล์ว่างเปล่าซึ่งไม่มีโค้ดในตัวที่สร้างได้เร็วขึ้นมาก และเมื่อใดก็ตามที่ไลบรารีมีการเปลี่ยนแปลง คุณจะต้องคอมไพล์ไลบรารีเหล่านั้นใหม่เท่านั้นเพื่อสร้างแอปอีกครั้ง

ตอนนี้เรามาดูกันว่าแอป Android Now in Android นี้สร้างขึ้นด้วย Lightbuild ได้สำเร็จหรือไม่ โดยมีโมดูลที่แตกต่างกันทั้งหมด 32 โมดูล

ใช่ นั่นแหละ

และเราอยากชี้ให้เห็นว่าสิ่งที่เราได้เรียนรู้จากการทดสอบเช่นนี้คือ Lightbuild ไม่ได้รองรับฟีเจอร์บิลด์ทุกรายการที่คุณอาจต้องการเสมอไป

เช่น แอป Now in Android ต้องใช้ปลั๊กอิน Hilt เพื่อใช้ Hilt และ Lightbuild ยังไม่รองรับสิ่งดังกล่าว

ดังนั้น Agent ของฉันจึงสามารถหาวิธีแก้ปัญหาได้ และยังคงได้รับการสนับสนุน Hilt โดยไม่ต้องเปลี่ยนโค้ดในโปรเจ็กต์มากนัก

โค้ดทั้งหมดในโมดูลเหล่านี้เหมือนกับที่เก็บต้นฉบับ

แต่สิ่งที่คุณควรคำนึงถึงเมื่อทดลองและสาธิต Lightbuild ด้วยตนเองคือการกำหนดค่าบิลด์อาจไม่รองรับทุกอย่างในโปรเจ็กต์ปัจจุบัน

ด้วยเหตุนี้ Lightbuild จึงยังอยู่ในเวอร์ชันตัวอย่างและยังอยู่ใน Android Studio Canary

และตอนนี้ฉันอยากจะกลับไปที่สไลด์

และเพื่อสรุปทุกอย่างที่เราพูดถึงที่นี่ โปรดจำไว้ว่า Lightbuild เป็นแพลตฟอร์มบิลด์ใหม่สำหรับ Android ซึ่งตอนนี้ยังอยู่ในขั้นทดลอง

โดยมีการกำหนดค่าบิลด์แบบประกาศ คุณจึงไม่ต้องเรียกใช้โค้ดที่สั่งการได้ในการกำหนดค่าบิลด์ ซึ่งจะปลดล็อกฟีเจอร์ที่ยอดเยี่ยมมากมายด้วยการซิงค์ IDE ที่รวดเร็วและบิลด์ที่มีประสิทธิภาพมากขึ้น

โดยมีการรองรับ AI Agent ระดับเฟิร์สคลาสที่บรรทัดคำสั่ง และมีฟีเจอร์ทั้งหมดที่คุณช่วยสาธิตให้ฉันดูในวันนี้

เราจึงขอเชิญให้คุณลองใช้และนำไปใช้กับโปรเจ็กต์สาธิตและโปรเจ็กต์ทดลอง

นอกจากนี้ Juan และฉัน รวมถึงวิศวกรบางคนในทีมจะอยู่ที่บูธ Agentic AI เพื่อตอบคำถามที่คุณมี

ขอขอบคุณมากนะคะ