Multitasking & Task killer

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

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

 

אז מאיפה מגיע המרדף אחרי הזיכרון הפנוי?

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

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

 

איך זה מתקשר לאנדרואיד?

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

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

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

 

יורדים לשורש הדברים

למערכת הפעלה ניידת יש דרישות ומגבלות מיוחדות:

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

אז איך התזמורת מנגנת בפועל:

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

את מי מהפעילויות שנמצאות בהמתנה תבחר המערכת להרוג?

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

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

לא הכל מושלם, ישנם כמה בעיות

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

 

למה לא לחסוך את הפעולה למערכת?

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

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

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

 

Multi Task

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

אז נדגים את דרך הפעולה של מערכת האנדרואיד ומערכת ה iOS בעזרת ניסוי קטן: ניקח מכשיר אנדרואיד ומכשיר iOS (אייפון) ונטען דף אינטרנט כבד (כדי שזמן הטעינה יהיה ארוך, ניקח לדוג’ את Facebook), כשהטעינה מגיעה לחצי ויש עם מה “לשחק” נשים את האצבע על המסך ונזיז אותו מעלה / מטה. התהליך שיקרה ב iOS הוא שהטעינה תעצור לגמרי! והמערכת תתן עדיפות לתהליך המגע שהתחלנו כעת, באנדרואיד הטעינה תמשיך והמערכת תנסה לשלב בין התהליכים. מה שראינו כרגע יהיה מאופיין באנדרואיד בלאגים (lags) מכיוון שכוח העיבוד מוגבל ואינו יכול לבצע את כל התהליכים בעת ובעונה אחת (ככל שמכשיר האנדרואיד יהיה בעל יותר משאבים, מעבד יותר מהיר, יותר ליבות, יותר זיכרון וכ’ו הסבירות שהתהליך יתאפיין בלאגים נמוכה).

בגרסת אנדרואיד ICS (גרסה 4.0) המפתחים בגוגל לקחו רעיון מה PC, וגרמו ל GPU (המעבד הגרפי) לעזור ל CPU (המעבד המרכזי) בעיבוד התהליכים ובכך לגרום לריצה חלקה יותר של המערכת. בנוסף ICS תומכת באופן מלא במעבדים מרובי ליבות ויודעת לחלק בינהם את הנטל (כמו ב PC) כך שהמערכת, שוב, תרוץ בצורה חלקה יותר.

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

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

 

ICS - 4.0

אם עד היום (עד גרסה ICS) יכולתם לראות רק את 6 היישומים האחרונים שהפעלתם (ע”י לחיצה ממושכת על מקש הבית) ב ICS אתם גם יכולים “לסגור” אותם ע”י דחיפה שלהם לצד ימין. אבל הם לא נסגרים לגמרי, הם נשארים קפואים.

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

אם תרצו להרחיב קיים פוסט בנושא בבלוג המפתחים של אנדרואיד: Multitasking the Android Way.