אנימציית Lottie: מדוע הממשק נתקע ואיך מתקנים זאת
אנימציית Lottie נראית תמימה: המעצב מוסר קובץ JSON, המפתח מחבר אותו למסך — והנה הכפתור פועם בעדינות, והאונבורדינג מתעורר לחיים. הבעיה מתגלה מאוחר יותר, כאשר ישנם חמישה קבצים כאלה על מסך אחד, כל אחד עם ציר הזמן שלו, והאפליקציה פתאום מתחילה לאבד פריימים במכשירים בינוניים.
אנימציית ממשק האפליקציה מפסיקה להיות קישוט והופכת לצוואר בקבוק: המשתמש רואה קפיצות בגלילה, ובלוגים צריכת הזיכרון גדלה.
הסיבה נעוצה באופן שבו נגן Lottie עובד עם תוכן הקובץ. כל שכבה היא אובייקט נפרד עם הטרנספורמציות, המסכות והאפקטים שלה; מסכות מורכבות וטשטושים מאלצים לצייר מחדש את האזור בכל פריים.
אם הסצנה הווקטורית מכילה מאות נתיבים, והרינדור מתבצע בזמן אמת, העומס נופל על התהליך הראשי — והחלקות של המסכים נשענת רק על חומרה חזקה. במכשירים חלשים זה מתבטא בירידות בקצב הרענון ובעיכובים מורגשים בתגובה.
סעיף ההוצאות הנסתר השני — המשקל וכמות הנכסים. JSON כבד אחד על המסך עוד נסבל, אבל כאשר האנימציות נטענות מראש ונשארות בזיכרון, האפליקציה אוכלת באופן בלתי מורגש משאב שנחוץ לרשימות ולתמונות.
אופטימיזציה של אנימציות מתחילה לא מהקוד, אלא מביקורת: כמה סצנות באמת נחוצות, אילו שכבות ניתן לפשט, והיכן די במצב סטטי.
ביצועי אפליקציית המובייל כאן נתקלים בשלושה דברים — מורכבות הסצנה, רגע ההפעלה שלה ואופן הרינדור. להסיר מסכות מיותרות, לפצל אנימציה ארוכה לקטעים קצרים, להפעיל אותה רק כשהמסך נראה ולשמור את התוצאה במטמון — זה לא קוסמטיקה, אלא עבודה עם צוואר בקבוק שמשפיע ישירות על שימור המשתמשים. בואו נפרק איך זה נסגר בפועל.
מה נותנת אנימציית Lottie מכוילת: האפקט במספרים
אנימציית Lottie היא פורמט וקטורי שמתנגן באופן מקורי על המכשיר, ולא כזרם וידאו. ההבדל המרכזי מ-GIF ומרצף PNG: במקום מאות פריימים רסטריים, אל הבנייה נכנס קובץ JSON קומפקטי אחד עם עקומות ותזמונים.
בדיוק משום כך אנימציה שנבנתה נכון נותנת אפקט מדיד: זמן רינדור הפריים יורד, צריכת הזיכרון על המסך פוחתת, ושיעור הכשלים במכשירים חלשים יורד.
מה בדיוק אנחנו מודדים
- זמן רינדור הפריים. שכבות וקטוריות מחושבות מחדש על ה-GPU, החלפות רסטריות כבדות לא חוסמות את ה-thread הראשי — הממשק נשאר מגיב גם בגלילה.
- צריכת זיכרון. JSON אחד במקום סט פריימים מקצר את משקל המסך פי כמה: האנימציה לא מחזיקה בזיכרון עשרות שכבות רסטריות בו-זמנית.
- שיעור הכשלים במכשירים חלשים. בלי זרם וידאו ובלי מפענחים מיותרים האנימציה לא «אוכלת» פריימים בדגמים תקציביים — התרחיש עובד באופן צפוי.
- אופטימיזציה של רינדור. מסכות, גרדיאנטים וקומפוזיציות מקוננות נבנות מחדש למבנה שטוח, כדי לא ליצור שכבות מיותרות ברינדור.
השוואת פורמטים של אנימציה
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| Lottie (וקטורי) | אייקונים, אונבורדינג, מיקרו-אנימציות, מצבי כפתורים | סצנות פוטו-ריאליסטיות מורכבות דורשות תוספות רסטריות |
| GIF | לופים קצרים ופשוטים שבהם חשובה התאימות | פלטה מוגבלת, משקל גדול, אין חלקות |
| וידאו (MP4/WebM) | פתיחים ארוכים, אפקטים מורכבים | משקל כבד, מפענח נפרד, קשה יותר להתאים למסכים |
| רצף רסטרי | אפקטי פריימים נדירים | משקל הבנייה וצריכת הזיכרון גדלים בחדות |
בחירת הפורמט היא פשרה בין משקל, חלקות ומורכבות הסצנה. עבור אנימציות ממשק, הווקטור כמעט תמיד מנצח: הוא מתאים את עצמו לכל צפיפות מסך בלי לאבד איכות ולא גורר אחריו נגן וידאו.
Lottie מבית Airbnb קובע את הסטנדרט להעברת אנימציה וקטורית בין עיצוב לפיתוח — הקובץ נבנה פעם אחת ומתנגן באותו אופן בשתי הפלטפורמות. אנחנו מכניסים לבנייה בדיקת משקל, מספר שכבות ופרופיל רינדור, כדי שהאפקט מהאנימציות יהיה אמיתי ולא הצהרתי.
כיצד אנו מטמיעים אנימציות: שלבי העבודה ההנדסית
הטמעת אנימציות אינה מתחילה ברישום, אלא בביקורת ממשק: מהנדסים עוברים על המסכים, מודדים זמני תגובה, מאתרים מקומות שבהם הממשק "שותק" — מעבר בין מצבים, טעינת נתונים, אישור פעולה.
בשלב זה אנו קובעים אילו תרחישים אכן מרוויחים מתנועה ואילו נשארים סטטיים: אנימציה לשם אנימציה אוכלת את תקציב הפריימים ומפריעה לעבודה.
לאחר מכן — תכנון והרכבה. כל מעבר מקבל תזמון, עקומת האצה ונקודת יציאה, כך שהתנועה תתאים להיגיון המסך ולא תתקיים בנפרד ממנו. סצנות מוכנות נאספות לאנימציית Lottie ונבדקות במכשירים אמיתיים: משקל הקובץ, חלקות על חומרה חלשה, התנהגות בעת interruption במחווה.
- ביקורת ממשק. עוברים על המסכים, מודדים תגובה, מרכיבים מפת מקומות שבהם נדרשת אנימציה, ומסננים את המיותר.
- תיאום תרחישים. קובעים מה בדיוק מונפש, לכמה זמן, ומה קורה בלחיצה חוזרת או ביציאה מהמסך.
- אב-טיפוס של תנועה. מרכיבים אנימציית Lottie ראשונית במעברים המרכזיים, ומציגים במכשיר לפני הרישום הסופי.
- הרכבת פרודקשן. רושמים סצנות, מייעלים קווים ושכבות, מסירים כל מה שלא משפיע על התמונה אך מכביד על המשקל.
- בדיקה במכשירים. מריצים על דגמים חלשים וחזקים, בודקים חלקות וצריכת זיכרון בשימוש ממושך.
- אינטגרציה באפליקציה. מחברים אנימציות למסכים, מוודאים שהן אינן חוסמות את הממשק ונעצרות כראוי.
- מסירת אנימציות ותיעוד. מוסרים קבצי מקור, קבצים מוכנים, כללי תזמון והוראות כיצד לבצע שינויים בלעדינו.
תהליך הנדסי כזה מניב תוצאה צפויה: אנימציות אינן מנפחות את הבנייה, אינן מאטות במכשירים חלשים ונשארות ניתנות לניהול לאחר המסירה. תארו את המשימה — נחזור עם הערכה ותוכנית לפי שלבים.
במה שונה Lottie מאנימציית פריים-בי-פריים ומאנימציה נייטיבית?
אנימציית Lottie היא אנימציה וקטורית, שמתוארת לא באמצעות סט תמונות, אלא באמצעות מודל מתמטי: קואורדינטות, עקומות, פריימים מרכזיים ותזמונים. הקובץ מכיל הוראות "מה ואיך זז", ואת הרינדור במכשיר מבצעת ספריית ריצה (runtime).
מכאן ההבדל העיקרי מאנימציית פריים-בי-פריים: במקום עשרות פריימים רסטריים, כל מעבר באפליקציה מקבל קובץ קומפקטי אחד, שמתאים את עצמו לכל מסך ללא אובדן חדות.
אנימציית פריים-בי-פריים היא רצף של תמונות מוכנות, שמופעלות כמו שקופיות. היא נותנת שליטה מלאה על התמונה: אפשר לצייר טקסטורות מורכבות, רעש, אור, אפקטים שווקטור פשוט לא ישחזר.
אבל המחיר — משקל וזיכרון: סצנה ארוכה הופכת למאות פריימים, שכל אחד מהם תופס מקום בגרסה ובזיכרון הגישה בזמן ההפעלה. במכשירים חלשים זה מורגש בירידות ביצועים בגלילה ובצריכת סוללה.
אנימציה נייטיבית נבנית באמצעים של הפלטפורמה עצמה — שכבות, טרנספורמציות, מעברים בין מצבי מסך. היא אידיאלית לתנועות ממשק: הופעת כפתור, החלפת טאב, תגובה ללחיצה. כאן המשקל מינימלי והתגובתיות מקסימלית, כי המערכת עושה הכול.
המגבלה — כושר ביטוי: סצנה איורית מורכבת עם עשרות אובייקטים עצמאיים תיבנה באנימציה נייטיבית זמן רב ותהיה יקרה לתחזוקה.
בחירת הפורמט היא פשרה בין כושר ביטוי, משקל ומורכבות התיקונים. Lottie מנצחת במקום שדרושה סצנה וקטורית מפורטת, קובץ אחיד לשתי הפלטפורמות ותיקון מהיר ללא בנייה מחדש של האפליקציה: המעצב משנה את הקובץ, והעדכון מגיע ללא פרסום גרסה.
פריים-בי-פריים מנצחת בסרטונים קצרים בלופ עם גרפיקה פוטוריאליסטית, שבה וקטור חסר אונים. נייטיבית — בכל מה שקשור להתנהגות הממשק, ולא לאיור.
מבחינת זיכרון ומורכבות Lottie מפסידה כשהסצנה עמוסה מדי: מאות שכבות, מסכות כבדות, טשטושים וגרדיאנטים מאלצים את ספריית הריצה לחשב מחדש את הגיאומטריה בכל פריים, ובמכשירים זולים זה יוצר ירידות ביצועים. כאן עוזרים פישוט הסצנה, פיצול למספר קבצים וטעינה מוקדמת. אנחנו בשלב ההתחלה מעריכים כל אנימציה לפי הפרמטרים האלה ומציעים פורמט למסך הספציפי, ולא כברירת מחדל.
מקרה בוחן: איך הסרנו את הקפיצות במסכים באפליקציית משלוחים
מסך השלמת ההזמנה באפליקציית משלוחים קיפץ בגלילה: הפריים נבנה לאט יותר ממה שהמכשיר הספיק להציג, ובמכשירים חלשים האנימציה התפרקה לרעידות. הבעיה לא הייתה בקידוד, אלא בכך ששכבות וקטוריות כבדות נבנו מחדש בכל פריים במקום להתנגן כרצף מוכן מראש.
מדידות לפני התיקונים: רינדור הפריים חרג מתקציב של 16 מ״ש, צריכת הזיכרון המקסימלית במסך עמדה על כ-180 מ״ב, ושיעור הכשלים בפתיחת הסל במכשירים בסיסיים הגיע ל-7%.
מה בדיוק שינינו
העברנו את האנימציה של הסל ושל סטטוסי המשלוח ל-Lottie אנימציה — רצף וקטורי מחושב מראש שמנוגן על ידי רנדרר נייטיבי ללא בנייה מחדש של שכבות בכל פריים.
ספרייטים ראסטריים כבדים ושרשראות של שכבות מקוננות הוחלפו בקובץ קומפקטי אחד, והנגן עצמו מאותחל פעם אחת בכניסה למסך ומשמש מחדש בין מעברים. בנפרד הגבלנו את מספר האנימציות הפעילות בו-זמנית: בזמן שאחת מתנגנת, האחרות מושהות כדי שלא יתחרו על תהליך הרינדור.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן רינדור פריים | חרג מתקציב של 16 מ״ש | יציב בתוך התקציב |
| זיכרון מקסימלי במסך | ~180 מ״ב | ~95 מ״ב |
| כשלים במכשירים חלשים | עד 7% | מתחת ל-1% |
| גודל משאב האנימציה | מספר ערכות ספרייטים | קובץ וקטורי אחד |
הגלילה הפסיקה לקפוץ, ומסך הסל נפתח באופן צפוי גם במכשירים חסכוניים. אנחנו עובדים עם Lottie — פורמט שמתנגן באופן זהה בשתי הפלטפורמות ללא בנייה נפרדת לכל אחת, ולכן תיקוני אנימציה לא דורשים בנייה מחדש של מודולים נייטיביים.
תוצאת היישום
החלקות הממשק הפסיקה להיות תלויה בסוג המכשיר: מה שקודם לכן «התפרק» במכשירים חלשים, עובד כעת באופן אחיד וחלק. אופטימיזציית האפליקציה הניבה אפקט לוואי — המסך נפתח מהר יותר ופחות מעמיס על הסוללה, כי הרנדרר לא מחשב מחדש שכבות בכל פריים. בהמשך העברנו את אותה גישה גם למסכי מעקב ההזמנה והאונבורדינג.
ספקות לגבי תאימות, חזרה לאחור והרשאות — מפרקים
אנימציית Lottie היא לא חפץ נפרד "בוואקום", אלא קובץ שחייב להתנגן כראוי בגרסאות ספציפיות של iOS ו-Android, בספריית ריצה ספציפית ובמצב מסך ספציפי. לכן השאלה הטכנית המרכזית היא לא "האם זה נראה יפה", אלא "מה יקרה כשהאנימציה תפגוש את הסטאק הנוכחי שלכם". להלן — פירוק של ספקות אופייניות שעולות לפני ההתחלה.
מה אם יש לנו גרסה אחרת של ספריית הריצה? אנחנו בונים את האנימציה עבור הענף של הספרייה שכבר מותקן בפרויקט, ולא עבור האחרון. אם הגרסה ישנה — או שנתאים את השכבות הווקטוריות לקבוצת המאפיינים הנתמכת, או שנציע עדכון ממוקד של ספריית הריצה עם בדיקת רגרסיות. תאימות האנימציות נבדקת על מכשירים אמיתיים מהמטריצה שלכם, ולא רק בעורך.
מה אם אחרי הריליזציה צריך לחזור לאחור? כל אנימציה מנוהלת בגרסאות כקובץ נפרד, לכן חזרה לאחור של שינויים היא החלפה של חפץ אחד בקודמו, בלי לבנות מחדש את לוגיקת המסך. אנחנו מתעדים איזו גרסה יצאה באיזה ריליז, כדי שהחזרה תארך דקות ולא שעות של חיפושים.
איך תקבלו גישה לפרויקט ומה יישאר אצלכם?
אנחנו עובדים במאגר שלכם או מעבירים את קוד המקור בארכיון נפרד — ההרשאות לפרויקט נרשמות על החשבונות שלכם, ולא על שלנו. אחרי המסירה נשארים אצלכם קבצי מקור ניתנים לעריכה של האנימציות, ולא רק קבצים דחוסים, לכן ניתן לבצע תיקונים בלעדינו.
מה אם נרצה לשנות אנימציות בעצמנו? מסירת התיעוד כוללת את מבנה השכבות, שמות הקבוצות וכללי הייצוא — מעצב או מפתח עם ניסיון בסיסי יבצע תיקון בלי לשבור את ספריית הריצה. ספקות טכניים לגבי מעבר למנוע אחר גם סוגרים מראש: מתארים אילו מאפיינים לא עוברים אחד לאחד.
מה הלקוח מקבל לידיו:
- קבצי מקור של אנימציות בפורמט ניתן לעריכה;
- קבצים מיוצאים ל-iOS ול-Android עם בדיקה על מכשירים;
- מפת גרסאות: איזה קובץ באיזה ריליז;
- הוראות ייצוא והחלפה של אנימציה;
- רשימת מאפיינים נתמכים ומגבלות ספריית הריצה;
- צ'קליסט בדיקה לפני ריליז.
תארו את גרסת ספריית הריצה הנוכחית שלכם ואת מטריצת המכשירים — נחזור עם הערכה ותוכנית עבודה לאנימציות.