שימוש בגלי רדיו להעברת נתונים הוא אחד מהגורמים המשמעותיים ביותר להתרוקנות הסוללה באפליקציה. כדי לצמצם את קצב התרוקנות הסוללה שקשור לפעילות ברשת, חשוב להבין איך מודל הקישוריות ישפיע על חומרת הרדיו הבסיסית.
בקטע הזה נסביר על מכונת המצבים של רדיו אלחוטי ואיך מודל הקישוריות של האפליקציה שלכם פועל איתה. לאחר מכן מוצעות כמה שיטות שעוזרות לצמצם את ההשפעה של צריכת הנתונים של האפליקציה על הסוללה.
מכונת המצבים של הרדיו
לרדיו האלחוטי במכשיר של המשתמש יש תכונות מובנות לחיסכון באנרגיה, שעוזרות לצמצם את כמות הסוללה שהוא צורך. כשהרדיו האלחוטי פעיל, הוא צורך כמות משמעותית של חשמל, אבל כשהוא לא פעיל או במצב המתנה, הוא צורך מעט מאוד חשמל.
חשוב לזכור שאחד הגורמים שמשפיעים על התהליך הוא שרכיב הרדיו לא יכול לעבור ממצב המתנה למצב פעיל באופן מיידי. יש תקופת השהיה שקשורה להפעלת הרדיו. כך הסוללה עוברת ממצבי אנרגיה גבוהים למצבי אנרגיה נמוכים לאט, כדי לחסוך בחשמל כשהיא לא בשימוש, תוך ניסיון למזער את זמן האחזור שקשור ל'הפעלת' הרדיו.
מכונת המצבים של רדיו ברשת 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
, כמו שמוצג במאמר מעקב אחרי סטטוס החיבור ומדידת החיבור.
אם אין רשת, האפליקציה יכולה לחסוך בסוללה בכך שהיא לא מכריחה את הרדיו של הנייד לחפש רשת. אחרי שנוצר חיבור, אפשר לתזמן את הבקשה ולבצע אותה בחבילה עם בקשות אחרות.
חיבורים למאגרי מידע
אסטרטגיה נוספת שיכולה לעזור בנוסף לאיגום ולטעינה מראש היא איגום של חיבורי הרשת של האפליקציה.
בדרך כלל יעיל יותר לעשות שימוש חוזר בחיבורים קיימים לרשת מאשר ליצור חיבורים חדשים. שימוש חוזר בחיבורים מאפשר גם לרשת להגיב בצורה חכמה יותר לעומס ולבעיות נתונים קשורות ברשת.
HttpURLConnection
ורוב לקוחות ה-HTTP, כמו OkHttp, מאפשרים כברירת מחדל איגום חיבורים ושימוש חוזר באותו חיבור לכמה בקשות.
סיכום ומה צפוי בהמשך
בקטע הזה למדתם הרבה על רדיו אלחוטי ועל כמה אסטרטגיות שאפשר ליישם באופן כללי כדי לספק חוויית משתמש מהירה ורספונסיבית, תוך צמצום צריכת הסוללה.
בקטע הבא נבחן בפירוט שלושה סוגים שונים של אינטראקציות ברשת שמשותפים לרוב האפליקציות. תלמדו מהם הגורמים המניעים של כל אחד מהסוגים האלה, וגם על טכניקות וממשקי API מודרניים לניהול יעיל של האינטראקציות האלה.