Firebase Performance: คืออะไร เมตริก และวิธีติดตาม

Firebase Performance Monitoring คืออะไร

Firebase Performance Monitoring คือ SDK และแพลตฟอร์มคลาวด์สำหรับรวบรวม รวม และแสดงภาพเมตริกประสิทธิภาพของแอปมือถือ SDK จะถูกฝังในแอปและตรวจวัดจุดสำคัญโดยอัตโนมัติ: วงจรชีวิตของ Activity (Android) หรือ ViewController (iOS) คำขอเครือข่ายผ่าน URLSession (iOS) หรือ OkHttp (Android) และการเรียกของระบบ ข้อมูลที่รวบรวมจะถูกส่งไปยังเซิร์ฟเวอร์ Firebase ซึ่งจะถูกรวมตามเวอร์ชันแอป อุปกรณ์ ประเทศ และแอตทริบิวต์อื่น ๆ

สถาปัตยกรรมของ Performance SDK สร้างขึ้นบนหลักการของโอเวอร์เฮดที่น้อยที่สุด: การตรวจวัดเพิ่มไม่เกิน 1–2% ในเวลาดำเนินการของการดำเนินการที่วัด ข้อมูลจะถูกรวบรวมแบบอะซิงโครนัสและบัฟเฟอร์บนอุปกรณ์ก่อนส่ง ซึ่งช่วยขจัดผลกระทบต่อประสิทธิภาพของเธรด UI ข้อมูลจะถูกส่งตามกำหนดเวลา (โดยค่าเริ่มต้นทุก 30 นาที) หรือเมื่อบัฟเฟอร์ถึง 100 KB

ความแตกต่างหลักระหว่าง Firebase Performance และโปรไฟเลอร์ของ Android Studio (CPU Profiler) หรือ Xcode Instruments คือการตรวจสอบในระบบผลิต Firebase Performance รวบรวมข้อมูลจากอุปกรณ์ผู้ใช้จริง ไม่ใช่แค่อุปกรณ์ของนักพัฒนา ซึ่งช่วยให้ตรวจจับปัญหาที่เกิดขึ้นเฉพาะในรุ่นเฉพาะ เวอร์ชัน OS หรือในภูมิภาคใดภูมิภาคหนึ่งเท่านั้น — ปัญหาที่ไม่สามารถจำลองในสภาพแวดล้อมที่ควบคุมได้

SDK รวบรวมข้อมูลอย่างไรโดยไม่ต้องเปลี่ยนโค้ด

การตรวจวัดอัตโนมัติ คือคุณสมบัติหลักของ Firebase Performance สำหรับ Android SDK จะลงทะเบียน ActivityLifecycleCallbacks โดยอัตโนมัติและวัดเวลาระหว่าง onCreate และ onResume (เวลาเรนเดอร์หน้าจอ) สำหรับ iOS จะสวิซเซิลเมธอด viewDidLoad และ viewDidAppear คำขอเครือข่ายจะถูกสกัดกั้นที่ระดับ OkHttpInterceptor (Android) หรือ NSURLProtocol (iOS) นักพัฒนาไม่จำเป็นต้องเพิ่มการเรียก start/stop สำหรับเมตริกมาตรฐาน

การเปิดและปิด Performance SDK จัดการผ่านปลั๊กอิน Google Services (Android) หรือ Info.plist (iOS) สำหรับการดีบัก คุณสามารถเปิดการบันทึกแบบละเอียดของ Performance SDK ซึ่งจะแสดงเมตริกที่กำลังรวบรวมและส่ง ในระบบผลิต ขอแนะนำให้บันทึกในระดับคำเตือนเพื่อหลีกเลี่ยงการทำให้บันทึกรกด้วยข้อมูลที่ไม่จำเป็น สำหรับโปรเจกต์บน Flutter หรือ React Native การตรวจวัดอัตโนมัติอาจถูกจำกัด — รายละเอียดเพิ่มเติมในส่วนตัวอย่างโค้ด

ขีดจำกัดฟรีและราคา

Firebase Performance มีให้บริการในระดับ Spark ฟรีโดยไม่มีข้อจำกัดเกี่ยวกับจำนวนการติดตามหรือปริมาณข้อมูล ระดับ Blaze แบบชำระเงินก็ไม่เรียกเก็บค่าธรรมเนียมสำหรับ Performance Monitoring เช่นกัน — เป็นหนึ่งในบริการ Firebase ไม่กี่รายการที่ฟรีอย่างสมบูรณ์ในทั้งสองระดับ มีข้อจำกัดเพียงข้อเดียว: ข้อมูลถูกเก็บไว้ 30 วัน (บน Spark) และสูงสุด 365 วัน (บน Blaze) สำหรับการวิเคราะห์ระยะยาว ให้ส่งออกข้อมูลผ่าน BigQuery export

ไม่มีค่าใช้จ่าย ทำให้ Firebase Performance เป็นตัวเลือกที่เหมาะสำหรับทุกโปรเจกต์ — ตั้งแต่ต้นแบบไปจนถึงแอประดับองค์กรที่มีผู้ใช้หลายล้านคน ค่าใช้จ่ายเดียวคือการรับส่งข้อมูลขาออกของ Performance SDK แต่เล็กน้อยเมื่อเทียบกับการดำเนินการเครือข่ายอื่น ๆ ของแอป (น้อยกว่า 1 MB ต่อเดือนต่ออุปกรณ์) BigQuery export คิดค่าบริการจัดเก็บและคำค้นหา แต่ Performance SDK เองนั้นฟรี

เมตริกอัตโนมัติ: สิ่งที่วัดได้โดยไม่ต้องใช้โค้ด

Firebase Performance รวบรวมเมตริกห้าหมวดหมู่โดยอัตโนมัติโดยไม่ต้องใช้โค้ดแม้แต่บรรทัดเดียว: เวลาเริ่มต้นแอป คำขอ HTTP ช้า ความเร็วในการเรนเดอร์หน้าจอ การใช้หน่วยความจำ (Android เท่านั้น) และอัตราเฟรม (Android เท่านั้น) เมตริกเหล่านี้พร้อมใช้งานในคอนโซล Firebase ทันทีหลังจากเชื่อมต่อ SDK และเซสชันผู้ใช้ครั้งแรก

เวลาเริ่มต้นแอป — เวลาตั้งแต่เริ่มกระบวนการจนถึง UI พร้อมสำหรับการโต้ตอบอย่างสมบูรณ์ แบ่งออกเป็นการเริ่มต้นแบบเย็น (แอปเริ่มจากศูนย์) และการเริ่มต้นแบบอุ่น (แอปเริ่มใหม่จากสถานะพื้นหลัง) การเริ่มต้นแบบเย็นรวมถึงการโหลดไฟล์ DEX การเริ่มต้นฟิลด์สแตติก การเรียก Application.onCreate และ Activity.onCreate Firebase จำแนกประเภทการเริ่มต้นโดยอัตโนมัติและแสดงการกระจายเวลาสำหรับแต่ละประเภท

เวลาเรนเดอร์หน้าจอ — เวลาตั้งแต่เริ่มโหลดหน้าจอ (onCreate สำหรับ Android, viewDidLoad สำหรับ iOS) จนถึงช่วงเวลาที่หน้าจอพร้อมสำหรับการโต้ตอบ (onResume, viewDidAppear) Firebase รวมข้อมูลตามแต่ละหน้าจอ (ตามชื่อคลาสหรือชื่อหน้าจอที่กำหนดเอง) ทำให้สามารถระบุได้ว่าหน้าจอใดโหลดนานที่สุด สำหรับ Android จะวัดเฟรมที่ตกหล่นด้วย — จำนวนเฟรมที่ข้ามไประหว่างการเรนเดอร์หน้าจอ (jank)

คำขอเครือข่าย (HTTP/HTTPS)

Performance SDK สกัดกั้นและวัดทุกคำขอ HTTP/HTTPS ที่ส่งจากแอปผ่าน URLSession, OkHttp หรือ URLConnection โดยอัตโนมัติ สำหรับแต่ละคำขอจะถูกบันทึก: URL (เส้นทางโดยไม่มีพารามิเตอร์ค้นหาเพื่อความปลอดภัย), เมธอด HTTP, รหัสตอบกลับ, ขนาดตอบกลับเป็นไบต์, ระยะเวลาคำขอ และความเร็วการเชื่อมต่อ (WiFi, Cellular) ข้อมูลจะถูกรวมในแดชบอร์ดคำขอเครือข่ายของคอนโซล Firebase

คำขอช้า — คำขอที่มีระยะเวลาเกินเกณฑ์ที่กำหนด โดยค่าเริ่มต้น เกณฑ์คำขอช้าคือ 4000 ms เมตริกนี้มีความสำคัญมากสำหรับการระบุปัญหาแบ็กเอนด์: หากหลังจากการอัปเดตแบ็กเอนด์ จำนวนคำขอช้าเพิ่มขึ้นจาก 1% เป็น 15% นั่นคือสัญญาณสำหรับการวิเคราะห์บันทึกเซิร์ฟเวอร์ทันที ผู้ใช้จะไม่รอการตอบกลับนานกว่า 5 วินาที — ข้อมูล Firebase แสดงให้เห็นว่า 53% ของผู้ใช้ปิดแอปหากคำขอใช้เวลานานกว่า 3 วินาที

ข้อจำกัดของการตรวจวัดอัตโนมัติ

ข้อจำกัด iOS: บน iOS Performance SDK ไม่สามารถวัดเฟรมที่ตกหล่นได้ (นี่คือ API ส่วนตัว) ในการวัด jank บน iOS ให้ใช้ MetricKit หรือ CADisplayLink นอกจากนี้ บน iOS SDK จะไม่สกัดกั้นคำขอดำเนินการผ่านไคลเอ็นต์ HTTP ของบุคคลที่สามที่ไม่ใช้ URLSession (เช่น SwiftNIO) สำหรับกรณีเหล่านี้ ให้ใช้การติดตามแบบกำหนดเองกับแอตทริบิวต์ HTTP

ข้อจำกัด Android: บน Android การวัดหน่วยความจำอัตโนมัติมีเฉพาะในอุปกรณ์ที่ใช้ Android 8.0+ (API 26+) สำหรับเวอร์ชันเก่า ให้ใช้การติดตามแบบกำหนดเองกับข้อมูลที่ได้รับผ่าน Debug.getMemoryInfo() นอกจากนี้ SDK จะไม่สกัดกั้นการเชื่อมต่อ WebSocket — ต้องใช้การติดตามแยกต่างหาก แม้จะมีข้อจำกัดเหล่านี้ เมตริกอัตโนมัติครอบคลุม 80% ของความต้องการตรวจสอบประสิทธิภาพ

การติดตามแบบกำหนดเองและแอตทริบิวต์ HTTP

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

การติดตามแต่ละรายการมีชื่อ (สูงสุด 100 ตัวอักษร) และสามารถมีเมตริกแบบกำหนดเองได้สูงสุด 5 รายการ — ค่าตัวเลขที่บันทึกไว้ในการติดตาม ตัวอย่างเช่น ในการติดตาม "image_processing" คุณสามารถวัดเมตริกเช่น "original_file_size" และ "processed_file_size" เมตริกจะแสดงในคอนโซล Firebase เป็นการกระจาย (ต่ำสุด สูงสุด ค่าเฉลี่ย เปอร์เซ็นไทล์) ซึ่งช่วยให้วิเคราะห์ไม่เพียงแต่ระยะเวลา แต่ยังรวมถึงคุณลักษณะของการดำเนินการ

แอตทริบิวต์ HTTP — ประเภทพิเศษของการติดตามแบบกำหนดเองสำหรับคำขอเครือข่ายที่ไม่ได้ถูกสกัดกั้นโดยอัตโนมัติโดย SDK (เช่น ผ่าน WebSocket หรือไลบรารีของบุคคลที่สาม) แอตทริบิวต์ HTTP รวมถึง URL, เมธอด HTTP, รหัสตอบกลับ และขนาดตอบกลับ Firebase แสดงในส่วนคำขอเครือข่ายพร้อมกับคำขอที่รวบรวมโดยอัตโนมัติ ให้ภาพรวมของการโต้ตอบเครือข่ายที่เป็นหนึ่งเดียว

เมื่อใดควรใช้การติดตามแบบกำหนดเอง

การติดตามแบบกำหนดเอง ขาดไม่ได้สำหรับการวัด: เวลาโหลดข้อมูลจากฐานข้อมูลภายในเครื่อง (Room, CoreData), ระยะเวลาของการคำนวณที่ซับซ้อน (การเข้ารหัส, การบีบอัด), ประสิทธิภาพของแอนิเมชันและการเปลี่ยนภาพ, เวลาตอบสนองของ SDK ของบุคคลที่สาม (แผนที่, การชำระเงิน, การวิเคราะห์) สำหรับแต่ละสถานการณ์ดังกล่าว ให้สร้างการติดตาม หุ้มโค้ดที่วัดใน start/stop และเพิ่มแอตทริบิวต์สำหรับการแบ่งส่วนในภายหลัง

อย่าใช้มากเกินไป กับการติดตามแบบกำหนดเอง การติดตามแต่ละรายการเพิ่มการใช้แบตเตอรี่และการรับส่งข้อมูลเพิ่มเติม ขอแนะนำให้มีการติดตามที่ทำงานอยู่ไม่เกิน 10–15 รายการในเวอร์ชันระบบผลิตของแอป สำหรับการดีบัก คุณสามารถเพิ่มการติดตามได้มากขึ้น แต่ก่อนเผยแพร่ ให้ปิดการติดตามที่เกินจำเป็นผ่าน Remote Config (ใช้แฟล็ก performance_tracing_enabled) ซึ่งช่วยให้เปิดการติดตามแบบละเอียดสำหรับผู้ใช้หรือเซสชันที่เลือกเท่านั้น

แอตทริบิวต์การติดตามสำหรับการแบ่งส่วน

แอตทริบิวต์แบบกำหนดเอง คือคู่คีย์-ค่าที่สามารถเพิ่มในการติดตามเพื่อกรองในภายหลังในคอนโซล Firebase ตัวอย่างเช่น สำหรับการติดตาม "feed_load" คุณสามารถเพิ่มแอตทริบิวต์เช่น "feed_type" (main, explore, following) และ "cache_status" (cold, warm) ในคอนโซล ข้อมูลการติดตามสามารถกรองตามแอตทริบิวต์เหล่านี้เพื่อกำหนดว่าฟีดประเภทใดโหลดช้าที่สุด

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

เกณฑ์ประสิทธิภาพและการแจ้งเตือน

เกณฑ์ คือค่าขอบเขตที่กำหนดค่าได้สำหรับเมตริก เมื่อเกิน Firebase Performance จะสร้างคำเตือน เกณฑ์ถูกกำหนดในคอนโซล Firebase (Performance > Thresholds) สำหรับแต่ละเมตริกอัตโนมัติ: เวลาเริ่มต้นแอป (เย็น/อุ่น), เวลาเรนเดอร์หน้าจอ, คำขอ HTTP ช้า, เวลาตอบสนอง HTTP คุณสามารถกำหนดเกณฑ์ทั่วโลกสำหรับทุกเวอร์ชันแอปหรือเฉพาะสำหรับเวอร์ชันใดเวอร์ชันหนึ่ง

การแจ้งเตือน คือการแจ้งอัตโนมัติที่ Firebase ส่งเมื่อเกินเกณฑ์ การแจ้งเตือนสามารถกำหนดค่าผ่านอีเมล, Slack webhook, PagerDuty หรือ Cloud Functions (สำหรับการจัดการแบบกำหนดเอง) การแจ้งเตือนแต่ละรายการประกอบด้วย: ชื่อเมตริก, ค่าปัจจุบัน, ค่าเกณฑ์, เวอร์ชันแอป, ส่วน (อุปกรณ์, ประเทศ) การแจ้งเตือนช่วยให้ตอบสนองต่อการเสื่อมสภาพของประสิทธิภาพก่อนที่จะสังเกตเห็นได้โดยผู้ใช้

เกณฑ์ที่แนะนำ ตามมาตรฐานอุตสาหกรรม (Google I/O 2025): การเริ่มต้นแบบเย็น — น้อยกว่า 2 วินาที, การเริ่มต้นแบบอุ่น — น้อยกว่า 1 วินาที, การเรนเดอร์หน้าจอ — น้อยกว่า 500 ms, ระยะเวลาคำขอ HTTP — น้อยกว่า 3000 ms (เปอร์เซ็นไทล์ที่ 95), สัดส่วนคำขอช้า — น้อยกว่า 5% สำหรับแอปที่มีการแข่งขันสูง (โซเชียล, อีคอมเมิร์ซ) เกณฑ์เป้าหมายอาจเข้มงวดกว่า: การเริ่มต้นแบบเย็น < 1.5 วินาที, HTTP < 1000 ms

การกำหนดเกณฑ์ในคอนโซล Firebase

ในคอนโซล Firebase ไปที่ส่วน Performance เปิดแท็บ Thresholds สำหรับแต่ละเมตริก ให้กำหนดค่าเกณฑ์ที่ต้องการและเปอร์เซ็นต์ของผู้ใช้ที่ควรได้รับผลกระทบจากการเกิน ตัวอย่าง: "พิจารณาการเริ่มต้นแบบเย็นว่าช้าหากเกิน 2 วินาทีสำหรับผู้ใช้มากกว่า 10%" Firebase จะแสดงค่าเมตริกปัจจุบันและประวัติการเกินเพื่อช่วยเลือกเกณฑ์ที่สมจริง

สำคัญ: เกณฑ์ไม่ส่งผลต่อการรวบรวมข้อมูล เกณฑ์ควบคุมเฉพาะการสร้างการแจ้งเตือน หากเกณฑ์ต่ำเกินไป (เช่น การเริ่มต้นแบบเย็น 1 วินาที ในขณะที่ 50% ของอุปกรณ์เริ่มใน 3 วินาที) การแจ้งเตือนจะมาอย่างต่อเนื่องและกลายเป็น "เสียงรบกวน" ที่นักพัฒนาจะหยุดสังเกต กำหนดเกณฑ์ตามประสิทธิภาพปัจจุบัน จากนั้นค่อย ๆ ทำให้เข้มงวดขึ้นเมื่อคุณปรับปรุงแอป

แดชบอร์ดประสิทธิภาพในคอนโซล Firebase

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

แดชบอร์ดรองรับการเปรียบเทียบเวอร์ชัน: เลือกสองเวอร์ชันแอป (ปัจจุบันและก่อนหน้า) สำหรับการเปรียบเทียบเมตริกด้วยภาพ หากหลังจากการอัปเดต เปอร์เซ็นไทล์ที่ 95 ของเวลาเริ่มต้นเพิ่มขึ้นจาก 2.1 เป็น 3.4 วินาที — การถดถอยชัดเจน และคุณต้องค้นหาคอมมิตที่ทำให้เกิดการชะลอตัว Firebase Performance ผสานรวมกับ GitHub, GitLab และ Bitbucket ซึ่งช่วยให้เชื่อมโยงการเปลี่ยนแปลงเมตริกกับคอมมิตเฉพาะ

ตัวอย่างโค้ดสำหรับ Performance Monitoring

มาดูตัวอย่างการผสานรวม Firebase Performance Monitoring ในแอป Android ด้วย Kotlin โค้ดสาธิตการสร้างการติดตามแบบกำหนดเองเพื่อวัดการโหลดฟีดข่าว การเพิ่มแอตทริบิวต์ HTTP สำหรับคำขอที่ไม่ได้ถูกสกัดกั้นโดยอัตโนมัติ และการใช้ Trace เพื่อวัดเวลาประมวลผลภาพ ตัวอย่างทั้งหมดคำนึงถึงความสามารถในการปิดการติดตามผ่าน Remote Config

ก่อนใช้ ให้เพิ่มการพึ่งพา: implementation("com.google.firebase:firebase-perf") ผ่าน Firebase BOM สำหรับการตรวจวัดอัตโนมัติ ไม่จำเป็นต้องตั้งค่าเพิ่มเติม — SDK จะสกัดกั้นการดำเนินการมาตรฐานโดยอัตโนมัติหลังจากเพิ่มการพึ่งพา

การติดตามแบบกำหนดเองสำหรับการโหลดฟีด

ตัวอย่างแรก — การวัดเวลาโหลด ฟีดข่าวจากเซิร์ฟเวอร์ การติดตามหุ้มการดำเนินการแบบอะซิงโครนัส fetchFeed ซึ่งดึงข้อมูลจากเครือข่ายและแยกวิเคราะห์ JSON มีการเพิ่มแอตทริบิวต์แบบกำหนดเองในการติดตาม: แหล่งข้อมูล (cache หรือ network) และจำนวนโพสต์ที่ได้รับ ซึ่งช่วยให้แบ่งส่วนข้อมูลและเข้าใจว่าฟีดโหลดช้าที่สุดภายใต้เงื่อนไขใด

suspend fun loadFeedWithTrace(source: String) {
    val trace = Firebase.performance
        .newTrace("feed_load")
    trace.putAttribute("source", source)

    try {
        trace.start()
        val feed = fetchFeed()
        trace.putMetric(
            "items_count",
            feed.size.toLong()
        )
    } finally {
        trace.stop()
    }
}

ฟังก์ชัน loadFeedWithTrace รับพารามิเตอร์ source ("cache" หรือ "network") ซึ่งใช้เป็นแอตทริบิวต์การติดตาม หลังจากดำเนินการแบบอะซิงโครนัสเสร็จสิ้น การติดตามจะหยุดในบล็อก finally ซึ่งรับประกันการหยุดแม้ในกรณีที่มีข้อยกเว้น เมตริก items_count ช่วยให้วิเคราะห์ว่าจำนวนโพสต์ส่งผลต่อเวลาโหลดอย่างไร ในคอนโซล Firebase คุณสามารถกรองการติดตามตามแอตทริบิวต์ source และเห็นว่าการโหลดจากเครือข่ายช้ากว่า cache 3 เท่า

แอตทริบิวต์ HTTP สำหรับคำขอที่ไม่ได้มาตรฐาน

ตัวอย่างที่สอง — แอตทริบิวต์ HTTP สำหรับคำขอที่ดำเนินการผ่าน WebSocket (ไม่ถูกสกัดกั้นโดยอัตโนมัติ) ใช้คลาส HttpMetric ซึ่งช่วยให้ลงทะเบียนคำขอ URL, เมธอด, รหัสตอบกลับ และขนาดด้วยตนเอง Firebase จะแสดงคำขอนี้ในส่วนคำขอเครือข่ายพร้อมกับคำขอที่ถูกสกัดกั้นโดยอัตโนมัติ

suspend fun sendWithHttpMetric() {
    val metric = Firebase.performance
        .newHttpMetric(
            "https://api.example.com/data",
            FirebasePerformance.HttpMethod.POST
        )
    metric.start()

    try {
        val response = webSocketSend()
        metric.setHttpResponseCode(response.code)
        metric.setRequestPayloadSize(1024)
        metric.setResponsePayloadSize(
            response.body.length.toLong()
        )
    } finally {
        metric.stop()
    }
}

ในตัวอย่าง sendWithHttpMetric ใช้ newHttpMetric เพื่อลงทะเบียนการเรียก HTTP ที่ไม่ได้มาตรฐาน SDK ไม่ได้สกัดกั้นโดยอัตโนมัติ ดังนั้นนักพัฒนาจึงกำหนด URL, เมธอด, รหัสตอบกลับ และขนาดด้วยตนเอง การกำหนด URL โดยไม่มีพารามิเตอร์ค้นหาเป็นสิ่งสำคัญ (เพื่อความปลอดภัยและการรวม) — นั่นคือ /data ไม่ใช่ /data?token=abc Firebase จะจัดกลุ่มรูปแบบ URL ที่เหมือนกันโดยอัตโนมัติ

การวัดเวลาประมวลผลภาพ

ตัวอย่างที่สามสาธิตการวัดเวลา การประมวลผลภาพ (การบีบอัด การปรับขนาด) โดยใช้การติดตามแบบกำหนดเอง ในกรณีนี้ การติดตามหุ้มการดำเนินการแบบซิงโครนัส แต่สำหรับระบบผลิต ให้ใช้ coroutines หรือ RxJava เพื่อหลีกเลี่ยงการบล็อกเธรด UI

fun compressImage(bitmap: Bitmap): ByteArray {
    val trace = Firebase.performance
        .newTrace("image_compression")
    trace.putAttribute(
        "format", "JPEG"
    )
    trace.start()

    val stream = ByteArrayOutputStream()
    bitmap.compress(
        Bitmap.CompressFormat.JPEG, 80, stream
    )
    val result = stream.toByteArray()
    trace.putMetric(
        "output_size_kb",
        result.size / 1024.toLong()
    )
    trace.stop()
    return result
}

ฟังก์ชัน compressImage วัดเวลาบีบอัดภาพเป็น JPEG ที่คุณภาพ 80% แอตทริบิวต์ format ช่วยให้เปรียบเทียบเวลาบีบอัด JPEG กับ WebP ในอนาคต เมตริก output_size_kb แสดงประสิทธิภาพการบีบอัด ในคอนโซล Firebase คุณสามารถเห็นการกระจาย: บนอุปกรณ์ที่อ่อนแอ (Android ราคาประหยัด) การบีบอัดใช้เวลานานกว่า 4 เท่าเมื่อเทียบกับรุ่นเรือธง ซึ่งอาจเป็นสาเหตุของความล่าช้าเมื่ออัปโหลดภาพไปยังเซิร์ฟเวอร์

วิธีปรับปรุงประสิทธิภาพตามข้อมูล

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

การเริ่มต้นแบบเย็นช้า (> 2 วินาที): สาเหตุ — การเริ่มต้น SDK ที่หนักใน Application.onCreate (การวิเคราะห์, การรายงานการขัดข้อง, SDK แผนที่), การโหลดทรัพยากรขนาดใหญ่ (ฟอนต์, ธีม), การดำเนินการแบบซิงโครนัสในเธรดหลักเมื่อเริ่มต้น วิธีแก้: การเริ่มต้น SDK แบบขี้เกียจ, การโหลดทรัพยากรแบบรอ, การใช้ SplashScreen API (Android 12+) เพื่อแสดงตัวแทนระหว่างการเริ่มต้น Firebase Performance จะแสดงว่าเวอร์ชันแอปใดเริ่มช้าลง — ตรวจสอบว่ามีการเพิ่มหรืออัปเดตการพึ่งพาใดบ้าง

การเรนเดอร์หน้าจอช้า (> 500 ms): สาเหตุ — ลำดับชั้น View ที่ซับซ้อน (ConstraintLayout ซ้อนกัน, Fragment หลายตัว), การโหลดข้อมูลในเธรด UI (เครือข่ายหรือดิสก์), การดำเนินการวาดที่หนัก (ภาพขนาดใหญ่, View ที่กำหนดเอง) วิธีแก้: ปรับลำดับชั้นเค้าโครงให้เหมาะสม (Layout Inspector ใน Android Studio), ย้ายข้อมูลไปยังเธรดพื้นหลัง, แคชภาพผ่าน Glide หรือ Coil ใช้ตัวกรอง Screen Rendering ใน Firebase เพื่อค้นหาหน้าจอที่ช้าที่สุดและปรับให้เหมาะสมก่อน

การปรับปรุงคำขอเครือข่าย

คำขอ HTTP ช้า (> 3 วินาที): สาเหตุ — เซิร์ฟเวอร์ช้า, เพย์โหลดขนาดใหญ่, ขาดการแคช, โปรโตคอลที่ไม่เหมาะสม (HTTP/1.1 แทน HTTP/2), การแก้ไข DNS วิธีแก้: ตรวจสอบฝั่งเซิร์ฟเวอร์ (เวลาทำงาน, ความหน่วง), ลดขนาดการตอบกลับ (การแบ่งหน้า, GraphQL, protobuf แทน JSON), เปิดการแคชผ่านส่วนหัว HTTP (Cache-Control), ใช้ OkHttp Interceptor เพื่อเพิ่มหมดเวลาและตรรกะลองใหม่

Firebase Performance แสดงการกระจายเวลา ของคำขอ: การแก้ไข DNS, การจับมือ TCP, การจับมือ TLS, การส่งคำขอ, การรับการตอบกลับ หากเวลาส่วนใหญ่ใช้ไปกับ DNS — ให้ใช้การโหลด DNS ล่วงหน้า (OkHttp DNS-over-HTTPS) หากใช้กับ TLS — ให้ใช้การเริ่มเซสชันใหม่และการปรับชุดการเข้ารหัส หากใช้กับการรับการตอบกลับ — ตรวจสอบขนาดการตอบกลับและความเร็วเครือข่ายของผู้ใช้ ข้อมูล Firebase ช่วยระบุปัญหาที่ระดับโปรโตคอล แทนที่จะบอกว่า "คำขอช้า" เท่านั้น

การผสานรวม Remote Config สำหรับการปิดการติดตาม

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

ตัวอย่างตรรกะ: เมื่อเริ่มต้นแอป ให้ตรวจสอบพารามิเตอร์ Remote Config performance_tracing_enabled หากเป็น false — การเรียก Firebase.performance.newTrace() ทั้งหมดจะคืนค่าออบเจกต์ stub ที่ไม่รวบรวมข้อมูล ซึ่งดำเนินการผ่านคลาส wrapper ที่ตรวจสอบแฟล็กก่อนสร้างการติดตาม วิธีการนี้ช่วยให้เปิดการติดตามแบบละเอียดสำหรับผู้ใช้เฉพาะ (ผู้ทดสอบเบต้า, นักพัฒนา) โดยไม่ส่งผลกระทบต่อผู้ชมทั้งหมด