Traceview: คืออะไร เครื่องมือติดตามและโปรไฟล์ Android

Traceview ใน Android คืออะไร

Traceview เป็นโปรไฟล์เลอร์แบบกราฟิกที่สร้างใน Android Studio ซึ่งแสดงร่องรอยการทำงานของเมธอดแอปพลิเคชัน Android เป็นไทม์ไลน์และตารางการเรียก มันเป็นส่วนหนึ่งของ Android SDK และสามารถใช้งานผ่าน Android Profiler ตั้งแต่ Android Studio 3.0 รวมถึงผ่านยูทิลิตี้บรรทัดคำสั่ง dmtracedump

วัตถุประสงค์ของเครื่องมือ

งานหลักของ Traceview คือการช่วยนักพัฒนา ค้นหาเมธอดที่ใช้เวลา CPU มากที่สุด ต่างจากการบันทึกแบบง่าย Traceview จะบันทึกเวลาเข้าออกที่แน่นอนของแต่ละเมธอด สร้าง Call Chart และแผนภูมิ Top-Down ซึ่งช่วยให้สามารถตรวจจับความผิดปกติด้านประสิทธิภาพได้ด้วยสายตา เครื่องมือนี้มีประโยชน์โดยเฉพาะเมื่อโปรไฟล์เธรด UI ซึ่งความล่าช้า 16 มิลลิวินาทีทำให้เฟรมดรอป

ประวัติและการพัฒนา

Traceview ปรากฏครั้งแรกในเวอร์ชันแรกๆ ของ Android SDK ในฐานะยูทิลิตี้แบบสแตนด์อโลนสำหรับดูไฟล์ .trace ด้วยการเปิดตัว Android Studio 3.0 (2017) มันกลายเป็นส่วนหนึ่งของ Android Profiler โดยได้รับการผสานรวมกับไทม์ไลน์สดของ CPU หน่วยความจำ และเครือข่าย ตาม Google I/O 2018 ทีม Android Studio ยังคงพัฒนาโปรไฟล์เลอร์ต่อไป โดยเพิ่มการสนับสนุนโค้ดเนทีฟผ่าน systrace และ perfetto ใน Android Studio เวอร์ชันปัจจุบัน Traceview ทำงานบนรูปแบบ Perfetto แต่ยังคงความเข้ากันได้ย้อนหลังกับรูปแบบ .trace แบบคลาสสิก

Traceview ทำงานอย่างไร

Traceview รับข้อมูลจากกลไก System Tracing ใน Android Runtime (ART) เมื่อแอปพลิเคชันเริ่มทำงานโดยเปิดการติดตาม ART จะบันทึกการประทับเวลาเริ่มต้นและสิ้นสุดของแต่ละเมธอดที่ทำงาน รวมถึงชื่อคลาส ชื่อเมธอด และ ID เธรด

// เริ่มการติดตามในโค้ดของแอป
Debug.startMethodTracing("app_trace")

// ส่วนโค้ดสำคัญสำหรับการวิเคราะห์ประสิทธิภาพ
loadHeavyData()

// หยุดการติดตาม — ไฟล์ถูกบันทึกลงอุปกรณ์
Debug.stopMethodTracing()

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

รูปแบบไฟล์ .trace

ไฟล์ .trace ประกอบด้วยส่วนหัวที่มีเวอร์ชันรูปแบบและเวลาเริ่มต้น ตามด้วยบันทึกสำหรับการเรียกแต่ละครั้ง: ID เธรด, ID เมธอด, การประทับเวลาเข้า และ การประทับเวลาออก Android Studio จะโหลดไฟล์ .trace โดยอัตโนมัติและสร้างมุมมองหลักสองแบบ: แผงไทม์ไลน์สำหรับลำดับเหตุการณ์ และแผงโปรไฟล์สำหรับลำดับชั้นการเรียก โดยค่าเริ่มต้น ขนาดบัฟเฟอร์สูงสุดคือ 8 MB แต่สามารถเพิ่มได้ผ่าน Debug.startMethodTracing(filename, maxSize)

คุณสมบัติหลักของ Traceview

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

Call Chart (แผนภูมิการเรียก)

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

แผนภูมิ Top-Down และ Bottom-Up

แผนภูมิ Top-Down แสดงเวลาทำงานของเมธอดรวมถึงการเรียกที่ซ้อนกันทั้งหมด — Inclusive Time แผนภูมิ Bottom-Up ในทางกลับกัน แสดงว่าเมธอดแม่ใดเรียกเมธอดที่กำหนด — มีประโยชน์สำหรับการค้นหาแหล่งที่มาของการดำเนินการที่หนัก ความแตกต่างระหว่าง Inclusive และ Exclusive Time มีความสำคัญ: เมธอดอาจทำงานได้เร็วแต่เรียกเมธอดลูกที่ช้า และสิ่งนี้จะเห็นได้เฉพาะใน Inclusive Time

การค้นหาและการกรอง

Traceview รองรับการค้นหาตามชื่อเมธอด แพ็กเกจ หรือคลาส ผลลัพธ์จะถูกไฮไลต์บนไทม์ไลน์ และแผงโปรไฟล์จะแสดงสถิติเฉพาะเมธอดที่พบเท่านั้น นอกจากนี้ยังสามารถกรองตามเธรด — คุณสามารถซ่อนเธรดพื้นหลังและโฟกัสที่เธรดหลัก (UI) ซึ่งความล่าช้ามีความสำคัญมากที่สุด

การส่งออกข้อมูล

Traceview อนุญาตให้ส่งออกร่องรอยในรูปแบบ CSV เพื่อวิเคราะห์เพิ่มเติมในสเปรดชีตหรือสร้างกราฟ ใน Android Studio คุณยังสามารถคัดลอกส่วนที่เลือกของไทม์ไลน์เป็นรูปภาพ — สำหรับแทรกลงในรายงานข้อบกพร่องหรือเอกสาร สำหรับ CI/CD การส่งออกในรูปแบบ Perfetto สามารถใช้ได้ผ่านยูทิลิตี้ cmdline-tools

วิธีใช้ Traceview ใน Android Studio

การโปรไฟล์ ผ่าน Traceview มีสองวิธี: ผ่าน Android Profiler ด้วยการบันทึกสด และผ่านการเรียก API Debug ด้วยโปรแกรม วิธีแรกสะดวกสำหรับการวิเคราะห์เฉพาะกิจ วิธีที่สองสำหรับการทดสอบประสิทธิภาพที่สามารถทำซ้ำได้

การบันทึกผ่าน Android Profiler

ใน Android Studio เปิดแท็บ Profiler (View → Tool Windows → Profiler) เลือกอุปกรณ์และกระบวนการแอปพลิเคชันของคุณ คลิกที่ส่วน CPU จากนั้นเลือกโหมด “Trace Java Methods” และคลิก Record หลังจากโต้ตอบกับแอปพลิเคชัน คลิก Stop — Traceview จะเปิดร่องรอยที่บันทึกไว้โดยอัตโนมัติ ระยะเวลาการบันทึกเริ่มต้นจำกัดที่ 30 วินาที แต่สามารถเปลี่ยนขีดจำกัดได้ในการตั้งค่าโปรไฟล์เลอร์

การเริ่มติดตามด้วยโปรแกรม

สำหรับการโปรไฟล์ที่แม่นยำของส่วนโค้ดเฉพาะ ให้ใช้ Debug.startMethodTracing และ Debug.stopMethodTracing ไฟล์จะถูกบันทึกในพื้นที่เก็บข้อมูลภายนอกของแอปพลิเคชันตามเส้นทางที่ context.getExternalFilesDir(null) ส่งคืน หลังจากเสร็จสิ้น ให้ย้ายไฟล์ .trace ไปยังคอมพิวเตอร์ของคุณผ่าน Android Studio Device Explorer จากนั้นเปิดผ่าน File → Open ใน Android Studio

Debug.startMethodTracing(
    "heavy_computation",
    Debug.TRACE_COUNT_ALLOCS
)

processLargeDataset()

Debug.stopMethodTracing()

การกำหนดค่าพารามิเตอร์การติดตาม

Debug.startMethodTracing รับพารามิเตอร์สามตัว: ชื่อไฟล์ (ไม่มีนามสกุล), ขนาดบัฟเฟอร์สูงสุด (ค่าเริ่มต้น 8 MB) และแฟล็ก แฟล็ก TRACE_COUNT_ALLOCS เพิ่มการนับการจัดสรรออบเจ็กต์ — มีประโยชน์สำหรับการค้นหาการรั่วไหลของหน่วยความจำ Traceview ไม่เหมาะสำหรับการโปรไฟล์โค้ดเนทีฟ — ใช้ SimplePerf หรือ Perfetto สำหรับการทดสอบที่ยาวนาน (เกิน 30 วินาที) แนะนำให้เพิ่มบัฟเฟอร์เป็น 64–128 MB ผ่านพารามิเตอร์ maxSize

การอ่านไทม์ไลน์ Traceview

ไทม์ไลน์ Traceview ประกอบด้วยสองแผง: แผงไทม์ไลน์ด้านบนที่มีสี่เหลี่ยมการเรียกสี และแผงโปรไฟล์ด้านล่างพร้อมตารางสถิติ แผงไทม์ไลน์แสดงการทำงานของเธรดจากซ้ายไปขวา โดยแต่ละสี่เหลี่ยมคือการเรียกเมธอดเดียว สีของสี่เหลี่ยมถูกเข้ารหัสตามประเภทเมธอด: การเรียกระบบ Android (สีเขียว), เมธอดแอปพลิเคชัน (สีน้ำเงิน), การเรียกไลบรารี (สีส้ม)

วิธีอ่านแผงโปรไฟล์

ในแผงโปรไฟล์ แต่ละแถวคือเมธอดที่มีคอลัมน์สำหรับ Inclusive Time, Exclusive Time, Calls + Recur และ CPU Time จัดเรียงตารางตาม Inclusive Time (จากมากไปน้อย) เพื่อดูเมธอดที่ใช้เวลารวมมากที่สุดก่อน หากเมธอดที่มี Inclusive Time สูงแต่ Exclusive Time ต่ำ — ปัญหาอยู่ที่การเรียกลูกของมัน และคุณต้องขยายแผนภูมิ ตัวอย่างเช่น ListView.getView อาจมี Inclusive Time สูงเนื่องจากการเรียกโหลดรูปภาพ

การระบุคอขวด

มองหาเมธอดที่มี Real Time สูงผิดปกติแต่ CPU Time ต่ำ — นี่บ่งชี้ถึงการบล็อก (รอ I/O, การดำเนินการเครือข่าย, การขัดแย้งของล็อก) เมธอดที่มี CPU Time สูงต้องการการปรับอัลกอริทึมให้เหมาะสม สำหรับเธรด UI แต่ละเมธอดควรเสร็จภายใน 16 มิลลิวินาที — หากการเรียกใดเกินเกณฑ์นี้ แอปพลิเคชันจะเสียเฟรมและผู้ใช้เห็นอาการกระตุก ตามคำแนะนำของ Google เวลารวมของการเรียกทั้งหมดในเธรด UI ต่อเฟรมไม่ควรเกิน 8–10 มิลลิวินาที โดยเหลือเผื่อสำหรับการดำเนินการของระบบ

เปรียบเทียบ Traceview กับ Systrace

แม้ว่า Traceview และ Systrace ต่างก็เป็นเครื่องมือติดตาม Android แต่พวกมันแก้ปัญหาคนละอย่างและใช้ในขั้นตอนการโปรไฟล์ที่แตกต่างกัน ความแตกต่างหลักคือระดับรายละเอียด: Traceview ทำงานในระดับเมธอด Java/Kotlin ส่วน Systrace ทำงานในระดับกระบวนการระบบ (CPU, GPU, Binder, SurfaceFlinger)

ในทางปฏิบัติ เครื่องมือทั้งสองเสริมซึ่งกันและกัน: อันดับแรก Systrace ช่วยระบุว่าส่วนประกอบระบบใด causing ปัญหา (เช่น GC บ่อยหรือล็อก Binder) จากนั้น Traceview ช่วยให้เจาะลึกเมธอดเฉพาะภายในแอปพลิเคชัน ใน Android Studio เครื่องมือทั้งสองรวมอยู่ใน Android Profiler — CPU Profiler จะเลือกโหมดการบันทึกที่เหมาะสมที่สุดโดยอัตโนมัติ บนอุปกรณ์ที่ใช้ Android 12+ Systrace และ Traceview ทำงานบน Perfetto ซึ่งให้รูปแบบข้อมูลแบบรวมสำหรับการโปรไฟล์ทุกประเภท

ตัวอย่างโค้ดกับ Traceview

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

การโปรไฟล์การโหลด RecyclerView

ตัวอย่างแรกคือการติดตามเส้นทางสำคัญระหว่างการเลื่อนรายการ RecyclerView เรียก onBindViewHolder สำหรับแต่ละรายการที่มองเห็นได้ และหากเมธอดนี้ใช้เวลานานกว่า 16 มิลลิวินาที การเลื่อนจะกระตุก การติดตามรอบ onBindViewHolder จะแสดงว่าการดำเนินการเฉพาะใดภายในใช้เวลา

class MyAdapter : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        Debug.startMethodTracing("bind_card_$position")

        holder.bind(items[position])

        Debug.stopMethodTracing()
    }
}

การเปรียบเทียบอัลกอริทึมสองตัว

ตัวอย่างที่สองคือการทดสอบความเร็ว A/B ของสองการใช้งาน: การโหลดรูปภาพผ่าน Glide เทียบกับ BitmapFactory แบบแมนนวล ร่องรอยนี้ช่วยให้เปรียบเทียบ Inclusive Time ของทั้งสองกลยุทธ์อย่างเป็นกลางและเลือกกลยุทธ์ที่เหมาะสมที่สุด สิ่งสำคัญคือต้องเรียกใช้การทดสอบแต่ละครั้งบนอุปกรณ์ที่อุ่นเครื่องแล้ว (หลังจาก 3–5 รอบ) ภายใต้เงื่อนไขที่เหมือนกัน (โหลดพื้นหลัง อุณหภูมิ)

fun compareImageLoadingStrategies() {
    // การทดสอบ A: Glide
    Debug.startMethodTracing("glide_test")
    loadWithGlide()
    Debug.stopMethodTracing()

    // การทดสอบ B: BitmapFactory
    Debug.startMethodTracing("bitmap_test")
    loadWithBitmapFactory()
    Debug.stopMethodTracing()
}

หลังจากเรียกใช้ ให้เปิดไฟล์ .trace ทั้งสองใน Android Studio และเปรียบเทียบ Inclusive Time ในแผงโปรไฟล์ หาก Glide แสดง 3x Inclusive Time น้อยกว่าสำหรับงานเดียวกัน — นี่เป็นพื้นฐานวัตถุประสงค์ในการเลือกไลบรารี ตาม Tony John (นักพัฒนา Glide, 2023) ไลบรารีใช้แคชและพูลเธรด ซึ่งให้ผลกำไรสูงถึง 40% ในการโหลดซ้ำ