פתרון בעיות ברשת

התנועה ברשת שנוצרת על ידי אפליקציה יכולה להשפיע באופן משמעותי על חיי הסוללה של המכשיר. כדי לבצע אופטימיזציה של התנועה הזו, צריך למדוד אותה ולזהות את המקור שלה. בקשות לאחזור מהרשת יכולות להגיע ישירות מפעולת משתמש, מהקוד של האפליקציה שלכם או משרת שמתקשר עם האפליקציה.

במאמר הזה נסביר איך לעקוב אחרי התנועה ברשת ולסווג אותה, ואיך לזהות ולפתור בעיות.

שימוש בכלי לניתוח הרשת כדי לעקוב אחרי בקשות

משתמשים בכלי לניתוח הרשת כדי לעקוב אחרי הבקשות לאחזור מהרשת של האפליקציה. אתם יכולים לעקוב אחרי האופן שבו האפליקציה מעבירה נתונים ומתי היא עושה את זה, ולשפר את הקוד בהתאם.



איור 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 ‏(FCM) הוא מנגנון קל משקל שמשמש להעברת נתונים משרת למכונה מסוימת של אפליקציה. באמצעות FCM, השרת יכול להודיע לאפליקציה שפועלת במכשיר מסוים שיש נתונים חדשים שזמינים בשבילה.

במאמר אופטימיזציה של בקשות שהשרת יוזם מפורטות המלצות לאופטימיזציה של תנועה שהשרת יוזם.

שימוש ב-Battery Historian כדי להציג את ההשפעות של התנועה ברשת

Battery Historian הוא כלי שמציג באופן חזותי את צריכת הסוללה של המכשיר לאורך זמן. אתם יכולים להשתמש בכלי הזה כדי לנתח איך הפעילות ברשת משפיעה על צריכת הסוללה. לדוגמה, Battery Historian יכול להראות לכם אם האפליקציה משתמשת ברדיו הסלולרי בתדירות גבוהה מהצפוי. למידע נוסף על השימוש ב-Battery Historian, קראו את המאמר פרופיל השימוש בסוללה באמצעות Batterystats ו-Battery Historian.