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

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

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

ใช้โปรไฟล์เครือข่ายเพื่อตรวจสอบคำขอ

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



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

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

API สถิติการเข้าชมช่วยให้คุณติดแท็กการโอนข้อมูลที่เกิดขึ้นจากซ็อกเก็ตภายในเธรดที่กำหนดได้โดยใช้ TrafficStats.setThreadStatsTag() เพื่อให้ระบุสาเหตุของการโอนที่เพิ่มขึ้นได้ดียิ่งขึ้น การเรียกใช้ฟังก์ชันนี้ไม่ได้ติดแท็กการรับส่งข้อมูลทั้งหมดสำหรับเธรดใดเธรดหนึ่งโดยอัตโนมัติ แต่ต้องใช้แท็กกับซ็อกเก็ต

เมื่อตั้งค่าแท็กเธรดแล้ว คุณจะติดแท็กและยกเลิกการติดแท็กซ็อกเก็ตแต่ละรายการด้วยตนเองได้โดยใช้ TrafficStats.tagSocket() และ TrafficStats.untagSocket() นอกจากนี้ ระบบจะใช้แท็กหากมีการเปิดซ็อกเก็ตในเธรด หรือหากซ็อกเก็ตเซิร์ฟเวอร์ ยอมรับการเชื่อมต่อ

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

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

KotlinJava 
const val USER_INITIATED = 0x1000
const val APP_INITIATED = 0x2000
const val SERVER_INITIATED = 0x3000
 
public static final int USER_INITIATED = 0x1000;
public static final int APP_INITIATED = 0x2000;
public static final int SERVER_INITIATED = 0x3000;

จากนั้นคุณจะติดแท็กคำขอเครือข่ายได้ดังนี้

KotlinJava 
TrafficStats.setThreadStatsTag(USER_INITIATED)
TrafficStats.tagSocket(outputSocket)
// Transfer data using socket
TrafficStats.untagSocket(outputSocket)
 
TrafficStats.setThreadStatsTag(USER_INITIATED);
TrafficStats.tagSocket(outputSocket);
// Transfer data using socket
TrafficStats.untagSocket(outputSocket);

ไลบรารี HttpURLConnection จะติดแท็กซ็อกเก็ตโดยอัตโนมัติตามค่า TrafficStats.getThreadStatsTag() ปัจจุบัน นอกจากนี้ ไลบรารียังติดแท็กและยกเลิกการติดแท็กซ็อกเก็ตเมื่อรีไซเคิลผ่านพูล Keep-Alive ตามที่แสดงในตัวอย่างโค้ดต่อไปนี้

KotlinJava 
class IdentifyTransferSpikeTask {
    @WorkerThread
    fun request(url: String) {
        TrafficStats.setThreadStatsTag(APP_INITIATED)
        // Make network request using HttpURLConnection.connect()
        ...
        TrafficStats.clearThreadStatsTag()
    }
}
 
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