אנדרואיד - Multitasking

מערכת אנדרואיד מאפשרת לכמה אפליקציות לפעול ביחד, מה שמכונה "ריבוי משימות" או "Multi Tasking". פרק זה יסביר איך אנדרואיד מממשת את היכולת הזו. כבר ציינו שאנדרואיד היא מערכת הפעלה המיועדת למכשירים ניידים. ככזאת, היא מותאמת לעבודה בסביבה עם משאבי זיכרון מוגבלים. מערכת הפעלה קונבנציונלית ממשת ריבוי משימות על ידי מעבר מהיר של המעבד בין המשימות, על פי הצורך. לפני שהמעבד מפסיק טיפול במשימה הנוכחית ועובר לטיפול במשימה הבאה (task switching), עליו לשמור את המידע הקשור למשימה הנוכחית כך שיוכל להמשיך ולבצע אותה בהמשך. לצורך זה נדרש משטח עבודה (swap memory) מספיק גדול. למערכת הפעלה ניידת לעומת זאת יש  דרישות ומגבלות מיוחדות: 

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

 השיטה בה פועל אנדרואיד מושתת על הפרדה בין ישות ה- Activity השייכת לאפליקציה לבין משאבי מערכת ההפעלה - ה Process. ברירת המחדל היא שכל אפליקציה רצה על Process נפרד של מערכת ההפעלה. יחד עם זאת,  בהחלט אפשרי שאפליקציה תרוץ על מספר Process, וכמו שנראה מיד, במצבים מסוימם יתכן שלאפליקציה לא יהיה מחובר אף   .Process
משמעות ההפרדה, כלומר העדר צימוד, בין ה- Activity של האפליקציה לבין ה- Process של הלינוקס קרנל, היא שברגע שמערכת ההפעלה זקוקה למשאבי זיכרון עבור משימה אותה היא מבצעת, ה- Kernel רשאי  "להרוג" Process של אפליקציה הנמצאת בהמתנה ולהשתמש במשאבים שהתפנו. הפעולה הזו נעשית באופן ברוטלי, בלי שום תהליך שמירה לפניו, סינכרון או אזהרה מוקדמת! את מי מהפעילויות שנמצאות בהמתנה תבחר המערכת להרוג? הבחירה תעשה על פי קריטריונים של חשיבות האפליקציה למשתמש (לפי נתונים מפעילות בעבר) ולפי השוואת זמני ההמתנה כשהעדיפות להרוג את מי שלא היה פעיל זמן רב יותר.

נציין שאם מערכת ההפעלה לא נמצאת במצוקת משאבים, היא בהחלט תאפשר ל- process לעבוד ברקע עד כמה שיצטרך. למרות הנאמר לעי"ל, האפליקציות שהרגו להן את ה- Process שלהן, יוכלו להמשיך לפעול ברגע שהמשתמש יחזיר אותן לפעולה מול התצוגה (ל - Foreground). זה מתאפשר היות שהנתונים החיוניים לחזרה לפעולה מהנקודה בה המשתמש צפה בה לאחרונה, נשמרים ברגע שהאפליקציה יורדת מהתצוגה ועוברת לרוץ ברקע (Background). תהליכי שמירת ושחזור הנתונים של האפליקציה מנוהלים על-פי מערכת מצבים "Process Lifecycle" או "מהלך החיים", שנתאר בהמשך.

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

קיימים  מנגנוו כזה: ה- Service. 

• ה- Service רץ ברקע ללא UI - User Interface.
• כמות ה- Services במערכת אינה מוגבלת, כך שלא ניתן להבטיח שיהיה מספיק זיכרון עבור כולם.
• במקרה שמערכת הפעלה נאלצת להרוג Process של Service, היא תדאג להפעילו מחדש ברגע שיתפנו משאבים מספיקים לכך.
• ניתן להגדיר Service שיהיה חסין יותר מפני חיסול ע"י מערכת הפעלה. Service כזה, חייב לכלול הודעה למשתמש כל עוד הוא פועל. בניגוד למצב עם Service רגיל, המשתמש יכול לסגור אותו אם יחפוץ. זו הפשרה בעניין...דוגמא: נגן mp3 שרץ ברקע על service. הוא יוכל להיות מסומן ב-"בבקשה לא להרוג אותי", אבל יכיל אייקון שיסמן למשתמש שהוא עובד, וניתן יהיה להפסיק עבודתו.

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

הזכרתי במהלך הפרק את המושג "מהלך החיים" אן Life Cycle של האפליקציה. נייחד את הפרק הבא (או אחד הפרקים הבאים) לנושא.

קישור לפוסט כולל דוגמא על ה-service.