Trace me if you can: Automated instrumentation and field profiling

Rahul Ravikumar

สวัสดีทุกคน

ฉันชื่อ Rahul

ฉันเป็นวิศวกรในทีมประสบการณ์นักพัฒนาแอป Android

ฉันมุ่งเน้นที่ประสิทธิภาพของแอปและไลบรารี และการพูดคุยนี้จะเกี่ยวกับ Tracing

ก่อนที่จะเจาะลึกเรื่องการติดตาม ฉันอยากจะอธิบายคำศัพท์บางคำเพื่อให้คุณเข้าใจตรงกัน

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

ฉันไม่ได้พูดถึงเครื่องมือสร้างโปรไฟล์อัตโนมัติที่ฉันจะพูดถึง

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

ซึ่งมักจะดีกว่าบันทึกมาก

ผมไม่รู้ว่าคุณเคยเห็นเอาต์พุต Logcat ของแอปขนาดใหญ่ไหม

โดยปกติแล้วจะเป็นข้อความยาวเป็นพรืดที่เข้าใจได้ยาก

ในทางกลับกัน การลอกลายจะง่ายกว่ามาก

ซึ่งจะช่วยให้เห็นภาพได้ง่ายขึ้น

คุณมีระยะเวลา

คุณมีโครงสร้างบางอย่าง

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

ซึ่งทำให้ใช้งานได้สะดวกขึ้นมาก

และคุณสามารถชี้ให้ตัวแทนดูการติดตามและถามคำถามได้

คุณสามารถใช้เครื่องมือต่างๆ เช่น Trace Processor, การเปรียบเทียบ และแม้แต่แปลงการติดตามเป็นเมตริก

ทั้งหมดนี้คือสิ่งที่คุณทำได้ด้วยการติดตาม ซึ่งทำได้ยากด้วย Logcat

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

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

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

คุณอาจใช้ร่องรอยเมธอด ART ซึ่งคุณจะวัดคุมการเข้าและออกจากเมธอดทุกรายการ

หรือคุณอาจกำลังดูการสุ่มตัวอย่างสแต็กด้วยเครื่องมืออย่าง Simpleperf

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

ในปี 2026 นี้ RAM เป็นปัญหาที่พบได้ทุกที่ คุณจึงอาจต้องพิจารณาหน่วยความจำ หน่วยความจำรั่วไหล และโปรไฟล์ฮีป

ดังนั้น นี่จึงเป็นเครื่องมือวิเคราะห์ประสิทธิภาพอีกตัวหนึ่งที่คุณใช้ประโยชน์ได้

คุณสามารถดูเส้นทางการเก็บรักษาฮีปได้

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

ขวา

ตอนนี้เรามีคำศัพท์นั้นแล้ว

ตอนนี้เรามาพูดถึงสาเหตุที่เราสร้างคลังใหม่กัน

Tracing API ซึ่งเป็น API เวอร์ชัน 1.0 เปิดตัวครั้งแรกใน Android Jelly Bean

ซึ่งเกิดขึ้นในปี 2012

ซึ่งเป็นเวลากว่า 14 ปีมาแล้ว

นับตั้งแต่นั้นมา API ก็ไม่ได้พัฒนาไปมากอย่างที่คุณคิด

เราได้เพิ่มส่วนขยายบางรายการ

เหตุการณ์และตัวนับแบบไม่พร้อมกันได้รับการเพิ่มใน Android 10

ซึ่งเกิดขึ้นในปี 2019

และนั่นคือทั้งหมด

API ไม่มีการพัฒนาตั้งแต่นั้นมา

อย่างไรก็ตาม ระบบนิเวศมีการพัฒนาไปมาก

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

ซึ่งเป็นสิ่งที่เราต้องการเปลี่ยนแปลง

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

Atrace เป็นระบบย่อยการติดตามของ Android ที่เป็นเจ้าของข้อมูลนั้น

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

ซึ่งเป็นรูปแบบที่มีการบันทึกไว้อย่างดี แต่อาจเข้าใจได้ยาก

เราจึงต้องการแก้ไขปัญหานี้

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

นอกจากนี้ เรายังมีข้อจำกัดในการติดตาม 1.0 ซึ่งป้ายกำกับถูกจำกัดไว้ที่ 128 อักขระ

ข้อจำกัดดังกล่าวอาจสมเหตุสมผลในปี 2012 แต่ในปี 2026 ดูเหมือนจะแปลกไปหน่อย

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

และยังมีค่าใช้จ่ายในการดำเนินงานด้วย

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

ดังนั้น หากมีภาวะแข่งขันที่คุณต้องการจำลอง การติดตามไม่ควรทำให้ภาวะแข่งขันหายไป

ดังนั้น คุณจึงควรตรวจสอบว่าได้คงความหมายทั้งหมดที่ต้องการสื่อไว้

การติดตาม 1.0 มีค่าใช้จ่ายที่ค่อนข้างสูง และเราต้องการปรับปรุงในส่วนนี้

ตกลง

ฉันพูดถึงปัญหาต่างๆ ไปเยอะมาก

ทีนี้มาดูปัญหาบางอย่างในรูปแบบภาพและดูว่าปัญหาเหล่านั้นส่งผลกระทบอย่างไรในทางปฏิบัติ

นี่คือ Perfetto Trace

สำหรับแอป com.example.app

เรามีเทรดหลักและมีส่วนเดียวที่เรียกว่า initializeComponent

ตอนนี้เราต้องการรายละเอียดเพิ่มเติม

เรามาเพิ่มรายละเอียดกัน

ตอนนี้เราทราบแล้วว่า initializeComponent เรียกใช้ performInitialize

เรายังไม่ทราบว่าคอมโพเนนต์ใดที่กำลังเริ่มต้นทำงาน

ตอนนี้เครื่องมือเดียวในเข็มขัดเครื่องมือของเราที่มี Tracing 1 คือชื่อ ดังนั้นเราจึงเพิ่มชื่อดังกล่าวลงในชื่อของ Slice

โปรดทราบว่าชื่อส่วนการติดตามถูกจำกัดไว้ที่ 128 อักขระ ดังนั้นชื่อจึงถูกตัดให้สั้นลงในการติดตาม

และที่แย่ไปกว่านั้นคือตอนนี้โอเวอร์เฮดของการตัดทอนยังเป็นโอเวอร์เฮดที่คุณต้องรับผิดชอบเมื่อทำการติดตามด้วย

ตอนนี้คุณจึงพบปัญหานี้อย่างรวดเร็ว

เราจึงต้องการแก้ไขปัญหานี้เป็นอย่างมาก

คุณได้เห็นการติดตาม Perfetto และเห็นลักษณะของภาพแล้ว

ตอนนี้ เรามาดูจากมุมมองของการเขียนโค้ดเพื่อสร้างส่วนการติดตามเหล่านั้นกัน

เรามี initializeComponent API อีกครั้ง

โดยจะใช้บริบทและชื่อ และเรียกใช้ performInitialize

ทุกอย่างเป็นไปด้วยดี

ตอนนี้เราต้องการเพิ่มการติดตามด้วย Tracing 1.0 API คุณจึงทำได้โดยนำเข้า androidx.tracing.trace และใช้บล็อกการติดตาม

คุณตั้งชื่อให้กลุ่ม

ที่นี่คือ performInitialize

แต่เช่นเดียวกับที่เราต้องการทำก่อนหน้านี้ เราต้องการทราบชื่อของคอมโพเนนต์ ดังนั้นเราจะใช้การแทรกสตริงของ Kotlin และเราจะเพิ่มชื่อ

และนี่คือปัญหาแรก

ดังนั้น เราจึงจำกัดจำนวนอักขระไว้ที่ 128 ตัว

Rahul Ravikumar

เราแก้ไขปัญหานี้ได้ด้วยการติดตาม 2

คุณใช้ Tracer แทนการใช้ androidx.tracing.trace

API มีลักษณะคล้ายกันมาก

คุณมี Tracer.global.trace แทนที่จะเป็น trace

คุณมีหมวดหมู่

เราจะพูดถึงหมวดหมู่โดยละเอียดในภายหลัง แต่โดยพื้นฐานแล้ว คุณจะมีชื่อ

และคุณยังมีบล็อกโค้ดที่พยายามติดตามอยู่

และตอนนี้คุณไม่มีข้อจำกัดเรื่องจำนวนอักขระสูงสุด 128 ตัวอีกต่อไป

ฉันได้พูดถึงโอเวอร์เฮดของการติดตามไปแล้ว

เราอยากลงรายละเอียดเพิ่มเติมและดูว่าเราได้ปรับปรุงเรื่องนี้อย่างไรบ้าง

ใน Pixel 6a ที่ใช้ Android 16 การแทรกส่วนเริ่มต้นและส่วนสิ้นสุดเพียงส่วนเดียวใช้เวลาประมาณ 1,200 นาโนวินาที

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

เราจึงไม่อยากให้คุณเสียเวลาไปกับเรื่องนี้

เราได้ปรับปรุงสิ่งต่างๆ มากมายด้วย AndroidX Perfetto SDK

นี่คือ SDK เวอร์ชันทดลองที่เราเปิดตัวสำหรับการติดตามองค์ประกอบ ซึ่งช่วยปรับปรุงสถานการณ์ต่างๆ ได้อย่างมาก

เราไม่ต้องการให้คุณจัดส่งโค้ดนี้เนื่องจากเป็น Perfetto C SDK ที่มีการเชื่อมโยง JNI และ C SDK มีขนาดประมาณ 4 MB ภายใน APK

นี่ไม่ใช่สิ่งที่เราต้องการให้คุณจัดส่ง

ตอนนี้เรามี Tracing 2 ซึ่งเป็นไลบรารีที่สร้างขึ้นเพื่อวัตถุประสงค์นี้โดยเฉพาะ

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

สิ่งนี้ทำให้เกิดความเป็นไปได้อะไรบ้างที่ก่อนหน้านี้เป็นไปไม่ได้

ตัวอย่างหนึ่งคือฟีเจอร์การติดตามรันไทม์ของ Metro

สำหรับผู้ที่ไม่ทราบ Metro คือไลบรารีการแทรกทรัพยากร Dependency

รองรับ Kotlin Multiplatform

โดยใช้ปลั๊กอินคอมไพเลอร์ Kotlin

โดยจะสร้างโค้ดทั้งหมดสำหรับการแทรกทรัพยากร Dependency และผสานรวมกับ Tracing 2.0 เพื่อให้เห็นภาพต้นทุนของ @Inject ทุกรายการในโค้ดได้ง่ายขึ้น

ตัวอย่างเช่น

สมมติว่าเรามีกราฟแอป

ใน Metro ทุกอย่างจะกำหนดขอบเขตเป็นกราฟ ดังนั้นเราจึงมีช่องเดียวคือ AnalyticsTracker

นอกจากนี้ เรายังมี Binding ของผู้ให้บริการด้วย

เรามีไคลเอ็นต์เครือข่ายที่มี OkHttpClient เป็น impl จากนั้นการติดตั้งใช้งาน AnalyticsTracker จะมาจาก AnalyticsTrackerImpl และเราต้องการอินสแตนซ์ของไคลเอ็นต์เครือข่าย ซึ่งกราฟรู้วิธีจัดเตรียม

ดังนั้น ปลั๊กอินคอมไพเลอร์จะสร้างโค้ดที่มีลักษณะดังนี้

ดังนั้น หากคุณมี AnalyticsTracker Getter จะสร้างอินสแตนซ์ของไคลเอ็นต์เครือข่ายและส่งไปยังคอนสตรักเตอร์ของ AnalyticsTrackerImpl ซึ่งเป็นเรื่องดี

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

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

ดังนั้น Wise ซึ่งเป็นแอปการเงินจึงใช้ข้อมูลนี้เพื่อปรับปรุงการเริ่มต้นแอปได้ถึง 45%

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

หากคุณดูเมตริกการเริ่มต้นระบบของแอปเหล่านี้ คุณจะเห็นว่าน่าประทับใจมาก

นอกจากจะปรับปรุงเวลาที่ใช้ในการแสดงเฟรมแรกแล้ว ยังปรับปรุงเวลาที่ใช้ในการแสดงผลแบบเต็มด้วย

BandLab ซึ่งเป็นพาร์ทเนอร์อีกรายก็ใช้ข้อมูลเดียวกันนี้ใน CI

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

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

Rahul Ravikumar

ตกลง

ที่ผ่านมา ฉันได้พูดถึงสิ่งต่างๆ ที่เราได้ปรับปรุงเมื่อเทียบกับ Tracing 1 แต่ตอนนี้ฉันจะพูดถึงฟีเจอร์ใหม่ๆ ใน Tracing 2 ที่ไม่เคยทำได้มาก่อน

ดังนั้น ฟีเจอร์หลักอย่างหนึ่งจึงเรียกว่า Context Propagation และเนื่องจากแอปสมัยใหม่มีความซับซ้อนมากขึ้นเรื่อยๆ ภาระงานจึงทำงานในหลายเทรด หลายโครูทีน และหลายกระบวนการ

คุณต้องการเห็นภาพว่าคำขอส่งผ่านระหว่างชุดข้อความและกระบวนการแต่ละรายการอย่างไร

ซึ่งการส่งผ่านบริบทจะช่วยให้ทำเช่นนี้ได้

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

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

ซึ่งเป็นสิ่งที่การส่งผ่านบริบททำให้พร้อมใช้งาน

คุณจะยินดีที่ทราบว่าระบบรองรับการเผยแพร่บริบทอย่างเต็มรูปแบบ และนี่คือตัวอย่างจริง

เมื่อย้อนกลับไปดูการติดตาม Perfetto ของ com.example.app สมมติว่า performInitialize ใช้เวลานานเกินไปและคุณต้องการเลื่อนค่าใช้จ่ายออกไปหรือย้ายไปยังเธรดอื่น

ซึ่งเป็นสิ่งที่คุณทำได้แน่นอน

สมมติว่าฉันย้าย performInitialize ไปยังชุดข้อความอื่น

ตอนนี้คุณได้สูญเสียลักษณะลำดับชั้นของส่วนแบ่งนั้นไปแล้ว

ดังนั้น ตอนนี้คุณจึงไม่สามารถบอกได้อีกต่อไปว่า initializeComponent เป็นสาเหตุที่ทำให้เกิด performInitialize เว้นแต่คุณจะดูโค้ด

ในโลกอุดมคติ คุณคงอยากให้มีลูกศรบอกว่า A ทำให้เกิด B แล้วคุณก็สามารถหาเหตุผลเกี่ยวกับลำดับเหตุการณ์ที่เป็นเหตุเป็นผลกันได้

คุณอาจเคยเห็นการติดตามของระบบที่เราทำเช่นนี้กับธุรกรรม Binder บนแพลตฟอร์ม

คุณจะเห็นว่าการเปรียบเทียบ Compose ทำธุรกรรม Binder กับ system_server เพื่อเตรียมเฟรม

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

ตอนนี้ Tracing 2.0 จึงรองรับการเผยแพร่บริบท Coroutine ของ Kotlin อย่างเต็มรูปแบบ

คุณไม่ต้องทำอะไร

คุณเพียงแค่แกะกล่องออกมา

เราจึงมีเมธอด Suspend รายการเดียวที่ชื่อว่า fetchProfile

โดยจะเรียก client.get ซึ่งเป็นเมธอดการระงับอีกเมธอดหนึ่ง จากนั้นจะเปลี่ยนไปใช้ Dispatchers.Default เพื่อดีซีเรียลไลซ์การตอบกลับ

โค้ด Coroutine ที่เป็นแบบแผนทั่วไป ซึ่งคุณอาจต้องจัดการทุกวัน

ทีนี้ สมมติว่าเราต้องการติดตามเรื่องนี้

เราเพิ่มส่วนการติดตาม

ดังนั้นในกรณีนี้ เราจะใช้ traceCoroutine API แทนการติดตาม เนื่องจากเป็นบล็อกโค้ดที่ระงับไว้ จากนั้นสำหรับการเรียกภายในก่อนที่เราจะเปลี่ยนบริบทเป็น Dispatchers.Default เราจะเพิ่มส่วนการติดตามภายในอีกส่วนโดยใช้ traceCoroutine API เดียวกัน

ตอนนี้ในการติดตาม คุณจะเห็นข้อมูลในลักษณะนี้

คุณจะเห็นว่างานของเราเริ่มต้นใน Worker-1 จากนั้นจึงเปลี่ยนบริบทและย้ายไปยัง Worker-3 และคุณจะเห็นลูกศรที่เป็นประโยชน์ในการติดตามที่ชี้ไปยังจุดนั้น

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

คุณจะเห็นเวลาที่ Coroutine ถูกระงับ เวลาที่กลับมาทำงานอีกครั้ง และเห็นลำดับเหตุการณ์ที่เป็นสาเหตุทั้งหมด

อีกสิ่งหนึ่งที่ Tracing 2 ทำได้คือความสามารถในการเพิ่มข้อมูลเมตาที่กำหนดเองลงในการติดตาม

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

และคุณสามารถเพิ่มข้อมูลดังกล่าวลงในการติดตามได้

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

ตอนนี้คุณสามารถฝังทุกสิ่งที่คุณรู้ ข้อมูลเพิ่มเติมทั้งหมดที่คุณต้องการได้แล้ว

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

ซึ่งมาพร้อมกับ Compose 1.13 คุณจึงพร้อมใช้งานได้ตั้งแต่วันนี้

ตัวอย่างเช่น

นี่คือการติดตามการคอมโพสิชันที่ทุกคนน่าจะคุ้นเคยกันดี

ซึ่งมีมาตั้งแต่ช่วงแรกๆ ของ Compose

ซึ่งจะบอกต้นทุนที่เกี่ยวข้องของ Composable และส่วนย่อยทั้งหมด และต้นทุนของแต่ละรายการในเทรดที่เกิดขึ้น

ซึ่งก็ค่อนข้างตรงไปตรงมา

แต่สิ่งที่รายงานไม่ได้บอกคือบริบท

แต่ไม่ได้บอกสาเหตุที่ทำให้เกิดเหตุการณ์นี้

แต่จะไม่บอกเหตุผลที่องค์ประกอบต่างๆ มีการจัดเรียงใหม่

ดังนั้น หากฉันซูมออก นั่นคือขอบเขตที่น่าสนใจที่เราเพิ่งดูในสไลด์ก่อนหน้า

และทางด้านซ้าย คุณจะเห็นว่ามีเหตุการณ์อินพุตการส่งเกิดขึ้น

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

แต่ยังไม่ชัดเจน

คุณไม่รู้แน่ชัด

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

ไม่เพียงเท่านั้น คุณยังบอกได้ง่ายๆ ว่าเหตุการณ์เหล่านี้เกี่ยวข้องกัน

และหากคลิกที่รายการเหล่านั้น ระบบจะบอกคุณว่าสถานะใดมีการเปลี่ยนแปลง

ซึ่งจะบอกคุณว่านี่เป็นสถานะ เป็นค่าสถานะที่เปลี่ยนแปลงได้ซึ่งเปลี่ยนเป็นเท็จ โดยก่อนหน้านี้เป็นจริง

ไม่เพียงเท่านั้น เรายังจะบอกสแต็กการเรียกใช้ที่ทำให้เกิดข้อผิดพลาดดังกล่าวด้วย

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

ซึ่งเป็นเรื่องที่เจ๋งมากและเราไม่เคยทำได้มาก่อน

เครื่องมือเหล่านี้ยังมีให้ใช้งานด้วย ขออภัย ฟังก์ชันทั้งหมดนี้ยังมีให้ใช้งานในเครื่องมือ Android Performance Analyzer ใหม่ด้วย หากคุณต้องการลองใช้เครื่องมือ Agentic บางอย่าง

และขวา

เราได้บอกคุณไปแล้วว่าระบบรองรับการส่งผ่านบริบทอย่างเต็มรูปแบบสำหรับโครูทีนของ Kotlin

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

ตกลง

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

สมมติว่าเรามี API ที่มีอยู่แล้วซึ่งใช้ Callback และ Executor

การติดตั้งใช้งานจะใช้ executor.execute, เรียกใช้ runCatching ซึ่งเป็นรายละเอียดการติดตั้งใช้งาน, รับการตอบกลับ แล้วแจ้งให้ Callback ทราบเกี่ยวกับการตอบกลับ

ตกลง

ตอนนี้ หากฉันต้องการติดตามสิ่งนี้ ฉันจะทำ Tracer.global.trace ติดป้ายกำกับ แล้วล้อมรอบบล็อก

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

และสิ่งที่เราจะทำคือส่งโทเค็นไปยัง API การติดตามภายใน

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

ตกลง

ตอนนี้ผู้เรียก API นั้นสามารถเป็น API ที่ระงับได้

ที่นี่ฉันมีฟังก์ชัน Suspend profileRequest ซึ่งตอนนี้จะเรียก API ที่ใช้ Callback และ Executor

ในกรณีนี้ เนื่องจากฉันกำลังเชื่อมโยง 2 โลกเข้าด้วยกัน โดยเชื่อมโยงโลกของฟังก์ชัน Suspend กับโลกของ Callback ฉันจึงจะใช้ Builder suspendCoroutine

ฉันจะได้รับความต่อเนื่อง จากนั้นฉันจะเรียกใช้ API แล้วกลับมาดำเนินการต่อใน Callback เมื่อได้รับคำตอบ

และนี่คือ Executor ที่ผมกำหนดไว้ซึ่งเรียกว่า profileRequestContext

ซึ่งเป็น Executor แบบเทรดเดียว

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

และใน Trace จะแสดงให้เห็นอย่างชัดเจน

ดังนั้น คุณจะเห็นว่ามีบางอย่างที่เริ่มต้นใน worker-3 ซึ่งเปลี่ยนไปใช้ Executor แบบเทรดเดียวเมื่อเราเปลี่ยนบริบท จากนั้นจึงกลับมาทำงานต่อใน worker

ซึ่งก็ถือว่าเจ๋งมาก

Rahul Ravikumar

ตกลง

สิ่งอื่นๆ ที่คุณทำได้คือปรับแต่ง Tracer.global

จนถึงตอนนี้ Tracing 2.0 API มีค่าเริ่มต้นที่ดีมากสำหรับสิ่งที่ Tracer.global ควรเป็น แต่หากต้องการปรับแต่ง คุณก็ทำได้

นอกจากนี้ Tracing 2.0 ยังรองรับ JVM และ Android ด้วย เนื่องจากเราต้องการให้ Tracing รองรับทั้งไลบรารี Java และ Android อย่างเต็มรูปแบบ

ดังนั้น 3 ขั้นตอนสำหรับการเริ่มต้นคือ คุณสร้าง Trace Sink

Trace sink คือวิธีจัดเก็บแพ็กเก็ตการติดตามอย่างมีประสิทธิภาพ

โดยจะกำหนดรูปแบบสายและตำแหน่งของร่องรอยเอาต์พุตที่จัดเก็บไว้

เรามีการติดตั้งใช้งานแบบสำเร็จรูปสำหรับ Trace Sink ที่รองรับรูปแบบ Perfetto แต่คุณสามารถเขียน Trace Sink ของคุณเองได้

ซึ่งย้อนกลับไปที่การพยายามแก้ปัญหาที่ atrace เป็นแบ็กเอนด์เดียวที่ใช้ได้ใน Tracing 1

เราจึงต้องการแก้ไขปัญหานี้

ดังนั้น หากคุณต้องการเขียนซิงก์ OpenTelemetry หรือต้องการนำซิงก์ของคุณเองมาใช้ ก็ทำได้เลย

คุณเลือกที่จะลบล้างการตั้งค่าดังกล่าวได้

เมื่อมีซิงก์แล้ว คุณสามารถสร้างไดรเวอร์การติดตามและกำหนดซิงก์ให้ไดรเวอร์ดังกล่าวได้

นอกจากนี้ คุณยังเลือกหมวดหมู่ที่ต้องการเปิดได้ด้วย

ดังนั้น หมวดหมู่จึงมีประโยชน์มากในส่วนนี้

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

หรือจะพูดว่า "ฉันต้องการเปิดหมวดหมู่ทั้งหมดไม่ว่าจะมาจากที่ใดก็ตาม" ก็ได้

ซึ่งก็ไม่เป็นไรเลย

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

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

สุดท้าย คุณสามารถลงทะเบียน Tracer ได้โดยเรียกใช้ setGlobalTracer

ซึ่งจะเชื่อมโยง Tracer.global กับอินสแตนซ์ของ Tracer นี้ และจะพร้อมใช้งานสำหรับกระบวนการนี้ในภายหลัง

ใน Android เนื่องจากกระบวนการมีวงจรที่กำหนดไว้อย่างชัดเจนกว่ามาก สิ่งที่คุณต้องทำคือใช้ AbstractTraceDriver.Factory, ลบล้างเมธอด create และทำสิ่งเดียวกับที่เคยทำก่อนหน้านี้

คุณจึงสร้างซิงก์ แล้วจึงสร้างไดรเวอร์

คุณไม่จำเป็นต้องลงทะเบียนที่นี่

เราจะลงทะเบียนให้คุณเอง เพราะเรารู้ว่านี่คือสิ่งที่เกิดขึ้นก่อน

ตกลง

เอาล่ะ เราขอย้ำว่าการติดตามพร้อมใช้งานในหลายแพลตฟอร์มแล้ว

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

ปัจจุบันเรารองรับ Android และ JVM แต่การใช้งานของเราเปิดกว้างอย่างสมบูรณ์เพื่อให้เรารองรับแพลตฟอร์มในอนาคตได้หากต้องการ

Rahul Ravikumar

คุณคงยินดีที่ได้ทราบว่า R8 ซึ่งเป็นเครื่องมือที่ใช้ในการลดขนาดและเพิ่มประสิทธิภาพซอร์สโค้ดใน Android ใช้ Tracing 2.0

และด้วยการใช้ประโยชน์จากเทรซ เราได้เพิ่มประสิทธิภาพ R8 เพื่อลดขนาดและเพิ่มประสิทธิภาพโค้ดได้เร็วขึ้น 25%

ซึ่งหมายความว่าเวลาในการสร้างจะสั้นลง และคุณก็รู้ว่าเวลาในการรอการเพิ่มประสิทธิภาพจะสั้นลงด้วย

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

ดังนั้น R8 จึงเป็นเครื่องมือแปลงซอร์สโค้ดเป็นซอร์สโค้ดโดยพื้นฐาน

ดังนั้น คุณจะได้รับไฟล์ JAR จำนวนมาก และคุณจะย่อและเพิ่มประสิทธิภาพไฟล์เหล่านั้น และสร้างไฟล์ JAR อีกชุดหนึ่งที่คุณสามารถ dex ได้

ดังนั้น AGP จะเริ่มด้วยการอ่าน JAR ซึ่งไม่ใช่แค่แอปของคุณ แต่รวมถึงทรัพยากร Dependency ทั้งหมดด้วย

ดังนั้นจึงใช้ Gradle Worker เพื่อเริ่มอ่าน JAR อินพุตทั้งหมด

คุณมี JAR จำนวนมากที่ต้องการอ่าน

จากนั้นเมื่ออ่าน JAR เสร็จแล้ว R8 จะเริ่มแยกวิเคราะห์โค้ดและสร้างโมเดลของสิ่งที่โค้ดแสดง รวมถึงจุดแรกเข้าทั้งหมด เพื่อให้เริ่มเพิ่มประสิทธิภาพและลดขนาดโค้ดได้

ตอนนี้ ส่วนนั้นคือส่วนที่รอ ซึ่งแสดงถึงเวลาที่ R8 พร้อมที่จะเริ่มกระบวนการเพิ่มประสิทธิภาพจริงๆ ใช่ไหม

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

สาเหตุเป็นเพราะวิธีที่ API เดิมทำงานคือเรารอให้ผู้ปฏิบัติงานทั้งหมดอ่านไฟล์ทั้งหมดก่อนที่จะแยกวิเคราะห์สิ่งใดๆ

แน่นอนว่าเราแก้ไขปัญหานี้ได้ ซึ่งเราก็ได้ดำเนินการไปแล้ว

ดังนั้นใน AGP 9 คุณจะเห็นว่าเมื่อเราอ่าน JAR อินพุตเสร็จแล้ว เราจะเริ่มประมวลผลทันที

และเราไม่จำเป็นต้องรอให้ผู้ปฏิบัติงานทุกคนอ่านอินพุตจนเสร็จ

ซึ่งช่วยลดระยะเวลาที่เรารอเพื่ออ่านข้อมูลทั้งหมดที่ป้อนเข้ามาได้มาก

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

อีกเครื่องมือหนึ่งที่เราใช้ทุกวันในฐานะวิศวกร AndroidX คือ Metalava

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

เครื่องมือนี้ทำงานบน API สาธารณะและ API ที่ถูกจำกัดทุกรายการ ดังนั้นเวลาที่เราประหยัดได้ที่นี่จึงเป็นเวลาที่เราได้กลับมาในฐานะวิศวกร AndroidX

Metalava ยังใช้การติดตามเพื่อปรับปรุงเวลาหลังการส่งได้ถึง 15%

และเข้าไปที่การติดตามเพื่ออธิบายสิ่งที่เกิดขึ้น โดย Metalava จะทำการตรวจสอบ 2 ประเภท ได้แก่ การตรวจสอบ API ที่ถูกจำกัด และการตรวจสอบ API สาธารณะ

แต่คุณอาจสังเกตเห็นรูปแบบบางอย่าง

เรากำลังตั้งค่าหลายอย่างเพื่อทำการตรวจสอบเหล่านั้น 2 ครั้ง

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

จากนั้นเราจะสร้าง AST ก่อนที่จะเริ่มใช้การตรวจสอบ Lint ทั้งหมดที่ต้องการ

และเรากำลังทำงานที่ใช้ทรัพยากรมากนี้ถึง 2 ครั้ง

เราแก้ไขปัญหานี้อย่างไร

เราทำแค่ครั้งเดียว

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

ใช่

ตกลง

Rahul Ravikumar

ตอนนี้ฉันได้ให้คุณเห็นภาพคร่าวๆ แล้วว่า Tracing 2.0 ทำอะไรได้บ้าง สิ่งสำคัญที่ควรทราบคือแม้ว่าการติดตามจะสำคัญ แต่การรู้ว่าควรติดตามอะไรก็สำคัญไม่แพ้กัน

คุณคงไม่อยากให้มีการติดตามอยู่ทุกที่

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

ดังนั้นสิ่งแรกที่คุณควรทำคือค้นหาช่องว่างที่อธิบายไม่ได้ในการติดตาม

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

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

นอกจากนี้ คุณยังควรจัดลําดับความสําคัญผ่านเส้นทางของผู้ใช้ด้วย

ดังนั้น คุณจึงควรพิจารณาการเริ่มต้นแอป

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

ดังนั้น เมื่อใดก็ตามที่คุณไม่สามารถให้เหตุผลเกี่ยวกับบางสิ่งได้ สิ่งนั้นก็ควรค่าแก่การติดตาม

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

คุณจึงติดตามได้

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

โดยควรจะรอ I/O, รอธุรกรรม Binder หรือรอเหตุการณ์อินพุตภายนอกที่คุณคาดว่าจะเกิดขึ้น

แต่หากคุณมีการนอนหลับที่อธิบายไม่ได้ นั่นก็เป็นสิ่งที่ควรค่าแก่การตรวจสอบอย่างยิ่ง เพราะอาจมีบางอย่างแฝงอยู่

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

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

หรือจะข้ามขั้นตอนก่อนหน้าทั้งหมดแล้วให้ตัวแทนดำเนินการให้ก็ได้

นำหลักเกณฑ์เหล่านี้มาสร้างเป็นทักษะ แล้วชี้ให้ Agent ที่คุณชื่นชอบเห็น แล้วให้ Agent ลองทำดู

ใช่

Rahul Ravikumar

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

ซึ่งก็ตรงไปตรงมา

การติดตามเป็นเพียงไลบรารี Java แบบดั้งเดิมที่เรียบง่าย คุณจึงกำหนดทรัพยากร Dependency ใน androidx.tracing:tracing-wire ซึ่งเป็นไดรเวอร์การติดตามที่เข้ากันได้กับ Perfetto และชุดค่าผสมการติดตาม และเวอร์ชันเสถียรปัจจุบันคือ 2.0.5

หากคุณเป็นไลบรารี Java ก็จะเหมือนกันทุกประการ ขอย้ำอีกครั้งว่านี่คือ API แบบหลายแพลตฟอร์มอย่างสมบูรณ์

เราต้องการขยายการให้บริการไปยังแพลตฟอร์มอื่นๆ เมื่อเห็นว่าเหมาะสม

และเราแค่อยากสรุปสั้นๆ

เราได้พูดถึงฟีเจอร์ใหม่ๆ ที่น่าสนใจทั้งหมดที่เราเพิ่มเข้ามาแล้ว

ดังนั้นการส่งผ่านบริบทจึงมีประสิทธิภาพมาก

เราสามารถฝังข้อมูลที่กำหนดเอง ข้อมูลเมตา ข้อมูลสแต็กการเรียกใช้ และสิ่งอื่นๆ ได้ทุกประเภท

ยังมีอีกหลายเรื่องที่ฉันยังไม่ได้พูดถึง

คุณสามารถเปลี่ยนรูปแบบการติดตาม เปลี่ยนซิงก์การติดตาม และนำข้อมูลการติดตามไปยัง OpenTelemetry ได้

ทั้งหมดนี้คือสิ่งที่คุณทำได้

การติดตามเป็นแบบหลายแพลตฟอร์ม

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

และเครื่องมือทั้งหมดที่เราจัดส่ง ไม่ว่าจะเป็น Perfetto, AndroidX Benchmarks, เครื่องมือวิเคราะห์ประสิทธิภาพใหม่ หรือ Android Profiler เดิม ต่างก็รองรับ Tracing 2.0 ทั้งหมด

ขอขอบคุณที่รับฟัง

หวังว่าคุณจะได้รับประโยชน์จากการประชุมสุดยอดนักพัฒนาซอฟต์แวร์ครั้งนี้ และขอขอบคุณ