Bản dựng Android khai báo, sẵn sàng cho tác nhân bằng Lightbuild

Chào các bạn!

Tôi là Juan Sebastian Oviedo.

Tôi là nhà quản lý sản phẩm trong nhóm Trải nghiệm nhà phát triển Android.

Tôi và Scott rất vui được chia sẻ với các bạn cái nhìn sơ lược về Lightbuild, một trải nghiệm bản dựng thử nghiệm mới cho ứng dụng Android.

Tôi sẽ trình bày bối cảnh của dự án này, triết lý đằng sau và lý do chúng tôi tin rằng hiện tại là thời điểm thích hợp để xem xét lại cách định cấu hình các dự án Android.

Tôi cũng sẽ trình bày cách phương pháp mới này giúp chúng ta chuẩn bị cho tương lai của việc phát triển ứng dụng Android.

Trước tiên, hãy cùng tìm hiểu bối cảnh về cách hoạt động của mọi thứ hiện nay.

Gradle và tập lệnh bản dựng bắt buộc cho phép nhà phát triển xác định theo phương thức lập trình hầu hết mọi thứ về bản dựng của họ.

Ví dụ: bạn có thể có một logic tự động tính toán mã phiên bản dựa trên nhật ký Git hoặc xác định một tác vụ tuỳ chỉnh giúp biến đổi các thành phần.

// 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"

    }

  }

}

Bên cạnh Gradle, còn có AGP hay Trình bổ trợ Android cho Gradle. Trình bổ trợ này lấy công cụ đa năng của Gradle và điều chỉnh cho phù hợp với chuỗi công cụ Android.

Gradle và AGP cùng nhau tạo thành một hệ thống linh hoạt, hỗ trợ trải nghiệm cấu hình bản dựng cho hàng triệu ứng dụng chính thức hiện nay.

Do tính linh hoạt này, các công cụ cho nhà phát triển của chúng tôi hoạt động trong một vòng đời kiến trúc cụ thể.

Khi bạn mở một dự án, chuyển đổi nhánh hoặc chỉnh sửa tệp bản dựng, IDE cần có một bản đồ rõ ràng, hiểu rõ cấu hình dự án của bạn để có thể hỗ trợ các tính năng như hoàn thành mã và điều hướng mã.

Vì các tệp bản dựng được viết bằng ngôn ngữ Turing-complete bắt buộc, nên cách chung duy nhất để IDE biết cấu hình là chạy các tập lệnh bản dựng.

Trong quá trình đồng bộ hoá IDE, hệ thống xây dựng sẽ trải qua giai đoạn định cấu hình.

Giai đoạn này đánh giá tập lệnh bản dựng, thực thi logic trình bổ trợ và xây dựng mô hình dự án.

Thao tác này sẽ điều chỉnh chế độ xem dự án của Android Studio cho phù hợp với cấu hình dự án thực tế của bạn.

Là nhà phát triển, điều bạn quan tâm nhất là cung cấp một ứng dụng Android tuyệt vời và đưa ứng dụng đó đến tay người dùng.

Tuy nhiên, việc quản lý tập lệnh bản dựng, cập nhật AGP và đồng bộ hoá dự án với IDE sẽ tốn thời gian và công sức.

Có một số sáng kiến trên cả Google và hệ sinh thái rộng lớn hơn nhằm cải thiện trải nghiệm của nhà phát triển trong lĩnh vực này.

Các sáng kiến như Gradle khai báo và chuỗi công cụ Kotlin nhằm thay thế các tập lệnh bản dựng có thể thực thi bằng cấu hình bản dựng khai báo.

Trong Android Studio, chúng tôi có Trợ lý nâng cấp AGP, hướng dẫn bạn thực hiện các thay đổi cần thiết để chuyển từ phiên bản AGP này sang phiên bản AGP khác.

Chúng tôi cũng cung cấp một kỹ năng nâng cấp mà các nhân viên hỗ trợ có thể cài đặt và làm theo để nâng cấp AGP.

Ngoài ra, chúng tôi đang đầu tư vào các lĩnh vực như đồng bộ hoá theo giai đoạn và đồng bộ hoá linh hoạt, để nhà phát triển có trải nghiệm tốt hơn khi đồng bộ hoá và nhập dự án.

Mỗi nỗ lực này đều nhắm đến một phần của vấn đề để nhà phát triển có thể dành nhiều thời gian hơn cho việc tạo ứng dụng và ít thời gian hơn cho việc xây dựng dự án, quản lý tệp bản dựng và đồng bộ hoá dự án.

Bên cạnh những nỗ lực này, chúng tôi cũng tự đặt ra một câu hỏi rộng hơn.

Điều gì sẽ xảy ra nếu chúng ta tái thiết kế cách định cấu hình dự án từ đầu?

Khi xem xét cách thiết kế các ứng dụng Android hiện đại ngày nay, chúng ta thấy một sự thay đổi lớn theo hướng mô-đun hoá mạnh mẽ.

Toàn bộ mã nguồn lớn thường có hàng chục, thậm chí hàng trăm mô-đun: mô-đun giao diện người dùng, mô-đun tính năng, mô-đun miền và mô-đun dữ liệu.

Mặc dù đôi khi ứng dụng gốc có thể cần đóng gói tuỳ chỉnh, nhưng phần lớn các mô-đun thư viện đó đều tuân theo một mẫu chuẩn hoá có thể lặp lại.

Họ không thực sự cần có mã thực thi tuỳ ý trong tệp bản dựng.

Tất cả những gì họ cần là một cách rõ ràng để nêu cấu trúc và các phần phụ thuộc của họ.

Quan sát đó đã thôi thúc chúng tôi tạo ra Lightbuild.

Lightbuild dựa trên hai trụ cột.

Trước tiên, Gradle sử dụng cú pháp khai báo để định cấu hình, giúp phân tách rõ ràng giữa cấu hình bản dựng và logic.

Thứ hai, tính năng này mang lại trải nghiệm đồng bộ hoá IDE nhanh chóng thông qua việc phân giải phần phụ thuộc trước thời hạn.

Tôi sẽ trình bày chi tiết từng trụ cột để bạn có thể thấy được mức độ ảnh hưởng của các trụ cột này đối với quy trình làm việc hằng ngày của bạn.

Hãy bắt đầu với trụ cột của cấu hình bản dựng khai báo.

Hãy xem tệp ở bên trái màn hình.

Đây là cấu hình cho một mô-đun hiện nay.

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

Vì tệp này là mã thực thi, nên tệp có thể có các định nghĩa biến cục bộ, lệnh gọi đến các hàm trợ giúp tuỳ chỉnh hoặc trình bổ trợ quy ước, câu lệnh có điều kiện và định nghĩa tác vụ cùng dòng.

Để IDE biết cấu hình này phân giải thành gì, IDE thực sự cần chạy tập lệnh.

Bây giờ, hãy xem tệp ở bên phải màn hình.

Đây là cấu hình Lightbuild cho một mô-đun tương tự.

# 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

Tệp này hoàn toàn là dữ liệu khai báo.

Không có định nghĩa biến cục bộ, không có lệnh gọi đến hàm trợ giúp tuỳ chỉnh và không có câu lệnh có điều kiện hoặc định nghĩa tác vụ cùng dòng.

Tệp này nêu rõ loại mô-đun, mục tiêu SDK và các phần phụ thuộc của mô-đun.

Nếu một kỹ sư mới tham gia nhóm của bạn và mở tệp này, họ sẽ không phải giải mã các thành ngữ bản dựng tuỳ chỉnh và mọi mô-đun Lightbuild trong mọi dự án Lightbuild đều sử dụng cùng một ngôn ngữ dễ đọc.

Mặc dù việc tách biệt giữa cấu hình và logic giúp con người dễ đọc hơn, nhưng điều này thậm chí còn mang tính biến đổi hơn đối với quy trình làm việc có sự hỗ trợ của tác nhân.

Khi nhà phát triển sử dụng tác nhân trong quy trình công việc, các tác nhân đó cần có khả năng đọc và sửa đổi cấu hình bản dựng.

Tuy nhiên, họ không có cách nào để dự đoán tác dụng phụ của việc thay đổi cấu hình ngoài việc thực sự xây dựng dự án.

Việc thêm một dòng vào tệp cấu hình có thể xung đột với một biến được tính toán linh động ở nơi khác trong dự án hoặc với một trình bổ trợ quy ước.

Trong Lightbuild, cấu hình của dự án là một biểu đồ dữ liệu tĩnh, tất định.

Điều này có nghĩa là các tác nhân có thể kiểm tra biểu đồ đó, hiểu cấu trúc liên kết của mô-đun và sửa đổi mô-đun bằng một giản đồ đã biết.

Tác nhân có thể xem danh sách mô-đun, danh sách phần phụ thuộc và phiên bản của các phần phụ thuộc đó, cập nhật phần phụ thuộc hoặc thậm chí thêm một mô-đun tính năng hoàn toàn mới chỉ bằng cách đọc và ghi dữ liệu có cấu trúc.

Tệp này giúp cấu hình của dự án trở thành một thành phần quan trọng trong quy trình làm việc có sự hỗ trợ của tác nhân.

Một chi tiết khác mà tôi muốn nhấn mạnh tại thời điểm này là Lightbuild không phải là một trình bổ trợ cho hệ thống xây dựng, mà là một giao diện cho công cụ xây dựng.

Phiên bản Lightbuild (bản xem trước mà chúng tôi phát hành hôm nay) sử dụng Gradle làm công cụ thực thi.

Tuy nhiên, phương pháp kiến trúc mà chúng tôi áp dụng với Lightbuild giúp Android Studio (IDE) xem và xử lý dự án dưới dạng dự án Lightbuild.

Bây giờ, hãy cùng tìm hiểu về trụ cột thứ hai, đó là năng suất và quy trình làm việc của nhà phát triển: đồng bộ hoá IDE nhanh.

Ngay cả khi nhà phát triển sử dụng tác nhân trong quy trình làm việc, Android Studio vẫn là một công cụ thiết yếu cho các tác vụ tương tác, chẳng hạn như xem trước giao diện người dùng Compose hoặc từng bước xem mã trong trình gỡ lỗi khi điều tra vấn đề, hoặc phân tích hiệu suất bằng trình phân tích tài nguyên.

Vì cấu hình của dự án là một biểu đồ dữ liệu tĩnh, tất định, nên IDE không cần phải trải qua giai đoạn đánh giá tập lệnh hoặc thực thi mã trình bổ trợ để hiểu dự án của bạn.

Cho dù bạn mở một dự án, chỉnh sửa tệp bản dựng hay chuyển đổi nhánh, IDE đều có thể xử lý thông tin đó một cách nhanh chóng và đưa bạn đến ngay các công cụ của mình.

Một trong những lý do giúp Lightbuild đạt được tốc độ và độ tin cậy này là cách Lightbuild xử lý các phần phụ thuộc.

Thông thường, khi bạn khai báo một phần phụ thuộc, hệ thống xây dựng cần phải đi qua một cây phần phụ thuộc bắc cầu để thu thập thông tin phiên bản và giải quyết xung đột.

Trong Lightbuild, bất cứ khi nào các phần phụ thuộc của bạn thay đổi, công cụ này sẽ tự động tính toán thông tin phần phụ thuộc bắc cầu và ghi thông tin đó vào tệp resolved.deps bên trong mỗi thư mục mô-đun.

Điều này giúp đảm bảo rằng khi dự án được mở lại trong tương lai hoặc được tạo lại, cả IDE và công cụ xây dựng đều không cần tính toán lại thông tin phần phụ thuộc bắc cầu đó.

Bạn nên kiểm tra các tệp này trong chế độ kiểm soát nguồn để khi gửi các thay đổi cho đồng đội xem xét, họ có thể thấy hai điều: liệu có bất kỳ thay đổi nào đối với thông tin phần phụ thuộc bắc cầu hay không, đồng thời máy của họ sẽ không cần tính toán lại thông tin phần phụ thuộc bắc cầu đó.

Ngoài ra, bằng cách kiểm tra thông tin này trong hệ thống kiểm soát nguồn, bạn có thể đảm bảo rằng bạn, đồng đội và quy trình CI/CD của bạn có thể tạo bản dựng với cùng một phiên bản phần phụ thuộc mỗi lần.

Chúng tôi rất vui mừng được thông báo rằng Lightbuild hiện đã có bản xem trước trong Android Studio Canary và thông qua các công cụ CLI độc lập.

Xin lưu ý rằng phiên bản Lightbuild này đang trong giai đoạn thử nghiệm nên không có tất cả các tính năng bạn cần để xây dựng và duy trì một ứng dụng chính thức.

Vui lòng tiếp tục sử dụng AGP và Gradle cho các ứng dụng chính thức trong khi dùng thử Lightbuild trong các dự án minh hoạ và thử nghiệm.

Bạn có thể bắt đầu ngay hôm nay bằng cách truy cập vào goo.gle/lightbuild. Chúng tôi rất mong nhận được ý kiến phản hồi của bạn để giúp chúng tôi định hình sản phẩm trong quá trình phát triển.

Bây giờ, tôi xin nhường lời cho Scott để anh ấy giới thiệu về Lightbuild trong thực tế.

Cảm ơn bạn, Juan.

Tôi là Scott Myers.

Tôi là Kỹ sư quan hệ nhà phát triển Android. Chúng tôi đã phát triển Lightbuild được một thời gian và rất vui được hướng dẫn bạn cách bắt đầu sử dụng và trải nghiệm công cụ này ngay hôm nay.

Vì vậy, việc đầu tiên bạn cần làm là truy cập vào đường liên kết mà Juan đã đề cập, goo.gle/lightbuild hoặc chỉ cần tìm kiếm Lightbuild.

Và bạn sẽ được chuyển đến trang tài liệu này, nơi có tất cả các bước bạn cần để bắt đầu, bao gồm cả việc cài đặt phiên bản Canary của Android Studio, vì hãy nhớ rằng phiên bản này vẫn đang ở giai đoạn xem trước, chưa có trong phiên bản ổn định của Android Studio.

Ngoài ra, bạn có thể cài đặt Lightbuild CLI để tận hưởng toàn bộ lợi ích của trải nghiệm dựa trên tác nhân với Lightbuild.

Vì vậy, sau khi thiết lập xong, như tôi đã làm trên máy của mình, tôi sẽ chạy Android Studio Canary mới nhất.

Bây giờ, tôi sẽ hướng dẫn từng bước để tạo một dự án Lightbuild minh hoạ và cho bạn thấy cách thực hiện, thậm chí là ngay hôm nay.

Trước tiên, tôi sẽ chuyển đến trình hướng dẫn Dự án mới.

Tôi sẽ chọn Empty Activity (Hoạt động trống), rồi nhấn vào Next (Tiếp theo).

Bây giờ, bạn sẽ thấy đây là màn hình chi tiết dự án thông thường, nhưng ở dưới cùng có một lựa chọn mới.

Trong phần ngôn ngữ cấu hình bản dựng, bạn có thể chọn Lightbuild.

Và hệ thống sẽ nhắc bạn rằng đây là tính năng thử nghiệm trước khi bạn nhấn vào Hoàn tất.

Và bạn sẽ thấy ngay rằng dự án của chúng ta đã được đồng bộ hoá với IDE và đang hoạt động, sẵn sàng để chúng ta làm việc.

Bây giờ, hãy cùng xem cấu trúc dự án của một dự án Lightbuild thông thường.

Vì vậy, đây chỉ là mẫu Android mặc định mà bạn nhận được khi tạo một ứng dụng mới.

Nó chỉ nói "Hello, world!"

Vì vậy, đây là một cách đơn giản để bắt đầu.

Và bạn sẽ thấy rằng ở cấp gốc của dự án, chúng ta có một tệp tên là project.lightbuild.yaml.

Thao tác này sẽ cung cấp cho chúng ta các chế độ cài đặt chung cho toàn bộ dự án.

Vì vậy, bạn có thể đặt tên cho dự án, liệt kê tất cả các mô-đun trong dự án, cho biết kho lưu trữ bên ngoài mà bạn lấy các phần phụ thuộc, sau đó là các phiên bản được áp dụng trên toàn hệ thống cho các phần khác nhau của dự án tại đây.

Như vậy, chúng ta thấy có hai mô-đun ở đây, app và app-core.

Đó là vì tất cả dự án Lightbuild đều có ít nhất hai mô-đun.

Đó là vì bạn cần có ít nhất một mô-đun ứng dụng và ít nhất một mô-đun thư viện.

Tôi sẽ giải thích lý do ngay sau đây.

Trước tiên, hãy xem mô-đun ứng dụng này.

Nếu tôi mở rộng thư mục này, bạn sẽ thấy ở cấp gốc của mô-đun có một tệp lightbuild.yaml mà mọi mô-đun đều có.

Trong đây có một số thông tin cơ bản.

Chúng tôi đang phát triển nền tảng Android.

Và mô-đun này thuộc loại ứng dụng.

Bạn có thể liệt kê các phiên bản mục tiêu của SDK, mã ứng dụng, v.v. rồi liệt kê tất cả các mô-đun mà mô-đun ứng dụng này phụ thuộc vào.

Giờ đây, điều thú vị về mô-đun ứng dụng này (hơi khác so với mẫu Android chuẩn) là không có gì trong thư mục nguồn.

Vì vậy, trong Lightbuild, các mô-đun ứng dụng không chứa mã nguồn.

Lý do là vì mô-đun ứng dụng này sẽ không thay đổi thường xuyên, nhưng cần một chút thời gian để tạo.

Vì vậy, nếu bạn giữ tất cả mã xử lý ứng dụng trong các mô-đun thư viện, thì mỗi bản dựng sẽ diễn ra nhanh hơn vì không phải tính toán lại và đóng gói lại mọi thứ trong mô-đun ứng dụng.

Tiếp theo, hãy xem mô-đun app-core, tức là mô-đun thư viện mà mô-đun ứng dụng này phụ thuộc vào.

Và bạn có thể thấy mô-đun này thực sự có mã nguồn trong đó.

Nó có logic chính của chúng ta ở đây.

Nó chỉ nói "Hello, world!"

Và nếu xem tệp lightbuild.yaml trong mô-đun này, bạn có thể thấy tệp này thuộc loại thư viện.

Và tại đây, tệp này cũng đặt một số số phiên bản SDK, nhưng liệt kê tất cả các phần phụ thuộc bên ngoài mà chúng ta có trong mô-đun này.

Và tệp này cũng khai báo các kiểm thử đơn vị và kiểm thử đo lường.

Tiếp theo, hãy xem một tệp khác mà bạn có thể đã nhận thấy ở đây. Juan đã nói một chút về tệp này, đó là tệp resolved.deps bên trong mỗi mô-đun.

Và đây là tệp do Lightbuild tự động tạo.

Vì vậy, bạn không nên chỉnh sửa tệp này theo cách thủ công, nhưng tệp này sẽ chứa danh sách tất cả các phần phụ thuộc đã được phân giải trong mô-đun này.

Vì vậy, tất cả các phần phụ thuộc và phần phụ thuộc bắc cầu của bạn đều đã có ở đây.

Điều này có nghĩa là khi ứng dụng của bạn được mở trong IDE hoặc khi bạn tạo bản dựng, bạn không cần phải tìm hiểu điều này tại thời điểm đó vì nó đã được tìm hiểu trước và được kiểm tra trong dự án của bạn.

Tiếp theo, hãy xem một ví dụ về cách Lightbuild thực sự cải thiện trải nghiệm của nhà phát triển khi đồng bộ hoá dự án.

Bây giờ, tôi sẽ quay lại tệp project.lightbuild.yaml cấp gốc, chế độ cài đặt chung ở đây liệt kê tất cả các mô-đun trong ứng dụng của tôi.

Thông thường, khi chỉnh sửa tệp cấu hình hoặc tệp cấu hình bản dựng, bạn sẽ thấy một nút đồng bộ hoá xuất hiện. Quá trình này mất một chút thời gian để xử lý tất cả các tệp đó do các quy trình mà Juan đã mô tả, trong đó nút này phải thực hiện một bản dựng một phần bằng cách thực thi tất cả tập lệnh bản dựng, sau đó đồng bộ hoá mô hình đó với IDE.

Vì vậy, hãy thực hiện một thay đổi khá lớn cho dự án nhỏ này.

Chúng ta sẽ chỉ xoá một trong các mô-đun.

Và bạn có thể thấy rằng mô-đun này, trước khi tôi nhấn nút lưu, nó được IDE nhận dạng vì bạn có thể thấy nó được in đậm ở đây.

Nó nhận dạng được thư mục nguồn, thư mục kiểm thử.

Và ngay khi tôi nhấn vào lưu, sau khi tôi thực hiện thay đổi đó, bạn có thể thấy rằng mô-đun này ngay lập tức biến mất khỏi dự án.

Và nếu tôi huỷ thay đổi đó một lần nữa rồi nhấn vào lưu, thì thay đổi đó sẽ được áp dụng lại ngay lập tức.

Đây là ví dụ về tính năng đồng bộ hoá IDE nhanh mà Lightbuild mang đến cho các dự án của bạn.

Ngoài ra, bạn có thể thực hiện tất cả các lệnh thông thường mà bạn quen dùng trong Android Studio.

Bạn có thể nhấn vào nút chạy.

Trình mô phỏng sẽ biên dịch và chạy ứng dụng của bạn tại đây.

Ứng dụng minh hoạ cụ thể này không lớn lắm, nhưng tôi sẽ phóng to để cho thấy ứng dụng này đang hiển thị dòng chữ "Hello Android".

Bạn có thể chạy kiểm thử như bình thường bằng cách chuyển đến tệp kiểm thử, chạy tệp đó từ rãnh như thế này.

Và thực tế là Lightbuild đang được gọi ở chế độ nền để chạy các kiểm thử này.

Vì vậy, tất cả những điều này đều hoạt động như bạn mong đợi.

Nhưng tiếp theo, tôi muốn cho bạn biết cách sử dụng Lightbuild nếu bạn không dùng Android Studio, nếu bạn đang sử dụng một quy trình tác nhân khác.

Và để làm được điều đó, chúng ta có dòng lệnh.

Vì vậy, trong CLI cho Lightbuild, tôi sẽ chỉ chạy lệnh trợ giúp cơ bản.

Và đúng vậy, tất cả lỗi chính tả mà bạn thấy trong dự án này hôm nay đều là của tôi.

Vì vậy, Lightbuild sẽ có một số lệnh khác nhau được tích hợp sẵn, chẳng hạn như Ôi, xin lỗi, tôi đang chạy lệnh này bên ngoài một dự án.

Nó cứ nói với tôi như vậy.

Có, bản minh hoạ trực tiếp.

Vì vậy, trước tiên, trước khi chạy bất kỳ lệnh Lightbuild nào, tôi sẽ tạo một dự án Lightbuild.

Và để làm việc đó, tôi sẽ sử dụng lệnh android create, đây là công cụ dòng lệnh tiêu chuẩn của chúng tôi để tạo mẫu dự án mới.

Tôi sẽ dùng mẫu empty-activity-lightbuild và đặt tên cho ứng dụng là Lightbuild Demo, rồi đặt ứng dụng đó vào thư mục đầu ra của bản minh hoạ.

Được rồi, giờ nếu tôi nhập thư mục đó và nhập lightbuild -h, tôi sẽ thấy tất cả các lệnh khác nhau mà Lightbuild có.

Vì vậy, chúng ta có nhiều thứ mà bạn mong đợi: bản dựng, dọn dẹp, kiểm thử.

Nhưng có một số tính năng mới.

Có một lệnh giải quyết, thực sự chạy qua các phần phụ thuộc của dự án và tạo ra các tệp resolved.deps mà tôi đã trình bày trước đó.

Ngoài ra, còn có một lệnh truy vấn giúp bạn và các tác nhân hiểu rõ hơn về cấu trúc của dự án.

Trước tiên, hãy để tôi giới thiệu lệnh truy vấn mới.

Vì vậy, nếu tôi chỉ xem cấu trúc của dự án này bằng dòng lệnh, thì cấu trúc này giống với cấu trúc tôi có trong bản minh hoạ Android Studio.

Nhưng điều này không cho tôi biết nhiều về cách bố trí dự án.

Vì vậy, nếu tôi thực hiện truy vấn lightbuild và xem xét, chẳng hạn như mô-đun ứng dụng này, tôi sẽ sử dụng cú pháp đặc biệt này để nói: "Cho tôi xem mọi thứ trong mô-đun ứng dụng này".

Và nó cung cấp cho tôi bảng mục tiêu khác nhau mà tôi có thể tạo trong mô-đun ứng dụng.

Vì vậy, thư mục này có các tệp APK và AAB cho cả tệp nhị phân gỡ lỗi và phát hành.

Và nếu tôi chỉ chạy mục tiêu ứng dụng, thì mục tiêu này sẽ tạo mọi thứ.

Ngoài ra, bạn cũng có thể chỉ định kết quả đầu ra dưới dạng JSON.

Và theo cách đó, ồ, xin lỗi.

Một lần nữa, tất cả lỗi chính tả của tôi hôm nay đều là thật.

Để tôi dùng tính năng trợ giúp tương tác của Lightbuild để đảm bảo tôi đang làm đúng cách.

Hừm…

Yeah, that should be working.

Được rồi.

Nếu ai đó có thể chỉ ra tôi đang làm sai điều gì, hãy nói chuyện với tôi sau buổi nói chuyện này.

Nhưng dù sao thì thay vì bảng này, bạn cũng có thể xuất các lệnh Lightbuild dưới dạng JSON, giúp các tác nhân dễ dàng hơn.

--format json…

Ồ, định dạng.

Ồ, xin lỗi.

Cảm ơn bạn.

Đây là ý kiến phản hồi trực tiếp của nhà phát triển.

Cảm ơn bạn.

Được rồi, đúng vậy, và còn có lệnh đầu ra mà tôi cũng có thể minh hoạ, có thể là với sự trợ giúp của bạn.

Vì vậy, nếu tôi xuất các tệp thay vì các mục tiêu, thì thao tác này sẽ cho tôi biết vị trí của tất cả các tệp nhị phân khác nhau trong bản dựng của tôi.

Vì vậy, đây chỉ là một cách để bạn và các tác nhân có thể khám phá, hiểu rõ hơn về dự án của mình từ dòng lệnh bằng Lightbuild.

Sau đó, rõ ràng là có lệnh lightbuild resolve mà tôi đã đề cập trước đó, lệnh này sẽ tạo tất cả các tệp resolved.deps của bạn.

Phiên bản đó cũng có một số tính năng bổ sung.

Ví dụ: có tham số phần phụ thuộc bị khoá này, và nhờ đó, thay vì chỉ tạo các tệp này, tham số này sẽ thực sự so sánh nội dung của các tệp với phần phụ thuộc mà bạn đã khai báo trong cấu hình bản dựng.

Nếu có bất kỳ điểm khác biệt nào, công cụ này sẽ thông báo cho bạn và không tạo bản dựng.

Vì vậy, theo cách đó, các tệp phần phụ thuộc đã phân giải này có thể hoạt động như tệp khoá, ví dụ: nếu đang xây dựng ứng dụng trong hệ thống CI/CD cho phiên bản chính thức, bạn sẽ muốn biết liệu có phần phụ thuộc nào thay đổi trong quá trình xây dựng đó hay không.

Ngoài ra, Lightbuild còn có một tính năng kiểm thử tích hợp sẵn và bạn cũng có thể chạy tất cả các kiểm thử trong mô-đun thư viện này, chẳng hạn như ngay từ dòng lệnh.

Và còn một điều nữa tôi muốn giới thiệu.

Chỉ là công cụ này cũng có phần trợ giúp cung cấp cho bạn danh sách đầy đủ về tất cả các bản dựng của tất cả tham số và lệnh phụ mà bạn có thể sử dụng.

Tác nhân của bạn có thể sử dụng thông tin đó, nên đây là kết quả cho tác nhân.

Được rồi.

Bây giờ, sau khi chúng ta đã xem một số dự án đơn giản với Lightbuild, tôi muốn cho bạn thấy một dự án có quy mô lớn hơn một chút.

Vì vậy, chúng tôi có một ứng dụng mẫu do nhóm Android cung cấp, có tên là Now in Android. Ứng dụng này cung cấp cho bạn một số tính năng mới nhất của Android, hướng dẫn bạn cách sử dụng các tính năng đó và giới thiệu một số phương pháp hay nhất.

Đây là một ứng dụng có tính mô-đun cao.

Nó được chia thành khoảng 32 mô-đun khác nhau.

Đây là giao diện trong GitHub.

Nhưng tôi sẽ chuyển về Android Studio, nơi tôi đã sử dụng tác nhân của mình từ trước.

Tôi đã dùng Gemini Argon để chuyển đổi dự án Android Now in Android sang Lightbuild.

Vì vậy, đây không phải là nội dung chúng tôi đã xuất bản, mà chỉ là nội dung tôi tự làm.

Và bạn có thể thấy rằng mặc dù dự án này trong project.lightbuild.yaml của tôi có tất cả các mô-đun khác nhau này, nhưng nó vẫn mở cực kỳ nhanh và đồng bộ hoá với IDE này một cách rất nhanh chóng.

Một điều khác mà bạn cần lưu ý về dự án cụ thể này là dự án này sử dụng một số phiên bản bản dựng hoặc cấu hình bản dựng đặc biệt để có cả bản dựng minh hoạ và bản dựng chính thức, mỗi bản dựng có cách trình bày ứng dụng hơi khác nhau.

Phiên bản minh hoạ sẽ sử dụng các nguồn dữ liệu tích hợp sẵn, còn phiên bản chính thức sẽ thực sự kết nối với mạng và lấy dữ liệu.

Để làm được điều đó với Lightbuild, cách công cụ này xử lý những thứ như cấu hình bản dựng hoặc phiên bản sản phẩm khác nhau là bạn truy cập vào mô-đun ứng dụng và chỉ định rằng mô-đun ứng dụng này là ứng dụng minh hoạ.

Do đó, phiên bản này sẽ dựa vào tất cả thành phần cốt lõi, nhưng cũng lấy các chế độ cài đặt đặc biệt chỉ dành cho phiên bản minh hoạ của ứng dụng.

Vì vậy, theo cách này, bạn có thể có nhiều mô-đun ứng dụng.

Mỗi phiên bản có thể đại diện cho một phiên bản có tính phí hoặc miễn phí của ứng dụng.

Và bạn vẫn nhận được lợi ích từ việc mô-đun ứng dụng là một vỏ trống không có mã trong đó, được tạo nhanh hơn nhiều và bất cứ khi nào thư viện của bạn thay đổi, chỉ những thư viện đó mới cần được biên dịch lại để tạo lại ứng dụng.

Giờ hãy cùng xem ứng dụng Now in Android này có được tạo thành công bằng Lightbuild với tất cả 32 mô-đun khác nhau hay không.

Đúng vậy, chính là nó.

Và tôi muốn chỉ ra rằng chúng tôi còn học được nhiều điều khác khi thực hiện các thử nghiệm như thế này, đó là Lightbuild không phải lúc nào cũng hỗ trợ mọi tính năng bản dựng mà bạn có thể cần.

Ví dụ: ứng dụng Now in Android dựa vào một trình bổ trợ Hilt để sử dụng Hilt, nhưng Lightbuild chưa hỗ trợ loại trình bổ trợ đó.

Vì vậy, nhân viên hỗ trợ của tôi đã tìm ra giải pháp và vẫn có thể hỗ trợ Hilt mà không cần thay đổi nhiều mã trong chính dự án.

Ví dụ: tất cả mã trong tất cả các mô-đun này đều giống với kho lưu trữ ban đầu.

Nhưng đó là điều bạn chắc chắn cần lưu ý khi thử nghiệm và minh hoạ Lightbuild, đó là không phải mọi thứ trong dự án hiện tại của bạn đều được hỗ trợ về mặt cấu hình bản dựng.

Đó là lý do Lightbuild vẫn đang trong giai đoạn xem trước, vẫn trong Android Studio Canary.

Giờ thì tôi muốn quay lại trang trình bày.

Và để tóm tắt mọi nội dung chúng ta đã thảo luận, hãy nhớ rằng Lightbuild là một nền tảng bản dựng mới cho Android, hiện đang trong giai đoạn thử nghiệm.

Nó có cấu hình bản dựng khai báo, vì vậy, bạn không chạy bất kỳ mã thực thi nào trong cấu hình bản dựng của mình và điều đó mở ra nhiều tính năng tuyệt vời với tính năng đồng bộ hoá IDE nhanh và các bản dựng hiệu quả hơn.

Nó có hỗ trợ tác nhân AI hàng đầu, ở dòng lệnh, nó có tất cả những tính năng mà bạn đã giúp tôi minh hoạ hôm nay.

Vì vậy, chúng tôi mời bạn dùng thử và sử dụng Gemini cho các dự án minh hoạ và thử nghiệm.

Ngoài ra, tôi, Juan và một số kỹ sư trong nhóm sẽ có mặt tại gian hàng AI tác nhân để giải đáp mọi thắc mắc của bạn.

Cảm ơn các bạn rất nhiều!