אופטימיזציה של הגישה לרשת

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

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

מכונת המצבים של הרדיו

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

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

מכונת המצבים של רדיו ברשת 3G טיפוסית מורכבת משלושה מצבי אנרגיה:

• הספק מלא: משמש כשהחיבור פעיל, ומאפשר למכשיר להעביר נתונים בקצב הגבוה ביותר האפשרי.
• צריכת חשמל נמוכה: מצב ביניים שמפחית את צריכת החשמל מהסוללה בכ-50%.
• מצב המתנה: המצב שבו נצרך הכי פחות חשמל, ובמהלכו אין חיבור פעיל לרשת.

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

כדי לצמצם את זמן האחזור, מכונת המצבים משתמשת בעיכוב כדי לדחות את המעבר למצבי אנרגיה נמוכים יותר. באיור 1 מוצגים התזמונים של AT&T עבור רדיו 3G טיפוסי.

איור 1. מכונת מצבים אופיינית של רדיו אלחוטי 3G.

מכונת מצבי הרדיו בכל מכשיר, במיוחד עיכוב המעבר המשויך ("זמן השהייה") וחביון ההפעלה, משתנים בהתאם לטכנולוגיית הרדיו האלחוטית שבה נעשה שימוש (3G,‏ LTE,‏ 5G וכו') ומוגדרים ומותאמים על ידי רשת הספק שדרכה המכשיר פועל.

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

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

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

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

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

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

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

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

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

טכניקות אופטימיזציה

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

העברת נתונים בחבילה

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

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

שליפה מראש של נתונים

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

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

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

הנה דוגמה מעשית.

קורא חדשות

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

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

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

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

שיקולים נוספים

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

האופן שבו מתבצעת האחזור המקדים של הנתונים תלוי בגודל הנתונים שמורידים ובסבירות שהם ישמשו אתכם. ככלל, על סמך מכונת המצבים שתוארה קודם, לגבי נתונים שיש סיכוי של 50% שישמשו בסשן הנוכחי של המשתמש, בדרך כלל אפשר לבצע אחזור מראש למשך כ-6 שניות (כ-1-2 מגה-בייט) לפני שהעלות הפוטנציאלית של הורדת נתונים שלא נעשה בהם שימוש תהיה שווה לחיסכון הפוטנציאלי של אי-הורדת הנתונים האלה מלכתחילה.

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

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

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

בדיקת הקישוריות לפני שליחת בקשות

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

חיבורים למאגרי כתובות IP

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

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

‫HttpURLConnection ורוב לקוחות ה-HTTP, כמו OkHttp, מאפשרים כברירת מחדל איגום חיבורים ושימוש חוזר באותו חיבור לכמה בקשות.

סיכום ומה צפוי בהמשך

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

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