Build Type — คืออะไร, การกำหนดค่า debug และ release ใน Gradle

Build Type คืออะไร?

Build Type คือองค์ประกอบของการกำหนดค่า Gradle ในโปรเจกต์ Android ที่อธิบายพารามิเตอร์การคอมไพล์และการบรรจุของแอปพลิเคชัน แต่ละ Build Type คือชุดตัวเลือกที่มีชื่อ: debuggable (เปิดใช้งานการดีบัก), minificationEnabled (เปิดใช้งานการบีบอัดโค้ด), shrinkResources (เปิดใช้งานการบีบอัดทรัพยากร), proguardFiles (ไฟล์กฎ ProGuard), signingConfig (ใบรับรองการลงนาม) และอื่นๆ Build Types ถูกประกาศในบล็อก android.buildTypes ของไฟล์ build.gradle ของโมดูล app

วัตถุประสงค์หลักของ Build Type คือการแยก ขั้นตอนการทำงานของนักพัฒนา (บิวด์ที่รวดเร็ว, บันทึกโดยละเอียด, การดีบัก) ออกจาก การเผยแพร่โปรดักชัน (โค้ดที่ปรับให้เหมาะสม, ขนาดเล็กที่สุด, ความปลอดภัย) บิวด์ debug ควรคอมไพล์ภายในไม่กี่วินาทีและให้ข้อมูลสูงสุดแก่นักพัฒนา บิวด์ release ควรเร็วและกะทัดรัดที่สุดเท่าที่เป็นไปได้สำหรับผู้ใช้ Build Type คือการตั้งค่าโครงสร้างพื้นฐานที่ไม่เกี่ยวข้องกับฟังก์ชันการทำงานของแอปพลิเคชัน

Android Gradle Plugin จะสร้าง source set โดยอัตโนมัติสำหรับแต่ละ Build Type — ไดเรกทอรี src/<buildType>/ (เช่น src/debug/, src/release/) ทรัพยากร โค้ด และไฟล์แมนิเฟสต์ที่วางใน source set นี้จะใช้กับบิวด์ประเภทนั้นเท่านั้น ตัวอย่างเช่น ใน src/debug/ สามารถวาง AndroidManifest.xml ที่มีสิทธิ์การติดตั้งจาก ADB ในขณะที่ src/release/ ไม่มี Source set ของ Build Type มีลำดับความสำคัญเหนือ source set ของ Product Flavor

Build Type กับ Product Flavor ต่างกันอย่างไร

ความแตกต่างหลัก: Build Type ตอบคำถาม "สร้างอย่างไร?" ในขณะที่ Product Flavor ตอบคำถาม "สร้างอะไร?" Build Type สามารถเป็น debug, release, staging Product Flavor สามารถเป็น free, paid, enterprise Build Type ไม่เปลี่ยนฟังก์ชันการทำงานของแอปพลิเคชัน (ไม่เพิ่มหรือลบหน้าจอ) แต่ Product Flavor เปลี่ยนได้ Build Type สามารถปิดดีบักเกอร์และเปิดการทำให้สับสนได้ Product Flavor สามารถเปลี่ยน applicationId และทรัพยากรได้ ทั้งสองทำงานร่วมกัน: แต่ละ Build Type รวมกับแต่ละ Product Flavor เพื่อสร้าง Build Variant

Build Types มาตรฐาน: debug และ release

Debug คือ Build Type ที่ AGP สร้างโดยค่าเริ่มต้น โดยมี debuggable=true ซึ่งอนุญาตให้เชื่อมต่อดีบักเกอร์ ดูบันทึก Log.d และใช้โปรไฟเลอร์ของ Android Studio Minification ถูกปิดใช้งาน ดังนั้นบิวด์จึงรวดเร็ว ในบิวด์ debug applicationId จะได้รับคำต่อท้าย ".debug" (หากไม่ได้ถูกแทนที่) ทำให้สามารถติดตั้งเวอร์ชัน debug ควบคู่ไปกับเวอร์ชัน release บนอุปกรณ์เดียวกันได้ บิวด์ debug ลงนามด้วยใบรับรองจาก debug.keystore ซึ่ง Android SDK สร้างขึ้นโดยอัตโนมัติ

Release คือ Build Type สำหรับเผยแพร่แอปพลิเคชัน debuggable=false, minificationEnabled=true (ค่าเริ่มต้น), shrinkResources=true นักพัฒนาต้องระบุ signingConfig พร้อมใบรับรองโปรดักชัน ไม่เช่นนั้นบิวด์จะไม่ถือเป็นบิวด์ release บิวด์ release ใช้ ProGuard หรือ R8 สำหรับการทำให้สับสน เพิ่มประสิทธิภาพ และบีบอัดโค้ด Android Studio ไม่สามารถเชื่อมต่อดีบักเกอร์กับบิวด์ release (ถ้า debuggable=false) การเรียก Log.d และ Log.v ทั้งหมดจะถูกลบออกจากโค้ดระหว่าง minification หากมีการกำหนดกฎ ProGuard ที่เหมาะสม

สำคัญ: บิวด์ debug ไม่ได้ทดสอบพฤติกรรมของ release Minification สามารถเปลี่ยนพฤติกรรมของโค้ดได้ — การสะท้อน (reflection), การทำให้เป็นอนุกรม, Gson/SQLite และไลบรารีอื่นๆ มักต้องการกฎ ProGuard ดังนั้น ควรสร้างและทดสอบบิวด์ release ก่อนเผยแพร่เสมอ Google Play Console และ Firebase Test Lab อนุญาตให้อัปโหลดบิวด์ release สำหรับการทดสอบอัตโนมัติบนอุปกรณ์จริงก่อนเผยแพร่

android {
    buildTypes {
        debug {
            debuggable true
            minification false
            signingConfig signingConfigs.debug
            versionNameSuffix "-debug"
        }

        release {
            debuggable false
            minification true
            shrinkResources true
            proguardFiles "proguard-rules.pro"
            signingConfig signingConfigs.release
            ndk { abiFilters "arm64-v8a", "x86_64" }
        }
    }
}

การสร้าง Build Types แบบกำหนดเอง

การสืบทอดผ่าน initWith

นอกเหนือจาก debug และ release แล้ว ยังสามารถสร้าง Build Types แบบกำหนดเองได้ — ตัวอย่างเช่น staging (สภาพแวดล้อมกลาง) หรือ benchmark (สำหรับทดสอบประสิทธิภาพ) Build Type แบบกำหนดเองถูกประกาศในบล็อก buildTypes เช่นเดียวกับ debug และ release ชื่อสามารถเป็นอะไรก็ได้ แต่แนะนำให้ใช้ชื่อที่ชัดเจนในภาษาอังกฤษ สำหรับ staging โดยทั่วไปตั้งค่า debuggable=true (สำหรับวินิจฉัยปัญหาในสภาพแวดล้อม staging) และ minification=true (เพื่อทดสอบการทำให้สับสนก่อนโปรดักชัน)

Build Type แบบกำหนดเองจะได้รับ source set ที่สอดคล้องกันโดยอัตโนมัติ (src/staging/) และสร้างงานเช่น assembleStaging AGP ไม่จำกัดจำนวนประเภทแบบกำหนดเอง แต่แต่ละประเภทใหม่จะเพิ่มจำนวน Build Variants เป็นทวีคูณ ขีดจำกัดในทางปฏิบัติคือ 4-5 Build Types: debug, staging, benchmark, release และอาจรวมถึง debugMinified (debug ที่เปิด minification สำหรับทดสอบกฎ ProGuard)

สำหรับ Build Type แบบกำหนดเอง คุณสามารถสืบทอด debuggable จาก debug โดยใช้ initWith คีย์เวิร์ด initWith จะคัดลอกพารามิเตอร์ทั้งหมดของ Build Type ที่ระบุ หลังจากนั้นสามารถแทนที่ได้ สะดวกสำหรับการสร้าง staging บนพื้นฐานของ debug: initWith debug + เปิด minification เพิ่มเติม หากไม่มี initWith คุณจะต้องระบุพารามิเตอร์ทั้งหมดของประเภทพื้นฐานด้วยตนเอง

android {
    buildTypes {
        staging {
            initWith debug
            minification true
            shrinkResources true
            proguardFiles "staging-proguard-rules.pro"
            versionNameSuffix "-staging"
        }

        benchmark {
            initWith release
            signingConfig signingConfigs.debug
            matchingFallbacks = ["release"]
        }
    }
}

// matchingFallbacks — สำหรับไลบรารีที่ไม่มีประเภท benchmark
// ถ้าไลบรารีมีเฉพาะ release — AGP จะใช้มัน

การกำหนดค่าการลงนามสำหรับบิวด์ประเภทต่างๆ

SigningConfig กำหนดว่าใช้ใบรับรองใดในการลงนาม APK หรือ AAB Android กำหนดให้แอปพลิเคชันที่ติดตั้งได้ทั้งหมดต้องลงนาม — หากไม่มี ระบบจะไม่อนุญาตให้ติดตั้ง สำหรับบิวด์ debug AGP ใช้ debug.keystore — ใบรับรองที่ติดตั้งไว้ล่วงหน้าพร้อมรหัสผ่านที่รู้จักซึ่งสร้างโดย Android SDK Tools สำหรับบิวด์ release คุณต้องสร้างใบรับรองของคุณเองผ่าน Android Studio (Build → Generate Signed Bundle/APK) หรือผ่านคำสั่ง keytool

การจัดเก็บคีย์ลงนามเป็นประเด็นด้านความปลอดภัยที่สำคัญ ขอแนะนำ ไม่ให้จัดเก็บ คีย์ release ในที่เก็บซอร์สโค้ด ให้ใช้ไฟล์ keystore.properties (เพิ่มใน .gitignore), ตัวแปรสภาพแวดล้อม CI/CD หรือพื้นที่จัดเก็บที่เข้ารหัสของ Android Studio แทน ใน CI/CD (GitHub Actions, GitLab CI) คีย์ลงนามจะถูกจัดเก็บใน secrets และส่งต่อไปยัง build.gradle ผ่านคุณสมบัติของระบบ ตัวอย่าง: storePassword = System.getenv("KEYSTORE_PASSWORD")

แต่ละ Build Type สามารถอ้างอิง signingConfig ของตัวเองได้ สำหรับ release — ใบรับรองโปรดักชัน, สำหรับ debug — debug.keystore, สำหรับ staging — ใบรับรอง staging แยกต่างหาก การกำหนดค่าการลงนามส่งผลโดยตรงต่อความสามารถในการติดตั้งแอปพลิเคชัน: หากคุณลงนาม debug ด้วย debug.keystore และ staging ด้วยคีย์โปรดักชัน staging จะไม่สามารถติดตั้งทับเวอร์ชัน debug ได้เนื่องจากลายเซ็นไม่ตรงกัน applicationId ก็ต้องแตกต่างกัน — ใช้ applicationIdSuffix เพื่อการนี้

android {
    signingConfigs {
        debug {
            storeFile file("debug.keystore")
            storePassword "android"
            keyAlias "androiddebugkey"
            keyPassword "android"
        }
        release {
            storeFile file("release-key.jks")
            storePassword System.getenv("KEYSTORE_PASS")
            keyAlias "my-key"
            keyPassword System.getenv("KEY_PASS")
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

Minification, ProGuard และ R8

Resource Shrinking

Minification คือกระบวนการลบโค้ดที่ไม่ได้ใช้และเปลี่ยนชื่อคลาส เมธอด และฟิลด์เป็นชื่อสั้น AGP ดำเนินการ minification ด้วย ProGuard (แบบเก่า) หรือ R8 (แนะนำ, ในตัวตั้งแต่ AGP เวอร์ชัน 3.4) R8 ดำเนินการสี่อย่าง: shrinking (ลบคลาสที่ไม่ได้ใช้), optimisation (ทำให้โค้ดง่ายขึ้น), obfuscation (เปลี่ยนชื่อ) และ preverify (เพิ่มข้อมูลความเข้ากันได้) ผลลัพธ์คือ APK ที่เล็กลงและถอดรหัสได้ยากขึ้น

กฎ Minification ถูกกำหนดใน ไฟล์กฎ ProGuard — ไฟล์ข้อความที่มีไวยากรณ์เช่น -keep, -dontwarn, -keepclassmembers หากไม่มีกฎ R8 จะลบหรือเปลี่ยนชื่อคลาสที่ใช้ผ่านการสะท้อน (Gson, Retrofit, Room, การทำให้เป็นอนุกรมของ Kotlin) เทมเพลตโปรเจกต์ Android Studio สร้างไฟล์ proguard-rules.pro ซึ่งเพิ่มกฎสำหรับไลบรารีเฉพาะ ไลบรารีอาจมีกฎในตัว — จะถูกรวมโดยอัตโนมัติจาก jar/aar

Shrink resources (shrinkResources=true) จะลบทรัพยากรที่ไม่ได้ใช้ออกจาก APK R8 จะกำหนดก่อนว่าทรัพยากรใดไม่ได้ใช้ในโค้ด (ตรวจสอบ R.java และการอ้างอิงในแมนิเฟสต์) จากนั้นลบออกจากบิวด์สุดท้าย สำหรับทรัพยากรที่ใช้ผ่าน getIdentifier() หรือโดยไลบรารีของบริษัทอื่น คุณต้องเพิ่ม tools:keep="@layout/my_layout" ในทรัพยากร เมื่อรวมกับ minification การย่อทรัพยากรสามารถลดขนาด APK ได้ 40-60%

# proguard-rules.pro — กฎบังคับ
# Gson: เก็บคลาสสำหรับการทำให้เป็นอนุกรม
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit: เก็บอินเทอร์เฟซ API
-keep,allowobfuscation interface com.example.api.*

# Room: เก็บ DAO และ Entity
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines: ป้องกันการลบ Continuation
-keepnames class kotlinx.coroutines.internal.*

# OkHttp: เก็บรักษา service loader
-keep class okhttp3.** { *; }

BuildConfigField และทรัพยากรสำหรับ Build Type

BuildConfig คือคลาส Java/Kotlin ที่สร้างขึ้นโดยอัตโนมัติซึ่งมีค่าคงที่ที่กำหนดใน defaultConfig, productFlavors และ buildTypes ผ่าน buildConfigField สามารถเพิ่มฟิลด์แบบกำหนดเองได้: buildConfigField "String", "API_URL", '"https://api.example.com"' BuildConfigField ที่ประกาศใน buildType สามารถใช้ได้ในทุกรูปแบบของประเภทนั้น ค่าใน buildType จะแทนที่ค่าจาก productFlavor ซึ่งจะแทนที่ defaultConfig

สำหรับบิวด์ debug สะดวกในการตั้ง API_URL เป็น localhost หรือเซิร์ฟเวอร์ staging และสำหรับ release — เป็นโปรดักชัน BuildConfig.FLAVOR และ BuildConfig.BUILD_TYPE จะถูกสร้างขึ้นโดยอัตโนมัติและมีชื่อของ flavor และ build type ปัจจุบัน ในโค้ดสามารถใช้: if (BuildConfig.DEBUG) { /* บันทึก */ } — ค่าคงที่ DEBUG เป็นจริงเฉพาะสำหรับ debug build type เท่านั้น BuildConfig.DEBUG เป็นฟิลด์มาตรฐานที่ AGP เพิ่มในทุก BuildConfig

ทรัพยากรสำหรับ Build Type ถูกกำหนดผ่าน source set src/<buildType>/res/ ตัวอย่างเช่น src/debug/res/values/strings.xml สามารถมีสตริง "Server: Dev" ในขณะที่ src/release/res/ สามารถมี "Server: Prod" ทรัพยากรแมนิเฟสต์ก็ถูกแทนที่ผ่าน source set เช่นกัน: src/debug/AndroidManifest.xml สามารถรวม <uses-permission android:name="android.permission.INTERNET" /> เฉพาะสำหรับบิวด์ debug เท่านั้น ซึ่งสะอาดกว่าการตรวจสอบ BuildConfig ในโค้ดและทำงานแม้กับแอตทริบิวต์ที่ไม่สามารถตั้งค่าผ่านโปรแกรมได้ (เช่น networkSecurityConfig)

// src/debug/kotlin/.../DebugConfig.kt
object DebugConfig {
    val apiUrl = "http://localhost:8080/api"
    val enableLogging = true
    val enableCrashReporting = false
}

// src/release/kotlin/.../ReleaseConfig.kt
object ReleaseConfig {
    val apiUrl = "https://api.production.com/v2"
    val enableLogging = false
    val enableCrashReporting = true
}

// การใช้งาน: คลาสหลักโหลด Config ผ่านการสะท้อน (reflection)
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}