מדוע אנימציות Lottie מאבדות ביצועים בחלק מהמכשירים
אנימציות Lottie הן JSON וקטורי, שהאפליקציה מפרשת ומרסטרת על המכשיר עצמו ברגע ההצגה. במכשירי דגל זה לא מורגש, אך במכשירים חלשים פירוש הקובץ, מסכות, גרדיאנטים ושכבות עם שקיפות נופלים על חוט הרינדור הראשי. הממשק מתחיל לרעוד בדיוק במקום שבו המשתמש מצפה לתגובה מיידית.
מעל זה נוסף סדר הטעינה: טעינת אפקטים וקטוריים מתבצעת באופן סינכרוני עם ההצגה הראשונה של המסך, והאנימציה "משיגה" ממשק שכבר צויר. המעבר בין מסכים נפתח באיחור, חלק מהמכשירים פשוט מפספסים פריימים, ומעברי Hero ואנימציות קפיציות מעל מכפילים את העומס על אותו חוט.
סיבה נפרדת היא מטמון הפריימים המוכנים: במכשירים עם נפח זיכרון קטן הוא נדחק, ואותו אפקט נבנה מחדש בכל חזרה למסך. מבחוץ זה נראה כמו "רועד רק לפעמים", ולכן הבעיה מיוחסת זמן רב לרשת.
המחיר מתבטא בתרחישים מרכזיים — אונבורדינג, הוספת מוצר, אישור תשלום. מעבר מקוטע נקרא כ"האפליקציה נתקעת", והמשתמש עוזב, אף שהלוגיקה פעלה כהלכה. ירידות ביצועים כאלה נתפסות בקושי במכשירי בדיקה: על עמדת הבדיקה חלק, על מכשירים אמיתיים — באופן עקבי.
להלן נפרט כיצד זה נסגר: היכן מכינים את האנימציה מראש, היכן מחליפים פורמט, והיכן מסיטים את הרינדור מחוט ראשי — כדי שהחלקות הממשק תפסיק להיות תלויה בדגם המכשיר.
מערכת תנועה אחידה לממשק: מה היא נותנת לאפליקציה
מערכת תנועה לממשק אינה אוסף אפקטים לכל מסך, אלא ספריית מעברים לשימוש חוזר: תזמונים, עקומות האצה, התנהגות בעת קטיעה במחווה מתוארים פעם אחת ונעשים בהם שימוש חוזר בכל מקום. מסך חדש נבנה ממקטעים מוכנים, ולא מצויר מחדש, ולכן זמן ההשקה שלו מתקצר מימים לשעות.
מהירות השחרור של מסכים עולה גם בזכות ביטול התיאום: מעצב ומפתח כבר לא דנים במשך ובאופי של כל אנימציה, אלא לוקחים מעבר מתאים ומציבים בו תוכן. ציור וקטורי Lottie נותן תמונה זהה בשתי הפלטפורמות — אין צורך לתאר ולתחזק את אותו אפקט פעמיים.
תוצאה נפרדת היא סוג פגמים שהוסר: "רועד במחווה מהירה", "קופץ לאחר סיבוב המסך", "נתקע במכשיר חלש". מעברים הניתנים לקטיעה בכל רגע ומחשבים מיקום מהמצב הנוכחי מסירים טלטולים, ושיעור המכשירים עם ציור חלק נמדד בנפרד בפלח החלש — לפיו רואים שהרגרסיה לא חזרה.
אפקטים לשימוש חוזר מפחיתים גם את מספר התיקונים החוזרים: תיקון תזמון או עקומה במקום אחד חל על כל המסכים בבת אחת, ולא מוזן ידנית בכל אחד. בהדרגה הופך אוסף המעברים לשפת תנועה פורמלית, שלפיה מרכיבים מסכים חדשים בלי השתתפות מחבר הספרייה.
אנימציות Lottie ו-Rive: איזה פורמט לאיזו משימה
פורמט תנועה נבחר לפי מי ששולט במצב האנימציה — ציר זמן שצויר מראש או קוד האפליקציה. Lottie שומר סצנה וקטורית כמערכת שכבות ופריימים מרכזיים: הנגן משמיע אותה מתחילה ועד סוף במשך קבוע. Rive מתאר גרף מצבים, שבו את המעבר לא קובע הזמן, אלא פרמטר קלט — לחיצה, התקדמות, ערך מתג.
מעברים פיזיים בקפיצים ותרחישי מחוות אינם נשמרים בקובץ כלל: אותם מחשבת האפליקציה עצמה, תוך קישור התנועה למהירות האצבע ולאינרציה. מכאן גם ההבדל במשימות — הווקטור אחראי לעיצוב ולסיפור, והפיזיקה לתגובת הממשק.
| פורמט | מתי מתאים | מגבלות |
|---|---|---|
| וקטורי (Lottie) | אייקונים, אונבורדינג, איורים, אפקטי הצלחה ושגיאה — תרחיש ליניארי עם משך ידוע | מגיב בחולשה לקלט בזמן אמת: החלפת מצב היא החלפת קובץ או מקטע, ולא תגובה רציפה |
| אינטראקטיבי (Rive) | אלמנטים אינטראקטיביים: מתגים, דמויות, בלוקים עם הסתעפות לפי מצב | יקר יותר בייצור — דרוש מעצב שבונה גרף מצבים, ולא מצייר ציר זמן |
| מעברים פיזיים | ניווט בין מסכים, הופעת חלונות מודאליים, תגובה ללחיצה | פרמטרים מכוונן מהנדס, ולא מעצב; בלי החלקה רועדים במכשירים חלשים |
| תרחישי מחוות | החלקות, גרירת כרטיסים, רענון רשימה, ביטול פעולה | קשה לסנכרן ולבטל: התנועה צריכה לעקוב אחרי האצבע, ולא אחרי ציר הזמן |
בפועל הפורמטים לא מתחרים באותו מסך: שכבה וקטורית מכסה עיצוב, פיזיקה — ניווט, פורמט אינטראקטיבי — אלמנטים שהמשתמש שולט בהם. המגבלה המשותפת אחת — ככל שיותר שכבות מונפשות בו-זמנית, כך ירידת הביצועים מורגשת יותר במכשיר חלש.
שלבי הטמעה: מביקורת אפקטים קיימים ועד מסירה
אנימציה נשברת לא בעיצוב, אלא בהטמעה: האפקט מצויר במחזור הרינדור הראשי, גורר אחריו שכבות מיותרות ובמכשיר חלש הופך לטלטול. לכן אנו מובילים את תנועת הממשק בשלבים — כל אחד נשען על התוצר של הקודם, ובסיום נשארת מערכת ניתנת לניהול, ולא אוסף אפקטים מפוזרים.
- ביקורת תנועת הממשק. עוברים על המסכים ומתעדים כל מעבר, הופעת רשימה, תגובה ללחיצה: במה זה מצויר, היכן יש כפילות, אילו מסכים נפתחים לאט יותר מאחרים.
- סכימת אפקטים. מרכזים בטבלה מסך, אירוע-טריגר, משך, עקומה ואופן ציור — אנימציה וקטורית Lottie, פריים-אחר-פריים או קפיץ נייטיבי. הסכימה הופכת למילון: פעולות זהות במשמעותן נראות אותו דבר בכל האפליקציה.
- אופטימיזציית רינדור. חלקים סטטיים מוציאים למטמון, סצנות כבדות מפצלים למסלולים בלתי תלויים, שכבות דקורטיביות מוציאים מהמחזור הראשי. האפקט מפסיק להשפיע על החלקות הגלילה.
- בדיקה במכשירים. מריצים על דגמים חלשים, במצב כהה, במצב חיסכון באנרגיה ובמצב מערכתי "הפחתת תנועה": האנימציה לא צריכה להיעלם, אלא להיות מוחלפת בגרסה קצרה ובטוחה.
- מדידות ורגרסיה. משווים זמן פתיחת מסכים ומספר הפריימים שהוחמצו לפני ואחרי; מערכת הבדיקות נשארת אצל הצוות, כדי לבדוק לפיה גם אפקטים חדשים.
- מסירת הפרויקט. מוסרים סכימה, קבצי מקור, טוקנים של משכים ועקומות, תצורת בניית משאבים והוראה "כיצד להוסיף אפקט בלי לשבור את האחרים". לאחר סקירה עם צוות הלקוח, ניתן להמשיך בתמיכה בכוחות עצמכם.
ערכה לאחר מסירה: קבצי מקור, סכימות, נהלים
לאחר המסירה נשארים אצל הלקוח לא רק האפליקציה הבנויה, אלא גם ערכה שלפיה ניתן לפתח אותה בלעדינו: להלן מה בדיוק נכלל במסירה וכיצד זה נבדק בקבלה.
- קבצי מקור של אפקטים. פרויקטים עובדים של אנימציות וקטוריות Lottie, ולא רק קבצים שיוצאו מהן: שכבות בעלות שמות, תזמונים, עקומות תנועה והערות היכן האפקט קשור לנתונים מהאפליקציה.
- ספריית מעברים. מעברים לשימוש חוזר בין מסכים ומצבים — הופעה, חזרה, חלונות מודאליים, תגובה להחלקה — שנבנו כך שמסך חדש מחבר מעבר מוכן, ולא מצייר משלו.
- סכימת קשרי מסכים. מפה שבה רואים איזה מעבר מוביל מאיזה מסך לאיזה, במה נבדלים המצבים ומה קורה בעת קטיעה במחווה.
- כללי עריכת תיקונים. מה ניתן לשנות בקובץ האנימציה בלי לבנות מחדש, היכן הסף שאחריו האפקט נבנה מחדש, ומי בודק את התוצאה לאחר התיקון.
- סדר קבלה. רשימת בדיקות: התנהגות במכשירים חלשים, תגובה לקטיעה, מצב מערכתי להפחתת תנועה, היעדר טלטולים בעת טעינת נתונים.
- נהל ביצועים. תקציב למשך ולמספר אפקטים בו-זמניים, בתוספת רשימת מקומות שבהם האנימציה מושבתת בכפייה.
כל זה נמצא במאגר הקוד לצד האפליקציה, מנוהל בגרסאות יחד איתה ומתעדכן בכל מהדורה. תארו את המשימה — נחזור עם הערכה ותוכנית מסירה.
מקרה בוחן: כתבנו מחדש את תנועת הממשק והסרנו ירידות ביצועים
הפרויקט — אפליקציה של שירות משלוחים: יותר מ-40 מסכים, תנועת הממשק נבנתה מרצפי פריימים מבוססי ראסטר, ולכל אחד תזמון ועקומה משלו. במכשירים חלשים המעבר בין מדורים איבד ביצועים, בגלילה של רשימה ארוכה פריימים נפלו, ותיקון של אנימציה אחת גרר אחריו ייצוא מחדש של הגרפיקה.
תחילה מדדנו מה בדיוק מאט: צילמנו פרופיל רינדור על דגמים זולים ופירקנו את התנועה לשכבות. לאחר מכן העברנו סצנות לפורמטים וקטוריים — Lottie למצבי ממשק ו-Rive לאינטראקטיביים — ואת כל המעברים ריכזנו למערכת עקומות האצה משותפת.
| מדד | לפני | אחרי |
|---|---|---|
| תרחישי תנועה | 41 מערכי ראסטר | 12 סצנות וקטוריות |
| בניית מסך חדש | 3 ימים לגרפיקה | 4 שעות |
| מכשירים עם ציור חלק | 62% | 97% |
| משקל גרפיקה במהדורה | 14 MB | 3.2 MB |
מה שינינו במעברים
את המעברים כתבנו מחדש על עקומות קפיציות וקישרנו מסכים מזווגים לתנועה רציפה, כך שהיא נקראת כעצם אחד, ולא כהדבקה. את האנימציה הוצאנו כשכבה נפרדת מעל הפריסה, סצנות כבדות נטענות מראש עם הופעת המסך ונשמרות במטמון — הכנת הסצנה הבאה כבר לא חוסמת את הרינדור.
ירידות הביצועים במכשירים זולים נעלמו, מסכים חדשים נבנים מסצנות מוכנות, ולא מאפס לכל מדור. המעצבים מתקנים את תרחיש התנועה בעצמם, בלי מפתחים, ולכן האיטרציה הבאה של הממשק ארכה שבועיים במקום חודשיים.
מה לעשות אם אפליקציה קיימת כבר מאבדת ביצועים בחלק מהמכשירים
כן, ניתן להטמיע מערכת תנועה באפליקציה שכבר יצאה לאור בלי לכתוב אותה מחדש: האנימציה חיה בשכבה נפרדת של הממשק, ולכן החלפתה אינה נוגעת בלוגיקה, בעבודה עם הרשת ובאחסון נתונים. מדובר בעיבוד ממוקד — מחליפים מסכים מסוימים, ולא את כל האפליקציה.
מתחילים בתרחישים תכופים שהמשתמש עובר בכל הפעלה: היכרות עם האפליקציה, מעברים בין מדורים, מצבי טעינה ושגיאה, רענון רשימה, תגובה ללחיצה.
לפני התיקונים מבצעים מדידות במכשירים אמיתיים ומוצאים היכן בדיוק אובדת החלקות: לעתים קרובות די להעביר רצפי פריימים כבדים לאנימציות וקטוריות Lottie, והירידות נעלמות בלי שינוי במבנה המסך.
סעיף נפרד הוא תאימות לאחור. גרסאות מערכת ישנות ומכשירים חלשים מקבלים גרסת תנועה פשוטה או פריים ראשון סטטי, והמערכת החדשה מופעלת רק היכן שהיא תעבוד באופן צפוי; המשתמש לא רואה הבדל, מלבד העובדה שהממשק מפסיק לרעוד.
מטמיעים בשלבים: מהדורה אחת — תרחיש אחד, מאחורי מתג מרוחק ועם ביטול מיידי בלי להוציא בנייה חדשה. כך ירידת ביצועים בדגם מסוים לא הופכת לביטול של כל המהדורה, והאפקט של כל החלפה נראה מיד.
אם אפליקציה קיימת מאבדת ביצועים רק בחלק מהמכשירים, אין צורך בעיבוד מלא — די בתוכנית של כמה צעדים עם סדר ברור ובדיקה בכל שלב.
ספקות טכניים בנוגע לשילוב אפקטים ומעברים
ספקות לגבי אפקטים בדרך כלל אינם בשאלה "יפה או לא", אלא באורך חיי הפתרון: מה יקרה בעת החלפת פורמט, מי מתקן את האנימציה לאחר המסירה, כיצד היא מתנהגת במכשיר חלש. נבחן ארבע שאלות נפוצות.
האם ניתן להחליף פורמט אפקטים אחד באחר?
כן, אם האנימציה מוצאת בשכבה נפרדת, ולא תפורה ללוגיקת המסך. פורמט וקטורי כמו Lottie מוחלף בקובץ: הפריסה והמעברים נשארים במקומם. ההחלפה היקרה ביותר היא היכן שהאפקט קשור לפריסה — אז מתקנים גם את המסך עצמו.
מי מתחזק את האנימציה לאחר המסירה?
אנחנו מוסרים קבצי אפקטים, סכימת קישור למסכים וכללי הפעלה. צבע, מהירות ומשך הצוות שלכם משנה בלעדינו; עיבוד תרחיש מעבר — משימה של שעות, ולא בנייה מחדש של האפליקציה.
כיצד אפקטים מתנהגים במכשירים זולים?
אפקטים כבדים במכשיר חלש גורמים לירידת חלקות ולהתחממות. מראש מכינים גרסה פשוטה ומכבים שכבות רקע כשהסוללה נמוכה — הממשק נשאר מגיב, והאפקט לא נעלם.
מה לעשות אם הפריסה כבר מצוירת?
מעריכים אותה ביחס לישימות: חלק מהאפקטים מועברים אחד לאחד, חלק דורשים פישוט לפי המגבלות בפועל. עומס העבודה של התיקונים תלוי במספר המעברים הייחודיים — ככל שיותר מסכים מציירים את הפריסה מחדש, כך יותר עבודה.
נדון במשימה: הציגו את מצב הממשק הנוכחי
כדי שהשיחה תהיה עניינית, נדרש לא כל הפרויקט כולו, אלא מערך מינימלי של נתונים על מסכים ואנימציות מסוימים. אנחנו משחזרים את ההתנהגות במכשיר ורק לאחר מכן נותנים הערכה ותוכנית עבודה — אחרת לוחות הזמנים הופכים לניחושים.
- רשימת מסכים בעייתיים. היכן בדיוק האנימציה רועדת, הפריים הראשון נופל, הגלילה מאטה או שהממשק מתפרק במכשיר חלש — שמות המסכים לפי הפריסה ובאפליקציה עצמה.
- הקלטות התנהגות האפליקציה. הקלטת מסך ממכשיר אמיתי, עם ציון הדגם וגרסת המערכת. אם השאלה באנימציה וקטורית, צרפו את קובץ המקור שמצויר במסך הזה.
- קישורים לבנייה. גישה לבניית בדיקה, חשבון בדיקה ונתונים שבהם הפגם משוחזר באופן יציב — זה מסיר מחצית מהבהרות.
- פריסות וקבצי מקור של אנימציות. פרויקט בעורך המקורי, פירוט לפי שכבות וציון מה בדיוק צריך לזוז ומה נשאר סטטי.
- רשימת דרישות. פלטפורמות, גרסאות מערכת מינימליות, מגבלות על משקל האפליקציה וצריכת סוללה, רפרנסים לאנימציות — ומה בהם מוצא חן בעיניכם במיוחד.
- דרישות לוחות זמנים. עד איזה תאריך נדרשת המהדורה, האם יש קישור לאירוע חיצוני, האם אתם מוכנים לקבל בניות ביניים עם שינויים חלקיים.
בסיום אתם מקבלים הערכה ותוכנית עבודה: שלבים, מה אנחנו עושים, מה נדרש מהצוות שלכם, והצעד הבא עם תאריך. תארו את המשימה — נחזור עם הצעה.