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

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

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

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

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

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

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

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

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

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