מיכל ריצה של סופר אפליקציה: בידוד, גשר, מחזור חיים

מכלול זמן ריצה של Super App: בידוד, גשר, מחזור חיים

טביעת הזיכרון של Super App עם חמישה מיני-אפליקציות פעילים עולה על 1.2 ג'יגה-בייט במכשיר עם 4 ג'יגה-בייט RAM. ללא בידוד זמן ריצה, כל מיני-אפליקציה חולקת WebView משותף, מה שמוביל לדליפות הקשר JavaScript, התקפות cross-origin, ולולאות קריסה בעת מעבר. פיתוח מכלול זמן ריצה פותר בעיות אלו: הוא מבודד תהליכים, שולט ב-API של הגשר, ומנהל את מחזור החיים. הצוות שלנו יישם למעלה מ-50 מכלולים כאלה עבור iOS ו-Android, והפחית את עלות הבעלות הכוללת (TCO) של הלקוחות ב-35%.

מדוע בידוד מיני-אפליקציות הוא קריטי עבור Super Apps?

מכלול אינו רק WebView עם כתובת URL. הוא מערכת לבידוד, ניהול משאבים, קריאות marshaling ל-API מקוריים, ושליטה במחזור החיים של כל מיני-תוכנית. שגיאת עיצוב במכלול מובילה לדליפות זיכרון בין סשנים, לולאות קריסה בעת מעבר בין מיני-תוכניות, וחורי אבטחה—כאשר מיני-אפליקציה של ספק אחד מקבלת גישה לנתונים של אחר.

במערכת Android, יישום טיפוסי בנוי סביב מספר תהליכים מבודדים באמצעות android:process במניפסט, ClassLoader מותאם אישית לכל מיני-אפליקציה, ו-WebViewClient מותאם אישית המיירט את כל הבקשות ל-bridge:// URIs. במערכת iOS, אנו משתמשים ב-WKWebView עם WKProcessPool נפרד לכל מיני-תוכנית, WKWebsiteDataStore מבודד, ו-hooks ב-WKScriptMessageHandler לקריאות גשר מקוריות.

הבעיה שכמעט כולם מתמודדים איתה היא תקציב הזיכרון. במכשירים עם 3–4 ג'יגה-בייט RAM, החזקת 5–6 תהליכי WKWebView פעילים אינה ריאלית. WeChat פתרה זאת באמצעות טעינה מוקדמת אגרסיבית של WebView ריק אחד ומאגר hot-standby של 2–3 מופעים מאותחלים אך ללא תוכן. אנו משתמשים בגישה דומה, מותאמת למטריצת המכשירים של הלקוח, מה שמפחית את צריכת הזיכרון ב-40%.

ארכיטקטורת בידוד זמן ריצה

ההחלטה המרכזית היא בחירה בין מודלים של מכלול חד-תהליכי ורב-תהליכי.

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

רב-תהליכי (כל מיני-אפליקציה בתהליך משלה): יציב יותר, אך ב-Android מוסיף 30–50 מגה-בייט RAM לכל תהליך וזמן אתחול ראשון של 400–800 אלפיות שנייה עקב fork+zygote. ב-iOS, תהליכי WKWebView מנוהלים על ידי המערכת, כך שהבידוד הוא דה פקטו.

אנו מיישמים תכנית היברידית: מיני-אפליקציות רקע (אודיו, מיקום גיאוגרפי) רצות בתהליך נפרד עם FOREGROUND_SERVICE, בעוד מיני-אפליקציות UI פעילות רצות במאגר של WebViews בתוך תהליך המארח הראשי עם מגבלות הדוקות באמצעות WebSettings.setJavaScriptEnabled ו-ContentProvider מותאם אישית להחלפת נתונים בין אפליקציות. גישה זו מפחיתה את עלות הבעלות הכוללת בעד 35% על ידי הפחתת שיעורי קריסה ועלויות תחזוקה.

כיצד פועל גשר ה-JavaScript?

הגשר הוא הפרוטוקול בין קוד ה-JavaScript של המיני-אפליקציה ל-API המקוריים של המארח. העיצוב שלו קובע הן את היכולות והן את המגבלות של כל המערכת האקולוגית.

יישום Android טיפוסי:

webView.addJavascriptInterface(new NativeBridge(context), "__miniapp_bridge__"); 

אבל webView.addJavascriptInterface(new NativeBridge(context), "__miniapp_bridge__"); בצורתו הטהורה אינו בטוח—כל JS ב-WebView מקבל גישה לגשר. לכן אנו מוסיפים Origin Validator: כל קריאת גשר כוללת אסימון חתום שנוצר במהלך אתחול המיני-אפליקציה ומקושר ל-hash של ה-bundle שלה.

ב-iOS, אנו משתמשים ב-@JavascriptInterface:

configuration.userContentController.add(self, name: "miniAppBridge") 

עם בדיקה חובה של WKScriptMessageHandler—אחרת iframes בתוך המיני-אפליקציה מקבלים גם גישה ל-API מקוריים.

תכנית הקריאה היא אסינכרונית עם מזהה correlation: JS שולח configuration.userContentController.add(self, name: "miniAppBridge") , הצד המקורי פותר את ה-promise באמצעות message.frameInfo.isMainFrame. זמני timeout הם 5 שניות לקריאות רגילות, 30 שניות לקריאות איטיות (פעולות קבצים, Bluetooth). זמן האחזור של הגשר בדרך כלל אינו עולה על 50 אלפיות שנייה. 80% מהמיני-אפליקציות משתמשות ב-API של מיקום, מה שדורש תשומת לב מיוחדת להרשאות.

class MiniAppBridge: NSObject, WKScriptMessageHandler {
    func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
        guard message.frameInfo.isMainFrame else { return }
        // ... обработка вызова
    }
}

ניהול מחזור חיים וזיכרון

מחזור חיים של מיני-אפליקציה: {callId: uuid, method: "getLocation", params: {}}. המכלול מאזין לאירועי זיכרון של המערכת (webView.evaluateJavaScript("window.__resolve__('\(callId)', \(result))") ב-Android, class MiniAppBridge: NSObject, WKScriptMessageHandler { func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) { guard message.frameInfo.isMainFrame else { return } // ... обработка вызова } } ב-iOS) ומעביר באגרסיביות מיני-אפליקציות רקע מ-loading → active → background → suspended → destroyed ל-onTrimMemory (WebView קפוא, הקשר נשמר) או ל-UIApplicationDidReceiveMemoryWarningNotification (הכל מאופס, אתחול קר בעת פתיחה מחדש).

תרחיש טיפוסי שמפיל מתחרים: משתמש פותח 8 מיני-אפליקציות ברצף מבלי לסגור אף אחת. באייפון עם 4 ג'יגה-בייט RAM, זה ~1.6 ג'יגה-בייט רק עבור תהליכי WebView. המערכת שולחת התראת לחץ זיכרון, iOS הורגת מספר תהליכי רקע—והמשתמש רואה מסך לבן במקום המיני-אפליקציה. הפתרון שלנו: ניטור באמצעות background (זמין מאז iOS 13), השמדה יזומה של מיני-אפליקציות מושהה כאשר הלחץ עולה על 70%, ושחזור אוטומטי של מצב באמצעות snapshot מסודר לפני ההשמדה. לאחר האופטימיזציה, צריכת הזיכרון יורדת ב-60%.

אבטחה: בקרת גישה מבוססת יכולות

כל מיני-אפליקציה, בעת רישום בחנות, מצהירה על הרשאות: suspended. המכלול מאחסן הרשאות מאושרות באחסון מוצפן (Keychain / Android Keystore) ומאמת כל קריאת גשר מול המניפסט הזה. ניסיון לקרוא ל-API לא מוצהר גורם לכישלון שקט עם לוג באנליטיקה ודגל במערכת הניטור. הפתרון המוסמך שלנו עומד במלואו בשיטות האבטחה המומלצות.

מה כלול בעבודה

1. ביקורת על הארכיטקטורה הקיימת או עיצוב greenfield.
2. בחירת מודל בידוד (חד/רב/היברידי).
3. עיצוב ה-API של הגשר (בדרך כלל 2–4 שבועות ליישור, מכיוון שהוא הופך לחוזה עם מפתחי מיני-אפליקציות).
4. יישום מכלול זמן הריצה.
5. בדיקות עומס (100+ מיני-אפליקציות במקביל בבדיקה אוטומטית).
6. אינטגרציה עם החנות ומערכת ההרשאות.
7. תמיכה ואבולוציה של ה-API של הגשר.

לוחות זמנים למכלול שנבנה מאפס עבור שתי הפלטפורמות: 3 עד 6 חודשים, תלוי בדרישות הבידוד, בקבוצת ה-API המקוריים בגשר, ובזמינות של מפרטים מוכנים. Android או iOS בלבד—מהיר פי שניים. עלות הפרויקט מחושבת בנפרד לאחר הערכת היקף. הלקוחות שלנו חוסכים עד 40% מתקציב התמיכה הודות לניטור יזום וארכיטקטורה היברידית. צרו קשר כדי לקבל ייעוץ לפרויקט שלכם. הזמינו פיתוח של מכלול עבור ה-Super App שלכם—אנו נעזור בעיצוב וביישום.