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

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

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

ใช้เครื่องมือวิเคราะห์เครือข่ายเพื่อตรวจสอบคำขอ

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

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

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

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

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

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

หมายเหตุ: เทคนิคนี้ในการติดแท็กการเข้าชมเครือข่ายจากแอปขึ้นอยู่กับวิธีที่ API ที่คุณใช้เข้าถึงและจัดการซ็อกเก็ตเครือข่าย ไลบรารีการทํางานของเครือข่ายบางรายการอาจไม่อนุญาตให้ยูทิลิตี TrafficStats ติดแท็กการเข้าชมจากแอปของคุณ

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

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() นอกจากนี้ ไลบรารีจะติดแท็กและเลิกติดแท็กซ็อกเก็ตเมื่อรีไซเคิลผ่านพูลการคงสถานะไว้ตามที่แสดงในตัวอย่างโค้ดต่อไปนี้

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();
    }
}

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

วิเคราะห์ประเภทของการรับส่งข้อมูลในเครือข่าย

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

วิเคราะห์การเข้าชมที่ผู้ใช้เริ่ม

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

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

ดูคําแนะนําในการเพิ่มประสิทธิภาพการเข้าชมที่เกิดจากผู้ใช้ได้ที่เพิ่มประสิทธิภาพคำขอที่เกิดจากผู้ใช้

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

วิเคราะห์การเข้าชมที่มาจากแอป

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

ดูคําแนะนําในการเพิ่มประสิทธิภาพการเข้าชมที่เริ่มต้นจากแอปได้ที่เพิ่มประสิทธิภาพคำขอที่เริ่มต้นจากแอป

วิเคราะห์การเข้าชมที่เริ่มจากเซิร์ฟเวอร์

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

ดูคําแนะนําในการเพิ่มประสิทธิภาพการเข้าชมที่เริ่มโดยเซิร์ฟเวอร์ได้ที่เพิ่มประสิทธิภาพคำขอที่เริ่มโดยเซิร์ฟเวอร์

ใช้ Battery Historian เพื่อแสดงผลภาพผลกระทบของการรับส่งข้อมูลในเครือข่าย

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