AAB — คืออะไร ความแตกต่างจาก APK และหลักการทำงาน

AAB คืออะไร

AAB (Android App Bundle) เป็นรูปแบบการเผยแพร่ที่พัฒนาโดย Google เพื่อแทนที่ APK สำหรับการจัดจำหน่ายผ่าน Google Play ภายใน AAB คือไฟล์ ZIP ที่มีนามสกุล .aab ซึ่งประกอบด้วยโค้ดที่คอมไพล์แล้ว ทรัพยากร และเมตาดาตา ความแตกต่างหลัก: AAB ไม่ได้ถูกติดตั้งโดยตรงบนอุปกรณ์

วิธีการทำงาน

นักพัฒนาอัปโหลด AAB ไปยัง Google Play Console เมื่อผู้ใช้พยายามติดตั้งแอปพลิเคชัน Google Play จะวิเคราะห์การกำหนดค่าอุปกรณ์: ความหนาแน่นของหน้าจอ (DPI), สถาปัตยกรรม CPU, ภาษา และเวอร์ชัน Android จากการวิเคราะห์นี้ จะสร้าง APK ขนาดเล็กที่สุดที่มีเฉพาะส่วนประกอบที่จำเป็นเท่านั้น

ประวัติการนำไปใช้

Google เปิดตัว AAB ในปี 2018 ในงานประชุม I/O ตั้งแต่เดือนสิงหาคม 2021 รูปแบบนี้กลายเป็นข้อบังคับสำหรับแอปพลิเคชันใหม่ทั้งหมดบน Google Play แอปพลิเคชันที่มีอยู่สามารถใช้ APK ต่อไปได้ แต่แอปพลิเคชันใหม่จะต้องเผยแพร่ในรูปแบบ AAB เท่านั้น

AAB แตกต่างจาก APK อย่างไร

ความแตกต่าง ระหว่าง AAB และ APK นั้นเป็นพื้นฐาน: APK เป็นไฟล์ติดตั้งที่สมบูรณ์พร้อมสำหรับการติดตั้ง AAB คือคอนเทนเนอร์ที่มีส่วนประกอบต้นทางที่ต้องการการประมวลผล

APK เหมาะสำหรับการจัดจำหน่ายนอก Google Play — ผ่านเว็บไซต์ อีเมล หรือระบบ MDM ขององค์กร AAB ผูกติดกับโครงสร้างพื้นฐานของ Google Play และไม่สามารถติดตั้งได้โดยตรง สำหรับการทดสอบ AAB จะใช้เครื่องมือ bundletool ซึ่งจำลองการสร้าง APK บนเครื่องท้องถิ่น

โครงสร้างไฟล์ AAB

โครงสร้างภายในของ AAB คล้ายกับ APK แต่มีไดเรกทอรีและไฟล์เพิ่มเติมสำหรับอธิบายโมดูลและการพึ่งพาของโมดูล

โมดูลพื้นฐาน (base)

โมดูล base เป็นส่วนประกอบบังคับของ AAB ประกอบด้วยโค้ดหลัก ทรัพยากร และ manifest ของแอปพลิเคชัน หากไม่มีโมดูลพื้นฐาน จะไม่สามารถสร้างแอปพลิเคชันได้ โมดูลอื่น ๆ ทั้งหมดเป็นทางเลือกและเชื่อมต่อผ่าน Dynamic Delivery

รูปแบบ Protobuf

การกำหนดค่า AAB ใช้ Protocol Buffers (protobuf) แทน XML ไฟล์ .pb มีขนาดกะทัดรัดกว่าและถูกแยกวิเคราะห์ได้เร็วกว่าโดยโครงสร้างพื้นฐานเซิร์ฟเวอร์ของ Google เครื่องมือ bundletool จะแปลง protobuf เป็นรูปแบบที่อ่านได้สำหรับการดีบัก

Dynamic Delivery และโมดูลแอปพลิเคชัน

Dynamic Delivery เป็นเทคโนโลยีหลักที่ AAB สร้างขึ้นมา ช่วยให้สามารถส่งให้ผู้ใช้เฉพาะส่วนของแอปพลิเคชันที่ตรงกับอุปกรณ์และภาษาของพวกเขา รวมถึงโหลดโมดูลเพิ่มเติมตามคำขอ

ประเภทของโมดูล

โมดูล Install-time จะถูกโหลดพร้อมกับ APK พื้นฐานระหว่างการติดตั้ง โมดูล Conditional จะถูกส่งเมื่อตรงตามเงื่อนไขเท่านั้น — ตัวอย่างเช่น โมดูลที่มีเนื้อหาสำหรับหน้าจอ 4K โมดูล On-demand จะถูกโหลดตามคำขอของผู้ใช้ภายในแอปพลิเคชัน

Play Asset Delivery (PAD)

สำหรับทรัพยากรขนาดใหญ่ (สูงสุด 2 GB) จะใช้ Play Asset Delivery แทนไฟล์ OBB PAD รองรับโหมดการส่งสามโหมดเดียวกัน: install-time, fast-follow (ทันทีหลังจากติดตั้ง) และ on-demand

// การโหลดโมดูลตามคำขอผ่าน SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

val request = SplitInstallRequest
    .newBuilder()
    .addModule("level_pack_3")
    .build()

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Module installed")
    }

การกำหนดค่าโมดูลใน Gradle

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

การสร้าง AAB ผ่าน Gradle

การสร้าง AAB ทำผ่าน Android Gradle Plugin ด้วยงาน bundleRelease (หรือ bundleDebug) ผลลัพธ์คือไฟล์ .aab ในไดเรกทอรี build/outputs/bundle/

การกำหนดค่าการสร้าง

ไม่จำเป็นต้องมีการกำหนดค่าพิเศษสำหรับการสร้าง AAB — Android Gradle Plugin รองรับ Bundle โดยค่าเริ่มต้น เพียงระบุงาน bundle แทน assemble

// build.gradle.kts — การสร้าง AAB พร้อมลายเซ็น
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// งาน: ./gradlew bundleRelease

การทดสอบภายในเครื่องผ่าน bundletool

Google มีเครื่องมือ bundletool สำหรับสร้าง APK จาก AAB บนเครื่องท้องถิ่น คำสั่ง `bundletool build-apks --bundle=app.aab --output=app.apks` จะสร้างชุด APK สำหรับทดสอบบนการกำหนดค่าอุปกรณ์ต่าง ๆ

bundletool ยังสามารถแตกไฟล์ AAB แสดงการกำหนดค่า และตรวจสอบความสมบูรณ์ของลายเซ็นก่อนอัปโหลดไปยัง Google Play Console สำหรับการดีบัก จะใช้คำสั่ง `bundletool dump manifest --bundle=app.aab` เพื่อแสดง manifest ของโมดูลพื้นฐาน

การกำหนดค่า Split ใน AAB

โดยค่าเริ่มต้น AAB จะแบ่งทรัพยากรตามสามมิติ: ภาษา ความหนาแน่นของหน้าจอ (density) และสถาปัตยกรรม CPU (abi) นักพัฒนาสามารถปิดการแบ่งใด ๆ ใน build.gradle — ตัวอย่างเช่น หากแอปพลิเคชันรองรับเฉพาะภาษาอังกฤษ การปิดการแบ่งหมายความว่าทรัพยากรสำหรับทุกรูปแบบจะรวมอยู่ใน APK พื้นฐาน

การปรับทรัพยากรให้เหมาะสม — AAB จะแปลง PNG เป็น WebP โดยอัตโนมัติโดยไม่สูญเสียคุณภาพ บีบอัดทรัพยากรที่ไม่ได้ใช้ และลบสตริงที่ซ้ำกัน การปรับให้เหมาะสมเหล่านี้จะถูกนำไปใช้ฝั่ง Google Play เมื่อสร้าง APK สุดท้าย ผลลัพธ์คือผู้ใช้ได้รับ APK ที่เล็กกว่าไฟล์เก็บถาวรเต็ม 15–25%

การเผยแพร่ AAB บน Google Play

กระบวนการเผยแพร่ AAB ใน Google Play Console แตกต่างจาก APK เฉพาะรูปแบบของไฟล์ที่อัปโหลด คอนโซลจะรับไฟล์ .aab ตรวจสอบโครงสร้าง ลายเซ็น และการกำหนดค่าโมดูล จากนั้นสร้าง APK สำหรับอุปกรณ์แต่ละประเภท

App Signing by Google Play

เมื่ออัปโหลด AAB Google Play จะจัดการการจัดการคีย์ลายเซ็น นักพัฒนาอัปโหลดแพ็กเกจที่ลงนามด้วยคีย์ upload และ Google ลงนาม APK ที่สร้างขึ้นใหม่ด้วยคีย์ของตัวเอง การดำเนินการนี้ช่วยลดความซับซ้อนในการหมุนเวียนคีย์และการกู้คืนการเข้าถึงหากสูญเสีย keystore

การทดสอบก่อนเผยแพร่

Google Play Console มี การทดสอบ AAB ในตัว: คุณสามารถดาวน์โหลด APK ที่สร้างขึ้นสำหรับอุปกรณ์เฉพาะ หรือเรียกใช้การทดสอบภายในผ่านแทร็ก Internal Testing, Closed Alpha และ Open Beta

ปัญหาทั่วไปเกี่ยวกับ AAB และวิธีแก้ไข

การย้ายไปยัง AAB อาจทำให้เกิดปัญหา โดยเฉพาะในโครงการที่มีโมดูลไดนามิกจำนวนมากหรือการกำหนดค่าทรัพยากรที่ซับซ้อน

ข้อผิดพลาดการกำหนดค่าโมดูล

หากโมดูลไดนามิกอ้างอิงทรัพยากรของโมดูลพื้นฐานด้วยชื่อที่ไม่ถูกต้อง Google Play จะปฏิเสธ AAB ในขั้นตอนการตรวจสอบ วิธีแก้ไข — ใช้การตรวจสอบ lint ก่อนสร้างและทดสอบโมดูลทั้งหมดผ่าน bundletool ในเครื่อง

การแบ่งภาษาและผลกระทบต่อประสิทธิภาพ

การแบ่งตามภาษาอาจทำให้การเริ่มต้นแอปพลิเคชันช้าลงหากทรัพยากรสำหรับสถานที่ปัจจุบันถูกโหลดแบบไดนามิก คำแนะนำของ Google คือไม่ควรแบ่งภาษาหากมีน้อยกว่า 10 ภาษา หรือใช้ install-time สำหรับภาษาที่ได้รับความนิยมมากที่สุด

ความเข้ากันได้กับ SDK ของบุคคลที่สาม

SDK บางตัว (การวิเคราะห์ โฆษณา แผนที่) ต้องการเข้าถึง manifest และทรัพยากรทั้งหมด การตรวจสอบความเข้ากันได้กับ AAB เป็นขั้นตอนบังคับก่อนการย้าย SDK หลักส่วนใหญ่ (Firebase, Google Ads, Crashlytics) รองรับ AAB อย่างเต็มรูปแบบตั้งแต่ปี 2022 สำหรับการตรวจสอบความเข้ากันได้ จะใช้ bundletool พร้อมแฟล็ก --validate ซึ่งจำลองการสร้าง APK ฝั่งเซิร์ฟเวอร์

การกำหนดเวอร์ชัน AAB

AAB ใช้ versionCode จาก manifest ของโมดูลพื้นฐาน ซึ่งแตกต่างจาก APK ตรงที่ AAB รองรับ versionCode แยกต่างหากสำหรับแต่ละโมดูล — ซึ่งช่วยให้อัปเดตแต่ละส่วนของแอปพลิเคชันได้โดยไม่ต้องติดตั้งใหม่ทั้งหมด Dynamic Delivery ติดตามโมดูลที่ติดตั้งไว้และส่งเฉพาะส่วนประกอบที่เปลี่ยนแปลงระหว่างการอัปเดตผ่าน Google Play

การตรวจสอบและการวิเคราะห์ AAB

Google Play Console ให้การวิเคราะห์โดยละเอียดสำหรับแต่ละ AAB: จำนวน APK ที่สร้างขึ้น, Split ใดที่เป็นที่ต้องการ, ขนาดดาวน์โหลดเฉลี่ยต่ออุปกรณ์ Android Vitals แสดงเมตริกประสิทธิภาพของ APK ที่สร้างขึ้น ข้อมูลนี้ช่วยปรับการกำหนดค่า Split ให้เหมาะสมและลดขนาดดาวน์โหลดสำหรับอุปกรณ์ประเภทต่าง ๆ