เปรียบเทียบเมตริก "เขียน" และ "ดู"

Jetpack Compose ช่วยเร่งการพัฒนา UI และปรับปรุงการพัฒนา Android อย่างไรก็ตาม โปรดพิจารณาว่าการเพิ่ม Compose ลงในแอปที่มีอยู่จะส่งผลต่อเมตริกต่างๆ เช่น ขนาด APK, บิลด์ และประสิทธิภาพรันไทม์ของแอปอย่างไร

ขนาด APK และเวลาสร้าง

ส่วนนี้จะอธิบายผลกระทบต่อขนาด APK และเวลาสร้างโดยดูที่แอปตัวอย่าง Sunflower ซึ่งเป็นแอปที่แสดงแนวทางปฏิบัติแนะนำในการย้ายข้อมูลแอปที่ทำงานบน View ไปยัง Compose

ขนาด APK

การเพิ่มไลบรารีลงในโปรเจ็กต์จะเพิ่มขนาด APK ผลลัพธ์ต่อไปนี้เป็น APK รุ่นที่ผ่านการย่อขนาดของแต่ละโปรเจ็กต์ที่เปิดใช้การลดขนาดทรัพยากรและโค้ดโดยใช้โหมด R8 แบบเต็ม และวัดโดยใช้เครื่องมือวิเคราะห์ APK

เมื่อเพิ่ม Compose ลงใน Sunflower เป็นครั้งแรก ขนาด APK เพิ่มขึ้นจาก 2,252 KB เป็น 3,034 KB ซึ่งเพิ่มขึ้น 782 KB APK ที่สร้างขึ้นประกอบด้วยบิลด์ UI ที่มีทั้ง Views และ Compose การเพิ่มนี้เป็นสิ่งที่คาดไว้เนื่องจากมีการเพิ่มข้อกําหนดเพิ่มเติมลงใน Sunflower

ในทางกลับกัน เมื่อย้ายข้อมูล Sunflower ไปยังแอป Compose เท่านั้น ขนาด APK ลดลงจาก 3,034 KB เป็น 2,966 KB ลดลง 68 KB การลดลงนี้เกิดจากการนําการพึ่งพามุมมองที่ไม่ได้ใช้ออก เช่น AppCompat และ ConstraintLayout

เวลาบิลด์

การเพิ่ม Compose จะเพิ่มเวลาในการบิลด์แอปเนื่องจากคอมไพเลอร์ Compose จะประมวลผลคอมโพสิเบิลในแอปของคุณ ผลลัพธ์ต่อไปนี้ได้มาจากการใช้เครื่องมือ gradle-profiler แบบสแตนด์อโลน ซึ่งจะทำการบิลด์หลายครั้งเพื่อให้ได้เวลาเฉลี่ยในการบิลด์สำหรับระยะเวลาของบิลด์แก้ไขข้อบกพร่องของ Sunflower

gradle-profiler --benchmark --project-dir . :app:assembleDebug

เมื่อเพิ่ม Compose ลงใน Sunflower เป็นครั้งแรก เวลาสร้างโดยเฉลี่ยเพิ่มขึ้นจาก 299 มิลลิวินาทีเป็น 399 มิลลิวินาที ซึ่งเพิ่มขึ้น 100 มิลลิวินาที ระยะเวลานี้เกิดจากคอมไพเลอร์ Compose ดําเนินการเพิ่มเติมเพื่อเปลี่ยนรูปแบบโค้ด Compose ที่กําหนดไว้ในโปรเจ็กต์

ในทางกลับกัน เวลาที่ใช้ในการสร้างโดยเฉลี่ยลดลงเหลือ 342 มิลลิวินาที ลดลง 57 มิลลิวินาที เมื่อการย้ายข้อมูล Sunflower ไปยัง Compose เสร็จสมบูรณ์ การลดเวลานี้เป็นผลมาจากปัจจัยหลายประการที่รวมกันเพื่อลดเวลาในการสร้าง เช่น การนําการเชื่อมโยงข้อมูลออก การย้ายข้อมูล Dependency ที่ใช้ kapt ไปยัง KSP และการอัปเดต Dependency หลายรายการเป็นเวอร์ชันล่าสุด

สรุป

การใช้ Compose จะเพิ่มขนาด APK ของแอปอย่างมีประสิทธิภาพ และเพิ่มประสิทธิภาพเวลาสร้างของแอปด้วยเนื่องจากกระบวนการคอมไพล์โค้ด Compose อย่างไรก็ตาม คุณต้องพิจารณาข้อเสียเหล่านี้เทียบกับประโยชน์ของ Compose โดยเฉพาะอย่างยิ่งในด้านการเพิ่มประสิทธิภาพของนักพัฒนาแอปเมื่อใช้ Compose ตัวอย่างเช่น ทีม Play Store พบว่าการเขียน UI ใช้โค้ดน้อยลงมาก บางครั้งถึง 50% จึงช่วยเพิ่มประสิทธิภาพการทำงานและการบำรุงรักษาโค้ดได้

อ่านกรณีศึกษาเพิ่มเติมได้ในใช้ Compose สำหรับ Teams

ประสิทธิภาพรันไทม์

ส่วนนี้จะกล่าวถึงหัวข้อที่เกี่ยวข้องกับประสิทธิภาพรันไทม์ใน Jetpack Compose เพื่อช่วยให้คุณเข้าใจประสิทธิภาพของ Jetpack Compose เมื่อเทียบกับประสิทธิภาพของระบบ View และวิธีวัดประสิทธิภาพ

การจัดองค์ประกอบใหม่อย่างชาญฉลาด

เมื่อ UI บางส่วนไม่ถูกต้อง Compose จะพยายามคอมไพล์เฉพาะส่วนที่จำเป็นต้องอัปเดตใหม่ อ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในเอกสารประกอบวงจรชีวิตของคอมโพสิเบิลและระยะต่างๆ ของ Jetpack Compose

โปรไฟล์พื้นฐาน

โปรไฟล์พื้นฐานเป็นวิธีที่ดีในการเร่งเส้นทางของผู้ใช้ทั่วไป การรวมโปรไฟล์พื้นฐานไว้ในแอปจะช่วยเพิ่มความเร็วในการเรียกใช้โค้ดได้ประมาณ 30% จากการเปิดใช้งานครั้งแรกด้วยการหลีกเลี่ยงขั้นตอนตีความและการคอมไพล์แบบทันท่วงที (JIT) สำหรับเส้นทางโค้ดที่รวมไว้

ไลบรารี Jetpack Compose มีโปรไฟล์พื้นฐานของตัวเอง และคุณจะได้รับการเพิ่มประสิทธิภาพเหล่านี้โดยอัตโนมัติเมื่อใช้ Compose ในแอป อย่างไรก็ตาม การเพิ่มประสิทธิภาพเหล่านี้จะส่งผลต่อเส้นทางโค้ดภายในไลบรารี Compose เท่านั้น เราจึงขอแนะนำให้คุณเพิ่มโปรไฟล์พื้นฐานลงในแอปเพื่อครอบคลุมเส้นทางโค้ดที่อยู่นอก Compose

การเปรียบเทียบกับระบบ View

Jetpack Compose มีการปรับปรุงหลายอย่างเหนือกว่าระบบ View การปรับปรุงเหล่านี้อธิบายไว้ในส่วนต่อไปนี้

ทุกอย่างขยายมุมมอง

View ทั้งหมดที่วาดบนหน้าจอ เช่น TextView, Button หรือ ImageView ต้องมีการจัดสรรหน่วยความจำ การติดตามสถานะอย่างชัดเจน และการเรียกกลับต่างๆ เพื่อรองรับกรณีการใช้งานทั้งหมด นอกจากนี้ เจ้าของ View ที่กําหนดเองยังต้องใช้ตรรกะแบบชัดเจนเพื่อป้องกันการวาดใหม่เมื่อไม่จําเป็น เช่น สำหรับการประมวลผลข้อมูลที่ซ้ำกัน

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

นอกจากนี้ เครื่องมือแต่งภาพยังมีการจัดองค์ประกอบใหม่อย่างชาญฉลาด ซึ่งจะเล่นผลลัพธ์ที่วาดไว้ก่อนหน้านี้ซ้ำหากคุณไม่จําเป็นต้องทําการเปลี่ยนแปลง

การส่งผ่านเลย์เอาต์หลายรายการ

ViewGroup แบบดั้งเดิมมีการแสดงออกมากมายใน API ของข้อมูลการวัดและเลย์เอาต์ ซึ่งทำให้มีแนวโน้มที่จะใช้การผ่านเลย์เอาต์หลายครั้ง การวางผังหลายรอบเหล่านี้อาจทําให้เกิดความซับซ้อนมากขึ้นหากทําที่จุดที่ฝังอยู่เฉพาะเจาะจงในลําดับชั้นของมุมมอง

Jetpack Compose ใช้การเรียกใช้เลย์เอาต์ครั้งเดียวสำหรับคอมโพสิชันเลย์เอาต์ทั้งหมดผ่านสัญญา API ซึ่งช่วยให้ Compose จัดการต้นไม้ UI ระดับลึกได้อย่างมีประสิทธิภาพ หากต้องใช้การวัดผลหลายรายการ Compose มีการวัดผลในตัว

ดูประสิทธิภาพการเริ่มต้น

ระบบ View ต้องขยายเลย์เอาต์ XML เมื่อแสดงเลย์เอาต์หนึ่งๆ เป็นครั้งแรก ค่าใช้จ่ายนี้จะถูกบันทึกไว้ใน Jetpack Compose เนื่องจากเลย์เอาต์เขียนด้วย Kotlin และคอมไพล์เหมือนกับส่วนอื่นๆ ของแอป

เบนช์มาร์ก Compose

ใน Jetpack Compose 1.0 ประสิทธิภาพของแอปในโหมด debug และ release จะแตกต่างกันอย่างเห็นได้ชัด สําหรับการวัดเวลาที่เป็นตัวแทน ให้ใช้บิลด์ release แทน debug ทุกครั้งเมื่อโปรไฟล์แอป

หากต้องการตรวจสอบประสิทธิภาพของโค้ด Jetpack Compose ให้ใช้ไลบรารี Jetpack Macrobenchmark ดูวิธีใช้กับ Jetpack Compose ได้ที่โปรเจ็กต์ MacrobenchmarkSample

ทีม Jetpack Compose ยังใช้ Macrobenchmark เพื่อตรวจหาการถดถอยที่อาจเกิดขึ้นด้วย เช่น ดูการเปรียบเทียบสำหรับคอลัมน์แบบ Lazy และหน้าแดชบอร์ดเพื่อติดตามการถดถอย

การติดตั้งโปรไฟล์การเขียน

เนื่องจาก Jetpack Compose เป็นไลบรารีแบบไม่ได้รวมกลุ่ม จึงไม่ได้รับประโยชน์จาก Zygote ที่โหลดคลาสและองค์ประกอบที่วาดได้ของ UI Toolkit ของระบบ View ไว้ล่วงหน้า Jetpack Compose 1.0 ใช้การติดตั้งโปรไฟล์สำหรับบิลด์รุ่น โปรแกรมติดตั้งโปรไฟล์ช่วยให้แอประบุโค้ดที่สำคัญที่จะคอมไพล์ล่วงหน้า (AOT) ณ เวลาที่ติดตั้ง Compose จะจัดส่งกฎการติดตั้งโปรไฟล์ซึ่งช่วยลดเวลาในการเริ่มต้นและอาการกระตุกในแอป Compose