הגדרת שרת לסטרימינג של AssetBundle במשחקי VR

מדוע צווארי בקבוק בסטרימינג של נכסים נמצאים בשרת, לא בבנייה

גודל קובץ APK של משחק VR עם תוכן מלא עולה בקלות על 2 ג'יגה-בייט—המגבלה עבור Quest Store וקרוב למגבלה עבור Google Play. סטרימינג של נכסים פותר זאת: רק משאבי ההפעלה הקריטיים נכנסים לבנייה, והשאר נטען לפי דרישה. אבל "טעינה תוך כדי תנועה" ו"טעינה מהירה ואמינה" הן משימות שונות, והאחרונה תלויה לחלוטין בשרת מוגדר כראוי. הניסיון שלנו מראה: אפילו עם קוד לקוח מצוין, כותרות HTTP שגויות הורגות את ביצועי ההורדה.

מה השרת צריך לסטרימינג תקין של AssetBundle

AssetBundle הוא לא רק קובץ דרך HTTP. יש לו מספר תכונות המשפיעות על דרישות השרת.

• בקשות Range הן חובה. UnityWebRequest.GetAssetBundle() עם מטמון משתמש בכותרת HTTP Range כדי לבדוק אם קטע כבר הורד או צריך להתחדש. אם השרת מגיב ל-Range: bytes=0-1023 עם קובץ מלא במקום 206 Partial Content, מטמון Unity נשבר—כל השקה מורידה מחדש את כל ה-bundle. Nginx תומך ב-Range כברירת מחדל, אבל חלק מתצורות CDN משביתות זאת.
• ETag / Last-Modified לאימות מטמון. מטמון AssetBundle של Unity בודק גרסה דרך CacheControlParams או hash. אם השרת לא מספק ETag או Last-Modified, Unity לא יכול לקבוע אם ה-bundle השתנה—או שהוא מוריד הכל מחדש כל פעם או משתמש בגרסה מיושנת. הגדרת ETag ב-Nginx: etag on;—שורה אחת, אבל לעתים קרובות נשכחת.
• GZIP/Brotli רק למשאבים טקסטואליים. AssetBundle בפורמט LZ4 (אופטימלי לטעינה בזמן אמת) לא צריך להיות דחוס נוסף ברמת HTTP—רק בזבוז מחזורי CPU על דחיסה. ב-Nginx: gzip_types חייב להחריג במפורש application/octet-stream עבור bundles.
• CORS עבור WebGL. אם תוכן VR רץ דרך WebXR בדפדפן—השרת חייב לשלוח כותרות CORS מתאימות: Access-Control-Allow-Origin, Access-Control-Expose-Headers: Content-Length (נדרש עבור פס התקדמות במהלך טעינה).

למה תצורת שרת נכונה חוסכת עד 70% תעבורה

עם מטמון וגרסאות נכונים, הלקוח מוריד רק bundles שהשתנו—נפח התעבורה מופחת ב-40–70% בהתאם לתדירות העדכונים. אנו משתמשים בסכמת AssetBundle Manifest: ה-manifest נטען ללא מטמון, בעוד כל ה-bundles נטענים עם max-age=31536000. כאשר תוכן מתעדכן, ה-hash בנתיב משתנה, וה-CDN מגיש גרסה חדשה. זה מבטל הורדה מחדש של נתונים שלא השתנו.

ארכיטקטורת שרת לסטרימינג של נכסים

סכמה טיפוסית: שרת מקור (אחסון של מאסטרים, ניהול גרסאות) + CDN (הפצה, מטמון קצה).

עבור המקור, אנו משתמשים ב-Nginx או Caddy. Caddy אטרקטיבי יותר עבור צוותים קטנים: HTTPS אוטומטי דרך Let's Encrypt, תצורה בקובץ Caddyfile יחיד, כותרות נכונות מחוץ לקופסה.

מבנה כתובת ה-URL של הנכס כולל גרסה: /assets/v{hash}/{bundleName}. כאשר תוכן מתעדכן, ה-hash בנתיב משתנה—CDN לא מגיש נתונים מהמטמון, הלקוח מקבל bundle חדש. זה אמין יותר מאשר שבירת מטמון דרך query string (?v=123), שחלק מה-CDN מתעלמים ממנה.

עבור CDN המשרת קהל VR גלובלי, אנו ממליצים על Cloudflare R2 + Cloudflare CDN (יציאה חינם) או AWS S3 + CloudFront. הגדרות CloudFront מפתח: Cache-Control: max-age=31536000, immutable עבור bundles עם גרסאות, Cache-Control: no-cache עבור קובץ ה-manifest.

ה-AssetBundle Manifest הוא קובץ קל נפרד (~10 KB) המכיל רשימה של כל ה-bundles עם hashes ותלויות. הלקוח טוען אותו בהפעלה, משווה עם המטמון המקומי, ומוריד רק bundles שהשתנו. עדכוני תוכן ללא התקנה מחדש של האפליקציה—על ידי שינוי רשומות manifest והעלאת bundles חדשים ל-CDN.

איך אנו מבטיחים סטרימינג יציב של נכסים

הניסיון המוסמך שלנו כולל הגדרת מערכות לפרויקטים עם למעלה ממיליון התקנות. אנו מבטיחים שהתצורה עוברת בדיקות עומס: 1000 לקוחות במקביל עם ירידה של לא יותר מ-5% תחת 50% אובדן מנות. זה עוקב אחר ההמלצות הרשמיות של Unity עבור AssetBundles.

יישום בצד הלקוח

ב-Unity—UnityWebRequestAssetBundle.GetAssetBundle(url, cachedVersion, crc). אנו לוקחים cachedVersion מה-manifest. crc מספק בדיקת שלמות נוספת (אופציונלי אם TLS מוגדר כראוי).

אנו בונים טעינה דרך תור עדיפויות: נכסים לסצנה הנוכחית—עדיפות גבוהה, נכסים לסצנה הבאה—עדיפות בינונית, תוכן דקורטיבי—נמוכה. בקשות מקבילות מקסימליות: 4–6 (המגבלה של HTTP/1.1; עם HTTP/2 אפשר יותר, אבל Unity WebRequest לא תמיד מבצע multiplexing נכון).

עבור Quest (אנדרואיד), מגבלת Application.temporaryCachePath חשובה—אנו ממליצים על לא יותר מ-1 ג'יגה-בייט עבור מטמון ה-bundles, אחרת מערכת ההפעלה מנקה באגרסיביות. אנו מיישמים CacheEvictionPolicy עם LRU: כאשר המגבלה מושגת, הסר bundles בשימוש נדיר דרך Caching.ClearCachedVersion().

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

• ביקורת של סכמת טעינת הנכסים הנוכחית וארכיטקטורת הבנייה.
• הגדרת שרת המקור (Nginx/Caddy) עם כותרות נכונות ומדיניות מטמון.
• הגדרת CDN (Cloudflare, AWS CloudFront) עם חוקים עבור bundles עם גרסאות.
• אינטגרציה של AssetBundle Manifest וסקריפטים אוטומטיים לבנייה (Addressables, צינור CI).
• פיתוח טוען לקוח עם תור, עדיפויות ופינוי מטמון.
• בדיקות עומס המדמות עומסי שיא.
• תיעוד פריסה ותפעול.
• הדרכת צוות: פעולות בסיסיות, ניטור, התראות.
• תמיכה בשלב ההשקה (שבועיים).

לוחות זמנים משוערים

העלות מחושבת לאחר ניתוח נפח התוכן ודרישות הזמינות.

קבעו פגישת ייעוץ—נעזור לכם לקבוע את הארכיטקטורה האופטימלית לפרויקט שלכם. צרו קשר כדי לדון בפרטים.