แก้ปัญหาเครือข่าย

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

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

ใช้ 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