โปรดตั้งสติและให้เราแนะนำข้อมูลเบื้องหลังเพิ่มเติมเกี่ยวกับประสิทธิภาพ

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

การเพิ่มประสิทธิภาพตามโปรไฟล์

โปรไฟล์ Baseline และโปรไฟล์การเริ่มต้นเป็นรากฐานสำคัญในการปรับปรุงประสิทธิภาพการเริ่มต้นและรันไทม์ของแอป Android ซึ่งเป็นส่วนหนึ่งของการเพิ่มประสิทธิภาพกลุ่มที่เรียกว่าการเพิ่มประสิทธิภาพตามโปรไฟล์

เมื่อแพ็กเกจแอปแล้ว d8 dexer จะนำคลาสและเมธอดไปใส่ในไฟล์ classes.dex ของแอป เมื่อผู้ใช้เปิดแอป ระบบจะโหลดไฟล์ DEX เหล่านี้ทีละไฟล์จนกว่าแอปจะเริ่มทำงานได้ การระบุโปรไฟล์ Startup จะช่วยให้ d8 ทราบว่าควรแพ็กคลาสและเมธอดใดไว้ในไฟล์ classes.dex ไฟล์แรก โครงสร้างนี้ช่วยให้แอปโหลดไฟล์น้อยลง ซึ่งจะช่วยเพิ่มความเร็วในการเริ่มต้น

Baseline Profile จะย้ายขั้นตอนการคอมไพล์ Just in Time (JIT) ออกจากอุปกรณ์ของผู้ใช้ไปยังเครื่องของนักพัฒนาแอปได้อย่างมีประสิทธิภาพ โค้ดที่คอมไพล์ล่วงหน้า (AOT) ที่สร้างขึ้นได้รับการพิสูจน์แล้วว่าช่วยลดเวลาเริ่มต้นและปัญหาการแสดงผลได้

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

เราได้สอบถามวิศวกรในแอป Trello ว่า Baseline Profile ส่งผลต่อประสิทธิภาพของแอปอย่างไร หลังจากใช้โปรไฟล์พื้นฐานกับเส้นทางของผู้ใช้หลัก Trello พบว่าเวลาเริ่มต้นแอปสั้นลงอย่างเห็นได้ชัดถึง 25%

Trello สามารถปรับปรุงเวลาเริ่มต้นของแอปได้ 25 % โดยใช้โปรไฟล์พื้นฐาน

โปรไฟล์พื้นฐานที่ Meta

นอกจากนี้ วิศวกรที่ Meta เพิ่งเผยแพร่บทความเกี่ยวกับวิธีเร่งความเร็วแอป Android ด้วยโปรไฟล์พื้นฐาน

ทีมต่างๆ ในแอปของ Meta พบว่าเมตริกที่สำคัญต่างๆ ดีขึ้นสูงสุด 40 % หลังจากใช้โปรไฟล์ Baseline

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

เริ่มต้นใช้งานโปรไฟล์พื้นฐาน

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

การเขียนการเปรียบเทียบเช่นนี้เป็นเรื่องง่าย และคุณสามารถดูตัวอย่างทั้งหมดได้ใน GitHub

@Test

fun profileGenerator() {

    rule.collect(

        packageName = TARGET_PACKAGE,

        maxIterations = 15,

        stableIterations = 3,

        includeInStartupProfile = true

    ) {

        uiAutomator {

            startApp(TARGET_PACKAGE)

        }

    }


}

ข้อควรพิจารณา

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

เริ่มต้นใช้งานการเพิ่มประสิทธิภาพที่อิงตามโปรไฟล์

หากต้องการดูวิธีการทำงานของโปรไฟล์พื้นฐานเบื้องหลัง โปรดดูวิดีโอนี้จาก Android Developers Summit

และดูตอนเวลาบิลด์ของ Android เกี่ยวกับการเพิ่มประสิทธิภาพตามการกำหนดโปรไฟล์เพื่อดูข้อมูลเชิงลึกเพิ่มเติม 

นอกจากนี้ เรายังมีคำแนะนำที่ครอบคลุมเกี่ยวกับโปรไฟล์พื้นฐานและโปรไฟล์สตาร์ทอัปให้คุณอ่านเพิ่มเติมด้วย

การปรับปรุงประสิทธิภาพของ Jetpack Compose

เฟรมเวิร์ก UI สำหรับ Android ได้รับการลงทุนด้านประสิทธิภาพจากทีมวิศวกร ซึ่งส่งผลให้ตั้งแต่ Jetpack Compose เวอร์ชัน 1.9 การกระตุกขณะเลื่อนลดลงเหลือ 0.2 % ในการทดสอบเปรียบเทียบการเลื่อนแบบยาวภายใน 

การปรับปรุงเหล่านี้เกิดขึ้นได้เนื่องจากฟีเจอร์ต่างๆ ที่รวมอยู่ในรุ่นล่าสุด

กรอบเวลาแคชที่ปรับแต่งได้

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

หากต้องการเริ่มใช้ช่วงแคชที่ปรับแต่งได้ ให้สร้างอินสแตนซ์ LazyLayoutCacheWindow แล้วส่งไปยังรายการหรือตารางแบบเลซี วัดประสิทธิภาพของแอปโดยใช้ขนาดหน้าต่างแคชที่แตกต่างกัน เช่น 50% ของวิวพอร์ต ค่าที่เหมาะสมจะขึ้นอยู่กับโครงสร้างของเนื้อหาและขนาดของรายการ

val dpCacheWindow = LazyLayoutCacheWindow(ahead = 150.dp, behind = 100.dp)

val state = rememberLazyListState(cacheWindow = dpCacheWindow)

LazyColumn(state = state) {

    // column contents

}

องค์ประกอบที่หยุดชั่วคราวได้

ฟีเจอร์นี้ช่วยให้หยุดการคอมโพสชั่วคราวและแยกงานออกเป็นหลายเฟรมได้ API ดังกล่าวเปิดตัวในเวอร์ชัน 1.9 และตอนนี้ใช้โดยค่าเริ่มต้นในเวอร์ชัน 1.10 ในการดึงข้อมูลเลย์เอาต์แบบ Lazy Loading คุณควรได้รับประโยชน์สูงสุดจากรายการที่ซับซ้อนซึ่งมีเวลาในการจัดองค์ประกอบนานขึ้น 

การเพิ่มประสิทธิภาพ Compose เพิ่มเติม

ใน Compose เวอร์ชัน 1.9 และ 1.10 ทีมยังได้ทำการเพิ่มประสิทธิภาพหลายอย่างที่อาจไม่ชัดเจนนัก

เราได้ปรับปรุง API หลายรายการที่ใช้โครูทีนเบื้องหลัง ตัวอย่างเช่น เมื่อใช้ Draggable และ Clickable นักพัฒนาแอปควรเห็นเวลาตอบสนองที่เร็วขึ้นและจำนวนการจัดสรรที่เพิ่มขึ้น

การเพิ่มประสิทธิภาพในการติดตามสี่เหลี่ยมผืนผ้าของเลย์เอาต์ช่วยปรับปรุงประสิทธิภาพของตัวแก้ไข เช่น onVisibilityChanged() และ onLayoutRectChanged() ซึ่งจะช่วยเร่งระยะเลย์เอาต์ได้ แม้ว่าจะไม่ได้ใช้ API เหล่านี้โดยตรงก็ตาม

การปรับปรุงประสิทธิภาพอีกอย่างคือการใช้ค่าที่แคชไว้เมื่อสังเกตตำแหน่งผ่าน onPlaced()

ดึงข้อมูลข้อความล่วงหน้าในเบื้องหลัง

ตั้งแต่เวอร์ชัน 1.9 เป็นต้นไป Compose จะเพิ่มความสามารถในการดึงข้อมูลข้อความล่วงหน้าในเธรดเบื้องหลัง ซึ่งจะช่วยให้คุณอุ่นแคชล่วงหน้าเพื่อเปิดใช้เลย์เอาต์ข้อความที่เร็วขึ้น และเกี่ยวข้องกับประสิทธิภาพการแสดงผลแอป ในระหว่างการจัดวางข้อความจะต้องส่งไปยังเฟรมเวิร์ก Android ซึ่งจะมีการสร้างแคชคำ โดยค่าเริ่มต้น ฟังก์ชันนี้จะทำงานในเทรด UI การส่งต่อการดึงข้อมูลล่วงหน้าและการป้อนข้อมูลแคชคำไปยังเธรดเบื้องหลังจะช่วยเพิ่มความเร็วในการจัดวาง โดยเฉพาะอย่างยิ่งสำหรับข้อความที่ยาวขึ้น หากต้องการดึงข้อมูลล่วงหน้าในเธรดเบื้องหลัง คุณสามารถส่ง Executor ที่กำหนดเองไปยัง Composable ใดก็ได้ที่ใช้ BasicText ภายใต้โครงสร้างโดยการส่ง LocalBackgroundTextMeasurementExecutor ไปยัง CompositionLocalProvider ดังนี้

val defaultTextMeasurementExecutor = Executors.newSingleThreadExecutor()

CompositionLocalProvider(

    LocalBackgroundTextMeasurementExecutor provides DefaultTextMeasurementExecutor

) {

    BasicText("Some text that should be measured on a background thread!")


}

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

ข้อควรพิจารณาเกี่ยวกับประสิทธิภาพการทำงานในเบื้องหลัง

งานในเบื้องหลังเป็นส่วนสำคัญของแอปจำนวนมาก คุณอาจใช้ไลบรารี เช่น WorkManager หรือ JobScheduler เพื่อทำงานต่างๆ เช่น

• อัปโหลดเหตุการณ์วิเคราะห์เป็นระยะ
• การซิงค์ข้อมูลระหว่างบริการแบ็กเอนด์กับฐานข้อมูล
• การประมวลผลสื่อ (เช่น การปรับขนาดหรือการบีบอัดรูปภาพ)

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

อย่างไรก็ตาม WorkManager ไม่ใช่โซลูชันที่เหมาะกับทุกกรณี นอกจากนี้ Android ยังมี API ที่เพิ่มประสิทธิภาพการใช้พลังงานหลายรายการซึ่งออกแบบมาโดยเฉพาะโดยคำนึงถึงเส้นทางของผู้ใช้หลัก (Core User Journeys หรือ CUJ) ทั่วไปบางอย่าง  

ดูรายการตัวอย่างการทำงานในเบื้องหลังได้ที่หน้า Landing Page ของการทำงานในเบื้องหลัง ซึ่งรวมถึงการอัปเดตวิดเจ็ตและการรับตำแหน่งในเบื้องหลัง

เครื่องมือแก้ไขข้อบกพร่องในเครื่องสำหรับงานในเบื้องหลัง: สถานการณ์ที่พบบ่อย

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

WorkManager มี เครื่องมือที่เกี่ยวข้องหลายอย่างที่จะช่วยคุณแก้ไขข้อบกพร่องในเครื่องและเพิ่มประสิทธิภาพ (เครื่องมือบางอย่างใช้ได้กับ JobScheduler ด้วย) ต่อไปนี้คือสถานการณ์ที่พบบ่อยเมื่อใช้ WorkManager และคำอธิบายเครื่องมือที่คุณใช้ในการแก้ไขข้อบกพร่องได้

การแก้ไขข้อบกพร่องที่ทำให้งานที่กำหนดเวลาไว้ไม่ทำงาน

งานที่กำหนดเวลาไว้ล่าช้าหรือไม่ทำงานเลยอาจเกิดจากหลายปัจจัย ซึ่งรวมถึงการไม่เป็นไปตามข้อจำกัดที่ระบุหรือระบบกำหนดข้อจำกัดไว้ 

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

มีเครื่องมือหลายอย่างที่ใช้แก้ไขข้อบกพร่องในสถานการณ์นี้ได้

เครื่องมือตรวจสอบงานในเบื้องหลัง

เครื่องมือตรวจสอบงานในเบื้องหลังเป็นเครื่องมือที่มีประสิทธิภาพซึ่งผสานรวมอยู่ใน Android Studio โดยตรง โดยจะแสดงภาพแทนของงาน WorkManager ทั้งหมดและสถานะที่เกี่ยวข้อง (กำลังทำงาน เข้าคิว ไม่สำเร็จ สำเร็จ) 

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

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

มุมมองรายการของเครื่องมือตรวจสอบงานในเบื้องหลัง

มุมมองกราฟของเครื่องมือตรวจสอบงานในเบื้องหลัง

adb shell dumpsys jobscheduler

คำสั่งนี้จะแสดงรายการงาน JobScheduler ที่ทำงานอยู่ทั้งหมด (ซึ่งรวมถึง Worker ของ WorkManager) พร้อมกับข้อจำกัดที่ระบุและข้อจำกัดที่ระบบกำหนด นอกจากนี้ยังแสดงประวัติงานด้วย 

ใช้ตัวเลือกนี้หากต้องการดูงานที่กำหนดเวลาไว้และข้อจำกัดที่เกี่ยวข้องในรูปแบบอื่น สำหรับ WorkManager เวอร์ชันที่เก่ากว่า WorkManager 2.10.0, adb shell dumpsys jobscheduler จะแสดงรายการ Worker ที่มีชื่อนี้

[package name]/androidx.work.impl.background.systemjob.SystemJobService

หากแอปมี Worker หลายรายการ การอัปเดตเป็น WorkManager 2.10.0 จะช่วยให้คุณเห็นชื่อ Worker และแยกความแตกต่างระหว่าง Worker ได้ง่ายๆ ดังนี้

#WorkerName#@[package name]/androidx.work.impl.background.systemjob.SystemJobService

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

เปิดใช้การบันทึกการแก้ไขข้อบกพร่อง

คุณเปิดใช้การบันทึกที่กำหนดเองเพื่อดูบันทึก WorkManager แบบละเอียดได้ ซึ่งจะมี WM— แนบมาด้วย 

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

WorkInfo.StopReason

หากพบว่าประสิทธิภาพของ Worker บางตัวคาดเดาไม่ได้ คุณสามารถสังเกตสาเหตุที่ระบบหยุด Worker ในความพยายามรันครั้งก่อนได้โดยใช้ WorkInfo.getStopReason 

แนวทางปฏิบัติแนะนำคือการกำหนดค่าแอปให้สังเกต WorkInfo โดยใช้ getWorkInfoByIdFlow เพื่อระบุว่างานได้รับผลกระทบจากข้อจำกัดในเบื้องหลัง ข้อจำกัด การหมดเวลาบ่อยครั้ง หรือแม้แต่ถูกผู้ใช้หยุดหรือไม่

สิทธิประโยชน์: คุณใช้ WorkInfo.StopReason เพื่อรวบรวมข้อมูลภาคสนามเกี่ยวกับประสิทธิภาพของ Worker ได้

การแก้ไขข้อบกพร่องของระยะเวลา Wake Lock สูงที่เกิดจาก WorkManager ซึ่ง Android Vitals แจ้งว่าไม่เหมาะสม

Android Vitals มีเมตริก Wake Lock บางส่วนที่มากเกินไป ซึ่งจะไฮไลต์ Wake Lock ที่ทำให้แบตเตอรี่หมดเร็ว คุณอาจแปลกใจที่ทราบว่า WorkManager จะรับ Wake Lock เพื่อดำเนินการ และหาก Wake Lock เกินเกณฑ์ที่ Google Play กำหนดไว้ อาจส่งผลต่อการมองเห็นแอปของคุณ คุณจะแก้ไขข้อบกพร่องเพื่อหาสาเหตุที่ระยะเวลา Wake Lock ที่เกิดจากงานของคุณมีมากได้อย่างไร คุณใช้เครื่องมือต่อไปนี้ได้

แดชบอร์ด Android Vitals

ก่อนอื่น ให้ตรวจสอบในแดชบอร์ดการปลุกล็อกมากเกินไปของ Android Vitals ว่าระยะเวลาการปลุกล็อกสูงมาจาก WorkManager ไม่ใช่การปลุกหรือการปลุกล็อกอื่นๆ คุณสามารถใช้เอกสารประกอบระบุ Wake Lock ที่สร้างโดย API อื่นๆ เพื่อทำความเข้าใจว่า Wake Lock ใดที่ WorkManager ถือครองอยู่ 

Perfetto

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

ในแทร็ก "สถานะอุปกรณ์: งาน" คุณจะเห็น Worker ที่ดำเนินการและ Wake Lock ที่เชื่อมโยง

ส่วนสถานะอุปกรณ์ใน Perfetto ซึ่งแสดงการดำเนินการ CleanupWorker และ BlurWorker

แหล่งข้อมูล

โปรดดูหน้าการแก้ไขข้อบกพร่องของ WorkManager เพื่อดูภาพรวมของวิธีการแก้ไขข้อบกพร่องที่มีให้สำหรับสถานการณ์อื่นๆ ที่คุณอาจพบ

หากต้องการลองใช้วิธีการเหล่านี้ด้วยตนเองและดูข้อมูลเพิ่มเติมเกี่ยวกับการแก้ไขข้อบกพร่องของ WorkManager โปรดดู Codelab WorkManager ขั้นสูงและการทดสอบ

ขั้นตอนถัดไป

วันนี้เราได้ก้าวข้ามการลดขนาดโค้ดและสำรวจวิธีที่ Android Runtime และ Jetpack Compose แสดงผลแอปของคุณจริงๆ ไม่ว่าจะเป็นการคอมไพล์เส้นทางวิกฤตล่วงหน้าด้วยโปรไฟล์ Baseline หรือการปรับสถานะการเลื่อนให้ราบรื่นด้วยฟีเจอร์ใหม่ใน Compose 1.9 และ 1.10 เครื่องมือเหล่านี้มุ่งเน้นที่ความรู้สึกของแอป และเรายังได้เจาะลึกแนวทางปฏิบัติแนะนำในการแก้ไขข้อบกพร่องของงานที่ทำงานในเบื้องหลังด้วย

ถาม Android

ในวันศุกร์นี้ เราจะจัดเซสชัน AMA ถามตอบทุกข้อสงสัยแบบสดเกี่ยวกับประสิทธิภาพ ถามคำถามของคุณตอนนี้โดยใช้ #AskAndroid แล้วรับคำตอบจากผู้เชี่ยวชาญ

ความท้าทาย

เมื่อวันจันทร์ที่ผ่านมา เราได้ท้าทายให้คุณเปิดใช้ R8 วันนี้เราขอให้คุณสร้างโปรไฟล์พื้นฐาน 1 รายการสำหรับแอป

Android Studio Otter ทำให้การดำเนินการนี้ง่ายกว่าที่เคยด้วยวิซาร์ดโมดูล Baseline Profile Generator เลือกเส้นทางของผู้ใช้ที่สําคัญที่สุด แม้ว่าจะเป็นเพียงการเริ่มต้นแอปและการเข้าสู่ระบบ แล้วสร้างโปรไฟล์

เมื่อได้แล้ว ให้เรียกใช้ Macrobenchmark เพื่อเปรียบเทียบ CompilationMode.None กับ CompilationMode.Partial

แชร์การปรับปรุงเวลาเริ่มต้นบนโซเชียลมีเดียโดยใช้แฮชแท็ก #optimizationEnabled

ติดตามพรุ่งนี้

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

เข้าร่วมกับเราในวันพรุ่งนี้สำหรับวันที่ 4: คำแนะนำในการปรับระดับประสิทธิภาพ ซึ่งเราจะอธิบายวิธีวัดความสำเร็จอย่างละเอียด ตั้งแต่ข้อมูลภาคสนามใน Play Vitals ไปจนถึงการติดตามในระดับลึกด้วย Perfetto