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

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

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

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

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

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

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

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

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

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

הערה: הטכניקה הזו לתיוג תנועת הרשת מהאפליקציה שלכם תלויה באופן שבו ממשקי ה-API שבהם אתם משתמשים ניגשים לשקעי רשת ומנהלים אותם. יכול להיות שספריות מסוימות של רשתות לא יאפשרו לכלי השירות TrafficStats לתייג תנועה מהאפליקציה שלכם.

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

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();
    }
}

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

ניתוח של סוגי תנועה ברשת

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

ניתוח תנועה שנוצרה על ידי משתמשים

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

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

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

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

ניתוח תנועת גולשים שמגיעה מאפליקציות

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

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

ניתוח תנועה שהשרת מפעיל

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

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

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

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