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

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

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

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

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

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

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

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

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

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

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

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