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

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

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

שימוש ב-Network Profiler למעקב אחר בקשות

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

איור 1. מעקב אחר תעבורת הנתונים ברשת. דפוס תעבורת הנתונים ברשת מצביע על כך שאפשר לשפר משמעותית את היעילות על ידי אחסון בקשות מראש או קיבוץ העלאות.

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

כדי לזהות טוב יותר את הסיבה לעליות חדות בנפח ההעברה, באמצעות Traffic Stats API אפשר לתייג את העברות הנתונים שמתרחשות מיציאה (socket) בתוך שרשור נתון באמצעות TrafficStats.setThreadStatsTag(). קריאה לפונקציה הזו לא מתייגת באופן אוטומטי את כל התנועה של חוט מסוים. צריך להחיל את התגים על השקעים.

אחרי שמגדירים את תווית השרשור, אפשר לתייג ולבטל את התיוג של שקעים ספציפיים באופן ידני באמצעות TrafficStats.tagSocket() ו-TrafficStats.untagSocket(). התג מוחיל גם אם נפתח שקע בשרשור, או אם שקע שרת מקבל חיבור.

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

לדוגמה, אפשר להגדיר קבועים שמייצגים סוגים שונים של תעבורת נתונים ברשת, כמו בקטע הקוד הבא:

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;

לאחר מכן תוכלו לתייג את הבקשות לרשת בהתאם:

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

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.