גרסאות build דקלרטיביות של Android שמוכנות לסוכנים באמצעות Lightbuild

שלום לכולם,

קוראים לי חואן סבסטיאן אוביידו.

אני מנהל מוצר בצוות חוויית המפתחים של Android.

אני כאן עם סקוט, והיום אנחנו שמחים להציג לכם את Lightbuild, חוויית פיתוח ניסיונית חדשה לאפליקציות ל-Android.

אני אסביר את ההקשר של הפרויקט הזה, את הפילוסופיה שמאחוריו, ולמה אנחנו מאמינים שעכשיו זה הזמן הנכון לחשוב מחדש על האופן שבו פרויקטים של Android מוגדרים.

אני גם אסביר איך הגישה החדשה הזו מכינה אותנו לעתיד של פיתוח אפליקציות ל-Android.

נתחיל עם קצת הקשר לגבי אופן הפעולה של הדברים כיום.

סקריפטים של Gradle וסקריפטים אימפרטיביים של build מאפשרים למפתחים להגדיר באופן פרוגרמטי כמעט כל דבר שקשור ל-builds שלהם.

לדוגמה, אפשר להשתמש בלוגיקה שמחשבת באופן דינמי קודי גרסאות על סמך היסטוריית 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 יוצרים מערכת דינמית שמאפשרת את חוויית תצורת ה-build של מיליוני אפליקציות בסביבת הייצור כיום.

בגלל הגמישות הזו, כלי הפיתוח שלנו פועלים במסגרת מחזור חיים ארכיטקטוני ספציפי.

כשפותחים פרויקט, עוברים בין ענפים או עורכים קובץ build, סביבת הפיתוח המשולבת (IDE) צריכה מפה ברורה והבנה ברורה של הגדרות הפרויקט, כדי שהיא תוכל להפעיל תכונות כמו השלמת קוד וניווט בקוד.

מכיוון שקובצי build נכתבים בשפה אימפרטיבית שלמה לפי טיורינג, הדרך הכללית היחידה שבה ה-IDE יכול לדעת מהי התצורה היא להריץ את הסקריפטים של ה-build.

במהלך סנכרון ה-IDE, מערכת ה-build עוברת שלב של הגדרה.

הוא מעריך את סקריפטים של ה-build, מפעיל את הלוגיקה של הפלאגין ובונה את מודל הפרויקט.

כך התצוגה של הפרויקט ב-Android Studio תתאים להגדרות של הפרויקט בפועל.

כמפתחים, הדבר שהכי חשוב לכם הוא ליצור אפליקציה מעולה ל-Android ולהפיץ אותה למשתמשים.

עם זאת, ניהול סקריפטים של build, עדכון של AGP וסנכרון הפרויקט עם סביבת הפיתוח המשולבת (IDE) דורשים זמן ומאמץ.

יש כמה יוזמות ב-Google ובסביבה העסקית הרחבה יותר שנועדו לשפר את חוויית המפתחים בתחום הזה.

יוזמות כמו Declarative Gradle ו-Kotlin toolchain נועדו להחליף סקריפטים של build שניתנים להפעלה בתצורת build הצהרתית.

ב-Android Studio יש את AGP Upgrade Assistant, שמדריך אתכם לגבי השינויים שצריך לבצע כדי לעבור מגרסה אחת של AGP לגרסה אחרת.

אנחנו מספקים גם מיומנות שדרוג שנציגים יכולים להתקין ולפעול לפיה כדי לשדרג את AGP.

בנוסף, אנחנו משקיעים בתחומים כמו סנכרון הדרגתי וסנכרון גמיש, כדי שלמפתחים תהיה חוויה טובה יותר כשהם מסנכרנים ומייבאים את הפרויקטים שלהם.

כל אחד מהמאמצים האלה מתמקד בחלק מהפאזל, כדי שהמפתחים יוכלו להשקיע יותר זמן ביצירת האפליקציות שלהם ופחות זמן בבניית הפרויקטים, בניהול קובצי ה-build ובסנכרון הפרויקטים.

במקביל למאמצים האלה, שאלנו את עצמנו שאלה רחבה יותר.

מה אם היינו משנים את הדרך שבה מגדירים פרויקטים מהיסוד?

כשבוחנים את הארכיטקטורה של אפליקציות מודרניות ל-Android, רואים שינוי משמעותי לכיוון של מודולריזציה כבדה.

בבסיסי קוד גדולים יש בדרך כלל עשרות או אפילו מאות מודולים: מודולים של ממשק משתמש, מודולים של תכונות, מודולים של דומיינים ומודולים של נתונים.

לפעמים צריך לארוז את האפליקציה הראשית באופן מותאם אישית, אבל רוב המודולים של הספריות האלה פועלים לפי דפוס סטנדרטי שחוזר על עצמו.

הם לא באמת צריכים קוד שרירותי שניתן להפעלה בקובצי ה-build שלהם.

כל מה שצריך זה דרך ברורה לציין את המבנה ואת יחסי התלות שלהם.

התובנה הזו הובילה אותנו ליצור את Lightbuild.

‫Lightbuild מבוסס על שני עמודים.

קודם כל, הוא משתמש בתחביר הצהרתי להגדרה, ומספק הפרדה ברורה בין תצורת ה-build לבין הלוגיקה.

שנית, הוא מספק חוויית סנכרון מהירה של סביבת הפיתוח המשולבת (IDE) באמצעות פתרון תלויות מראש.

אני אעבור על כל אחד מהעמודים האלה בפירוט כדי שתוכלו לראות איך הם משפיעים על תהליך העבודה היומי שלכם.

נתחיל עם העיקרון של תצורת build הצהרתית.

תסתכלו על הקובץ בצד ימין של המסך.

זה מייצג את ההגדרות של מודול מסוים כיום.

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

מכיוון שהקובץ הזה הוא קוד שניתן להפעלה, הוא יכול לכלול הגדרות של משתנים מקומיים, קריאות לפונקציות עזר בהתאמה אישית או לפלאגינים של מוסכמות, הצהרות מותנות והגדרות של משימות מוטבעות.

כדי שסביבת הפיתוח המשולבת תדע מה התוצאה של ההגדרה הזו, היא צריכה להריץ את הסקריפט.

עכשיו תסתכלו על הקובץ בצד שמאל של המסך.

זו הגדרת 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 שלו ואת יחסי התלות שלו.

אם מהנדס חדש מצטרף לצוות ופותח את הקובץ הזה, הוא לא צריך לפענח ביטויים מותאמים אישית של גרסאות build, וכל מודול של Lightbuild בכל פרויקט של Lightbuild משתמש באותה שפה שניתן לקרוא באופן מיידי.

ההפרדה בין ההגדרות לבין הלוגיקה עוזרת לאנשים לקרוא את הקוד, אבל היא עוד יותר משמעותית בתהליכי עבודה שנעזרים ב-Agent Assist.

כשהמפתחים משתמשים בסוכנים כחלק מתהליך העבודה שלהם, הסוכנים האלה צריכים להיות מסוגלים לקרוא ולשנות את תצורת ה-build.

עם זאת, אין להם דרך לחזות את ההשפעות של שינוי בהגדרות, אלא אם הם בונים את הפרויקט בפועל.

הוספת שורה אחת לקובץ תצורה עלולה להתנגש עם משתנה שמחושב באופן דינמי במקום אחר בפרויקט או עם פלאגין של מוסכמות.

ב-Lightbuild, ההגדרות האישיות של הפרויקט הן תרשים נתונים סטטי ודטרמיניסטי.

זה אומר שהסוכנים יכולים לבדוק את התרשים, להבין את הטופולוגיה של המודול ולשנות אותה באמצעות סכימה מוכרת.

הסוכן יכול לראות את רשימת המודולים, את רשימת יחסי התלות והגרסאות שלהם, לעדכן את יחסי התלות או אפילו להוסיף מודול חדש לגמרי של תכונות, פשוט על ידי קריאה וכתיבה של נתונים מובְנים.

הוא הופך את הגדרת הפרויקט לחלק מרכזי בתהליכי עבודה שנעזרים בנציגים.

עוד פרט שחשוב להדגיש בשלב הזה הוא ש-Lightbuild הוא לא פלאגין למערכת build, אלא ממשק למנוע ה-build.

גרסת טרום-ההשקה של Lightbuild שאנחנו משיקים היום משתמשת ב-Gradle כמנוע ההפעלה שלה.

עם זאת, הגישה הארכיטקטונית שבה השתמשנו ב-Lightbuild גורמת לכך ש-Android Studio, סביבת הפיתוח המשולבת (IDE), רואה את הפרויקט ומתייחסת אליו כפרויקט Lightbuild.

עכשיו נעבור לעמוד התווך השני, שעוסק בפרודוקטיביות ובזרימה של המפתחים: סנכרון מהיר של IDE.

גם כשמפתחים משתמשים בסוכנים כחלק מתהליך העבודה שלהם, Android Studio נשאר כלי חיוני למשימות אינטראקטיביות. למשל, כדי לבדוק תצוגות מקדימות של ממשק משתמש ב-Compose, לעבור על הקוד בכלי לניפוי באגים כחלק מבדיקת בעיה או לנתח את הביצועים באמצעות הכלי לניתוח ביצועים.

מכיוון שההגדרות של הפרויקט הן תרשים נתונים סטטי ודטרמיניסטי, סביבת הפיתוח המשולבת לא צריכה לעבור שלב של הערכת סקריפט או להריץ קוד פלאגין כדי להבין את הפרויקט.

לא משנה אם אתם פותחים פרויקט, עורכים קובץ build או מחליפים ענפים, סביבת הפיתוח המשולבת (IDE) יכולה לעבד את המידע הזה במהירות ולהעביר אתכם ישירות לכלים שלכם.

אחת הסיבות למהירות ולאמינות האלה היא האופן שבו Lightbuild מטפל ביחסי תלות.

בדרך כלל, כשמצהירים על תלות, מערכת ה-build צריכה לעבור על עץ של תלויות טרנזיטיביות כדי לאסוף מידע על הגרסאות ולפתור התנגשויות.

ב-Lightbuild, בכל פעם שהתלויות משתנות, הכלי מחשב באופן אוטומטי את פרטי התלות הטרנזיטיבית וכותב אותם בקובץ resolved.deps בתוך כל ספריית מודולים.

כך, כשפותחים את הפרויקט שוב בעתיד או כשבונים אותו מחדש, לא צריך לחשב מחדש את המידע על יחסי התלות הטרנזיטיביים ב-IDE או בכלי ה-build.

מומלץ להוסיף את הקבצים האלה לבקרת המקור, כדי שכשתשלחו שינויים לחברי הצוות לבדיקה, הם יוכלו לראות אם היו שינויים במידע על התלות הטרנזיטיבית, והמכונות שלהם לא יצטרכו לחשב מחדש את המידע הזה.

בנוסף, אם תבדקו את המידע הזה בבקרת המקור, אתם, חברי הצוות שלכם וצינורות עיבוד הנתונים של CI/CD תוכלו לבנות עם אותן גרסאות של יחסי תלות בכל פעם.

אנחנו שמחים להודיע ש-Lightbuild זמין בגרסת טרום-השקה מוקדמת ב-Android Studio Canary וגם דרך כלי CLI נפרדים.

חשוב לזכור שהגרסה הזו של Lightbuild היא ניסיונית, ולכן אין בה את כל התכונות שצריך כדי ליצור ולתחזק אפליקציה בסביבת ייצור.

המשיכו להשתמש ב-AGP וב-Gradle לאפליקציות בסביבת הייצור, ונסו את Lightbuild בפרויקטים ניסיוניים ובפרויקטים להדגמה.

כדי להתחיל להשתמש בכלי, נכנסים לכתובת goo.gle/lightbuild. נשמח לקבל מכם משוב שיעזור לנו לשפר את המוצר.

עכשיו אעביר את המצגת לסקוט כדי שהוא יוכל להראות לכם את Lightbuild בפעולה.

תודה, חואן.

קוראים לי סקוט מאיירס.

אני מהנדס קשרי מפתחים ב-Android. אנחנו עובדים על Lightbuild כבר זמן מה, ואנחנו שמחים להראות לכם איך אתם יכולים להתנסות בו כבר היום.

אז הדבר הראשון שצריך לעשות הוא להיכנס לקישור שחואן הזכיר, goo.gle/lightbuild, או פשוט לחפש את Lightbuild.

הקישור אמור להוביל אתכם לדף התיעוד הזה, שבו מפורטים כל השלבים שצריך לבצע כדי להתחיל, כולל התקנה של גרסת Canary של Android Studio. חשוב לזכור שהתכונה הזו עדיין בגרסת טרום-השקה (Preview), והיא עדיין לא זמינה בגרסה היציבה של Android Studio.

בנוסף, יש ממשק שורת פקודה (CLI) של Lightbuild שאפשר להתקין כדי ליהנות מכל היתרונות של חוויית הסוכן ב-Lightbuild.

אז אחרי שמגדירים את זה, כמו שעשיתי כאן במחשב שלי, יש לי את הגרסה העדכנית ביותר של Android Studio Canary.

עכשיו אעבור על השלבים ליצירת פרויקט Lightbuild לדוגמה, ואראה לכם איך אתם יכולים לעשות את זה, אפילו היום.

אז קודם כל, אעבור לאשף הפרויקט החדש.

אבחר באפשרות Empty Activity (פעילות ריקה) ואלחץ על Next (הבא).

עכשיו אתם יכולים לראות שזהו מסך פרטי הפרויקט הרגיל, אבל כאן למטה יש אפשרות חדשה.

בקטע "שפת תצורת ה-build", אתם יכולים לבחור באפשרות Lightbuild.

לפני שתלחצו על "סיום", תופיע תזכורת לכך שמדובר בתכונה ניסיונית.

ואפשר לראות מיד שהפרויקט שלנו מסונכרן עם ה-IDE ופועל, ומוכן לעבודה.

עכשיו נראה את מבנה הפרויקט של פרויקט Lightbuild טיפוסי.

אז זו רק תבנית ברירת המחדל של Android שאתם מקבלים כשאתם יוצרים אפליקציה חדשה.

הוא פשוט אומר "Hello, world!‎"

זו דרך פשוטה להתחיל.

ואפשר לראות שברמת הבסיס של הפרויקט שלנו כאן, יש לנו קובץ שנקרא project.lightbuild.yaml.

כך אנחנו מקבלים את ההגדרות הגלובליות של כל הפרויקט.

אז אתם יכולים לתת שם לפרויקט, לרשום את כל המודולים בפרויקט, לציין מאילו מאגרים חיצוניים אתם שולפים את יחסי התלות, ואז את הגרסאות שחלות באופן גלובלי על החלקים השונים של הפרויקט כאן.

אז אנחנו רואים שיש לנו כאן שני מודולים, app ו-app-core.

הסיבה לכך היא שבכל הפרויקטים ב-Lightbuild יש לפחות שני מודולים.

הסיבה לכך היא שחובה שיהיו לפחות מודול אחד של אפליקציה ומודול אחד של ספרייה.

עוד רגע אסביר למה.

קודם כל, בואו נסתכל על מודול האפליקציה הזה.

אם ארחיב אותו כאן, תוכלו לראות שברמת הבסיס של המודול יש קובץ lightbuild.yaml, שיהיה בכל מודול.

יש כאן מידע בסיסי.

אנחנו עובדים על פלטפורמת Android, כמובן.

והמודול הזה הוא מסוג אפליקציה.

אפשר לציין את גרסאות היעד של ה-SDK, את מזהה האפליקציה וכו', ואז לציין את כל המודולים שמודול האפליקציה הזה תלוי בהם.

עכשיו, מה שמעניין במודול האפליקציה הזה, שהוא קצת שונה מהתבנית הרגילה של Android, הוא שאין שום דבר בתיקיית המקור.

לכן, מודולים של אפליקציות ב-Lightbuild לא מכילים קוד מקור.

הסיבה לכך היא שמודול האפליקציה הזה לא ישתנה לעיתים קרובות, אבל לוקח קצת זמן לבנות אותו.

לכן, אם תשמרו את כל קוד האפליקציה במודולים של הספרייה, כל גרסה תיווצר מהר יותר כי לא יהיה צורך לחשב מחדש ולארוז מחדש את כל מה שנמצא במודול האפליקציה.

עכשיו נסתכל על המודול app-core, שהוא מודול הספרייה שמודול האפליקציה הזה תלוי בו.

ואפשר לראות שהמודול הזה באמת מכיל קוד מקור.

כאן נמצאת הלוגיקה העיקרית שלנו.

הוא פשוט אומר "Hello, world!‎"

ואם אסתכל על הקובץ lightbuild.yaml במודול הזה, אפשר לראות שהוא מסוג ספרייה.

וגם כאן מוגדרים כמה מספרי גרסאות של SDK, אבל מפורטים כל יחסי התלות החיצוניים שיש לנו, בתוך המודול הזה.

וגם מצהיר על בדיקות היחידה ובדיקות האינסטרומנטציה שלנו.

עכשיו נסתכל על קובץ אחר שאולי שמתם לב אליו כאן, וחואן דיבר עליו קצת, יש קובץ resolved.deps בתוך כל מודול.

זה קובץ שנוצר באופן אוטומטי על ידי Lightbuild.

כלומר, לא צריך לערוך אותו באופן ידני, אבל הוא יכיל רשימה של כל יחסי התלות שנפתרו במודול הזה.

כלומר, כל יחסי התלות ויחסי התלות הטרנזיטיביים כבר נמצאים כאן.

זה אומר שכשהאפליקציה נפתחת ב-IDE או כשאתם יוצרים build, אתם לא צריכים להבין את זה באותו רגע כי זה כבר הובן מראש ונבדק בפרויקט.

עכשיו נראה דוגמה לאופן שבו Lightbuild משפר את חוויית המפתחים באמצעות סנכרון פרויקטים.

אז עכשיו חזרתי לרמת הבסיס project.lightbuild.yaml, ההגדרות הגלובליות כאן שמפרטות את כל המודולים באפליקציה שלי.

ובדרך כלל, כשעורכים קובצי תצורה או קובצי תצורת build, מופיע כפתור סנכרון שלוקח קצת זמן לעבד את כל אלה בגלל התהליכים שחואן תיאר, שבהם צריך לבצע build חלקי על ידי הפעלת כל הסקריפטים של ה-build ואז לסנכרן את המודל הזה עם ה-IDE.

אז בואו נעשה שינוי די משמעותי בפרויקט הקטן הזה.

אנחנו פשוט נמחק את אחד מהמודולים.

ואפשר לראות שהמודול הזה, לפני שלחצתי על כפתור השמירה, מזוהה על ידי ה-IDE כי אפשר לראות שהוא מודגש כאן.

הוא זיהה את ספריית קובצי המקור ואת ספריות הבדיקה.

וברגע שאני לוחץ על שמירה, אחרי שביצעתי את השינוי הזה, אפשר לראות שהמודול הזה נעלם מיד מהפרויקט.

ואם אבטל את השינוי הזה שוב ואלחץ על שמירה, הוא יחזור באותה מהירות.

אז זו דוגמה לסנכרון המהיר של ה-IDE ש-Lightbuild מביא לפרויקטים שלכם.

בנוסף, אתם יכולים פשוט להשתמש בכל הפקודות הרגילות שאתם רגילים אליהן ב-Android Studio.

אפשר ללחוץ על כפתור ההפעלה.

הוא יקמפל את האפליקציה ויריץ אותה כאן.

אפליקציית ההדגמה הזו לא גדולה במיוחד, אבל אגדיל את התצוגה כדי להראות שכתוב בה "שלום Android".

אתם יכולים להריץ את הבדיקות כרגיל: נכנסים לקובץ הבדיקה ומריצים אותו מהשוליים, ככה.

ובעצם, הוא מפעיל את Lightbuild מאחורי הקלעים כדי להריץ את הבדיקות האלה.

אז כל זה עובד כמו שאתם מצפים.

אבל עכשיו אני רוצה להראות איך משתמשים ב-Lightbuild אם לא נמצאים ב-Android Studio, אם משתמשים בתהליך אחר של סוכן.

לשם כך, יש לנו את שורת הפקודה.

אז ב-CLI של Lightbuild, אני פשוט אריץ את פקודת העזרה הבסיסית.

וכן, כל שגיאות ההקלדה שאתם רואים בפרויקט הזה היום הן שלי.

אז ל-Lightbuild יהיו כמה פקודות שונות שמובנות בו, כמו "אוי, סליחה, אני מריץ את זה מחוץ לפרויקט".

הוא ממשיך להגיד לי את זה.

כן, הדגמה בשידור חי.

אז קודם כל, לפני שאני מריץ פקודות Lightbuild, אני אצור פרויקט Lightbuild.

ולשם כך, אשתמש ב-android create, שהוא כלי שורת הפקודה הסטנדרטי שלנו ליצירת תבניות פרויקט חדשות.

אשתמש בתבנית empty-activity-lightbuild, אקרא לאפליקציה Lightbuild Demo ואשים אותה בספריית הפלט של ההדגמה.

אוקיי, אז עכשיו אם אכנס לספרייה הזו ואקליד lightbuild -h, אראה את כל הפקודות השונות שזמינות ב-Lightbuild.

אז יש לנו הרבה דברים שהייתם מצפים להם: build, ‏ clean, ‏ test.

אבל יש כמה חדשים.

יש פקודת פתרון, שבעצם עוברת על יחסי התלות של הפרויקט ויוצרת את קובצי ה-resolved.deps שהראיתי קודם.

ויש פקודת שאילתה שמאפשרת לכם ולסוכנים שלכם להבין טוב יותר את מבנה הפרויקט.

אז קודם כול, למה שלא אציג את פקודת השאילתה החדשה?

אז אם אני מסתכל על המבנה של הפרויקט הזה באמצעות שורת הפקודה, הוא זהה לזה שהיה לי בהדגמה של Android Studio.

אבל זה לא אומר הרבה על המבנה של הפרויקט.

אז אם אני מריץ שאילתה ב-Lightbuild, ואני מסתכל, נגיד, על מודול האפליקציה הזה, ואני משתמש בתחביר המיוחד הזה כדי להגיד, "תראה לי את כל מה שנמצא מתחת למודול האפליקציה הזה".

ואני מקבל את הטבלה הנחמדה הזו של יעדים שונים שאני יכול לבנות בתוך מודול האפליקציה.

לכן, יש בו את קובצי ה-APK וה-AAB גם של הקבצים הבינאריים לניפוי באגים וגם של הקבצים הבינאריים לפרסום.

ואם אני פשוט מריץ את יעד האפליקציה, הוא יבנה את הכול.

ויש גם דרך לציין את הפלט כ-JSON.

ככה, אה, סליחה.

שוב, כל שגיאות ההקלדה שלי אמיתיות היום.

אני אשתמש בעזרה האינטראקטיבית של Lightbuild כדי לוודא שאני עושה את זה נכון.

הממ…

כן, זה אמור לעבוד.

טוב.

אם מישהו יכול להגיד לי מה אני עושה לא נכון, דברו איתי אחרי ההרצאה.

בכל מקרה, במקום הטבלה הזו, אתם יכולים גם להפיק את פקודות Lightbuild כ-JSON, שקל יותר לסוכנים שלכם.

‫--format json…

אה, פורמט.

אוי, סליחה.

תודה.

זהו משוב בזמן אמת מהמפתחים.

תודה.

אוקיי, כן, ויש גם את פקודת הפלט שאני יכול להדגים, אולי בעזרתך.

אז אם אני מוציא את הקבצים במקום את היעדים, זה יראה לי את המיקומים של כל הקבצים הבינאריים השונים בתוך ה-build שלי.

אז זו רק דרך שמאפשרת לכם ולסוכנים שלכם לחקור ולהבין טוב יותר את הפרויקט משורת הפקודה באמצעות Lightbuild.

ואז, כמובן, יש את הפקודה lightbuild resolve שהזכרתי קודם, שתיצור את כל קובצי ה-resolved.deps.

יש בה גם כמה תכונות נוספות.

לדוגמה, יש את הפרמטר הזה של יחסי תלות נעולים, אז במקום ליצור את הקבצים האלה, הוא פשוט ישווה את תוכן הקבצים ליחסי התלות שהצהרתם עליהם בתצורת ה-build.

אם יש הבדלים, תקבלו הודעה על כך וה-build ייכשל.

לכן, קובצי יחסי התלות שנפתרו יכולים לפעול כקובצי נעילה. לדוגמה, אם אתם יוצרים את האפליקציה במערכת CI/CD לסביבת ייצור, תרצו לדעת אם יחסי תלות כלשהם משתנים במהלך ה-build הזה.

בנוסף, ב-Lightbuild יש תכונת בדיקה מובנית, ואפשר גם להריץ את כל הבדיקות במודול הספרייה הזה, למשל, ישירות משורת הפקודה.

ויש עוד דבר אחד שאני רוצה להראות.

אבל יש גם עזרה זמינה שתיתן לכם רשימה מלאה של כל הפרמטרים ופקודות המשנה שבהם אתם יכולים להשתמש.

המידע הזה זמין לסוכן, אז זה הפלט של הסוכן.

טוב.

אחרי שראינו כמה פרויקטים פשוטים עם Lightbuild, אני רוצה להראות איך נראה פרויקט קצת יותר שאפתני.

אז יש לנו אפליקציה לדוגמה שצוות Android מספק, שנקראת Now in Android. היא נותנת לכם כמה מהתכונות העדכניות ביותר של Android, מראה לכם איך להשתמש בהן ומציגה כמה שיטות מומלצות.

זו אפליקציה מודולרית מאוד.

הוא מחולק ל-32 מודולים שונים.

ככה זה נראה ב-GitHub.

אבל אני אחזור ל-Android Studio, שם כבר השתמשתי בסוכן שלי מראש.

השתמשתי ב-Gemini Argon כדי להמיר את הפרויקט Now in Android ל-Lightbuild.

אז זה לא משהו שפרסמנו, זה רק משהו שעשיתי בעצמי.

ואפשר לראות שלמרות שבפרויקט הזה ב-project.lightbuild.yaml יש את כל המודולים השונים האלה, הוא עדיין נפתח מהר מאוד, ומסתנכרן עם ה-IDE הזה בצורה מהירה מאוד.

דבר נוסף שכדאי לשים לב אליו בפרויקט הספציפי הזה, הוא שהוא השתמש בכמה סוגי build, או הגדרות build מיוחדות, כדי שיהיו גם build להדגמה וגם build לייצור, שלכל אחד מהם הייתה דרך שונה במקצת להציג את האפליקציה.

גרסת ההדגמה תשתמש במקורות נתונים מובנים, וגרסת הייצור תתחבר לרשת ותשלוף נתונים.

כדי לעשות את זה ב-Lightbuild, הדרך שבה הוא מטפל בדברים כמו תצורות build שונות או גרסאות מוצר, היא שאתם נכנסים למודול האפליקציה ומציינים שמודול האפליקציה הזה הוא, למשל, אפליקציית ההדגמה.

לכן, היא תסתמך על כל רכיבי הליבה, אבל גם תמשוך הגדרות מיוחדות רק לגרסת ההדגמה של האפליקציה.

כך אפשר להשתמש בכמה מודולים של אפליקציות.

כל אחד מהם יכול לייצג, למשל, גרסה בתשלום או גרסה חינמית של האפליקציה.

אתם עדיין נהנים מהיתרונות של מודול האפליקציה כמעטפת ריקה בלי קוד, שנבנית הרבה יותר מהר. בכל פעם שהספריות משתנות, צריך לקמפל מחדש רק אותן כדי לבנות את האפליקציה שוב.

עכשיו נבדוק אם אפליקציית Now in Android נבנית בהצלחה באמצעות Lightbuild עם כל 32 המודולים השונים שלה.

כן, הנה זה.

חשוב לציין שדברים נוספים שלמדנו מניסויים כאלה הם ש-Lightbuild לא תמיד תומך בכל תכונת build שאתם צריכים.

לדוגמה, אפליקציית Android Now in Android מסתמכת על פלאגין של Hilt כדי להשתמש ב-Hilt, ו-Lightbuild עדיין לא תומך בדברים כאלה.

אז הסוכן שלי הצליח למצוא פתרון עקיף, ועדיין לקבל את התמיכה של Hilt בלי לשנות הרבה מהקוד בפרויקט עצמו.

למשל, כל הקוד בכל המודולים האלה זהה למאגר המקורי.

אבל זה משהו שבהחלט צריך לזכור כשאתם מתנסים ב-Lightbuild ומדגימים אותו בעצמכם, כי לא כל מה שיש בפרויקט הנוכחי שלכם ייתמך מבחינת תצורת ה-build.

לכן Lightbuild עדיין נמצא בגרסת טרום-השקה (Preview) ב-Android Studio Canary.

עכשיו אני רוצה לחזור למצגת.

ולסיכום כל מה שדיברנו עליו כאן, זכרו את Lightbuild, פלטפורמת פיתוח חדשה ל-Android, שנמצאת כרגע בשלב ניסיוני.

יש לו תצורת build הצהרתית, כך שלא מריצים קוד בר-ביצוע בתצורות ה-build, וזה מאפשר הרבה תכונות נהדרות עם סנכרון מהיר של IDE ו-builds יעילים יותר.

יש לו תמיכה מעולה בסוכני AI, בשורת הפקודה, יש לו את כל התכונות שעזרת לי להדגים היום.

אנחנו מזמינים אתכם לנסות אותו ולהשתמש בו לפרויקטים ניסיוניים ולהדגמות.

גם חואן ואני, וחלק מהמהנדסים בצוות, נהיה בדוכן של AI אקטיבי כדי לענות על כל שאלה.

אז תודה רבה.