הכלי 'תעבורת נתונים ברשת' הוצא משימוש. אם אתם משתמשים ב-Android Studio בגרסה 3.0 ומעלה, כדאי להשתמש בNetwork Profiler כדי לבדוק איך ומתי האפליקציה מעבירה נתונים ברשת.
בקטע הקודם, תייגתם את קוד האפליקציה במזהי תנועה, הפעלתם בדיקות ואספתם נתונים. בשיעור הזה נסביר איך לעיין בנתוני תנועת הרשת שאספתם, וניתן לכם הנחיות לפעולות שיעזרו לכם לשפר את ביצועי הרשת של האפליקציה ולהפחית את צריכת החשמל שלה.
ניתוח של תנועה ברשת באפליקציות
שימוש יעיל במשאבי הרשת על ידי אפליקציה מתאפיין בתקופות משמעותיות שבהן חומרת הרשת לא נמצאת בשימוש. במכשירים ניידים, יש עלות משמעותית שקשורה להפעלת הרדיו כדי לשלוח או לקבל נתונים, ולשמירה על פעילות הרדיו הנייד למשך תקופות ארוכות. אם האפליקציה ניגשת לרשת בצורה יעילה, תוכלו לראות שהתקשורת שלה ברשת מקובצת בצורה הדוקה, עם רווחים גדולים בין התקופות שבהן האפליקציה לא שולחת בקשות לחיבור.
באיור 1 מוצגת תעבורת נתונים לא אופטימלית מאפליקציה, כפי שנמדדה על ידי הכלי Network Traffic (תעבורת נתונים ברשת). האפליקציה שולחת בקשות רשת בתדירות גבוהה. בתנועה הזו יש מעט תקופות מנוחה שבהן הרדיו יכול לעבור למצב המתנה עם צריכת חשמל נמוכה. התנהגות הגישה לרשת של האפליקציה הזו כנראה תשאיר את הרדיו פועל למשך תקופות ארוכות, מה שגורם לבזבוז סוללה.
איור 1. פעילות ברשת שצורכת הרבה סוללה, שנמדדת מתוך אפליקציה.
איור 2 מציג דפוס אופטימלי של תעבורת נתונים ברשת. האפליקציה שולחת בקשות לרשת במנות, עם הפסקות ארוכות בין המנות שבהן אין תנועה והרדיו יכול לעבור למצב המתנה. בתרשים הזה מוצגת אותה כמות עבודה כמו באיור 1, אבל הבקשות הועברו וקובצו כדי לאפשר למכשיר להיות במצב המתנה רוב הזמן.
איור 2. פעילות ברשת שחוסכת בסוללה, שנמדדת מתוך אפליקציה.
אם תנועת הרשת של האפליקציה שלכם דומה לגרף באיור 2, אתם במצב טוב. מזל טוב! כדאי לעיין בטכניקות שמתוארות במאמר אופטימיזציה של השימוש הכללי ברשת כדי לשפר את יעילות הרשת.
אם תעבורת הנתונים ברשת של האפליקציה שלכם דומה יותר לגרף באיור 1, הגיע הזמן לבדוק לעומק את אופן הגישה של האפליקציה לרשת. כדאי להתחיל בניתוח של סוגי תנועת הרשת שהאפליקציה יוצרת.
ניתוח של סוגי תנועה ברשת
כשבודקים את התנועה ברשת שנוצרת על ידי האפליקציה, צריך להבין את מקור התנועה כדי לבצע אופטימיזציה מתאימה. פעילות רשת תכופה שנוצרת על ידי האפליקציה יכולה להיות מתאימה לחלוטין אם היא מגיבה לפעולות של המשתמשים, אבל היא לא מתאימה אם האפליקציה לא פועלת בחזית או אם המכשיר נמצא בכיס או בתיק. בקטע הזה מוסבר איך לנתח את סוגי תנועת הרשת שנוצרים על ידי האפליקציה, ומוצעות פעולות שאפשר לבצע כדי לשפר את הביצועים.
בשיעור הקודם תייגתם את קוד האפליקציה לסוגים שונים של תנועה והשתמשתם בכלי 'תנועת רשת' כדי לאסוף נתונים על האפליקציה וליצור תרשים של הפעילות, כמו שמוצג באיור 3.
איור 3. תנועת הרשת מתויגת לפי שלוש קטגוריות: משתמש, אפליקציה ושרת.
הכלי 'תנועת נתונים ברשת' צובע את תנועת הנתונים על סמך התגים שיצרתם בשיעור הקודם. הצבעים מבוססים על הקבועים של סוג התנועה שהגדרתם בקוד האפליקציה. כדאי לעיין בקוד האפליקציה כדי לראות אילו קבועים מייצגים תנועה שנוצרה על ידי משתמש, אפליקציה או שרת.
בקטעים הבאים נסביר איך לבדוק את סוגי התנועה ברשת ונספק המלצות לאופטימיזציה של התנועה.
ניתוח של תנועה ברשת שנוצרת על ידי משתמשים
פעילות ברשת שהמשתמש יזם יכולה להיות מקובצת ביעילות בזמן שהמשתמש מבצע פעילות ספציפית באפליקציה, או להיות מפוזרת באופן לא אחיד בזמן שהמשתמש מבקש מידע נוסף שהאפליקציה צריכה לקבל. המטרה שלכם בניתוח תנועת רשת שנוצרת על ידי משתמשים היא לחפש דפוסים של שימוש תכוף ברשת לאורך זמן, ולנסות ליצור תקופות שבהן לא מתבצעת גישה לרשת או להאריך את התקופות האלה.
הבקשות של המשתמשים הן בלתי צפויות, ולכן קשה לבצע אופטימיזציה של השימוש ברשת מהסוג הזה באפליקציה. בנוסף, המשתמשים מצפים לתשובות מהירות כשהם משתמשים באפליקציה באופן פעיל, ולכן עיכוב של בקשות לצורך יעילות עלול להוביל לחוויית משתמש גרועה. באופן כללי, כשמשתמש מקיים אינטראקציה ישירה עם האפליקציה, חשוב לתת עדיפות לתגובה מהירה למשתמש על פני שימוש יעיל ברשת.
ריכזנו כאן כמה גישות לאופטימיזציה של תנועת רשת שנוצרת על ידי משתמשים:
- אחזור מראש של נתונים מהרשת – כשהמשתמש מבצע פעולה באפליקציה, האפליקציה מנחשת אילו נתונים יכול להיות שיידרשו לפעולות הבאות של המשתמש, מאחזרת אותם בכמות גדולה בחיבור יחיד ומחזיקה אותם עד שהמשתמש מבקש אותם.
- בדיקת החיבור או האזנה לשינויים – לפני שמבצעים עדכון, צריך לבדוק את החיבור לרשת או להאזין לשינויים בחיבור.
- צמצום מספר החיבורים – שימוש בממשקי API של השרת שמאפשרים להוריד נתונים בקבוצות.
ניתוח של תנועה ברשת שנוצרת על ידי אפליקציות
בדרך כלל, פעילות ברשת שמופעלת על ידי קוד האפליקציה היא תחום שבו אפשר להשפיע באופן משמעותי על השימוש היעיל ברוחב הפס של הרשת. במהלך ניתוח הפעילות ברשת של האפליקציה, כדאי לחפש תקופות של חוסר פעילות ולבדוק אם אפשר להאריך אותן. אם אתם רואים דפוסים של גישה עקבית לרשת מהאפליקציה, כדאי לחפש דרכים להרווח בין הגישות האלה כדי לאפשר לרדיו של המכשיר לעבור למצב צריכת חשמל נמוכה.
ריכזנו כאן כמה גישות לאופטימיזציה של תנועת רשת שנוצרת על ידי אפליקציות:
איגוד בקשות לרשת ותזמון שלהן – דחיית הבקשות לרשת של האפליקציה כדי שניתן יהיה לעבד אותן יחד ובזמן שנוח לחיי הסוללה.
Allow System to Check for Connectivity (מתן הרשאה למערכת לבדוק את הקישוריות) – כדי להימנע מהצורך להשתמש בסוללה כדי להפעיל את האפליקציה רק כדי לבדוק את החיבור לרשת, אפשר לאפשר למערכת להריץ את הבדיקה בזמן שהאפליקציה במצב שינה.
ניתוח של תנועה ברשת שנוצרת על ידי שרת
פעילות ברשת שמתחילה בשרתים שמתקשרים עם האפליקציה היא בדרך כלל תחום שבו אפשר להשפיע באופן משמעותי על השימוש היעיל ברוחב הפס של הרשת. כשמנתחים את הפעילות ברשת מחיבורי השרת, צריך לחפש תקופות של חוסר פעילות ולקבוע אם אפשר להאריך אותן. אם אתם רואים דפוסים של פעילות רשת עקבית מהשרתים, כדאי לחפש דרכים להרווח בין הפעילויות כדי לאפשר לרדיו של המכשיר לעבור למצב צריכת חשמל נמוכה.
הנה גישה לאופטימיזציה של תנועת גולשים ברשת שמתחילה בשרת:
- שימוש ב-FCM לעדכוני שרת – מומלץ להשתמש בשירות Firebase Cloud Messaging לעדכונים בצד השרת במקום בסקר.