การจราจรของข้อมูลในเครือข่ายที่แอปสร้างขึ้นอาจส่งผลอย่างมากต่ออายุการใช้งานแบตเตอรี่ของอุปกรณ์ หากต้องการเพิ่มประสิทธิภาพการเข้าชมดังกล่าว คุณต้องวัดการเข้าชมและระบุแหล่งที่มาของการเข้าชม คำขอเครือข่ายอาจมาจากการดำเนินการของผู้ใช้โดยตรง จากโค้ดแอปของคุณเอง หรือจากเซิร์ฟเวอร์ที่สื่อสารกับแอปของคุณ
หัวข้อนี้จะแสดงวิธีตรวจสอบและจัดหมวดหมู่การจราจรของข้อมูลในเครือข่าย รวมถึงให้คำแนะนำในการระบุและแก้ไขปัญหา
ใช้ Network Profiler เพื่อตรวจสอบคำขอ
ใช้ Network Profiler เพื่อติดตามคำขอเครือข่ายของแอปพลิเคชัน คุณสามารถตรวจสอบวิธีและเวลาที่แอปโอนข้อมูล และเพิ่มประสิทธิภาพโค้ดที่เกี่ยวข้องได้อย่างเหมาะสม
รูปที่ 1 การติดตามการจราจรของข้อมูลในเครือข่าย รูปแบบการจราจรของข้อมูลในเครือข่ายแสดงให้เห็นว่าประสิทธิภาพจะเพิ่มขึ้นอย่างมากได้ด้วยการดึงข้อมูลคำขอล่วงหน้าหรือรวมการอัปโหลดเข้าด้วยกัน
การตรวจสอบความถี่ในการโอนข้อมูลและปริมาณข้อมูลที่โอนระหว่างการเชื่อมต่อแต่ละครั้งจะช่วยให้คุณระบุส่วนต่างๆ ของแอปพลิเคชันที่สามารถประหยัดแบตเตอรี่ได้มากขึ้น โดยทั่วไป คุณจะมองหาการเพิ่มขึ้นอย่างรวดเร็วในระยะสั้นที่สามารถเลื่อนออกไปได้
Traffic Stats API ช่วยให้คุณติดแท็กการโอนข้อมูลที่เกิดขึ้นจากซ็อกเก็ตภายในชุดข้อความที่กำหนดโดยใช้ TrafficStats.setThreadStatsTag() เพื่อระบุสาเหตุของการโอนข้อมูลที่เพิ่มขึ้นอย่างรวดเร็วได้ดียิ่งขึ้น
การเรียกใช้ฟังก์ชันนี้จะไม่ติดแท็กการรับส่งข้อมูลทั้งหมดสำหรับชุดข้อความหนึ่งๆ โดยอัตโนมัติ แต่ต้องใช้แท็กกับซ็อกเก็ต
เมื่อตั้งค่าแท็กชุดข้อความแล้ว คุณจะติดแท็กและยกเลิกการติดแท็กซ็อกเก็ตแต่ละรายการด้วยตนเองได้โดยใช้ TrafficStats.tagSocket() และ TrafficStats.untagSocket()
นอกจากนี้ ระบบจะใช้แท็กหากมีการเปิดซ็อกเก็ตในชุดข้อความ หรือหากซ็อกเก็ตเซิร์ฟเวอร์ยอมรับการเชื่อมต่อ
การเข้าถึงซ็อกเก็ตเดียวกันพร้อมกันโดยหลายชุดข้อความจะใช้แท็กใดก็ตามที่ซ็อกเก็ตมีเมื่อส่งหรือรับแพ็กเก็ตเครือข่าย (ซึ่งอาจแตกต่างจากเมื่อผู้ใช้เขียนหรืออ่านข้อมูลเนื่องจากการบัฟเฟอร์และการส่งซ้ำ)
ตัวอย่างเช่น คุณสามารถกำหนดค่าคงที่เพื่อแสดงการจราจรของข้อมูลในเครือข่ายประเภทต่างๆ ดังที่แสดงในตัวอย่างโค้ดต่อไปนี้
Kotlin
const val USER_INITIATED = 0x1000 const val APP_INITIATED = 0x2000 const val SERVER_INITIATED = 0x3000
Java
public static final int USER_INITIATED = 0x1000; public static final int APP_INITIATED = 0x2000; public static final int SERVER_INITIATED = 0x3000;
จากนั้นคุณจะติดแท็กคำขอเครือข่ายได้ตามความเหมาะสม ดังนี้
Kotlin
TrafficStats.setThreadStatsTag(USER_INITIATED) TrafficStats.tagSocket(outputSocket) // Transfer data using socket TrafficStats.untagSocket(outputSocket)
Java
TrafficStats.setThreadStatsTag(USER_INITIATED); TrafficStats.tagSocket(outputSocket); // Transfer data using socket TrafficStats.untagSocket(outputSocket);
ไลบรารี HttpURLConnection จะติดแท็กซ็อกเก็ตโดยอัตโนมัติตามค่า TrafficStats.getThreadStatsTag() ปัจจุบัน นอกจากนี้ ไลบรารียังติดแท็กและยกเลิกการติดแท็กซ็อกเก็ตเมื่อรีไซเคิลผ่านพูล Keep-Alive ดังที่แสดงในตัวอย่างโค้ดต่อไปนี้
Kotlin
class IdentifyTransferSpikeTask { @WorkerThread fun request(url: String) { TrafficStats.setThreadStatsTag(APP_INITIATED) // Make network request using HttpURLConnection.connect() ... TrafficStats.clearThreadStatsTag() } }
Java
public class IdentifyTransferSpikeTask { @WorkerThread public void request(String url) { TrafficStats.setThreadStatsTag(APP_INITIATED); // Make network request using HttpURLConnection.connect() ... TrafficStats.clearThreadStatsTag(); } }
วิเคราะห์ประเภทการจราจรของข้อมูลในเครือข่าย
เมื่อดูการจราจรของข้อมูลในเครือข่ายที่แอปสร้างขึ้น คุณต้องเข้าใจแหล่งที่มาของการจราจรของข้อมูลในเครือข่ายเพื่อให้เพิ่มประสิทธิภาพได้อย่างเหมาะสม กิจกรรมเครือข่ายที่เกิดขึ้นบ่อยครั้งจากแอปของคุณอาจเหมาะสมอย่างยิ่งหากเป็นการตอบสนองต่อการดำเนินการของผู้ใช้ แต่ไม่เหมาะสมอย่างยิ่งหากแอปไม่ได้อยู่เบื้องหน้าหรือหากอุปกรณ์อยู่ในกระเป๋าเสื้อหรือกระเป๋าถือ
วิเคราะห์การเข้าชมที่ผู้ใช้เริ่ม
การจราจรของข้อมูลในเครือข่ายที่ผู้ใช้เริ่มต้นอาจจัดกลุ่มเข้าด้วยกันอย่างมีประสิทธิภาพขณะที่ผู้ใช้ทำงานหนึ่งๆ ภายในแอป หรือกระจายออกอย่างไม่สม่ำเสมอเมื่อผู้ใช้ขอข้อมูลเพิ่มเติมที่แอปของคุณต้องได้รับ เป้าหมายของคุณในการวิเคราะห์การจราจรของข้อมูลในเครือข่ายที่ผู้ใช้เริ่มคือการมองหารูปแบบการใช้เครือข่ายบ่อยครั้งเมื่อเวลาผ่านไป และพยายามลดความถี่ลงโดยการจัดกลุ่มคำขอเข้าด้วยกัน
คำขอของผู้ใช้ที่คาดเดาไม่ได้ทำให้การเพิ่มประสิทธิภาพการใช้เครือข่ายประเภทนี้ในแอปเป็นเรื่องที่ท้าทาย นอกจากนี้ ผู้ใช้ยังคาดหวังการตอบสนองที่รวดเร็วเมื่อใช้แอปอยู่ ดังนั้นการหน่วงเวลาคำขอเพื่อประสิทธิภาพอาจทำให้ผู้ใช้ได้รับประสบการณ์ที่ไม่ดี โดยทั่วไป คุณควรให้ความสำคัญกับการตอบสนองที่รวดเร็วต่อผู้ใช้มากกว่าการใช้เครือข่ายอย่างมีประสิทธิภาพขณะที่ผู้ใช้โต้ตอบกับแอปโดยตรง
ดูคำแนะนำในการเพิ่มประสิทธิภาพการเข้าชมที่ผู้ใช้เป็นผู้เริ่มได้ที่หัวข้อเพิ่มประสิทธิภาพคำขอที่ผู้ใช้เป็นผู้เริ่ม
วิเคราะห์การเข้าชมที่เริ่มต้นจากแอป
การจราจรของข้อมูลในเครือข่ายที่เริ่มต้นโดยแอปมักเป็นส่วนที่คุณสามารถส่งผลกระทบอย่างมากต่อการใช้แบนด์วิดท์เครือข่ายอย่างมีประสิทธิภาพ ในการวิเคราะห์กิจกรรมเครือข่ายของแอป ให้มองหาระยะเวลาที่ไม่มีการใช้งานและพิจารณาว่าจะเพิ่มระยะเวลาดังกล่าวได้หรือไม่ หากคุณเห็นรูปแบบการเข้าถึงเครือข่ายที่สม่ำเสมอจากแอป ให้ลองจัดกลุ่มการรับส่งข้อมูลนี้เพื่อให้วิทยุของอุปกรณ์เปลี่ยนกลับไปเป็นโหมดใช้พลังงานต่ำระหว่างช่วงเวลาที่มีกิจกรรม
ดูคำแนะนำในการเพิ่มประสิทธิภาพการเข้าชมที่เริ่มต้นจากแอปได้ที่เพิ่มประสิทธิภาพคำขอที่เริ่มต้นจากแอป
วิเคราะห์การเข้าชมที่เริ่มจากเซิร์ฟเวอร์
กิจกรรมเครือข่ายที่เริ่มต้นโดยเซิร์ฟเวอร์ที่สื่อสารกับแอปของคุณก็มักจะเป็นส่วนที่คุณสามารถส่งผลกระทบอย่างมากต่อการใช้แบนด์วิดท์เครือข่ายอย่างมีประสิทธิภาพ Firebase Cloud Messaging (FCM) เป็นกลไกขนาดเล็กที่ใช้ในการส่งข้อมูลจากเซิร์ฟเวอร์ไปยังอินสแตนซ์แอปหนึ่งๆ เมื่อใช้ FCM เซิร์ฟเวอร์จะแจ้งเตือนแอปที่ทำงานในอุปกรณ์หนึ่งๆ ได้ว่ามีข้อมูลใหม่พร้อมใช้งาน
ดูคำแนะนำในการเพิ่มประสิทธิภาพการเข้าชมที่เซิร์ฟเวอร์เป็นผู้เริ่มได้ที่เพิ่มประสิทธิภาพคำขอที่เซิร์ฟเวอร์เป็นผู้เริ่ม
ใช้ Battery Historian เพื่อแสดงผลกระทบของการจราจรของข้อมูลในเครือข่าย
Battery Historian เป็นเครื่องมือที่แสดงภาพการใช้แบตเตอรี่ของอุปกรณ์ในช่วงระยะเวลาหนึ่ง คุณสามารถใช้เครื่องมือนี้เพื่อวิเคราะห์ว่ากิจกรรมเครือข่ายส่งผลต่อการใช้แบตเตอรี่อย่างไร เช่น Battery Historian สามารถแสดงให้เห็นว่าแอปของคุณใช้สัญญาณโทรศัพท์มือถือบ่อยกว่าที่คาดไว้หรือไม่ ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ Battery Historian ได้ที่โปรไฟล์การใช้งานแบตเตอรี่ด้วย Batterystats และ Battery Historian