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

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

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

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

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

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

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

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

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 זמין במאמר Profile battery usage with Batterystats and Battery Historian.