אופטימיזציה של פריסת ממשק Unity UI (uGUI) למשחקים

Unity UI (uGUI) פריסת ממשק למשחקים

אתה פותח מלאי במכשיר נייד, וה-FPS צונח ב-15%. Frame Debugger מציג 214 קריאות ציור למסך אחד. נשמע מוכר? אנחנו נתקלים בזה באופן קבוע ומתקנים את זה תוך שבוע. Unity UI (uGUI) הוא חזק, אבל הביצועים שלו נקבעים במהלך ארכיטקטורת ה-Canvas, לא לפי מספר האלמנטים. ב-5 שנים, ייעלנו UI ביותר מ-50 פרויקטים — מאינדי ועד AAA. נשתף איך להימנע מטעויות נפוצות.

מדריך אופטימיזציה של Unity UI מסביר את היסודות: Canvas מקבץ אלמנטים של UI אם הם חולקים חומר וטקסטורה מ-Sprite Atlas.

למה uGUI יכול לגרום ל-Lag?

Canvas מקבץ אלמנטים של UI לקבוצה עם קריאת ציור אחת. קיבוץ דורש אותו חומר, אותה טקסטורה (Sprite Atlas), וללא חפיפות עם אלמנטים זרים. שלושה דברים שוברים קיבוץ:

1. ערבוב טקסטורות. אייקון מ-Atlas A, כפתור מ-Atlas B, טקסט דרך TextMeshPro — כל מעבר טקסטורה יוצר קריאת ציור חדשה. פתרון: כל האלמנטים הוויזואליים של מסך אחד ב-Sprite Atlas אחד. טקסטים של TextMeshPro — קבוצה נפרדת אבל לפחות אחת.
2. Mask מקונן. כל Mask מוסיף 2 מעברי stencil ושובר את הקיבוץ מבפנים ומבחוץ. עבור אלמנטים סטטיים עם פינות חתוכות, קל יותר לצייר טקסטורה עם הצורה הרצויה במקום להשתמש ב-Mask.
3. סדר Sibling Index שגוי. אם Image A ו-B חופפים ומגיעים מאותו atlas, הקיבוץ עדיין יכול להישבר בגלל סדר z. קיבוץ ב-Unity עובד רק אם אין חפיפות בין אלמנטים מ-atlases שונים.

אבחון: Frame Debugger → Enable → חפש את קטע ה-UI. מספר טוב ל-HUD הוא 5-15 קריאות ציור. מעל 50 — סיבה לאופטימיזציה.

איך אנחנו מפחיתים קריאות ציור: מקרה מהפרקטיקה שלנו

פרויקט הגיע עם תלונה על ירידה של 15% ב-FPS בעת פתיחת מלאי. Frame Debugger הראה 214 קריאות ציור עבור 48 משבצות. כל משבצת הייתה Prefab נפרד עם אייקון מ-PNG (לא atlas), כמות של TextMeshPro, מסגרת רקע מ-PNG אחר, ורכיב Outline (מייצר mesh נוסף).

פתרון: ארזנו את כל האייקונים לשני Sprite Atlases (פריטים ו-UI chrome בנפרד), החלפנו TextMeshPro Outline ב-SDF Outline בחומר TMP, הוספנו Virtual Scroll List (מבוסס pool) לרשת הפריטים. תוצאה: 22 קריאות ציור על אותו מסך. ה-FPS חזר לנורמלי. יתרון: עד 40% הפחתה בזמן רינדור. אנחנו מבטיחים גישה דומה ל-UI שלך.

מה כוללת העבודה שלנו על פריסת UI

• ביקורת UI נוכחית: Frame Debugger, Profiler, ניתוח ארכיטקטורת Canvas.
• אופטימיזציית Atlas: חיתוך, מיזוג, הגדרת Fallback Fonts.
• פריסת RectTransform עם קשירת עוגנים להתאמת רזולוציה.
• הגדרת Canvas Scaler לפלטפורמות יעד.
• הטמעת גלילה וירטואלית לרשימות דינמיות (ScrollView עם pool).
• שילוב אנימציות (DoTween, Animator) ללא אובדן ביצועים.
• תיעוד ארכיטקטורת UI וסגנון קוד.
• הדרכת צוות על קיבוץ ופרופיילינג.

RectTransform: כללים שחוסכים כאב ראש

Anchors ו-Pivot הם לא אותו דבר. Anchor מגדיר את נקודת החיבור להורה, Pivot מגדיר את מרכז הסיבוב והקנה מידה. טעות אופיינית: עוגנים מוגדרים לפינה שמאלית-עליונה, אבל האלמנט צריך להיות ממורכז. בשינוי רזולוציה, האלמנט נסחף. תיקון: anchor → center/middle, מיקום מעוגן = (0, 0).

להתאמה, אנחנו משתמשים ב-Canvas Scaler עם Scale With Screen Size. Reference Resolution 1920×1080 ו-Match = 0.5 הוא בסיס עובד. למובייל, Match = 0.8–1.0 (העדף Height) מונע מתיחת UI על מסכים צרים.

ContentSizeFitter + VerticalLayoutGroup נוחים לרשימות דינמיות, אבל כל שינוי גורם ל-Layout Rebuild. עבור ScrollView עם מאות אלמנטים, השתמש ב-Virtual Scroll List: שמור רק את הנראים בזיכרון — עד 10-15 אובייקטים פעילים במקום מאות.

איך להגדיר Canvas Scaler למכשירים ניידים?

למובייל עם יחסי גובה-רוחב שונים, הגדר Match ל-0.8–1.0 לטובת Height. אחרת, באייפון עם 19.5:9, ה-UI נמתח אופקית. אנחנו גם מגדירים Reference Resolution לרזולוציית היעד — בדרך כלל 750×1334 (iPhone 6/7/8) עם מצב Scale With Screen Size. פרטים בתיעוד Canvas Scaler הרשמי.

TextMeshPro: גופנים וביצועים

TextMeshPro הוא התקן לטקסט. הוא משתמש ברינדור SDF, שמבטיח חדות בכל קנה מידה. ללוקליזציה בקירילית או CJK, הגדר Fallback Font Asset: גופן ראשי ללטינית עם Fallback לשפה הנדרשת. TextMeshPro טוען אוטומטית גליפים חסרים, ושומר טקסט ב-1-2 קריאות ציור.

Atlas Population Mode: Dynamic מוסיף גליפים במפגש — טוב לפיתוח, רע לשחרור (micro-stutters ברינדור ראשון). לייצור, השתמש ב-Static עם atlas מלא מראש דרך Font Asset Creator.

תהליך העבודה