การอัปเกรด Dependency ช่วยให้คุณเข้าถึงฟีเจอร์ การแก้ไขข้อบกพร่อง และการปรับปรุงล่าสุดได้ หากต้องการอัปเกรด Dependency คุณจะต้องเข้าใจวิธีที่ Gradle แก้ปัญหาเกี่ยวกับเวอร์ชันที่คุณขอ ความเสี่ยงที่เกี่ยวข้อง และขั้นตอนที่คุณทำได้เพื่อลดความเสี่ยงเหล่านั้น
พิจารณากลยุทธ์การอัปเกรดของคุณ
ขั้นตอนที่สำคัญที่สุดในการอัปเกรดใดๆ คือการวิเคราะห์ความเสี่ยง พิจารณาว่าคุณสะดวกที่จะอัปเกรดแต่ละรายการที่ต้องใช้ร่วมกันมากน้อยเพียงใด มีหลายสิ่งที่ต้องพิจารณาเมื่อกำหนดกลยุทธ์การอัปเกรด ซึ่งรวมถึง
สร้างห้องสมุด |
คุณกำลังสร้างแอปพลิเคชันที่ผู้ใช้ดาวน์โหลดและเรียกใช้ในอุปกรณ์ใช่ไหม หรือคุณกำลังสร้างไลบรารีเพื่อช่วยนักพัฒนาซอฟต์แวร์คนอื่นสร้างแอปพลิเคชันของพวกเขา หากกำลังสร้างแอปพลิเคชัน คุณควรมุ่งเน้นที่การทำให้แอปพลิเคชันเป็นเวอร์ชันล่าสุดและทำงานได้อย่างเสถียร หากคุณกำลังสร้างไลบรารี คุณควรให้ความสำคัญกับแอปพลิเคชันของนักพัฒนาซอฟต์แวร์รายอื่น การอัปเกรดจะส่งผลต่อผู้บริโภค หากคุณอัปเกรดข้อกำหนดอย่างใดอย่างหนึ่ง เวอร์ชันนั้นจะกลายเป็นตัวเลือกสำหรับการแก้ไขข้อกำหนดของ Gradle ซึ่งอาจทำให้แอปพลิเคชันใช้งานข้อกำหนดนั้นไม่ได้ ประการแรก - ลดทรัพยากร Dependency ของไลบรารีให้น้อยที่สุดเท่าที่จะทำได้ ยิ่งคุณมีทรัพยากร Dependency น้อย ก็ยิ่งส่งผลต่อการแก้ไขปัญหาการขึ้นต่อกันของผู้บริโภคน้อยลง โปรดปฏิบัติตามการกำหนดเวอร์ชันแบบเซมาติกเพื่อช่วยระบุประเภทการเปลี่ยนแปลงที่คุณทำ ตัวอย่างเช่น AndroidX ใช้การแยกเวอร์ชันแบบเป็นความหมายและเพิ่มรูปแบบการแยกเวอร์ชันรุ่นก่อนเผยแพร่ พยายามหลีกเลี่ยงการอัปเกรดเป็นเวอร์ชัน ลองสร้างคลังรุ่นที่พร้อมเผยแพร่ (RC) เพื่อให้ผู้ใช้ทดสอบได้ตั้งแต่เนิ่นๆ ดูรายละเอียดเกี่ยวกับการทำให้ Application Binary Interface (ABI) ของไลบรารีเข้ากันได้อยู่เสมอได้ที่หลักเกณฑ์ความเข้ากันได้แบบย้อนหลังสำหรับผู้เขียนไลบรารี ใช้การทดสอบการผสานรวมและเครื่องมือต่างๆ เช่น โปรแกรมตรวจสอบความเข้ากันได้ของไบนารีเพื่อให้แน่ใจว่าการเปลี่ยนแปลง ABI ของคุณตรงกับการเปลี่ยนแปลงเวอร์ชันที่ต้องการ หากคุณเผยแพร่การแก้ไขในไลบรารีเวอร์ชัน หากการอัปเกรดคลังของคุณจำเป็นต้องมีการเปลี่ยนแปลงที่ส่งผลกับผู้บริโภคซึ่งอาจรู้สึกเจ็บปวดอย่างมากต่อผู้บริโภค ให้พิจารณาการเผยแพร่การเปลี่ยนแปลงเหล่านั้นเป็นอาร์ติแฟกต์ใหม่ เพื่อให้ทั้งเวอร์ชันเก่าและเวอร์ชันใหม่อยู่ร่วมกันได้ รวมถึงช่วยให้ทยอยเปิดตัวได้มากขึ้น หมายเหตุ: หากการอัปเกรดทรัพยากร Dependency มีการเปลี่ยนแปลง API ที่สำคัญ คุณอาจต้องอัปเกรดในรุ่น |
ช่วงปล่อยเพลง |
คุณเผยแพร่แอปพลิเคชันหรือไลบรารีบ่อยแค่ไหน วงจรการพัฒนาและการเผยแพร่ที่สั้นลง
วงจรการพัฒนาและการเผยแพร่ที่นานขึ้น
|
ติดตามฟีเจอร์ล่าสุด |
คุณต้องการใช้ฟีเจอร์และ API เวอร์ชันล่าสุดที่มี หรือจะอัปเกรดเฉพาะเมื่อต้องการฟีเจอร์หรือการแก้ไขข้อบกพร่อง พิจารณาข้อดีข้อเสียของการอัปเกรดบ่อยๆ การอัปเกรดในอนาคตจะง่ายขึ้น (มีการเปลี่ยนแปลงน้อยกว่าในการผสานรวม) แต่คุณจะต้องเสี่ยงกับการอัปเกรดบ่อยขึ้น การทดสอบการอัปเกรดไลบรารีเป็นเวอร์ชันก่อนเผยแพร่ (อัลฟ่า เบต้า และรุ่นที่อาจได้รับการเผยแพร่) จะช่วยเตรียมความพร้อมเมื่อมีรุ่นเสถียรให้ใช้งาน |
ทรัพยากร Dependency ใหม่ |
หากคุณจะเพิ่มการพึ่งพาใหม่ ให้พิจารณาใช้กระบวนการตรวจสอบที่เข้มงวดซึ่งจะตรวจสอบไลบรารีนั้นเพื่อหาเกณฑ์ความเสี่ยงทั้งหมดเพื่อให้มั่นใจว่าได้รับการประเมินอย่างเหมาะสม ไม่อนุญาตให้เพิ่มการพึ่งพาใหม่โดยไม่ผ่านการตรวจสอบ |
ทีมเฉพาะ |
คุณมีทีมสร้างโดยเฉพาะไหม วิศวกรซอฟต์แวร์ดูแลรักษาบิลด์ไหม ทีมเฉพาะทางมักจะมีเวลาวิเคราะห์ความเสี่ยงในการอัปเกรดและทดสอบเวอร์ชันใหม่เพื่อให้แน่ใจว่าบิลด์ทํางานได้อย่างถูกต้องก่อนที่วิศวกรจะใช้เวอร์ชันใหม่ |
ประเภทการอัปเกรด |
การอัปเกรดบางอย่างสำคัญกว่าการอัปเกรดอื่นๆ ลองนึกถึงสิ่งที่สำคัญที่สุดสำหรับคุณ การอัปเกรดเครื่องมือสร้าง เช่น Gradle และปลั๊กอิน Gradle มักส่งผลกระทบต่อผู้ใช้น้อยลง และความเสี่ยงส่วนใหญ่จะอยู่ในบิลด์ของคุณ บิลด์เองจะช่วยตรวจสอบการเปลี่ยนแปลงเหล่านี้ การอัปเกรดไลบรารีและ SDK นั้นตรวจสอบได้ยากกว่าและมีความเสี่ยงต่อผู้ใช้มากกว่า ปลั๊กอิน Android Gradle (AGP) — เครื่องมือที่ใช้สร้างแอปพลิเคชันหรือไลบรารี Android การอัปเกรดนี้เป็นอัปเกรดที่สำคัญที่สุดที่คุณทำได้ เนื่องจากมักจะมีการปรับปรุงประสิทธิภาพ การแก้ไขข้อบกพร่อง กฎใหม่ของ Lint และการรองรับแพลตฟอร์ม Android เวอร์ชันใหม่ Gradle - คุณมักจะต้องอัปเกรด Gradle เมื่ออัปเกรด AGP หรือปลั๊กอิน Gradle อื่น ปลั๊กอิน Gradle อื่นๆ — บางครั้ง API ปลั๊กอินของ Gradle มีการเปลี่ยนแปลง เมื่ออัปเกรด Gradle ให้ตรวจสอบการอัปเกรดปลั๊กอินที่คุณใช้ Kotlin และ Java - ไลบรารีและปลั๊กอินบางอย่างต้องใช้ Kotlin หรือ Java เวอร์ชันขั้นต่ำ หรือต้องการใช้ประโยชน์จากฟีเจอร์ภาษาใหม่ๆ, API หรือการปรับปรุงประสิทธิภาพ แพลตฟอร์ม Android — Play Store กำหนดให้อัปเกรด Android SDK เป็นเวอร์ชันล่าสุดเป็นประจำ คุณควรทดสอบ Android SDK เวอร์ชันใหม่โดยเร็วที่สุด การอัปเกรด SDK บางรายการต้องมีการเปลี่ยนแปลงแอปพลิเคชัน เช่น สิทธิ์ใหม่หรือการใช้ API ใหม่ คลัง — คุณต้องการจัดลําดับความสําคัญของคลังตามความใกล้เคียงกับสถาปัตยกรรมโดยรวมไหม
Android Studio — การอัปเดต Android Studio เป็นเวอร์ชันล่าสุดอยู่เสมอจะช่วยให้คุณเข้าถึงฟีเจอร์และการแก้ไขข้อบกพร่องล่าสุดในแพลตฟอร์มและเครื่องมือ IntelliJ IDEA ที่เกี่ยวข้องเพื่อใช้งานกับ Android SDK เวอร์ชันล่าสุด |
เครื่องมือที่ใช้ได้ |
มีเครื่องมือและปลั๊กอินมากมายที่จะช่วยคุณในการอัปเกรด เครื่องมืออย่าง Dependabot และ Renovate จะอัปเกรดเวอร์ชันไลบรารีในบิลด์โดยอัตโนมัติ แต่อย่าลืมวิเคราะห์ผลลัพธ์เพื่อตรวจสอบความเสี่ยง |
กลยุทธ์สำหรับการอัปเกรดบางประเภท
การอัปเกรดทรัพยากรบางส่วนอาจส่งผลต่อเนื่อง ทำให้ต้องอัปเกรดทรัพยากรประเภทอื่นๆ ด้วย เราพูดถึงความสัมพันธ์ระหว่าง องค์ประกอบที่สร้างในส่วนการพึ่งพากันระหว่างเครื่องมือและไลบรารี
เมื่ออัปเกรดคอมโพเนนต์แต่ละประเภท ให้พิจารณาว่าการอัปเกรดจะส่งผลต่อคอมโพเนนต์อื่นๆ ในบิลด์อย่างไร
ปลั๊กอิน Android Gradle (AGP) |
Android Studio มีผู้ช่วยอัปเกรด AGP ที่สามารถช่วยเหลือในงานเหล่านี้ได้ หากคุณใช้ผู้ช่วยหรืออัปเกรดด้วยตนเอง โปรดพิจารณาสิ่งต่อไปนี้ อัปเกรด Gradle เป็นเวอร์ชันที่ระบุเป็นอย่างน้อย อัปเกรด Android Studio เป็นเวอร์ชันที่รองรับเวอร์ชัน AGP ที่เลือก ใช้ Android Studio และ AGP เวอร์ชันที่รองรับ Android SDK ที่ต้องการใช้ ตรวจสอบความเข้ากันได้กับเครื่องมือสร้าง SDK, NDK และ JDK หากคุณพัฒนาปลั๊กอิน Gradle (สำหรับใช้ภายในหรือสาธารณะ) ที่ขยายหรือใช้ข้อมูลจาก AGP ให้ตรวจสอบว่าจำเป็นต้องอัปเกรดปลั๊กอินหรือไม่ บางครั้ง AGP จะเลิกใช้งานและนํา API ออกในภายหลัง ซึ่งทําให้ใช้งานร่วมกับปลั๊กอินก่อนหน้าไม่ได้ |
คอมไพเลอร์ ภาษา และรันไทม์ของ Kotlin |
โปรดดูปัญหาที่ทราบและฟังก์ชันที่ทำงานร่วมกับ Kotlin ไม่ได้ในบันทึกประจำรุ่นของ Kotlin หากใช้ Jetpack Compose ให้ทำดังนี้
หากคุณใช้การประมวลผลสัญลักษณ์ Kotlin (KSP) โปรดดูเริ่มต้นใช้งาน KSP อย่างรวดเร็วสำหรับการตั้งค่าและรุ่น KSP สำหรับเวอร์ชันที่ใช้ได้ โปรดทราบว่าคุณต้องใช้ KSP เวอร์ชันที่ตรงกับเวอร์ชัน Kotlin เช่น หากคุณใช้ Kotlin 2.0.21 คุณจะใช้ปลั๊กอิน KSP เวอร์ชันใดก็ได้ที่ขึ้นต้นด้วย 2.0.21 เช่น 2.0.21-1.0.25 โดยปกติแล้วคุณไม่จำเป็นต้องอัปเกรดตัวประมวลผล KSP (เช่น คอมไพเลอร์ Room ซึ่งปรากฏเป็น อัปเกรดปลั๊กอิน Kotlin Compiler อื่นๆ ทั้งหมดที่คุณใช้อยู่ Kotlin Compiler Plugin API มีการเปลี่ยนแปลงบ่อยครั้งระหว่างรุ่นต่างๆ และปลั๊กอินต้องใช้ API ที่เข้ากันได้ หากปลั๊กอินแสดงอยู่ในปลั๊กอินคอมไพเลอร์ คุณต้องใช้เวอร์ชันเดียวกับคอมไพเลอร์ Kotlin สําหรับปลั๊กอินการคอมไพล์อื่นๆ โปรดดูการแมปที่เหมาะสมในเอกสารประกอบ โปรดทราบว่าปลั๊กอินของคอมไพเลอร์ที่ไม่ได้รับการดูแลควบคู่ไปกับคอมไพเลอร์ Kotlin เองมักประสบปัญหาความล่าช้าในการเผยแพร่เนื่องจากรอให้ API ปลั๊กอินของคอมไพเลอร์เสถียร ก่อนอัปเกรด Kotlin โปรดตรวจสอบว่าปลั๊กอินคอมไพเลอร์ทั้งหมดที่ใช้มีการอัปเกรดที่ตรงกัน สุดท้าย ในบางกรณี ภาษา Kotlin อาจเปลี่ยนแปลงไป คุณจึงต้องอัปเดตโค้ด กรณีนี้มักเกิดขึ้นหากคุณกำลังทดลองใช้ฟีเจอร์ทดลอง หากโค้ดของคุณไม่คอมไพล์อย่างถูกต้องหลังจากอัปเกรดคอมไพเลอร์ Kotlin ให้ตรวจสอบการเปลี่ยนแปลงภาษาหรือไลบรารีรันไทม์ที่ใช้งานไม่ได้ในหมายเหตุประจำรุ่นของ Kotlin |
ปลั๊กอินคอมไพเลอร์ Kotlin |
หากต้องการอัปเกรดปลั๊กอินคอมไพเลอร์ Kotlin ให้อัปเกรดเป็น Kotlin เวอร์ชันที่ใช้อยู่ ปลั๊กอินคอมไพเลอร์ Kotlin ส่วนใหญ่จะใช้เวอร์ชันเดียวกับคอมไพเลอร์ Kotlin หรือเริ่มต้นด้วยคอมไพเลอร์ Kotlin เวอร์ชันที่จำเป็น เช่น หากเวอร์ชันของปลั๊กอินคือ 2.0.21-1.0.25 คุณต้องใช้คอมไพเลอร์ Kotlin เวอร์ชัน 2.0.21 บางครั้งการเปลี่ยนเวอร์ชันคอมไพเลอร์ Kotlin จะต้องมีการเปลี่ยนแปลงอื่นๆ |
ห้องสมุด |
ไลบรารีเป็นทรัพยากรที่ต้องอัปเกรดบ่อยที่สุดในบิลด์ คุณจะเห็นการอัปเกรดที่ใช้ได้ในเครื่องมือแก้ไขของ Android Studio หรือเมื่อใช้เครื่องมือและปลั๊กอินที่ต้องพึ่งพาบางรายการ บางไลบรารีระบุ ไลบรารีบางแห่งยังระบุเวอร์ชัน Kotlin ขั้นต่ำสำหรับการใช้งานด้วย อัปเดตเวอร์ชัน Kotlin ในไฟล์บิลด์เป็นเวอร์ชันที่ระบุไว้เป็นอย่างน้อย |
Gradle |
บางครั้ง Gradle เวอร์ชันใหม่จะเลิกใช้งาน API ที่มีอยู่และนำ API เหล่านั้นออกในรุ่นถัดไป หากคุณพัฒนาปลั๊กอิน Gradle ให้อัปเกรดปลั๊กอินโดยเร็วที่สุด โดยเฉพาะหากปลั๊กอินนั้นเป็นแบบสาธารณะ การอัปเกรด Gradle บางรายการกำหนดให้ต้องค้นหาปลั๊กอินเวอร์ชันใหม่ที่คุณใช้ โปรดทราบว่าปลั๊กอินเหล่านี้อาจล้าสมัยในการพัฒนาเนื่องจากมีการอัปเกรดปลั๊กอินให้ตรงกับ API ของปลั๊กอิน Gradle เวอร์ชันล่าสุด วิธีอัปเกรด Gradle
|
ปลั๊กอิน Gradle |
ในบางครั้ง ปลั๊กอิน Gradle ที่อัปเกรดแล้วจะใช้ Gradle API ใหม่หรือที่เปลี่ยนแปลงไป ซึ่งทำให้ต้องอัปเกรด Gradle หรืออาจต้องเปลี่ยนแปลงการกำหนดค่าในไฟล์บิลด์ ไม่ว่าในกรณีใด คุณจะเห็นคำเตือนหรือข้อผิดพลาดเกี่ยวกับบิลด์เพื่อบ่งบอกถึงความเข้ากันไม่ได้ อัปเกรด Gradle ทุกครั้งที่อัปเกรดปลั๊กอิน |
Android SDK |
Android Studio มีผู้ช่วยอัปเกรด Android SDK ที่ช่วยทำงานเหล่านี้ได้ หากคุณใช้ผู้ช่วยหรืออัปเกรดด้วยตนเอง โปรดพิจารณาสิ่งต่อไปนี้ SDK ของ Android แต่ละรุ่นมีฟีเจอร์และ API ใหม่ การแก้ไขข้อบกพร่อง และการเปลี่ยนแปลงลักษณะการทํางาน Play Store กำหนดให้อัปเดต โปรดอ่านบันทึกประจำรุ่นอย่างละเอียดก่อนอัปเกรด Android SDK โปรดดูที่ส่วนการเปลี่ยนแปลงลักษณะการทำงาน ซึ่งมีรายละเอียดดังนี้
ส่วนการเปลี่ยนแปลงลักษณะการทํางานอาจยาวมาก แต่โปรดอ่านอย่างละเอียดเนื่องจากส่วนนี้มักจะมีการเปลี่ยนแปลงที่สําคัญซึ่งคุณต้องทํากับแอปพลิเคชัน คุณต้องอัปเกรด หากต้องการใช้ประโยชน์จากฟีเจอร์ใหม่ของ SDK ในระหว่างการพัฒนาและตรวจสอบความเข้ากันได้ระหว่างการสร้าง ให้อัปเกรดปลั๊กอิน Android Gradle (AGP) และ Android Studio ซึ่งรวมถึงเครื่องมือใหม่และเครื่องมือที่ได้รับการปรับปรุงสำหรับ SDK ใหม่ ดูเวอร์ชันขั้นต่ำของเครื่องมือสำหรับระดับ API ของ Android เมื่ออัปเกรด Android SDK ให้อัปเกรดไลบรารี AndroidX ที่คุณใช้ด้วย AndroidX มักใช้ API ใหม่และที่อัปเดตแล้วเพื่อให้ใช้งานร่วมกันได้และมีประสิทธิภาพมากขึ้นใน Android SDK แต่ละเวอร์ชัน |
Android Studio |
โดยทั่วไปแล้ว คุณจะอัปเกรด Android Studio ได้ทุกเมื่อ คุณอาจเห็นข้อความแจ้งให้อัปเกรด AGP หรืออัปเกรด Android SDK ขอแนะนำอย่างยิ่งให้ใช้การอัปเกรดเหล่านี้ แต่ก็ไม่บังคับ หากต้องการใช้ Android Studio เพื่ออัปเกรด AGP หรือ Android SDK ในภายหลัง ก็ค้นหาตัวเลือกเหล่านี้ได้ในเมนูเครื่องมือ |
Java |
หากคุณมีซอร์สโค้ดของ Java ในแอปพลิเคชัน Android คุณอาจต้องใช้ประโยชน์จาก Java API รุ่นใหม่ Android SDK แต่ละเวอร์ชันรองรับชุดย่อยของ Java API และฟีเจอร์ภาษา AGP รองรับการใช้งานร่วมกับ Android SDK เวอร์ชันที่ต่ำกว่าโดยใช้กระบวนการที่เรียกว่า desugaring บันทึกประจำรุ่นของ Android SDK ระบุระดับของ Java ที่รองรับและปัญหาที่อาจเกิดขึ้น ปัญหาเหล่านี้บางส่วนอาจส่งผลต่อซอร์สโค้ดของ Kotlin ด้วยเช่นกัน เนื่องจาก Kotlin มีสิทธิ์เข้าถึง Java API เดียวกัน โปรดอ่านส่วน JDK API ที่ปรากฏในส่วนการเปลี่ยนแปลงด้านลักษณะการทํางานของบันทึกประจำรุ่นอย่างละเอียด แม้ว่าคุณจะไม่มีซอร์สโค้ด Java ก็ตาม การใช้งาน JDK จะระบุไว้ในหลายตำแหน่งในสคริปต์บิลด์ ดูข้อมูลเพิ่มเติมได้ที่เวอร์ชัน Java ในบิลด์ Android |
การวิเคราะห์การอัปเกรด
การอัปเกรดทรัพยากร Dependency อาจทำให้เกิดความเสี่ยงในรูปแบบ API และการเปลี่ยนแปลงลักษณะการทำงาน ข้อกำหนดใหม่ในการใช้งาน ปัญหาด้านความปลอดภัยใหม่ๆ หรือแม้แต่การเปลี่ยนแปลงใบอนุญาต เช่น คุณต้องดำเนินการต่อไปนี้หรือไม่
- เปลี่ยนโค้ดสำหรับการเปลี่ยนแปลง API ไหม
- เพิ่มการตรวจสอบสิทธิ์ใหม่ไหม
- สร้างการทดสอบเพิ่มเติมหรือแก้ไขการทดสอบที่มีอยู่เพื่อดูการเปลี่ยนแปลงลักษณะการทำงาน
พิจารณาว่าทรัพยากร Dependency ที่คุณอัปเกรดได้อัปเกรดการขึ้นต่อกันเวอร์ชัน แล้วหรือไม่ ซึ่งอาจทําให้เกิดการเปลี่ยนแปลงจํานวนมากได้อย่างรวดเร็ว
หากคุณใช้เครื่องมืออย่าง Renovate หรือ Dependabot เพื่ออัปเกรดโดยอัตโนมัติ โปรดทราบว่าเครื่องมือเหล่านี้จะไม่ทำการวิเคราะห์ให้คุณ แต่จะอัปเกรดเป็นไลบรารีเวอร์ชันล่าสุด อย่าคิดว่าทุกอย่างจะทำงานได้อย่างถูกต้องหลังจากการอัปเกรดอัตโนมัติประเภทเหล่านี้
กุญแจสำคัญในการอัปเกรดที่ประสบความสำเร็จคือการวิเคราะห์การอัปเกรด
- ระบุความแตกต่างของรายการที่ต้องพึ่งพาก่อนและหลังการอัปเกรด
- ตรวจสอบการเปลี่ยนแปลงแต่ละรายการและระบุความเสี่ยงที่เกี่ยวข้อง
- ลดความเสี่ยง หรือยอมรับหรือปฏิเสธการเปลี่ยนแปลง
ระบุความแตกต่างของทรัพยากร Dependency
ขั้นตอนแรกในการวิเคราะห์การอัปเกรดคือการพิจารณาการเปลี่ยนแปลงของข้อกําหนด ใช้ประโยชน์จากการควบคุมเวอร์ชัน (VCS เช่น Git) และปลั๊กอิน Dependency Guard เพื่อดูการเปลี่ยนแปลงได้อย่างรวดเร็ว เป้าหมายของคุณคือสร้างภาพสแนปชอตก่อนและหลัง แล้วเปรียบเทียบภาพเหล่านั้น
ตั้งค่าและสร้างเส้นฐานแรก
ก่อนเริ่มการอัปเกรด ให้ตรวจสอบว่าโปรเจ็กต์ของคุณสร้างสําเร็จ
วิธีที่ดีที่สุดคือการแก้ไขคําเตือนให้ได้มากที่สุด หรือสร้างเส้นฐานเพื่อติดตามคําเตือนที่คุณเคยเห็น
- Lint: ตรวจสอบคำเตือน Lint ที่มีอยู่และสร้างฐานบรรทัดฐาน Lint ของ Android
- คอมไพเลอร์ Kotlin
- เปิดใช้
-Werror
เพื่อถือว่าคำเตือนทั้งหมดเป็นข้อผิดพลาด ดูวิธีกำหนดตัวเลือก - ลองใช้ปลั๊กอิน เช่น Kotlin Warning Baseline หรือKotlin Warnings Baseline Generator
- เปิดใช้
- เครื่องมืออื่นๆ: หากคุณใช้เครื่องมือวิเคราะห์แบบคงที่อื่นๆ (เช่น Detekt) ที่รองรับการติดตามเส้นฐาน ให้ตั้งค่าเส้นฐานของเครื่องมือเหล่านั้น
เกณฑ์พื้นฐานคำเตือนเหล่านี้ช่วยให้เห็นคำเตือนใหม่ได้ง่ายขึ้นเมื่ออัปเกรดทรัพยากร Dependency
สร้างเส้นฐานของ Dependency โดยการตั้งค่าและเรียกใช้ Dependency Guard ในแคตตาล็อกเวอร์ชัน gradle/libs.versions.toml ให้เพิ่มข้อมูลต่อไปนี้
[versions]
dependencyGuard = "0.5.0"
[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }
และเพิ่มโค้ดต่อไปนี้ลงในไฟล์บิลด์ของแอป
Kotlin
plugins { alias(libs.plugins.dependency.guard) } dependencyGuard { configuration("releaseRuntimeClasspath") }
Groovy
plugins { alias(libs.plugins.dependency.guard) } dependencyGuard { configuration('releaseRuntimeClasspath') }
การกําหนดค่า releaseRuntimeClasspath
น่าจะเป็นเป้าหมาย แต่หากต้องการใช้การกําหนดค่าอื่น ให้เรียกใช้ ./gradlew dependencyGuard
โดยไม่ระบุการกําหนดค่าที่แสดงในไฟล์บิลด์เพื่อดูการกําหนดค่าที่ใช้ได้ทั้งหมด
หลังจากตั้งค่าแล้ว ให้เรียกใช้ ./gradlew dependencyGuard
เพื่อสร้างรายงานใน app/dependencies/releaseRuntimeClasspath.txt
นี่คือรายงานพื้นฐาน
คอมมิตข้อมูลนี้ลงในระบบควบคุมเวอร์ชัน (VCS) เพื่อบันทึก
โปรดทราบว่า Dependency Guard จะบันทึกเฉพาะรายการไลบรารีที่ต้องใช้ ยังมีทรัพยากร Dependency อื่นๆ ในไฟล์บิลด์ เช่น เวอร์ชัน Android SDK และ JDK การทำคอมมิตใน VCS ก่อนที่คุณจะเปลี่ยนแปลงทรัพยากร จะช่วยให้ VCS diff ไฮไลต์การเปลี่ยนแปลงเหล่านั้นด้วย
อัปเกรดและเปรียบเทียบกับเกณฑ์พื้นฐาน
เมื่อคุณมีข้อมูลพื้นฐานแล้ว ให้อัปเกรด Dependency และการเปลี่ยนแปลงอื่นๆ ของบิลด์ที่ต้องการทดสอบ อย่าอัปเกรดซอร์สโค้ดหรือทรัพยากรในตอนนี้
เรียกใช้ ./gradlew lint
เพื่อดูคำเตือนหรือข้อผิดพลาดใหม่ของ Lint แก้ไขปัญหาสำคัญแล้วอัปเดตเกณฑ์พื้นฐานของคำเตือนโดยเรียกใช้ ./gradlew lint
-Dlint.baselines.continue=true
หากคุณใช้เครื่องมืออื่นๆ เพื่อบันทึกพื้นฐานคำเตือน เช่น พื้นฐานคำเตือน Kotlin หรือเครื่องมือสร้างพื้นฐานคำเตือน Kotlin ให้แก้ไขคำเตือนใหม่และอัปเดตพื้นฐานด้วย
เรียกใช้ ./gradlew dependencyGuard
เพื่ออัปเดตรายงานพื้นฐาน จากนั้นเรียกใช้ diff VCS เพื่อดูการเปลี่ยนแปลงที่ไม่ใช่ไลบรารี เป็นไปได้ว่าจะมีการอัปเกรด
ไลบรารีมากกว่าที่คุณคิด
วิเคราะห์ความเสี่ยง
เมื่อทราบสิ่งที่เปลี่ยนแปลงแล้ว ให้พิจารณาถึงความเสี่ยงที่อาจเกิดขึ้นจากไลบรารีที่อัปเกรดแต่ละรายการ วิธีนี้จะช่วยเน้นการทดสอบหรือการตรวจสอบการเปลี่ยนแปลงอย่างละเอียดยิ่งขึ้น กําหนดชุดความเสี่ยงที่จะวิเคราะห์สําหรับโปรเจ็กต์เพื่อให้การวิเคราะห์สอดคล้องกัน
สิ่งที่ควรพิจารณามีดังนี้
การยกตัวขึ้นของเวอร์ชันหลัก |
หมายเลขเวอร์ชันหลักมีการเปลี่ยนแปลงหรือไม่ เมื่อเห็นข้อความนี้ ให้ตรวจสอบคลังภาพที่ได้รับผลกระทบอย่างละเอียดเมื่อพิจารณาข้อควรพิจารณาต่อไปนี้ หากโค้ดของคุณใช้ API เวอร์ชันทดลอง (ซึ่งมักจะกำหนดให้คุณเลือกใช้โดยใช้คำอธิบายประกอบหรือข้อกำหนดของไฟล์บิลด์) การเปลี่ยนแปลงเวอร์ชันย่อยหรือแพตช์ เช่น การอัปเกรดจาก 1.2.3 เป็น 1.3.1 หรือ 1.2.3 เป็น 1.2.5 อาจก่อให้เกิดความเสี่ยงเพิ่มเติม |
API ที่ไม่เสถียร |
ไลบรารีบางรุ่นอาจมี API ที่ไม่เสถียร ซึ่งมักจะเป็น API ที่อยู่ระหว่างดำเนินการหรือขึ้นอยู่กับ API อื่นที่ไม่เสถียร แม้ว่าโดยทั่วไปแล้ว จะจำกัดให้แสดงเฉพาะตัวอย่าง เช่น เวอร์ชันอัลฟ่า เวอร์ชันที่กำลังพัฒนา หรือเวอร์ชันทดลอง แต่ไลบรารีบางส่วนจะมี API ที่ระบุว่าเป็นเวอร์ชันทดลองหรือไม่เสถียร โปรดหลีกเลี่ยง API ดังกล่าว หากเป็นไปได้ หากคุณจำเป็นต้องใช้ โปรดอย่าลืมบันทึกการใช้งานและคอยดูการเปลี่ยนแปลงหรือการนำออกในรุ่นต่อๆ ไป |
ลักษณะการทำงานแบบไดนามิก |
ไลบรารีบางรายการจะทำงานแตกต่างกันไปตามปัจจัยภายนอก เช่น ไลบรารีที่สื่อสารกับเซิร์ฟเวอร์จะขึ้นอยู่กับการเปลี่ยนแปลงในเซิร์ฟเวอร์นั้น
|
การรวมไฟล์ Manifest |
ไลบรารีที่เผยแพร่เป็นไฟล์เก็บถาวร Android (AAR) อาจมีทรัพยากรและไฟล์ Manifest ที่ผสานเข้ากับแอปพลิเคชัน ซึ่งสามารถเพิ่มสิทธิ์และคอมโพเนนต์ Android ใหม่ เช่น กิจกรรมหรือ Broadcast Receiver ที่ทำงานโดยอ้อม |
การอัปเดตรันไทม์ |
ไลบรารีบางรายการใช้ฟีเจอร์ที่อัปเดตได้นอกเหนือการควบคุมของแอปพลิเคชัน ไลบรารีอาจใช้บริการ Google Play ซึ่งได้รับการอัปเกรดแยกจาก Android SDK ไลบรารีอื่นๆ อาจเชื่อมโยงกับบริการในแอปพลิเคชันภายนอกที่อัปเดตแยกต่างหาก (มักใช้ AIDL) |
คุณจะข้ามกี่เวอร์ชัน |
ยิ่งคุณรออัปเกรดคลังนานเท่าใด ความเสี่ยงก็ยิ่งมีมากขึ้นเท่านั้น หากคุณเห็นการเปลี่ยนแปลงเวอร์ชันอย่างมาก เช่น 1.2.3 เป็น 1.34.5 ให้ตรวจสอบคลังนี้เป็นพิเศษ |
คำแนะนำในการย้ายข้อมูล |
ตรวจสอบว่าคลังมีคำแนะนำในการย้ายข้อมูลหรือไม่ ซึ่งจะช่วยลดการวิเคราะห์ความเสี่ยงและการวางแผนการบรรเทาความเสี่ยงได้อย่างมาก โปรดทราบว่าการมีคู่มือดังกล่าวเป็นตัวบ่งชี้ที่ดีว่านักพัฒนาแอปมุ่งเน้นที่ความเข้ากันได้และพิจารณาการลดผลกระทบของการอัปเกรด |
บันทึกประจำรุ่น |
ดูบันทึกประจำรุ่น (หากมี) ของไลบรารีแต่ละรายการที่มีการเปลี่ยนแปลง มองหาสัญญาณที่บ่งบอกถึงการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบหรือข้อกำหนดใหม่ เช่น สิทธิ์ที่เพิ่มขึ้น |
README |
ไฟล์ README บางไฟล์สำหรับไลบรารีจะระบุถึงความเสี่ยงที่อาจเกิดขึ้น โดยเฉพาะในกรณีที่ไลบรารีไม่มีหมายเหตุเกี่ยวกับรุ่น มองหา_ปัญหาที่ทราบ_ โดยเฉพาะข้อกังวลด้านความปลอดภัยที่ทราบ |
ตรวจสอบช่องโหว่ที่ทราบ |
ดัชนี SDK ของ Play จะติดตามช่องโหว่ของ SDK ยอดนิยมหลายรายการ Play Console จะรายงานว่าคุณใช้ SDK รายการใดรายการหนึ่งที่ระบุไว้ซึ่งมีช่องโหว่ที่ทราบหรือไม่ เมื่อแก้ไขไฟล์บิลด์ใน Android Studio IDE จะตรวจสอบดัชนี SDK และแจ้งการใช้ไลบรารีเวอร์ชันที่มีช่องโหว่ สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (NIST) ดูแลฐานข้อมูลช่องโหว่แห่งชาติ (NVD) ขนาดใหญ่ ปลั๊กอิน Gradle แบบ Dependency Check จะตรวจสอบทรัพยากร Dependency ที่ใช้เทียบกับ NVD หากต้องการใช้การตรวจสอบการขึ้นต่อกัน ให้ขอคีย์ NVD API ตั้งค่าปลั๊กอิน Gradle และเรียกใช้ |
ความขัดแย้งของเวอร์ชัน |
เวอร์ชันได้รับการแก้ไขตามที่คาดไว้ไหม มองหาข้อขัดแย้ง โดยเฉพาะความแตกต่างของเวอร์ชันหลัก ดูรายละเอียดเกี่ยวกับวิธีค้นหาข้อขัดแย้งได้ที่การแก้ไขการพึ่งพา Gradle โดยเฉพาะอย่างยิ่ง ให้ค้นหา หากเป็นไปได้ ให้ทํางานร่วมกับผู้เขียนผู้พึ่งพิงเพื่อแยกการขึ้นต่อกันของผู้ใช้รายนั้นออก หากบริษัทอนุญาต คุณสามารถมีส่วนร่วมในการเปลี่ยนแปลงของไลบรารี (การส่งต่อข้อมูล) เพื่อช่วยปรับปรุงความเข้ากันได้ของไลบรารี |
ตรวจสอบใบอนุญาต |
มองหาการเปลี่ยนแปลงในใบอนุญาตเมื่ออัปเกรดคลัง ไลบรารีอาจเปลี่ยนเป็นใบอนุญาตที่ใช้ร่วมกับแอปพลิเคชันหรือไลบรารีของคุณไม่ได้อีกต่อไป ไลบรารีใหม่แบบทรานซิทีฟอาจทำให้เกิดใบอนุญาตที่เข้ากันไม่ได้ด้วย โปรดดูรายละเอียดการตรวจสอบชุดใบอนุญาตปัจจุบันในทรัพยากร Dependency ที่หัวข้อตรวจสอบใบอนุญาต |
ความเสี่ยงด้านการบำรุงรักษาและ |
สำหรับคลังที่มีที่เก็บข้อมูลสาธารณะ ให้ทำดังนี้
|
โอเพนซอร์สกับโคลสซอร์ส |
หากไลบรารีเป็นโอเพนซอร์ส การแก้ปัญหาจะง่ายกว่าแหล่งที่มาแบบปิด ไม่ว่าปัญหาจะอยู่ในโค้ดหรือโค้ดไลบรารีก็ตาม ลดการพึ่งพาซอร์สโค้ดแบบปิดและตรวจสอบเพิ่มเติมในระหว่างการประเมิน มีทางเลือกอื่นที่เหมาะกับกรณีการใช้งานของคุณไหม ข้อตกลงระดับการให้บริการใดบ้างที่ใช้ได้กับไลบรารีแบบซอร์สโค้ดปิด หากเลือกใช้ทรัพยากร Dependency แบบปิด โปรดเตรียมเขียนกรอบการทดสอบเพิ่มเติมเพื่อช่วยจำกัดความเสี่ยง |
เรียกใช้บิลด์
สร้างโปรเจ็กต์ มองหาข้อผิดพลาดหรือคำเตือนใหม่ หากคุณสามารถระบุได้ว่าไลบรารีใดเป็นต้นเหตุของไลบรารีดังกล่าว ให้สังเกตว่าเป็นความเสี่ยงในการอัปเกรดไลบรารีดังกล่าว
หากเห็นคำเตือนการลดค่าใหม่ ให้เพิ่มคำเตือนเหล่านั้นเป็นความเสี่ยงที่เฉพาะเจาะจงสำหรับคลังที่สร้างคำเตือน ซึ่งจะนําออกได้ในรุ่นต่อๆ ไป หากต้องการใช้ไลบรารีนั้นต่อไป โปรดสละเวลาในการแปลงจากการใช้ API ที่เลิกใช้งานแล้วในการเปลี่ยนทดแทน หรือจดบันทึกการเลิกใช้งานเพื่อคอยสังเกตการทำงานเหล่านั้นและดูว่าจะมีการนำ API เหล่านั้นออกในภายหลังหรือไม่
ใช้ Lint เพื่อตรวจหาปัญหาเกี่ยวกับ API
Android Lint อาจตรวจพบปัญหามากมายในแอปพลิเคชันของคุณ รวมถึงปัญหาบางอย่างที่เกิดจากการเปลี่ยนเวอร์ชันทรัพยากร Dependency หรือ Android SDK เช่น หากคุณอัปเกรด compileSdk
และใช้ API ใหม่ของ compileSdk
นั้น Lint จะรายงาน API ที่ไม่มีใน SDK เวอร์ชันก่อนหน้า
Lint จะทำงานในเครื่องมือแก้ไขของ Android Studio โดยจะรายงานปัญหาขณะที่คุณทําการเปลี่ยนแปลง
แต่โดยทั่วไปจะไม่ทํางานเป็นส่วนหนึ่งของบิลด์ใน Studio หรือเมื่อคุณเรียกใช้บิลด์บรรทัดคําสั่ง เว้นแต่คุณจะใช้เป้าหมาย build
หรือ lint
หากคุณใช้การรวมอย่างต่อเนื่อง (CI) ให้เรียกใช้ gradlew
build
หรือ gradlew lint
ในระหว่างการสร้าง CI (หรืออย่างน้อยก็ในบิลด์รายวัน) เพื่อตรวจหาข้อผิดพลาดประเภทเหล่านี้
หากคุณไม่ได้ใช้ CI โปรดเรียกใช้ gradlew lint
เป็นครั้งคราวเป็นอย่างน้อย
โปรดตรวจสอบข้อผิดพลาดและคำเตือนเกี่ยวกับโปรแกรมตรวจไวยากรณ์เป็นพิเศษ ไลบรารีบางแห่งจัดส่งด้วยการตรวจสอบ Lint ของตนเองเพื่อให้มั่นใจว่าใช้ API ได้อย่างเหมาะสม ไลบรารีบางเวอร์ชันใหม่มีคำเตือนและข้อผิดพลาดเกี่ยวกับ Lint ใหม่ ซึ่งส่งผลให้มีรายงานใหม่เมื่อคุณสร้าง
ลดความเสี่ยง
หลังจากพิจารณาความเสี่ยงของการอัปเกรดแล้ว ให้ตัดสินใจว่าคุณต้องการลดความเสี่ยงเหล่านั้นอย่างไร ดังนี้
- ยอมรับความเสี่ยงตามที่เป็นอยู่ ความเสี่ยงบางอย่างก็ต่ำพอที่จะยอมรับได้ โดยเฉพาะเมื่อเวลาและทรัพยากรในการอัปเกรดมีจำกัด
- ปฏิเสธความเสี่ยงบางรายการโดยสิ้นเชิง การอัปเกรดบางอย่างอาจดูมีความเสี่ยงสูงเกินไป โดยเฉพาะในกรณีที่คุณมีเวลาหรือทรัพยากรจํากัดในการลดความเสี่ยง หากต้องการคัดแยก ให้เน้นการอัปเกรดที่จำเป็นสำหรับข้อบกพร่องที่พบหรือฟีเจอร์ใหม่ที่ต้องการ
- ลดความเสี่ยงที่เหลือ
- ลองจัดกลุ่มการอัปเกรดเป็นชุดการเปลี่ยนแปลงขนาดเล็กๆ ที่ไม่เกี่ยวข้องกัน วิธีนี้ช่วยลดความเสี่ยงโดยรวมและอนุญาตให้เปลี่ยนกลับบางส่วนได้
- ตรวจสอบการเปลี่ยนแปลงโดยละเอียด
- ทดสอบแอปเพื่อตรวจหาการเปลี่ยนแปลงที่ไม่คาดคิด เพิ่มการทดสอบใหม่เมื่อจําเป็นเพื่อสร้างความสําคัญในการอัปเกรด
- ดูแหล่งที่มา (หากมี) เมื่อพบสิ่งที่น่าสงสัย
- ทำการเปลี่ยนแปลงที่จำเป็นในแหล่งที่มาหรือบิลด์
บันทึกการตัดสินใจของคุณ หากความเสี่ยงจากการอัปเกรดกลายเป็นปัญหาเมื่อเรียกใช้แอปพลิเคชัน เอกสารประกอบการวิเคราะห์ความเสี่ยงจะช่วยลดความจําเป็นในการวิเคราะห์ข้อผิดพลาดได้
ตรวจสอบใบอนุญาต
นักพัฒนาไลบรารีออกใบอนุญาตให้ใช้ไลบรารี คุณต้องปฏิบัติตามข้อกําหนดของใบอนุญาต ไม่เช่นนั้นคุณจะใช้คลังไม่ได้ ใบอนุญาตบางประเภทมีความยืดหยุ่นมาก โดยมักกำหนดให้ระบุแหล่งที่มาของคลังเท่านั้นและแสดงข้อความของใบอนุญาตต่อผู้ใช้ปลายทาง ซึ่งบางฟีเจอร์ถือเป็นแบบไวรัล หากใช้ไลบรารีเหล่านั้น คุณต้องใช้ใบอนุญาตเดียวกันกับแอปพลิเคชันหรือไลบรารี
ใบอนุญาตอาจมีการเปลี่ยนแปลงในทุกรุ่น เมื่อใดก็ตามที่คุณอัปเกรด คุณควรตรวจสอบว่าไลบรารีที่ใช้อยู่ได้รับอนุญาตในลักษณะที่เข้ากันได้กับแอปพลิเคชันหรือไลบรารีของคุณ
หากใบอนุญาตใช้ร่วมกันไม่ได้ (หรือมีการเปลี่ยนแปลงให้ใช้ร่วมกันไม่ได้อีกต่อไป) คุณจะไม่สามารถใช้คลังเวอร์ชันนั้นได้ ดังนี้
- ติดต่อเจ้าของคลังภาพและขอใช้ใบอนุญาตที่มีอยู่ต่อไปหรือขอใบอนุญาตแบบคู่เพื่อให้ใช้ใบอนุญาตเดิมได้
- โปรดปรึกษาทีมกฎหมายเพื่อดูว่าคุณเปลี่ยนใบอนุญาตให้ใช้งานร่วมกันได้หรือไม่
- ค้นหาไลบรารีอื่นที่มีใบอนุญาตที่เข้ากันได้และแก้ไขแอปพลิเคชันตามที่จำเป็น
- แยกห้องสมุดเวอร์ชันล่าสุดที่เข้ากันได้ (หากใบอนุญาตนั้นอนุญาตให้ใช้ผลงานที่ดัดแปลงและการเปลี่ยนแปลงจะไม่มีผลย้อนหลัง) แล้วทําการเปลี่ยนแปลงของคุณเอง