Build Config trong ứng dụng di động — khái niệm, thiết lập và nguyên lý hoạt động

Build Config trong phát triển di động là gì

Build Config là tập hợp các cài đặt xác định quy trình biên dịch, xây dựng và đóng gói ứng dụng di động. Cấu hình build bao gồm lựa chọn nền tảng mục tiêu, phiên bản SDK tối thiểu, cờ tối ưu hóa, khóa ký và biến môi trường.

Các dự án di động hiện đại hiếm khi có một cấu hình build duy nhất. Thông thường chúng có nhiều cấu hình: debug (dành cho phát triển với gỡ lỗi), release (dành cho sản xuất với tối ưu hóa), staging (dành cho kiểm thử với dữ liệu thực) và các flavor khác nhau (dùng thử, đầy đủ, doanh nghiệp).

Theo Gradle Build Tool Survey (2025), một dự án Android trung bình sử dụng 3,2 cấu hình build khác nhau, trong khi dự án iOS sử dụng 2,8. Mỗi cấu hình có thể có cờ biên dịch, chứng chỉ ký và URL máy chủ riêng.

Nhiệm vụ chính của Build Config là tự động hóa việc chuyển đổi giữa các cấu hình này. Thay vì thay đổi thủ công URL máy chủ hoặc cờ gỡ lỗi, nhà phát triển chọn Build Variant mong muốn trong IDE và hệ thống build sẽ tự động áp dụng các tham số tương ứng.

Việc thiết lập Build Config đúng cách ảnh hưởng nghiêm trọng đến bảo mật ứng dụng: bản build debug bao gồm log chi tiết, trình kiểm tra cơ sở dữ liệu và các endpoint gỡ lỗi cần được loại trừ vật lý khỏi tệp nhị phân release. Gradle giải quyết điều này thông qua Build Types: debug có thể có cờ debuggable true, release — minifyEnabled true với ProGuard. iOS đạt được điều tương tự thông qua Swift Active Compilation Conditions, nơi mã bên trong #if DEBUG không được biên dịch trong cấu hình release.

Build Config trong Android: Gradle và BuildConfig

Android sử dụng hệ thống build Gradle với hai khái niệm chính: Build Types và Product Flavors. Sự kết hợp của chúng tạo thành Build Variants — mỗi biến thể có cấu hình build hoàn chỉnh riêng.

Build Types: Debug và Release

Build Type là cấu hình xác định cách ứng dụng được xây dựng. Theo mặc định, Gradle tạo hai loại: debug (có gỡ lỗi, không làm rối mã) và release (có ProGuard/R8, đã ký để phát hành). Nhà phát triển có thể thêm loại riêng: staging, benchmark, qa.

// build.gradle.kts
android {
    buildTypes {
        debug {
            isDebuggable = true
            buildConfigField("String", "API_URL", "\"http://dev.api.com\"")
        }
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
            buildConfigField("String", "API_URL", "\"https://prod.api.com\"")
        }
    }
}

Product Flavors: Phiên bản ứng dụng

Product Flavors cho phép tạo các phiên bản khác nhau của cùng một ứng dụng từ một mã nguồn duy nhất. Ví dụ: phiên bản miễn phí có quảng cáo, phiên bản trả phí không quảng cáo và phiên bản doanh nghiệp có tính năng bổ sung. Mỗi flavor có thể có applicationId, tài nguyên và phụ thuộc SDK riêng.

android {
    productFlavors {
        register("demo") {
            applicationId = "com.example.app.demo"
            versionNameSuffix = "-demo"
        }
        register("full") {
            applicationId = "com.example.app"
            versionNameSuffix = ""
        }
    }
}

Lớp BuildConfig: Truy cập từ mã

Cho mỗi Build Variant, Gradle tạo một lớp BuildConfig với các trường cấu hình. Nhà phát triển thêm trường tùy chỉnh qua buildConfigField, trong khi các trường tiêu chuẩn (DEBUG, APPLICATION_ID, BUILD_TYPE, VERSION_CODE, FLAVOR) được tạo tự động.

// Sử dụng BuildConfig trong mã
class NetworkModule {
    fun createApiClient(): ApiClient {
        return if (BuildConfig.DEBUG) {
            ApiClient(
                baseUrl = BuildConfig.API_URL,
                interceptor = HttpLoggingInterceptor()
            )
        } else {
            ApiClient(baseUrl = BuildConfig.API_URL)
        }
    }
}

BuildConfig cũng cho phép bật hoặc tắt chức năng tại thời điểm build. Ví dụ: bạn có thể thêm trường FEATURE_CHAT_ENABLED và chỉ bật trò chuyện trong phiên bản đầy đủ của ứng dụng, mà không cần kiểm tra thời gian chạy và toán tử điều kiện trong mã.

Để gỡ lỗi yêu cầu mạng, BuildConfig với trường DEBUG cho phép tự động đính kèm HttpLoggingInterceptor trong OkHttp chỉ cho bản build debug. Điều này đảm bảo không có yêu cầu HTTP nào bị ghi log trong sản xuất, ngay cả khi nhà phát triển vô tình quên xóa ghi log trước khi build release.

Build Config trong iOS: Xcode và Build Settings

Trong hệ sinh thái iOS, Build Config được quản lý thông qua Xcode Build Settings — một bảng tham số nơi mỗi tham số có thể có giá trị khác nhau cho các cấu hình khác nhau (Debug, Release, Staging).

Xcode Build Configurations

Theo mặc định, Xcode tạo hai cấu hình: Debug (cho phát triển, không tối ưu hóa) và Release (cho sản xuất, với tối ưu hóa -Os). Nhà phát triển có thể thêm cấu hình riêng qua menu Project > Info > Configurations.

Cho mỗi cấu hình, Build Settings được cấu hình: cờ trình biên dịch (OTHER_SWIFT_FLAGS, GCC_PREPROCESSOR_DEFINITIONS), mã ký (CODE_SIGN_IDENTITY), hồ sơ cấp phép và entitlements. Xcode ghi các cài đặt này vào tệp project.pbxproj.

xcconfig: Tệp cấu hình bên ngoài

Để quản lý Build Settings thuận tiện, nhà phát triển iOS sử dụng tệp .xcconfig — tệp văn bản với tham số ở định dạng KEY = VALUE. Đây tương tự như .env cho Xcode: các giá trị được kết nối với dự án và ghi đè cài đặt trong project.pbxproj.

// Debug.xcconfig
BUNDLE_ID_SUFFIX = .debug
API_BASE_URL = http://localhost:8080
SWIFT_ACTIVE_COMPILATION_CONDITIONS = DEBUG
CODE_SIGN_IDENTITY = Apple Development

// Release.xcconfig
BUNDLE_ID_SUFFIX =
API_BASE_URL = https://api.production.com
SWIFT_ACTIVE_COMPILATION_CONDITIONS =
CODE_SIGN_IDENTITY = Apple Distribution

Info.plist: Cấu hình thời gian chạy

Một số tham số Build Config được đưa vào Info.plist — tệp kê khai của ứng dụng iOS. Thông qua Info.plist, các lược đồ URL, quyền (máy ảnh, micrô), chế độ nền và cấu hình đăng nhập dịch vụ bên thứ ba được thiết lập.

Giá trị từ xcconfig có thể được thay thế trong Info.plist bằng cú pháp $(VARIABLE_NAME). Ví dụ: $(API_BASE_URL) trong Info.plist sẽ được mở rộng theo cấu hình build đang hoạt động. Điều này tập trung hóa việc quản lý tham số môi trường cho tất cả nền tảng Apple.

Build Config trong pipeline CI/CD

Trong các dự án hiện đại, Build Config tích hợp với hệ thống tích hợp liên tục: GitLab CI, GitHub Actions, Bitrise, CircleCI. Mỗi pipeline có thể ghi đè tham số Build Config thông qua biến môi trường của hệ thống CI/CD.

Gradle Build Config trong CI

Đối với Android, pipeline CI chạy Gradle với Build Variant được chỉ định: ./gradlew assembleFullRelease. Tham số ký được truyền qua biến CI: STORE_PASSWORD, KEY_ALIAS. Gradle đọc chúng từ môi trường thực thi và thay thế trong build.gradle.kts.

// build.gradle.kts — đọc từ biến CI
android {
    signingConfigs {
        register("release") {
            storeFile = file(System.getenv("KEYSTORE_PATH") ?: "debug.keystore")
            storePassword = System.getenv("STORE_PASSWORD") ?: ""
            keyAlias = System.getenv("KEY_ALIAS") ?: "key"
            keyPassword = System.getenv("KEY_PASSWORD") ?: ""
        }
    }
}

Xcode Build Config trong CI

Đối với iOS, CI sử dụng xcodebuild với cờ cấu hình: -configuration Release. Chứng chỉ ký được cung cấp qua CI secrets và hồ sơ qua Apple Developer Portal API hoặc Fastlane match.

Công cụ Fastlane tự động hóa quản lý Build Config: tạo xcconfig, cập nhật phiên bản trong Info.plist, ký các IPA đã xây dựng và tải lên App Store Connect. Fastlane gym (build) và match (ký) là tiêu chuẩn cho pipeline CI iOS.

Theo Bitrise Build Report (2025), các dự án có Build Config được thiết lập trong CI giảm thời gian cấu hình build thủ công 73% và giảm lỗi ký 89%. Build Config tự động hóa là yếu tố bắt buộc của pipeline sẵn sàng sản xuất.

Một khía cạnh quan trọng khác là tham số hóa phiên bản thông qua Build Config. Gradle cho phép đọc versionCode và versionName từ biến CI và thay thế chúng trong build.gradle.kts một cách động, loại bỏ sự mất đồng bộ phiên bản giữa các nhà phát triển. Trong iOS, một tác vụ tương tự được giải quyết thông qua agvtool (Apple Generic Versioning Tool), có thể tăng số build dựa trên thẻ git hoặc số build trong CI.