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

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 ต้องมีการจัดสรรหน่วยความจำ การติดตามสถานะอย่างชัดแจ้ง และ Callback ต่างๆ เพื่อรองรับ Use Case ทั้งหมด นอกจากนี้ เจ้าของ View ที่กำหนดเองต้องใช้ตรรกะที่ชัดเจนเพื่อป้องกันการวาดซ้ำโดยไม่จำเป็น เช่น สำหรับการประมวลผลข้อมูลซ้ำๆ

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

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

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

ViewGroup แบบดั้งเดิมมีการแสดงออกมากมายใน Measure และ Layout 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