| Key concepts | Set up your development environment | Build an RE SDK | Consume the RE SDK | Testing, and building for distribution |
מושגים מרכזיים
בקטע הזה מוסבר על הארכיטקטורה של SDK Runtime, על אופן ההתקנה של ערכות SDK שתואמות לזמן ריצה, על תאימות לאחור ועל אופן ההעברה של ערכות SDK קיימות ל-SDK Runtime.
מילון מונחים
- SDK שתומך בסביבת זמן ריצה (RE SDK): ערכת SDK שנועדה לפעול בסביבת זמן הריצה של ה-SDK ולתקשר עם האפליקציה באמצעות תקשורת בין תהליכים (IPC).
- SDK שתומך בסביבת זמן ריצה (RA SDK): ערכת SDK שלא תומכת בסביבת זמן ריצה, שמקושרת לאפליקציה באופן סטטי ועשויה להכיל את קוד ה-SDK הקיים שלכם וגם קוד חדש לקריאה ל-SDK שתומך בסביבת זמן ריצה.
- הקישור הזה נקרא לפעמים גם קישור סטטי או SDK סטטי.
- Shim: ספריית Jetpack שעוזרת ליצור תקשורת מופשטת בין תהליכים או תקשורת בין תהליכים (IPC), תוך שמירה על אותו ממשק בין האפליקציה ל-SDK.
הארכיטקטורה של SDK Runtime
זמן הריצה של ה-SDK מבוסס על מודל מסוג לקוח-שרת.
ההבדל העיקרי הוא ש'הלקוח' (האפליקציה) ו'השרת' (ערכות SDK שפועלות בסביבת זמן ריצה) פועלים באותו מכשיר, והתקשורת הזו מתרחשת בין תהליכים.
כדי לעזור לכם להתמודד עם האתגרים האלה, יצרנו את הספריות והכלים הבאים של Jetpack כדי לפשט את השילוב של אפליקציות עם SDK בסביבת זמן הריצה של ה-SDK:
- ספריית shim: ספריית המעטפת (או shim) עוזרת ליצור תקשורת מופשטת בין תהליכים או תקשורת בין תהליכים (IPC). הוא גם עוזר לשמור על אותו ממשק בין האפליקציה ל-SDK.
- ספריית תאימות לאחור: הספרייה הזו מטפלת בתאימות לאחור, ומבטיחה שערכת ה-SDK תואמת גם אם סביבת זמן הריצה של ה-SDK זמינה וגם אם לא.
- ספריית ממשק משתמש: אנחנו מספקים גם ספריות לטיפול בהצגה מרחוק, כמו אחזור ממשק משתמש מ-SDK שתומך בסביבת זמן ריצה או שינוי הגודל והפריסה של תצוגות.
שינויים בתהליך ההתקנה
כשאתם יוצרים ערכת SDK שתואמת לזמן ריצה ב-Android Studio או בכלים אחרים, אתם יוצרים חבילת Android SDK (ASB), שהוא פורמט פרסום לערכות SDK שתואמות לזמן ריצה.
bundletool מעבד את ה-ASB כדי ליצור קובץ APK ל-SDK המופעל בסביבת זמן הריצה: קובץ ה-APK הנפרד הזה מכיל את קוד ה-SDK אבל לא את קוד האפליקציה.
קובץ המניפסט של האפליקציה מצהיר על תלות בשם ובגרסה של ערכת ה-SDK שתואמת לזמן הריצה, והתלות הזו נפתרת על ידי אפליקציית ההתקנה.
אחרי שמנהל ההתקנה מקבל את קובץ ה-APK של ה-SDK, ההתקנה מתחילה בהתקנה של קובץ ה-APK של ה-SDK. אם הפעולה תתבצע בהצלחה, תתבצע התקנה של קובץ ה-APK של האפליקציה.
התהליך שונה אם האפליקציה מותקנת ב-Android מגרסה 13 ומטה, ובמכשירים שלא תומכים בזמן הריצה ל-SDK. בתרחיש הזה, החנות מתקינה קובץ APK אחד שמכיל גם את ה-SDK שתומך בסביבת זמן הריצה וגם את קוד האפליקציה. מידע נוסף זמין בקטע 'הפצה'.
בכל פעם שאפליקציה תלויה ב-SDK הזה בסביבת הייצור, חנות האפליקציות יוצרת את קובץ ה-APK הנכון של ה-SDK מה-ASB הזה ומתקינה אותו.
תאימות לאחור
זמן הריצה ל-SDK הוצג ב-Android 14, ולכן נדרשנו לתמוך בגרסאות קודמות בלי להוסיף עומס למפתחי ה-SDK או האפליקציות.
כדי לטפל בתאימות לאחור ב-Android 13 ובגרסאות קודמות, הוספנו ספריית Jetpack שיכולה להריץ בצורה חלקה את ערכת ה-SDK שתואמת לזמן ריצה, ללא קשר לתמיכה של המכשיר בזמן הריצה ל-SDK.
אם תפעלו לפי המדריך הזה, ערכת ה-SDK שתואמת לזמן הריצה תהיה תואמת לאחור כברירת מחדל, ולא תצטרכו לבצע פעולות נוספות.
בשלבים הרלוונטיים נדגיש את הפעולות שקשורות לתאימות לאחור, אבל באופן כללי, חשוב לוודא שהצהרתם על יחסי התלות הנכונים ושאתם משתמשים בכיתות *Compat בכל מקרה שבו זה רלוונטי.
העברת ערכות SDK קיימות
אם יש לכם ערכת SDK קיימת שאתם רוצים להעביר לסביבת זמן הריצה, אתם לא צריכים לבצע רפאקציה של כל קוד הבסיס בבת אחת. במקום זאת, תוכלו להעביר את הלוגיקה הקיימת של ה-SDK באופן מצטבר ל-SDK החדש שתומך בסביבת זמן הריצה.
מומלץ לבצע את שלושת השלבים הבאים כדי להעביר ערכת SDK קיימת לסביבת זמן הריצה של SDK:
- פיתוח ערכת SDK שתואמת לזמן ריצה לתקופת המעבר, יחד עם ערכת SDK עבה מקבילה שתומכת בזמן ריצה. כך תוכלו להעביר בהדרגה את הלוגיקה העסקית מ-SDK הקיים, ותהיה לכם פלטפורמת בדיקה לבדיקות A/B.
- העברת כל הלוגיקה העסקית הקיימת של ה-SDK למצב יציב, יחד עם ערכת SDK דקה מקבילה שתומכת בסביבת זמן ריצה, כדי להקל על העברת האפליקציה
- תמיכה באפליקציות המעוניינות במיגרציה מלאה, כדי להשתמש ב-SDK שתומך בזמן ריצה ישירות, בלי SDK דק שתומך בזמן ריצה
שלב 1 – תקופת מעבר: SDK עבה עם תמיכה בסביבת זמן ריצה
כדי להתחיל, אפשר לבחור לשמור חלק מהלוגיקה העסקית ב-SDK שמתחשב בסביבת זמן הריצה. אנחנו מכנים את זה SDK עבה עם תמיכה בסביבת זמן ריצה או מעטפת בתוך האפליקציה.
הגישה הזו מאפשרת לשמור את כל היכולות של ה-SDK או חלק מהן בספריית האפליקציה הסטטית, לצד ערכת SDK חדשה שתומכת בסביבת זמן ריצה.
כך תוכלו להעביר בהדרגה את התרחישים לדוגמה ל-SDK שתומך בסביבת זמן הריצה, ולבדוק את ה-SDK שתומך בסביבת זמן הריצה בהשוואה ל-SDK הקיים.
בשלב הזה, מפתח האפליקציה לא צריך לשנות את אופן השימוש ב-SDK, כי ספריית האפליקציה הסטטית (SDK עם תמיכה בסביבת זמן ריצה) מבצעת את העבודה הנדרשת לשימוש ב-SDK עם תמיכה בסביבת זמן ריצה.
שלב 2 – מצב יציב: SDK דק שמתעדכן בזמן ריצה
בניגוד ל-SDK עבה עם תמיכה בסביבת זמן ריצה, מעטפת דקה או SDK דק עם תמיכה בסביבת זמן ריצה (thin RA_SDK) מכיל רק תרגום של ממשקי API וקוד של קריאה ל-SDK עם תמיכה בסביבת זמן ריצה ב-SDK של הספרייה המקושרת באופן סטטי.
בשלב הזה, אתם אמורים להעביר את כל קוד ה-SDK מ-SDK הספרייה הסטטית של האפליקציה ל-SDK התומך בסביבת זמן ריצה.
מפתחי האפליקציות לא צריכים לבצע שינויים משלב 1, כי ה-SDK הדק בתוך האפליקציה שמתאים לסביבת זמן ריצה מטפל בקריאה ל-SDK התואם לסביבת זמן הריצה בתוך זמן הריצה ל-SDK.
שלב 3 – העברה מלאה
בשלב האחרון הזה, העברתם את כל היכולות של ה-SDK ל-SDK שפועל בסביבת זמן ריצה והסרתם את כל הספריות הסטטיות מהאפליקציה.
בשלב הזה, לקוחות האפליקציה כבר לא צריכים לכלול את הספריות שלכם בגרסאות ה-build שלהם, אלא רק לרשום את יחסי התלות של ה-SDK במניפסט ולכלול את הקריאות ל-SDK בקוד האפליקציה שלהם.
המערכת מפנה את הקריאות ל-SDK אל זמן הריצה של ה-SDK, שבו ה-SDK התומך בזמן ריצה נטען באופן אוטומטי.
שלב 2: מגדירים את סביבת הפיתוח