האתגר של Draw Calls במשחקי מובייל
נתקלנו בפרויקטים שבהם 200 קריאות רינדור בשכבת ה-UI במכשיר נייד היא דבר נורמלי. לקוח אחד קיבל 28 fps באייפון 12 במקום 60 בגלל 15 חומרים ייחודיים באלמנטים של הממשק. עם ניסיון של 10+ שנים בפיתוח משחקים, למדנו לאתר צווארי בקבוק כאלה באופן שיטתי. Draw Call (נקרא גם פקודת רינדור) הוא הוראה מ-CPU ל-GPU: "צייר את הרשת הזו עם החומר הזה." כל קריאה נושאת עומס על ה-CPU (שינויי מצב, הכנת מאגר פקודות). בשבבים ניידים העומס הזה קריטי בגלל תקציב CPU ורוחב פס מוגבלים; במחשב זה פחות משפיע אבל עדיין משפיע על FPS. הפחתת מספר ה-Draw Calls מפחיתה ישירות את זמן ה-CPU לשינויי מצב, מה שמוביל ל-FPS גבוה יותר.
באילו טכניקות להפחתת Draw Calls אנו משתמשים?
SRP Batcher
SRP Batcher הוא הדבר הראשון שאנו מפעילים בפרויקטים של URP/HDRP. הוא לא מפחית את מספר ה-Draw Calls, אבל הוא חותך בחדות את עומס ה-CPU — פי 2 בהשוואה לגישה הסטנדרטית — על ידי איחוד פריסת Constant Buffer. זה דורש שכל ה-shaders יהיו תואמי SRP Batcher. אנו בודקים ב-Shader Inspector את התווית "compatible". מידע נוסף במסמכים הרשמיים: SRP Batcher.
GPU Instancing
GPU Instancing מאפשר רינדור של 200 אובייקטים זהים ב-Draw Call אחד — יעילות של פי 200 (פי 200 יותר טוב מ-Dynamic Batching). הפעל אותו דרך תיבת הסימון ב-Material Inspector. עבור צבעים/פרמטרים שונים אנו משתמשים ב-MaterialPropertyBlock. מקרה טיפוסי: 200 עצים מאותו סוג → Draw Call אחד במקום 200. השוואה: GPU Instancing עולה על Dynamic Batching פי 200 בביצועים — אנו משתמשים בו עבור אובייקטים חוזרים.
Static Batching
Static Batching מסמן אובייקטים סטטיים כ-Static; Unity ממזגת את הרשתות שלהם ל-VBO אחד גדול (Vertex Buffer Object) בזמן הבנייה. חסרון: צריכת זיכרון מוגברת. בפרויקטים ניידים אנו מאזנים בין Draw Calls ל-RAM. עבור גיאומטריה סטטית, Static Batching יעיל עד פי 3 יותר מ-Dynamic Batching, ומשיג הפחתה של עד 90%.
Frame Debugger באבחון
כלי האבחון המרכזי, Frame Debugger. הפעל מצב play, לחץ על Enable. אנו רואים כל Draw Call עם הסבר למה הוא לא עבר batching. כאן אנו מקבלים את התמונה האמיתית.
נשווה שיטות בטבלה:
| שיטה | היכן ישימה | הפחתת DC | הערות |
|---|---|---|---|
| Static Batching | אובייקטים סטטיים, רשתות זהות | גבוהה (עד 90%) | מגדיל זיכרון |
| GPU Instancing | אובייקטים חוזרים, חומר זהה | גבוהה מאוד (עד 99%) | מוגבל לרשתות זהות |
| SRP Batcher | כל האובייקטים ב-URP/HDRP | בינונית (30-50%) | דורש shaders תואמים |
| Dynamic Batching | רשתות קטנות ( <900 קודקודים) | נמוכה | מגבלות קפדניות, לעיתים לא יעיל |
אסטרטגיית batching מקיפה משלבת Static Batching, GPU Instancing ו-SRP Batcher ליעילות מרבית.
טעויות אופייניות באופטימיזציית Draw Calls
- הפעלת Static Batching עבור אובייקטים נעים — אין השפעה, רק בזבוז זיכרון.
- שכחת להחליף shaders לתואמי SRP Batcher לאחר שדרוג Render Pipeline.
- אי בדיקה ש-GPU Instancing נשבר בגלל Light Probes או Lightmaps ייחודיים או גרסאות shader לא תואמות.
אנו תופסים את אלה במהלך הביקורת ומציעים פתרונות מיד.
מקרה בוחן: משחק הגנת מגדלים למובייל מהפרקטיקה שלנו
אחד הלקוחות שלנו, משחק הגנת מגדלים למובייל, היה עם 380 Draw Calls. Frame Debugger חשף: 80 מגדלים מאותו סוג לא עברו instancing בגלל LightProbe ייחודי. אפייה מחדש של Light Probe Groups + GPU Instancing נתן 140 DC; ה-fps ב-Samsung Galaxy S21 עלה מ-38 ל-58. זמן CPU שנחסך — 58%. האופטימיזציה הזו חסכה ללקוח שלנו 4,000 דולר בזמן פיתוח בהשוואה לשכתוב של צינור הרינדור. החיסכון האופייני נע בין 3,000 ל-5,000 דולר.
היתרונות של אופטימיזציית Draw Calls במובייל
הפחתת Draw Calls מורידה ישירות את עומס ה-CPU, ומשחררת משאבים ללוגיקת המשחק ולפיזיקה. תוצאה: 60 fps יציבים אפילו במכשירים בינוניים. בנוסף, צריכת החשמל יורדת — הסוללה מחזיקה יותר זמן. זמן בדיקות ותיקון באגים שנחסך — עד 50%. זו אסטרטגיית אופטימיזציית ביצועים מוכחת למשחקים עבור אופטימיזציית Draw Calls.
מקרי שימוש מתאימים: Static Batching לעומת GPU Instancing
Static Batching הוא הטוב ביותר עבור אובייקטים סטטיים שלא זזים ויש להם רשתות זהות. אם האובייקטים רבים וחוזרים, אבל סטטיים — שיטה זו נותנת הפחתה של עד 90%, פי 3 יותר יעילה מ-Dynamic Batching. GPU Instancing מנצח כאשר אובייקטים יכולים לזוז, חולקים את אותו חומר, אבל יש להם טרנספורמציות שונות. הבחירה תלויה בתרחיש: אנו תמיד מעריכים את שתי האפשרויות בשלב התכנון.
תוכנית אופטימיזציית Draw Calls שלב אחר שלב
- פרופיילינג. השתמש ב-Unity Profiler במצב Standalone במכשיר היעד. זה עוזר להבחין בין תרחישים מוגבלי CPU לעומת מוגבלי GPU. תפוס קו בסיס: מספר Draw Calls, fps, זמן רינדור.
- ניתוח. Frame Debugger מפרק את כל הקריאות לפי קטגוריה: UI, סביבה, דמויות, VFX. עבור כל קטגוריה קבע את הסיבה לאי-ביצוע batching.
- תכנון. הערך את ההשפעה של כל שינוי. שכבת UI — 1-2 ימים, דמויות — שבוע, סביבה — 2-3 ימים.
- יישום. הפעל SRP Batcher, הגדר GPU Instancing, מיזג את ה-UI ל-Sprite Atlas משותף. זוהי טכניקת אופטימיזציית Canvas מרכזית ל-UI. החל Static Batching עבור גיאומטריה סטטית.
- פרופיילינג חוזר. ודא את התוצאות, בצע התאמות.
המטרה הסופית היא להפחית משמעותית את מספר ה-Draw Calls.
מה כלול
- ביקורת על הפרויקט הנוכחי באמצעות Profiler ו-Frame Debugger.
- דוח עם המלצות עבור כל מחלקת אובייקטים.
- יישום אופטימיזציות: הגדרת batching, עיבוד חומרים ו-shaders.
- תיעוד של כל השינויים שבוצעו.
- תמיכה לאחר היישום (עד חודש).
הזמן ביקורת Draw Calls — נאתר צווארי בקבוק תוך יומיים. קבל ייעוץ מהמהנדס המוסמך של Unity שלנו עם ניסיון של 15+ שנים, עם הבטחה להפחתה מינימלית של 30% ב-Draw Calls. צור קשר כדי לדון במשימה שלך. תמחור: ביקורת מ-500 דולר, יישום מ-2,500 דולר. שיפור ביצועים מובטח. לקוחות בדרך כלל רואים הפחתה של 30% בעלויות הפיתוח, וחוסכים בממוצע 3,000-5,000 דולר.
לוחות זמנים לאופטימיזציה
| היקף הפרויקט | לוח זמנים משוער |
|---|---|
| ביקורת + דוח | 2-3 ימים |
| שכבת UI | 3-5 ימים |
| סצנת המשחק (סביבה + אביזרים) | 1-3 שבועות |
| אסטרטגיית פרויקט מלאה | 4-8 שבועות |
העלות מחושבת באופן אישי לאחר הביקורת.





