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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אחזור נתונים מראש (prefetch)

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

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

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

הנה דוגמה מהשטח.

קורא חדשות

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

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

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

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

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

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

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

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

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

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

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

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

חיבורי בריכה

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

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

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

סיכום ומבט קדימה

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

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