שימוש ברדיו אלחוטי להעברת נתונים הוא אחד מהגורמים המשמעותיים ביותר להתרוקנות הסוללה באפליקציה. כדי לצמצם את התרוקנות הסוללה שקשורה לפעילות ברשת, חשוב להבין איך מודל הקישוריות ישפיע על חומרת הרדיו הבסיסית.
בקטע הזה נציג את מכונת המצבים של הרדיו האלחוטי ונסביר איך מודל הקישוריות של האפליקציה פועל איתה. לאחר מכן, מוצגות כמה שיטות שיעזרו לכם לצמצם את ההשפעה של צריכת הנתונים של האפליקציה על הסוללה.
מכונת המצבים של הרדיו
למשדר הרדיו האלחוטי במכשיר של המשתמש יש תכונות מובנות לחיסכון בחשמל, שעוזרות לצמצם את צריכת הסוללה. כשהרדיו האלחוטי פעיל לגמרי, הוא צורך הרבה אנרגיה, אבל כשהוא לא פעיל או במצב המתנה, הוא צורך מעט מאוד אנרגיה.
חשוב לזכור שהרדיו לא יכול לעבור ממצב המתנה למצב פעיל באופן מיידי. יש תקופת השהיה שקשורה ל"הפעלת" הרדיו. לכן, הסוללה עוברת ממצבי אנרגיה גבוהים למצבי אנרגיה נמוכים באיטיות כדי לחסוך בחשמל כשהיא לא בשימוש, תוך ניסיון למזער את זמן האחזור שקשור ל "הפעלת" הרדיו.
מכונת המצבים של רדיו טיפוסי ברשת 3G מורכבת משלושה מצבי אנרגיה:
- עוצמה מלאה: המצב הזה משמש כשהחיבור פעיל, ומאפשר למכשיר להעביר נתונים בקצב המהיר ביותר.
- צריכת חשמל נמוכה: מצב ביניים שמפחית את צריכת החשמל של הסוללה בכ-50%.
- המתנה: מצב צריכת החשמל המינימלי שבו אין חיבור פעיל לרשת.
במצבי צריכת החשמל הנמוכה וההמתנה, הסוללה מתרוקנת הרבה פחות, אבל יש גם זמן אחזור משמעותי בבקשות לאחזור מהרשת. החזרה למצב הפעלה מלא ממצב צריכת חשמל נמוכה נמשכת כ-1.5 שניות, והמעבר ממצב המתנה למצב הפעלה מלא יכול להימשך יותר מ-2 שניות.
כדי לצמצם את זמן האחזור, מכונת המצבים משתמשת בהשהיה כדי לדחות את המעבר למצבים שבהם צריכת החשמל נמוכה יותר. באיור 1 מוצגים זמני התזמון של AT&T לרדיו 3G טיפוסי.
איור 1. מכונת מצבים אופיינית של רדיו אלחוטי בדור שלישי.
מכונת המצבים של הרדיו בכל מכשיר, ובמיוחד זמן ההשהיה של המעבר ("זמן הסיום") וזמן האחזור של ההפעלה, משתנים בהתאם לטכנולוגיית הרדיו האלחוטית שבה משתמשים (3G, LTE, 5G וכו'), ומוגדרים על ידי רשת הספק שבה המכשיר פועל.
בדף הזה מתואר מכונת מצבים מייצגת של רדיו אלחוטי 3G טיפוסי, על סמך נתונים שסופקו על ידי 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 מודרניים לניהול יעיל של האינטראקציות האלה.