การพึ่งพากันระหว่างเครื่องมือและไลบรารี

ทรัพยากร Dependency ของบิลด์เป็นคอมโพเนนต์ภายนอกที่จำเป็นต่อการสร้างโปรเจ็กต์ให้เสร็จสมบูรณ์ เวอร์ชันอาจขึ้นอยู่กับไลบรารี, ปลั๊กอิน, โปรเจ็กต์ย่อย, Android SDK, เครื่องมือ เช่น คอมไพเลอร์ Kotlin และ Java, สภาพแวดล้อมในการพัฒนาซอฟต์แวร์ เช่น Android Studio และ Gradle เอง

ทรัพยากร Dependency แต่ละรายการอาจต้องใช้การอ้างอิงอื่นๆ ได้ เราเรียกสิ่งเหล่านี้ว่าการขึ้นต่อกันแบบสับเปลี่ยน และสามารถเพิ่มทรัพยากร Dependency โดยรวมที่แอปพลิเคชันของคุณใช้ได้อย่างรวดเร็ว เมื่อต้องการอัปเกรด Dependency ไม่ว่าจะเป็นไลบรารี เครื่องมือ หรือ Android SDK การอัปเกรดดังกล่าวอาจส่งผลแบบเป็นขั้นเป็นตอน ซึ่งจะอัปเกรด Dependency อื่นๆ อีกมากมาย

ซึ่งมักจะไม่ก่อให้เกิดปัญหาใดๆ เนื่องจากไลบรารีจำนวนมากเป็นไปตามรูปแบบที่เรียกว่าการกำหนดเวอร์ชันเชิงความหมาย ไลบรารีเหล่านี้จะจำกัดประเภทการเปลี่ยนแปลงที่ทำขึ้นเพื่อความเข้ากันได้กับเวอร์ชันที่ต่ำกว่า

การกำหนดเวอร์ชันทางอรรถศาสตร์เป็นไปตามรูปแบบ major.minor.patch ตัวอย่างเช่น ในหมายเลขเวอร์ชัน 4.8.3, 4 คือเวอร์ชัน major, 8 คือเวอร์ชัน minor และ 3 คือหมายเลข patch เมื่อส่วน major มีการเปลี่ยนแปลง ไลบรารีอาจมีการเปลี่ยนแปลงที่ส่งผลอย่างมากใน API หรือลักษณะการทํางาน ซึ่งอาจส่งผลต่อลักษณะการทํางานของบิลด์หรือแอปพลิเคชัน

เมื่อส่วน minor (ฟีเจอร์ใหม่) หรือ patch (การแก้ไขข้อบกพร่อง) มีการเปลี่ยนแปลง นักพัฒนาไลบรารีจะแจ้งให้คุณทราบว่าไลบรารียังคงใช้งานร่วมกันได้และไม่ควรส่งผลกระทบต่อแอปพลิเคชันของคุณ

คุณควรคอยสังเกตการเปลี่ยนแปลงดังกล่าว และเครื่องมืออัปเกรด Dependency หลายรายการสามารถช่วยคุณได้

ความสัมพันธ์ในบิลด์

บิลด์ Android มีความสัมพันธ์ระหว่างสิ่งต่อไปนี้

• ซอร์สโค้ด - โค้ดและทรัพยากรที่คุณควบคุมได้
• ทรัพยากร Dependency ของไลบรารี - ไลบรารีหรือโมดูลภายนอกที่โปรเจ็กต์และโปรเจ็กต์ย่อยของคุณรวมไว้เมื่อสร้าง
• เครื่องมือ - คอมไพเลอร์ ปลั๊กอิน และ SDK ที่แปลแหล่งที่มาของคุณเป็นแอปพลิเคชันหรือไลบรารี

ซอร์สโค้ด

ซอร์สโค้ดของคุณคือโค้ด Kotlin หรือ Java ที่คุณเขียนในแอปพลิเคชันหรือไลบรารี (โปรดดูรายละเอียดการใช้ C++ ที่ Android NDK)

ซอร์สโค้ดขึ้นอยู่กับไลบรารี (รวมถึงไลบรารีรันไทม์ของ Kotlin และ Java) และ Android SDK และจำเป็นต้องใช้ Kotlin หรือ Java Compiler ที่เกี่ยวข้อง

ซอร์สโค้ดบางโค้ดมีคำอธิบายประกอบที่ต้องมีการประมวลผลเพิ่มเติม เช่น หากเขียนโค้ด Jetpack Compose คุณจะเพิ่มคำอธิบายประกอบอย่างเช่น @Composable ที่ต้องประมวลผลโดยปลั๊กอินคอมไพเลอร์ Kotlin เครื่องมือประมวลผลสัญลักษณ์ Kotlin (KSP) หรือเครื่องมือประมวลผลคำอธิบายประกอบแยกต่างหากอาจประมวลผลคำอธิบายประกอบอื่นๆ

ทรัพยากร Dependency ของไลบรารี

ไลบรารีมีไบต์โค้ดที่ดึงเข้ามาเป็นส่วนหนึ่งของแอปพลิเคชัน ซึ่งอาจเป็น Java JAR, ไลบรารี Android (AAR) หรือโปรเจ็กต์ย่อยในบิลด์ของคุณ ไลบรารีจำนวนมากใช้การกำหนดเวอร์ชันเชิงความหมาย ซึ่งช่วยให้คุณทราบว่าเมื่อใดที่เวอร์ชันเหล่านั้นยังคงใช้งานร่วมกันได้ (หรือไม่) ขณะอัปเกรด

ไลบรารีอาจขึ้นอยู่กับไลบรารีอื่นๆ สำหรับการใช้งานซ้ำ ซึ่งเรียกว่าการขึ้นต่อกันแบบสโลแกน การดำเนินการนี้จะลดทรัพยากร Dependency ที่คุณต้องจัดการอย่างชัดแจ้ง โดยให้ระบุทรัพยากร Dependency ที่คุณใช้โดยตรง จากนั้น Gradle จะดึงข้อมูลทรัพยากรพร้อมกับทรัพยากร Dependency เหล่านั้น โปรดทราบว่าเมื่อคุณอัปเกรดการพึ่งพาโดยตรง แพ็กเกจเหล่านั้นอาจอัปเกรดการพึ่งพาแบบเปลี่ยนผ่านด้วย

บางครั้งไลบรารีอาจกำหนดให้ใช้ Android SDK เวอร์ชันต่ำสุดขณะรันไทม์ (minSdk) หรือเวลาคอมไพล์ (compileSdk) ซึ่งจำเป็นต้องใช้เมื่อไลบรารีใช้ฟังก์ชันที่รวมอยู่ใน Android SDK หรือ JDK API ที่มีให้ minSdk ที่มีประสิทธิภาพของแอปพลิเคชันคือ minSdk สูงสุดที่แอปพลิเคชันของคุณขอ รวมถึงทรัพยากร Dependency ของไลบรารีโดยตรงและทรานซิทีฟทั้งหมด

การใช้ไลบรารีบางรายการอาจต้องใช้ปลั๊กอิน Gradle ที่เฉพาะเจาะจง ปลั๊กอินตัวช่วยเหล่านี้มักจะติดตั้งตัวประมวลผลสัญลักษณ์ Kotlin หรือตัวประมวลผลคำอธิบายประกอบอื่นๆ ซึ่งสร้างโค้ดหรือแก้ไขการคอมไพล์แหล่งที่มาเพื่อรองรับการใช้ฟีเจอร์ของไลบรารี ตัวอย่างเช่น Jetpack Room มีคำอธิบายประกอบและ KSP ที่เปลี่ยนรูปแบบเป็นโค้ดที่สร้างขึ้นเพื่อดึงและแก้ไขข้อมูลในฐานข้อมูล Jetpack Compose ต้องใช้ปลั๊กอินคอมไพเลอร์ Compose เพื่อแก้ไขฟังก์ชันที่มีคำอธิบายประกอบเพื่อจัดการวิธีและเวลาที่เรียกใช้ฟังก์ชันนั้นอีกครั้ง

เครื่องมือ

ขอบเขต Gradle

Gradle จัดกลุ่มทรัพยากร Dependency ของไลบรารีลงในขอบเขตต่างๆ (เรียกว่าการกำหนดค่าใน Gradle API) ซึ่งช่วยให้คุณระบุชุดทรัพยากร Dependency ของไลบรารีที่แตกต่างกันเพื่อใช้ในส่วนต่างๆ ของบิลด์ได้ ตัวอย่างเช่น คุณอาจไม่ต้องการรวมไลบรารีการทดสอบอย่าง JUnit ในแอปพลิเคชันหรือไลบรารีที่เผยแพร่ แต่คุณต้องการไลบรารีดังกล่าวเมื่อสร้างและเรียกใช้การทดสอบ 1 หน่วย นอกจากนี้ คุณยังใช้ขอบเขตเพื่อเพิ่มตัวประมวลผลสัญลักษณ์หรือการกำกับเนื้อหาเพื่อวิเคราะห์โค้ดได้ด้วย

ตัวอย่างเช่น AGP จะกําหนดขอบเขต implementation และ api ซึ่งเป็นวิธีระบุว่าจะแสดงข้อมูลการพึ่งพาต่อผู้ใช้โปรเจ็กต์ย่อยหรือไม่ โปรดดูคำอธิบายขอบเขตเหล่านี้และขอบเขตอื่นๆ ที่ใช้ในบิลด์ของ Android ที่หัวข้อกำหนดค่าทรัพยากร Dependency

เพิ่มทรัพยากร Dependency ของไลบรารีในบล็อก dependencies ของไฟล์บิลด์ ไม่ว่าจะเป็นสตริง group:artifact:version ดังนี้

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation("com.example:library1:1.2.3")
    api("com.example:library2:1.1.1")
}

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation 'com.example:library1:1.2.3'
    api 'com.example:library2:1.1.1'
}

หรือในแคตตาล็อกเวอร์ชัน

# Version catalog - gradle/libs.versions.toml
[versions]
exampleLib = "1.2.3"
examplePlugin = "2.3.4"

[libraries]
example-library = { group = "com.example", name = "library", version.ref = "exampleLib" }

[plugins]
example-plugin = { id = "com.example.plugin", version.ref = "examplePlugin" }

และระบุตัวแปรที่สร้างขึ้นในไฟล์บิลด์

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation(libs.example.library)
}

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation libs.example.library
}