מדוע משחק מובייל לא שומר על 60 פריימים לשנייה יציבים
צניחות פריימים כמעט אף פעם לא קשורות ל"חומרה" — הן תוצאה של האופן שבו המשחק משתמש בצינור הגרפי.
אופטימיזציה של רינדור במשחק מובייל מתחילה באיתור צוואר הבקבוק: אותה צניחה מ-60 ל-40 פריימים לשנייה נגרמת מציור חוזר של הממשק מעל הסצנה, מקריאות ציור מיותרות לכל אובייקט, מדליפות זיכרון לטקסטורות ומאפקטים כבדים כמו שקיפות ועיבוד-בתר. כל עוד הסיבה לא מאותרת, כל תיקון הוא ניחוש.
ציור חוזר של הממשק הוא האשם הנסתר השכיח ביותר. כל רכיב HUD שמתעדכן בלולאת המשחק מאלץ בנייה מחדש של שכבה מעל הסצנה, והעלות גדלה באופן ליניארי עם מספר רכיבים כאלה.
קריאות ציור מיותרות יוצרות אפקט דומה: מאות אובייקטים נפרדים במקום מאוחדים לאצוות מעמיסים על המעבד יותר מאשר הגאומטריה עצמה. דליפות זיכרון לטקסטורות ולמאגרים לא מתגלות מיד — בדקות הראשונות המשחק שומר על פריימים, ובאמצע הסשן מתחילות קפיצות ופריקה כפויה.
מנקודת המבט של השחקן זה נראה צפוי: התחממות המכשיר, throttling לאחר 10-15 דקות, צניחות בסצנות דינמיות ותלונות על "מתקע לי בטלפון". אנו מפרקים כיצד כל אחד מצווארי הבקבוק הללו נסגר ברמת הרינדור, ולא באמצעים מאולתרים בלוגיקת המשחק.
מה נותנת אופטימיזציית רינדור של משחק מובייל
אופטימיזציית רינדור היא לא "להאיץ את התמונה", אלא להסיר עבודה מיותרת מהנתיב הקריטי של הפריים. כאשר תקציב הפריים נשמר, המנוע מספיק לרנדר את הסצנה ולהכין את הפריים הבא, במקום להדביק את מה שהוחמץ.
בפועל זה נראה כך: במקום צניחות בסצנות מורכבות — גרף יציב, שבו זמן הפריים נשמר בגבולות שנקבעים על ידי קצב רענון המסך.
הדבר הראשון שהשחקן רואה — קצב פריימים יציב וחלקות אנימציה צפויה. הדבר השני שהוא מרגיש — זמן תגובת השליטה: הלחיצה מעובדת באותו פריים, ולא אחרי שניים-שלושה. זה משפיע ישירות על שימור השחקנים — בסצנות דינמיות השהיה של כמה פריימים נתפסת כ"המשחק נתקע", גם אם המדד הממוצע גבוה.
הבא בתור — צריכת האנרגיה של המשחק. כאשר הרינדור לא עושה עבודה מיותרת, המכשיר מתחמם פחות ומפחית את התדרים לעתים רחוקות יותר תחת עומס. זה מסיר את הסיבה העיקרית לביצועים "צפים": הטלפון לא נכנס ל-throttling אחרי עשר דקות משחק, והפריימים לא מתחילים לצנוח לקראת אמצע הסשן.
והאחרון בסדר, אך לא בחשיבות — תמיכה במכשירים חלשים. רינדור מאופטם מרחיב את רשימת הדגמים שעליהם המשחק רץ בנוחות, בלי בנייה מצומצמת נפרדת לכל סוג.
אנחנו עובדים על Unity ומבצעים פרופיילינג לסצנות אמיתיות על מכשירי היעד, ולא רק בעורך — ולכן האפקט של האופטימיזציה נראה במדידות חיות, ולא בתיאוריה.
גישות לרינדור: מה לבחור בהתאם למשימה
הבחירה של צינור הרינדור קובעת את תקרת הביצועים של כל המשחק: החלפתו באמצע הפרויקט יקרה יותר מאשר להטמיע את הנכון מלכתחילה. צינור ישיר מצייר כל אובייקט בתורו — צפוי וזול בסצנה עם מאה אובייקטים, אך בסצנה צפופה הוא נתקל במספר קריאות הציור.
רינדור באצוות מאחד אובייקטים מאותו סוג לקריאה אחת ומסיר את המגבלה הזו, ורינדור נדחה מעביר את חישוב התאורה למעבר נפרד ושומר על פריים יציב במקום שיש הרבה מקורות אור.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| צינור ישיר | סצנות פשוטות, 2D, אב-טיפוס מוקדם | מספר קריאות הציור גדל, ירידות ביצועים בסצנות צפופות |
| רינדור באצוות | הרבה אובייקטים מאותו סוג, סצנות 3D למובייל | דורש חומרים וטקסטורות משותפים, מורכב יותר עם שקיפות |
| רינדור נדחה | הרבה תאורה דינמית, סצנות מורכבות | עומס גבוה יותר על הזיכרון, חלש יותר במכשירים חלשים |
רמת הפירוט פועלת מעל כל צינור: אובייקטים רחוקים מקבלים גאומטריה וטקסטורות מפושטות, וזה מפנה את תקציב הפריים למה שהשחקן רואה מקרוב.
מגבלות הרינדור במובייל נקבעות לא רק על ידי השבב, אלא גם על ידי throttling תרמי — 60 פריימים יציבים חשובים יותר מ-120 שיאיים שמחזיקים רק בדקות הראשונות.
מפרקים כיצד להתאים צינור לסצנה מסוימת ולשמור על קצב פריימים ללא ירידות.
איך עוברת אופטימיזציה של רינדור במשחק מובייל
אופטימיזציה של רינדור היא לא "לתקן שיידרים וזה נהיה מהיר יותר", אלא מחזור: מדידה, איתור צוואר הבקבוק, תיקון, מדידה חוזרת על מכשיר חי. להלן — איך עוברת עבודה כזו אצל המהנדסים שלנו.
- אוספים מדדים בסיסיים. מודדים קצב פריימים וזמן רינדור פריים על מכשירי ייחוס — ממכשירים תקציביים ועד לדגלי. מתעדים לא את המדד הממוצע, אלא את ההתפלגות: ירידות באחוזון ה-90 מורגשות על ידי השחקן חזק יותר מקצב פריימים ממוצע ואחיד.
- מבצעים פרופיילינג לרינדור. מפרקים את הפריים לשלבים: הכנת סצנה, רינדור גיאומטריה, עבודה עם שקיפות, פוסט-עיבוד. הפרופיילר מראה איזה שלב אוכל את תקציב הפריים — ומשם עובדים ממוקד, ולא "מייעלים הכל".
- מחפשים צווארי בקבוק. סיבות טיפוסיות לירידות: קריאות רינדור מיותרות, רינדור חוזר של פיקסלים זה על גבי זה, שיידרים כבדים, מקורות אור מיותרים, טקסטורות לא אופטימליות. כל אחד מאשרים במדידה, ולא בניחוש.
- מתקנים שיידרים וחומרים. מפשטים חישובים בשיידרים, מסירים מעברים מיותרים, מאחדים חומרים כדי לצמצם את מספר קריאות הרינדור. המטרה — להכניס את הפריים בתקציב בקצב היעד.
- בודקים על מכשירים. מריצים את הבילד על פארק מכשירים אמיתי: שבבים שונים, כמויות זיכרון, גרסאות מערכת. אמולטור לא יציג ת'רמינל ת'רוטלינג ודגרדציה אמיתית — רק הרצה חיה.
- חוזרים על המחזור. לאחר התיקונים שוב אוספים מדדים ומשווים לבסיסיים. אם הירידות נשארו — חוזרים לפרופיילינג, עד שהתפלגות הפריימים תהיה אחידה.
- מעבירים את התוצאה. מוסרים מדידות לפני/אחרי, רשימת תיקונים והמלצות, כדי שהצוות יוכל לתחזק את הביצועים בעת הוספת תוכן חדש.
מחזור כזה סוגר את המשימה לא באופן חד-פעמי, אלא כתהליך: כל תיקון מאושר במדידה, ולא בתחושה ש"כאילו נהיה חלק יותר".
מה הלקוח מקבל בסיום העבודה
בסיום אופטימיזציית הרינדור הלקוח מקבל לא דוח, אלא ערכה עובדת שאיתה הפרויקט ממשיך לחיות ללא מעורבותנו. להלן מה שנשאר בדיוק במאגר הקוד ובתיעוד.
- פרופילי איכות גרפית — סט תצורות הניתנות להחלפה מ"חיסכון באנרגיה" ועד "מקסימום": טווח רינדור, צפיפות צללים, רמת החלקה, רזולוציית רינדור. כל פרופיל משויך למחלקת מכשיר, כך שבמכשירים חלשים המשחק לא צונח בירידות ביצועים, ובמכשירי דגל הוא לא נראה מקוצץ.
- מפת סצנה — מפה של מה ומתי נכנס לפריים: גאומטריה סטטית, אובייקטים דינמיים, אפקטים, שכבות ממשק. לפיה ניתן לראות אילו צמתים אפשר לכבות או להחליף בגרסאות מפושטות מבלי לשבור את התמונה.
- מדיניויות איכות — כללים שלפיהם המנוע עצמו מפחית עומס: סדרי עדיפויות רינדור, תקציבים לפריים, התנהגות בעת התחממות ופריקת סוללה. המשחק שומר על 60 פריימים/שנייה כיעד ולא נכנס להתחממות בסשנים ארוכים.
- תיעוד רינדור — תיאור הצינור, נקודות המדידה וכיצד כל הגדרה משפיעה על קצב הפריימים. מהנדס שיגיע לפרויקט מאוחר יותר יסתדר ללא פניות אלינו.
- נוהל בדיקה — רשימת תיוג לקבלה: על אילו מכשירים וסצנות אנחנו מודדים, אילו ספים נחשבים לנורמה, מה מתעדים בדוח. רגרסיה בפריימים נתפסת לפני השחרור, ולא בביקורות.
- הגדרות גרפיות מוגדרות בתפריט — מתגים מובנים למשתמש עם תוויות כנות, כדי שהוא עצמו יבחר את האיזון בין התמונה לזמן העבודה על הסוללה.
- סקריפטים למדידות — הרצה אוטומטית של סצנות עם רישום קצב הפריימים וזמן הפריים, כדי שניתן יהיה להשוות כל בנייה לקודמתה.
את הערכה אנו מוסרים עם פירוט: מראים היכן היו צווארי בקבוק, מה שינינו וכיצד לבדוק את התוצאה במו ידיכם. תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: איך המשחק הפסיק לאבד פריימים במכשירים בינוניים
הפרויקט — משחק מזדמן עם סצנה איזומטרית ועשרות אובייקטים מונפשים. בפלח המכשירים הבינוניים קצב הפריימים צנח ל-40–45, ובסצנות המוניות — ל-30, עם פספוסים קבועים: שיעור הפריימים שרונדרו מעבר לתקציב הגיע עד לרבע. השחקנים התלוננו על שליטה "מקוטעת", ולא על גרפיקה — הצניחות פגעו בהיענות הקלט.
התחלנו בפרופיילינג על מכשירים אמיתיים מהפלח הבינוני, ולא על מכשירי דגל: מדדנו זמן פריים, התפלגות הפספוסים ועומס הרינדור לפי פריימים. התברר שצוואר הבקבוק אינו מספר האובייקטים, אלא קריאות רינדור מיותרות ורינדור מחדש של הרקע הסטטי בכל פריים.
ארזנו את הסצנה לאצוות לפי חומרים, הוצאנו את הסטטי לשכבה נפרדת, העברנו את האנימציות לאטלס משותף, וניתקנו את הפיזיקה והלוגיקה מקצב הרינדור — כעת הן מחושבות בצעד קבוע ואינן "צפות" בעת צניחות.
Unity סיפק כלים לרינדור באצוות ולפרופיילינג, אבל מה שהכריע לא היה הפלטפורמה, אלא סדר העבודה: קודם מדידה, אחר כך שינוי, ואחר כך מדידה חוזרת על אותה קבוצת מכשירים.
לאחר האופטימיזציה קצב הפריימים במכשירים בינוניים הגיע ל-58–60 יציבים בסצנות המוניות, שיעור הפריימים שהוחמצו ירד מרבע לאחוזים בודדים, והפער בין הפריים הטוב ביותר לגרוע ביותר הצטמצם פי כמה — הרינדור הפסיק "להתכווץ". בפלח החלש שמרו על 45–50 ללא פישוטים ויזואליים שהשחקן היה מבחין בהם.
בנפרד בדקנו את יציבות הרינדור תחת עומס: סשנים ממושכים, התחממות, תהליכי רקע. הצניחות שהצטברו בעבר עד הדקה העשירית של המשחק נעלמו — זמן הפריים נשמר אחיד לאורך כל הסשן.
במה שונה רינדור מושהה מרינדור ישיר?
רינדור ישיר שולח פקודות ציור למאיץ הגרפי מיד עם עדכון הסצנה במחזור הנוכחי. היישום עצמו מחליט מה ומתי לצייר, ושומר על שליטה מלאה בסדר הקריאות. הדבר מעניק השהיה מינימלית בין שינוי המצב להופעת התמונה — קריטי לתגובתיות שליטה בסצנות דינמיות, שבהן חשובה התגובה למגע בתוך מחזור אחד.
רינדור מושהה אוסף תחילה רשימת פקודות למאגר, ממיין ומקבץ אותן לפי חומר ומצב, ורק לאחר מכן שולח אותן במקבץ. הרווח — בצמצום החלפות מצבים ובמספר הקריאות: עצמים מאותו סוג מצוירים ברצף, והמאיץ מתבטל פחות בין החלפות טקסטורות ושיידרים. בסצנות עם מאות עצמים מאותו סוג זה מעלה באופן ניכר את ביצועי הרינדור ומייצב את זמן הפריים.
הבחירה בגישה תלויה בפרופיל הסצנה, ולא בשיטה ה"טובה ביותר". רינדור ישיר מנצח במקום שבו יש מעט עצמים, אך הם מחליפים מצב לעתים קרובות, או במקום שנדרשת השהיית קלט צפויה. רינדור מושהה — במקום שבו יש עצמים רבים, הם סטטיים מבחינת חומר וניתן לקבץ אותם ביעילות. הגרסה המשולבת נפוצה ביותר: ממשק המשתמש והאפקטים מצוירים ישירות, והרקע והעצמים ההמוניים — דרך המאגר.
גם המגבלות של השיטות מקבילות זו לזו. רינדור ישיר נתקל בתקרה של מספר הקריאות: ככל שיש יותר עצמים, כך עולה העומס על המעבד ולעתים קרובות יותר הפריים אינו נכנס לתקציב.
רינדור מושהה מוסיף זיכרון למאגר הפקודות והשהיה של פריים-שניים, וכן מסבך את העבודה עם שקיפות וסדר שכבות — מיון לפי מצב עלול להתנגש עם מיון לפי עומק.
בפועל לא קובעים את הגישה אחת ולתמיד: בוחרים אותה עבור סצנה מסוימת ומחליפים בין המצבים לפי הפרופיל שלה. תחילה מבצעים מדידות — היכן בדיוק מתבזבז זמן הפריים, על המעבד או על המאיץ, — ורק לאחר מכן מתאימים את השיטה.
כך אופטימיזציה של רינדור במשחק מובייל נשענת על נתונים ולא על הרגל, ושמירה על 60 פריימים יציבים הופכת למשימה ניתנת לניהול.
ספקות טכניים נפוצים לגבי אופטימיזציה של רינדור
לפני תחילת העבודה לקוחות שואלים את אותן שאלות: האם המשחק יישבר במכשירים ישנים, כמה זמן זה ייקח, מה יקרה לגיימפליי. להלן תשובות ישירות, בלי מילים כלליות.
האם האופטימיזציה לא תשבור את הרינדור במכשירים חלשים?
לא, אם בונים אותה על פרופילי איכות ולא על פריסט אחיד. אנחנו מבצעים מדידות על מכשירים אמיתיים מהקהל שלכם, קובעים תקציב פריים לכל מחלקה ומפצלים את ההגדרות: במקום אחד מורידים את צפיפות החלקיקים ואת רזולוציית הצללים, במקום אחר מחליפים חומר לחומר זול יותר.
מכשירים חלשים מקבלים פריים יציב בלי ירידות, מכשירי דגל — תמונה מלאה. תאימות נבדקת לפני השחרור, ולא אחרי תלונות.
כמה זמן לוקחת אופטימיזציה של רינדור?
תלוי בהיקף הסצנה ובמספר הפלטפורמות. אודיט ראשוני עם מדידות ותוכנית — כמה ימים, לאחר מכן איטרציות על צווארי בקבוק. אם הבעיה היא באפקט כבד אחד, התיקונים לוקחים ימים; אם כל צינור הרינדור נבנה מחדש — שבועות. מועד מדויק נקבל לאחר מדידות, ולא «בעין».
מהם הסיכונים של השינויים והאם אפשר לחזור אחורה?
הסיכון העיקרי — ארטיפקטים ויזואליים בעת הורדה אגרסיבית של האיכות. לכן כל שינוי הולך בענף נפרד עם מדידה לפני ואחרי, ולא בקומיט גדול אחד. כל שלב ניתן לחזור ממנו בלי לאבד שיפורים קודמים, ואנחנו שומרים בילדים לדוגמה להשוואה.
האם האופטימיזציה תשנה את הגיימפליי או את התמונה?
המטרה — לשמר את חוויית המשחק תוך הסרת עומס מיותר. אנחנו לא חותכים את מה שהשחקן מבחין בו: אפקטים מרכזיים, קריאות הסצנה, היענות השליטה נשארים. מסירים עלויות נסתרות — קריאות רינדור מיותרות, חומרים כפולים, גיאומטריה בלתי נראית. ויזואלית המשחק נראה אותו דבר, אבל רץ חלק יותר.
האם צריך לכתוב מחדש את הפרויקט לפלטפורמה חדשה?
בדרך כלל לא. אופטימיזציה של רינדור — זו עבודה ממוקדת עם הקוד וההגדרות הקיימים, ולא כתיבה מחדש. אנחנו מתאימים את הצינור לארכיטקטורה הנוכחית, לכן מחזור השחרור לא מתארך, והצוות ממשיך להוציא עדכונים במקביל.
אם נותרו ספקות לגבי הפרויקט שלכם — תארו את המשימה, נחזור עם הערכה ותוכנית עבודה.
נדון במשימה שלך לאופטימיזציית רינדור
כדי לחזור עם הערכה ותוכנית אופטימיזציה, אנחנו צריכים לא בקשה מופשטת כמו "המשחק מקרטע", אלא פרוסה של מצב הרינדור הנוכחי. ככל שהנתונים הראשוניים konkרטיים יותר, כך ההערכה למלאכה מדויקת יותר ומספר האיטרציות לתיאום קטן יותר.
מה לשלוח כדי להתחיל:
- פרופיל פריימים: הקלטה מפרופיילר על סצנה אופיינית — היכן בדיוק זמן הפריים צונח (רינדור, לוגיקה, פיזיקה, טעינת משאבים).
- מכשירי יעד: דגמים שעליהם האפליקציה חייבת לשמור על פריימים יציבים, והמדדים הנוכחיים עליהם.
- רשימת מקומות כבדים: סצנות עם מספר האובייקטים המקסימלי, אפקטים, שקיפות, תאורה דינמית.
- קוד מקור והרשאות גישה: מאגר קוד, ענף, בילד, גישה למערכות אנליטיקה ודוחות קריסות.
- אילוצים: לוחות זמנים, פלטפורמות, דרישות תאימות למכשירים ישנים.
מכאן עובדים בשלבים. תחילה משחזרים את הצניחות על סטנד ומתעדים מדדי בסיס — בלי זה כל אופטימיזציה הופכת לניחוש. לאחר מכן מפרקים את צווארי הבקבוק: באצ'ינג של קריאות רינדור, שימוש חוזר במשאבים, פריקת ה-thread הראשי, רמות פירוט. אחר כך — תוכנית אופטימיזציה עם עדיפויות: מה נותן אפקט מיידי, ומה דורש עיבוד מחדש של סצנות.
מתאמים את התוכנית, מתחילים עבודה באיטרציות קצרות עם מדידה אחרי כל שלב. בתוצאה — לא רק רינדור מואץ, אלא גם מסירת הפרויקט: תיעוד השינויים, כללים לצוות, כדי שהצניחות לא יחזרו עם התוכן הבא. תאר את המשימה ושלח את הנתונים הראשוניים — נחזור עם הערכה ותוכנית.