אנימציות Spring ב-iOS: היכן הממשק מאבד את ההיענות
היענות הממשק נשברת לא במסכים "כבדים", אלא במחוות קטנות: החלקת כרטיס, סגירת מגירה, גרירת פריט ברשימה. המשתמש מרים את האצבע באמצע התנועה, והאלמנט או קופא, או נטרק לנקודת הסיום בעקומה לינארית — והמחווה מפסיקה להרגיש פיזית.
הסיבה היא שמעבר לינארי מחשב זמן, ולא מהירות ואינרציה: הוא אינו יודע באיזו מהירות האצבע נעה ברגע השחרור, ואינו יודע להמשיך את התנועה מהמיקום הנוכחי.
אנימציות Spring ב-iOS פותרות זאת אחרת — המעבר מתואר כמערכת תנודה עם קשיחות, ריסון ומהירות התחלתית. כאשר המשתמש מרים את האצבע, האנימציה קולטת את מהירות המחווה בפועל ומביאה את האלמנט אל היעד בהאטה טבעית, ולא במשך זמן קבוע.
זוהי הפיזיקה של האנימציה: התנועה נשארת רציפה, גם אם המחווה הופסקה באמצע הדרך, ונגיעה חוזרת תופסת את האנימציה באופן מיידי ללא טלטלה.
החלקות המעברים נפגעת גם במקומות שבהם האנימציה מופעלת ידנית לפי טיימר. בזמן שמעבר אחד מתרחש, השני נכנס לתור או מתנגש בראשון — הממשק כאילו "נתקע" לשבריר שנייה, ואותו שבריר שנייה המשתמש קורא כהיעדר היענות.
מודל Spring מאפשר להרכיב ולקטוע אנימציות: יעד חדש פשוט משנה את נקודת שיווי המשקל, והמערכת עצמה מחשבת מחדש את המסלול מהמצב הנוכחי.
מקום נפרד תופסים המעברים בין מסכים ומצבי רשימה. Easing לינארי למרחקים ארוכים נראה מכני: ההתחלה והסיום חדים, האמצע "ריק". קפיץ נותן האצה בהתחלה ובלימה רכה בסוף, ולכן הממשק נתפס כמהיר יותר, אף שמשך המעבר בפועל לא השתנה.
מפרקים כיצד זה נסגר: היכן להפעיל את מודל Spring במקום עקומות לינאריות, כיצד לקשר אותו למהירות המחווה וכיצד לא לאבד היענות במכשירים חלשים.
מה נותנת מודל תנועה פיזיקלי בממשק
מודל תנועה פיזיקלי מתאר את הממשק לא באמצעות סט של פריימים מרכזיים, אלא באמצעות פרמטרים של המערכת: קשיחות, ריסון ומהירות התחלתית. בגלל זה אנימציות spring ב-iOS ממשיכות תנועה מהנקודה הנוכחית ברגע הנגיעה, ולא מתחילות מחדש מאפס.
עבור המשתמש זה נראה כמו תגובה ש"מקשיבה לאצבע": ניתן לקטוע swipe אחורה באמצע, למשוך בחזרה ולשחרר — הכרטיס ימשיך לפי אינרציה, בלי טלטלה ובלי המתנה לסיום האנימציה.
הערך המעשי מתבטא בשלושה דברים מדידים. הראשון — מהירות התגובה: הזמן עד לתגובה הנראית הראשונה למגע מתקצר לפריים אחד, כי האנימציה מתחילה מהמיקום בפועל של השכבה, ולא ממצב מחושב מראש.
השני — עמידות בפני קטיעות: מעברים בין מסכים, מגירות ופאנלים נפתחים משלימים נכון מכל נקודת ביניים, ולכן שיעור המצבים ה"תקועים", שבהם הממשק ממתין לסיום האנימציה, יורד כמעט לאפס.
השלישי — חלקות הגלילה: אינרציית הרשימה והמשיכות הקפיציות של הכותרות מחושבות לפי אותו מודל, ובגלל זה בפידים ארוכים נעלם חוסר התיאום בין האצבע לתוכן.
בנפרד כדאי לציין את ההשפעה על התפיסה. "הקרטוע" כמעט תמיד נולד לא מקצב פריימים נמוך, אלא מעימות בין שני מודלים: חלק מהאלמנטים חיים לפי עקומות ליניאריות, וחלק — לפי קפיצים.
כאשר כל הממשק מועבר למודל תנועה פיזיקלי, ההתנהגות הופכת לצפויה, ומספר הפניות מסוג "הכפתור לא נלחץ" או "המסך נתקע" יורד באופן ניכר — זה נראה בביקורות בחנויות ובבעומס על התמיכה.
המעבר לא דורש כתיבה מחדש של האפליקציה: פרמטרי הקפיצים מוציאים לשכבה משותפת של הגדרות, והמעברים הקיימים מתחברים אליה בהדרגה, מסך אחר מסך. בהמשך נפרק איך זה בנוי בקוד ומה בדיוק מוגדר.
מצבי מימוש: שכבה נייטיבית, פיזיקה ידנית, היברידי
בחירת המצב נקבעת לא לפי טעם, אלא לפי מספר המסכים שהאנימציה נוגעת בהם ועד כמה היא צריכה להתנהג בצורה צפויה תחת עומס. להלן שלוש גישות שביניהן באמת בוחרים בתחילת הפרויקט.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| שכבה נייטיבית של אנימציה | מעברים טיפוסיים, סוויפים, תגובה למגע; האנימציה חיה במסך אחד | קשה לקשר כמה מסכים לרצף אחד רציף; חלק מהפרמטרים אינם זמינים לכוונון עדין |
| פיזיקה ידנית | התנהגות לא סטנדרטית: אלמנטים מקושרים, תגובה למהירות המחווה, עצירה באמצע הדרך | כל המתמטיקה עלינו: כיוונון קשיחות, דעיכה, טיפול בהפסקות ובמקרי קצה |
| גישה היברידית | תרחישים ארוכים, שבהם חלק מהתנועה הוא מערכתי וחלק הוא авторский | המפגש בין שתי המודלים: צריך לסנכרן תזמונים, אחרת המעבר ביניהם נראה לעין |
השכבה הנייטיבית נותנת את התגובה הטובה ביותר במינימום קוד: המערכת עצמה מחשבת אינרציה ומתאמת אותה לקצב רענון המסך. המחיר — צפיות ההתנהגות במכשירים חלשים ושליטה מוגבלת באופן שבו התנועה מסתיימת.
פיזיקה ידנית נחוצה במקום שבו חשוב לשלוט בתחושה עצמה: עד כמה האלמנט חוזר בצורה אלסטית, כיצד הוא מגיב למחווה חדה, מה קורה במגע חוזר בזמן תנועה. כאן אנחנו מגדירים במפורש פרמטרים ומקבלים תוצאה זהה בכל המכשירים — אבל כל תרחיש דורש כיול נפרד.
הגישה ההיברידית היא לרוב גם הפשרה העובדת: השכבה המערכתית אחראית על המעברים בין המסכים, הפיזיקה המחברת — על אלמנטים אינטראקטיביים מרכזיים. המגבלה אחת — המפגש בין המודלים: אם התזמונים לא מיושרים, המשתמש חש בקרע בין החלק ה"מערכתי" ל"שלנו" של התנועה.
אנחנו קובעים את המצב לכל מסך בנפרד ומתארים את המגבלות לפני תחילת העבודה — כדי שבשלב הקבלה לא יתברר שהגישה שנבחרה לא עומדת בתרחיש הנדרש.
כיצד אנו מיישמים אנימציות פיזיקליות: שלבי העבודה
אנימציות פיזיקליות נשברות לא בשלב של "לצייר יפה", אלא בממשק עם נתונים אמיתיים וחומרה חלשה. לכן אנו בונים את התהליך כך שפרמטרי הקפיץ נבדקים בתרחישים חיים, ולא באב-טיפוס מבודד.
כיצד בנוי התהליך
- ביקורת אנימציות. אנו אוספים מלאי של כל המעברים באפליקציה: היכן משתמשים באינטרפולציה לינארית, היכן — במשך זמן קבוע, היכן האנימציה מופעלת ידנית לפי טיימר. אנו מסמנים מעברים שמתנגשים עם מחוות וגלילה, ומקומות שבהם הפריימים נופלים באנימציות מקבילות.
- כוונון פרמטרים. עבור כל מעבר אנו בוחרים קשיחות, ריסון ומהירות התחלתית — לא לפי העין, אלא בהתבסס על המסה של האלמנט וההקשר של המחווה. סגירה בהחלקה והופעה של חלון מודאלי דורשות פרופילים שונים: אחד צריך "להדביק" את האצבע, השני — לדעוך ללא רתיעה.
- חיבור למחוות. אנו קושרים את התקדמות האנימציה למיקום האצבע, כך שהשחרור תופס את המהירות הנוכחית, ולא מתחיל מאפס. זה מסיר את הפער בין תנועת היד לתגובת הממשק.
- בדיקה על מכשירים. אנו מריצים את המעברים על דגמים חלשים וחזקים, במצב כהה, כאשר מצב הפחתת התנועה מופעל ובקצבי רענון מסך שונים. אנו בוחנים לא רק את החלקות, אלא גם את ההתנהגות בעת קטיעת האנימציה באמצע.
- פרופיילינג. אנו מודדים את זמן הפריים בתרחישים העמוסים ביותר — פתיחת מסך עם טעינת נתונים, מעברים מקבילים, רשימות ארוכות. אנימציות שמפילות פריימים אנו מעבירים למאפיינים זולים יותר.
- עיצוב תקנון. אנו מתעדים הסכמות: אילו פרמטרים נחשבים לתקניים, כיצד מכנים פרופילים, מה לעשות בעת הוספת מעבר חדש.
- העברה לצוות הלקוח. אנו מקיימים סקירה עם המפתחים, מראים היכן לשנות פרמטרים וכיצד לבדוק את התוצאה, כדי שמכאן והלאה התיקונים יבוצעו בלעדינו.
מה נשאר לצוות הלקוח
לאחר ההעברה, ללקוח יש פרופילי אנימציות מכווננים, הקשורים למעברים ספציפיים, ותקנון עם ערכים תקניים. מפתח חדש מוסיף מסך ולוקח פרופיל מוכן במקום להמציא תזמונים מחדש — התנהגות הממשק נשארת צפויה ככל שהאפליקציה גדלה.
פרמטרים של קפיץ והתנהגות במסכים שונים
אנימציית קפיץ מתוארת על ידי שלושה פרמטרים: קשיחות, ריסון ומהירות התחלתית. הקשיחות קובעת באיזו מהירות המערכת שואפת למיקום היעד — ערכים גבוהים נותנים תגובה חדה, ערכים נמוכים הופכים את התנועה לצמיגית.
הריסון קובע כמה תנודות יישארו לאחר ההגעה ליעד: קפיץ מרוסן חסר "מצלצל" וחוצה את נקודת המנוחה, קפיץ מרוסן יתר זוחל אליה ללא אופי. המהירות ההתחלתית מקשרת את האנימציה למחווה — אם האצבע נעה במהירות, הממשק צריך להמשיך את התנועה באותה אנרגיה, אחרת נוצר פער בין הפעולה לתגובה.
תחושת הממשק מורכבת מיחס שלושת הגדלים הללו, ולא מכל אחד בנפרד. אותו צמד קשיחות-ריסון על מתג קל נקרא כאסוף, ואילו על פאנל במסך מלא — כעצבני: ככל שהמרחק ושטח האלמנט גדולים יותר, כך הקשיחות צריכה להיות נמוכה יותר כדי שהתנועה תישאר קריאה.
את המהירות ההתחלתית אין לקבע כקבוע — היא נלקחת מהמהירות הנוכחית של המחווה, אחרת החלקה מהירה והזזה איטית יורגשו אותו דבר, מה שמיד מסגיר אנימציה "מצוירת".
ההתנהגות במסכים שונים דורשת הגדרה נפרדת, ולא פריסט אחיד. במסכים קומפקטיים האלמנטים עוברים מרחק קטן יותר, וקשיחות גבוהה מתאימה שם — התנועה מספיקה להסתיים לפני שהמשתמש מעביר את המבט.
במסכים רחבים ובטאבלטים אותו ערך נותן טלטלה בהתחלה וזנב ארוך בסוף, לכן מורידים את הקשיחות ומעלים את הריסון קרוב יותר לקריטי, כדי שמשטחים גדולים ינועו בצורה חלקה וצפויה.
אנחנו מוציאים את פרמטרי הקפיצים לקונפיגורציה אחודה עם פריסטים לפי מחלקות אלמנטים ודריסה לפי גודל מסך, ולא מקודדים ערכים קשיחים במקומות הקריאה. כך עריכה אחת משנה את התנהגות המערכת כולה בעקביות, וחוסר סנכרון בין מסכים נתפס בשלב הבדיקה, ולא בביקורות של משתמשים.
מה הלקוח מקבל לידיו לאחר ההטמעה
לאחר הטמעת אנימציות פיזיות הפרויקט נשאר ניתן לניהול: מהנדס שיפתח אותו כעבור חצי שנה רואה לא קבועים מפוזרים ברחבי הקוד, אלא שכבת התנהגות אחידה. להלן — מה בדיוק אנו מעבירים לצוות הלקוח.
- תצורות אנימציה מוגדרות: פרמטרים של גמישות, דעיכה ומהירות התחלתית הוצאו לשכבה נפרדת ומקובצים לפי תרחישים — הופעת מסך, תגובה ללחיצה, סגירת חלון מודאלי. הערכים נערכים במקום אחד ומיושמים בכל האפליקציה.
- תרשימי מעברים בין מסכים: מתואר איזה מעבר מופעל באיזו תנועה, כיצד מתנהגת סגירה אינטראקטיבית ומה קורה בעת קטיעת תנועה באמצע. התרשים מסיר מחלוקות מסוג "ככה זה אמור להיות" בעת הקבלה.
- ספריית אינטראקציות טיפוסיות: סט מודלים מוכנים של תגובה לכרטיסים, רשימות, כפתורים ומתגים. מסכים חדשים נבנים מהם, ולא נכתבים מאפס.
- תיעוד לשכבת האנימציות: היכן נמצאות התצורות, כיצד להוסיף תרחיש חדש, אילו פרמטרים משפיעים על תחושת המהירות והמשקל. עם דוגמאות קוד וניתוח של שגיאות טיפוסיות.
- תקנון תחזוקה: כללים לפיהם אנימציות משתנות לאחר שחרור — מי מאשר עריכה, כיצד נבדק במכשירים חלשים, מה נחשב לרגרסיה.
- סט בדיקות התנהגות: תרחישים שמורצים לפני שחרור — קטיעת מעבר, לחיצות חוזרות מהירות, חזרה מהרקע. תופסים תקלות אנימציה לפני שהמשתמש רואה אותן.
- פרופיל התנהגות במכשירים חלשים: מתועד כיצד המערכת מפחיתה עומס כאשר מצב הפחתת תנועה מופעל ובמודלים ישנים.
כל זה נשאר במאגר הקוד של הלקוח יחד עם היסטוריית השינויים. הצוות יכול לפתח אנימציות בעצמו, ואנו מתחברים נקודתית — בתרחישים חדשים או כאשר יש צורך להרכיב מחדש התנהגות עבור ממשק שהשתנה.
במה שונה אנימציה פיזיקלית מאנימציה לינארית ומה לבחור
אנימציה לינארית קובעת התקדמות לפי עקומה קבועה: הערך עובר אינטרפולציה בין ההתחלה לסוף בזמן נתון, ופונקציית ה-easing רק מפזרת מחדש את המהירות בתוך הקטע הזה. אנימציה פיזיקלית (Spring) מתארת במקום עקומה מערכת: יש לה מסה, קשיחות קפיץ ודעיכה, והמיקום מחושב לפי חוק התנועה.
מכאן נובע ההבדל המרכזי בהתנהגות — אנימציה לינארית אינה יודעת מה קרה לפני שהופעלה, ואילו אנימציית Spring מתחילה מהמהירות הנוכחית ומדכאת אותה בהדרגה.
בפועל זה ניכר ברגע הקטיעה. אם המשתמש מושך כרטיס בזמן שהוא עוד בתנועה, אנימציה לינארית או מופעלת מחדש בפתאומיות מאפס, או קופאת — מפני שהמצב שלה הוא רק זמן. אנימציית Spring קולטת את המהירות הנוכחית וממשיכה את התנועה בלי קריעה: אותו מחווה, המשוחרר באמצע הדרך, נראה טבעי.
לכן אנימציה פיזיקלית הכרחית במקומות שבהם יש מניפולציה ישירה — החלקות (swipes), drag-and-drop, pull-to-refresh, מעברים אינטראקטיביים בין מסכים.
קריטריוני הבחירה מצטמצמים לשלוש שאלות. האם לאנימציה יש מהירות התחלתית שצריך לשמר? האם המשתמש יכול לקטוע אותה באמצע? האם היא צריכה להגיב לשינוי היעד במהלך ביצועה? אם לפחות תשובה אחת היא "כן" — לוקחים Spring.
אם האנימציה דקורטיבית וחד-פעמית (הופעת חלון מודאלי, שינוי צבע, התקדמות טעינה), עקומה לינארית צפויה יותר וזולה יותר בחישובים.
לפי תרחישי שימוש החלוקה היא כזו: מעברים והופעת אלמנטים — לינארית עם easing מחושב היטב, מחוות אינטראקטיביות וכל מה שעוקב אחרי האצבע — פיזיקלית. לא כדאי לערבב באותו אלמנט: מודלים שונים של תנועה יוצרים תחושה לא עקבית.
המהנדסים שלנו מכווננים את פרמטרי הקפיץ לתרחיש מסוים — הקשיחות והדעיכה נבחרות כך שהתנועה תיקרא כתגובת ממשק, ולא כאפקט לשם אפקט.
מקרה בוחן: הסרנו את הקפיצות בפיד והאצנו את התגובתיות
הלקוח — שירות עם פיד המלצות: כרטיסים עם תמונות, גלילה אינסופית, עשרות אלפי משתמשים פעילים ביום. הפיד רעד בגלילה מהירה, והתגובה להקשה על כרטיס התעכבה — המעבר נפתח באיחור מורגש.
לתמיכה זרם שטף קבוע של פניות בדיוק בנוגע לחלקות: המשתמשים תיארו זאת כ"נתקע" ו"לא מגיב", אף שמבחינה פונקציונלית הכול עבד.
אנימציות Spring טיפלנו בהן כמשימה נפרדת, ולא כקוסמטיקה. הסיבה לקפיצות לא הייתה במהירות הרשת, אלא בכך שהאנימציות הופעלו ידנית לפי טיימר ולא התחשבו בהפרעות: בגלילה מהירה פריימים נערמו זה על זה, ומחוות ההקשה עובדה רק לאחר סיום האנימציה הנוכחית.
העברנו את המעברים למודל פיזיקלי — התנועה מחושבת מהמיקום והמהירות הנוכחיים, ולא ממשך קבוע, ולכן הפרעה במחווה אינה שוברת את הפריים.
מה שינינו
- מעברים של כרטיסים ופתיחת פרטים הועברו למודל קפיצי עם קשיחות ודעיכה ניתנות להגדרה במקום משכים קבועים.
- מחוות קיבלו עדיפות על פני אנימציה: הקשה מפסיקה את התנועה הנוכחית ומתחילה חדשה מהמיקום בפועל.
- פעולות כבדות בפתיחת כרטיס הוצאו מפריים האנימציה, כדי לא לחסום את הרינדור.
- אספנו מדידות תגובתיות וחלקות להרצה אוטומטית — רגרסיות בפריימים נתפסות לפני שחרור.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| תגובה להקשה על כרטיס | עיכוב מורגש, המעבר "הדביק" את האצבע | הפתיחה מתחילה מיד מנקודת הנגיעה |
| חלקות הפיד בגלילה מהירה | קפיצות בכל מסך | תנועה חלקה לכל האורך |
| פניות לתמיכה בנוגע לחלקות | שטף קבוע | שיעור הפניות ירד פי כמה |
תפיסת הממשק השתנתה חזק יותר מכפי שאפשר לשפוט לפי מדידות בלבד: הפיד החל להרגיש "חי", ולא "כבד". זה המקרה שבו הפיזיקה של התנועה חשובה יותר מהמספרים המוחלטים — המשתמש קורא את התגובתיות לפי האופן שבו האלמנט עוקב אחרי האצבע, ולא לפי זמן טעינת הנתונים.
ספקות טכניים לפני תחילת העבודה
אנימציות Spring פיזיות ב-iOS מבוססות על UISpringTimingParameters ו-UIViewPropertyAnimator — זהו שכבה מערכתית, ולא ספרייה חיצונית, ולכן שאלת התאימות מצטמצמת לגרסת המערכת.
בענפים עדכניים של iOS הכול עובד מהקופסה; במכשירים שבהם המערכת ישנה יותר, אנו מחליפים את המכניקה ב-CASpringAnimation מ-Core Animation — ויזואלית ההתנהגות זהה, ורק שיטת החישוב משתנה.
בנפרד אנו בודקים Reduce Motion: אם המשתמש הפעיל הפחתת תנועה בהגדרות הנגישות, האנימציה צריכה לעבור לקרוספייד קצר, אחרת האפליקציה תידחה בבדיקת הנגישות.
הביצועים תלויים במה שאנו מנפישים. ספרינג על transform ו-opacity מחושב במאיץ הגרפי ואינו מעמיס על התהליך הראשי; ספרינג על frame או cornerRadius מאלץ חישוב מחדש של הפריסה בכל פריים ובמכשירים ישנים גורם לירידות.
אנו מסמנים מראש אילו מאפיינים ניתן להוביל דרך טרנספורמציות, והיכן נדרש פשרה — ומקבעים זאת במפרט האנימציות לפני תחילת העריכות.
היקף השינויים תלוי בארכיטקטורה הנוכחית של המסך. אם הפריסה מבוססת על Auto Layout והאנימציות כבר הופרדו לשכבה נפרדת, אינטגרציה של אנימציות Spring ב-iOS מצטמצמת לעריכות ממוקדות ב-3-5 מקומות.
אם הלוגיקה מפוזרת בין הקונטרולרים, תחילה מוציאים את שכבת האנימציה, אחרת כל ספרינג חדש שובר את זה שלצידו.
האם זה יעבוד במכשירים ישנים?
כן. אנו לא נצמדים ל-API אחד: במערכות חדשות אנו משתמשים במנגנון המערכתי, ובישנות — ב-Core Animation עם אותם פרמטרי גמישות. ההתנהגות והתזמונים נשארים צפויים, ובחומרה חלשה אנו מפחיתים את מספר האלמנטים המונפשים בו-זמנית, כדי שהפריימים לא ייפלו.
האם הביצועים ייפגעו לאחר ההטמעה?
ספרינגים על טרנספורמציות ושקיפות אינם מעמיסים על התהליך הראשי. הסיכון נוצר רק במקומות שבהם האנימציה מפעילה חישוב מחדש של הפריסה — מקומות כאלה אנו מאתרים בשלב הניתוח ומעבירים למאפיינים בטוחים. לאחר העריכות אנו מריצים מדידות פריימים על מכשירי היעד.
כמה גדול היקף העריכות בקוד הקיים?
תלוי במידת הבידוד של האנימציות. בפריסה מסודרת אלה שינויים ממוקדים; בלוגיקה מפוזרת — הוצאה מקדימה של שכבת האנימציה. את הגבול המדויק נקבע לאחר ניתוח הקוד, לפני תחילת העבודה.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי שההערכה תהיה מבוססת ולא "ממוצע שוק", עלינו להבין את מצב האנימציות הנוכחי באפליקציה: היכן הן כבר קיימות, על מה הן בנויות ומה בדיוק לא מספק — טלטלות במחוות, חוסר סנכרון עם הגלילה או היעדר תגובה לעצירה.
תארו את המצב בצורה חופשית, ואנחנו נחזור עם הערכת העבודה ותוכנית הטמעה של אנימציות Spring המותאמת לפרויקט שלכם.
מה כדאי לצרף לתיאור המשימה כדי שנראה מיד את ההיקף:
- רשימת מסכים ורכיבים שבהם נדרשות אנימציות פיזיקליות: מעברים, החלקות, drag-and-drop, פריסת כרטיסים, תגובה ללחיצה.
- הגישה הנוכחית: אנימציות UIView עם משך קבוע, ספריות מוכנות או חישובים ידניים — ובמה בדיוק מתבטאת הבעיה.
- ההתנהגות הרצויה: כיצד הרכיב צריך להגיב לעצירת מחווה, לשחרור באמצע תנועה, לשינוי כיוון.
- מגבלות: גרסת מערכת מינימלית נתמכת, קיום שכבות עם רסטריזציה, צללים כבדים וטשטושים המשפיעים על החלקות.
- רפרנסים: אפליקציות או סרטונים שבהם התנהגות האנימציות מספקת אתכם — זה מסיר מחצית מהאי-בהירות בקבלה.
- גישות וחומרים: מאגר קוד, עיצובים, מערכת עיצוב, מדידות נוכחיות של קצב פריימים תחת עומס.
לפי סט זה אנו קובעים היכן מספיק להעביר את המעברים הקיימים למודל קפיצי, והיכן יהיה צורך לעבד מחדש את היררכיית השכבות ולהוציא חישובים מהתהליך הראשי.
בתגובה אתם מקבלים תוכנית הטמעה בשלבים: ביקורת של לוגיקת האנימציה הנוכחית, אב טיפוס על מסך אחד לצורך השוואת תחושות, העברת שאר הסצנות, מדידות חלקות לפני ואחרי, בדיקות רגרסיה על מכשירים חלשים.
השלבים הבאים פשוטים: אתם שולחים תיאור וחומרים, אנחנו לומדים אותם וקובעים שיחה קצרה בנושאים השנויים במחלוקת. לאחריה אנו מקבעים את ההיקף, סדר העבודה וקריטריוני הקבלה — ומתחילים עם אב טיפוס, כדי שתראו את התנהגות האנימציות על מכשיר אמיתי לפני שהתיקונים יתפשטו על פני כל האפליקציה.