אנדרואיד - 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.

כמה מילים על קובץ המניפסט

נתייחס לקובץ ה- AndroidManifest.xml הנמצא בספריה הראשית של הפרויקט. מטרת סקירה זו היא לקבל אוריינטציה שנזדקק לה בהמשך, בפרק הבא הדן ב-intents. קובץ המניפסט כולל אינפורמציה על האפליקציה כגון מיקום קובץ האייקון שישמש להפעלת האפליקציה, ורשימה של ה-Activity וה- Services שקימים בפרויקט ופרמטרים הקשורים אליהם.
סיבת הקיום העיקרית של הקובץ: הכרזה על מרכיבי האפליקציה השונים כך שהאנדרואיד יכיר אותם ויוכל להפעיל אותם.
על המפתח לרשום את הנתונים של כל ה- Activities וה- Services בקובץ המניפסט. אלמנט שלא ירשם בקובץ, האפליקציה כאמור לא תכיר אותו.

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

1. <?xml version="1.0" encoding="utf-8"?>
2. <manifest xmlns:android="http://schemas.android.com/apk/res/android"
3.       package="com.example.hello"
4.       android:versionCode="1"
5.       android:versionName="1.0">
6.     <application android:icon="@drawable/icon" 
7. android:label="@string/app_name">
8.         <activity android:name=".Hello"
9.                   android:label="@string/app_name">
10.             <intent-filter>
11.                 <action android:name="android.intent.action.MAIN" />
12.                 <category android:name="android.intent.category.LAUNCHER" 
13. />
14.             </intent-filter>
15.         </activity>
17.     </application>
18.     <uses-sdk android:minSdkVersion="8" />
    
19. </manifest> 

שורות 1-7 כוללות כותרות והגדרות כלליות של הפרויקט כגון שם החבילה (שורה 3), גרסת ושם האפליקציה (שורה 4 ו-5), בשורה 6 מתואר הקובץ שישמש כאייקון להפעלת האפליקציה. במקרה שלנו, מדובר בקובץ icon.png הנמצא בספריית res/draw, ראה התייחסות לנושאי תוכן הספריות בשיעור Hello World.
שורה 8-15 מתארת את הActivity שבמקרה שלנו הוא היחידי בפרויקט. במידה שהיו נוספים Activity או Service נוספים הם היו צריכים להרשם כאן. שורה 8: שם ה Activity, שנתנו כזכור עם בניית הפרויקט. שורה 10-14 מגדירות Intent Filter. הגדרת ה- Intent ניתנה בשיעור קודם שהתייחס להגדרות מושגים. זוהי הודעת מערכת שמנותבת ע"י מסנן (Intent Filter). נרחיב על הנושא באחד הפרקים הבאים.
שורה 18 מציינת את גרסת ה- API המינימלית אליה הפרויקט מסוגל להתאים. שוב, מספר זה נתנו כשבנינו את הפרויקט. ראה שיעור Hello World.

מושגי יסוד של אנדרואיד

מספר מושגי יסוד של האנדרואיד: 

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

1. Activity
2. Intent
3. Service

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

Intent - זהו המנגנון באמצעותו מועברות הודעות במערכת. בעזרת מנגנון זה ניתן ליצור קשר עם אלמנטים בתוך האפליקציה ומחוצה לה, וכך לבצע פעולות כמו:   מעבר בין מסכי התצוגה שנעשה ע"י שליחת Intent להפעלת  Activity  הרצוי; העברת נתונים בין Activities; גישה לשרותים של מערכת האנדרואיד, למשל שליחת אימייל; יציאת קשר עם שרותים אחרים ע"ע Service כאן בהמשך; גישה למודולים של גורם שלישי הקיימים על הפלטפורמה, העברת הודעות Broadcast במערכת. קיימים שני טיפוסים של Intent - מפורש ומרומז.   ב-Intent מפורש (Explicit) השולח מציין במפורש את שם יעד ההודעה. במקרה של אינטנט מרומז (Implicit) השולח לא מציין את יעד ההודעה, אבל לפי הפרמטרים שבה, ההודעה מכוונת ע"י ה- Intent Filter ליעד המתאים. מנגנון זה מאפשר קוד גמיש בו אין צורך לדעת מראש את זהות היעד של הודעה.
באחד השיעורים הבאים נלמד את המנגנון לעומק.

Service-   פעילות שרצה ברקע, ללא אינטראקציה ישירה עם המשתמש, כלומר בלי UI. ה- Service יכול לקבל פקודות מ-Activities - שהוא כאמור בעל ממשק למשתמש - באמצעות  Intent. ה- Service מתאים לפעילויות רקע כגון נגן, טיימר וכדומה.