הכנה וניקוי SVG לאפליקציות מובייל

ייצוא SVG לאפליקציות מובייל: היכן אובדת האיכות

מעצב מוסר אייקון שיוצא מהעורך כפי שהוא — והוא מפסיק להתאים לגריד. הסיבה לרוב נמצאת באזור העבודה (artboard): הקובץ נושא רוחב וגובה קבועים במקום viewBox, קואורדינטות הנתיבים מגיעות עם ארבע ספרות אחרי הנקודה, והקבוצה עצמה מורמת מעל הקנבס. בהטמעה אייקון כזה נחתך פעם מימין ופעם מלמטה, ובפריסה הוא יושב בסטייה של חצי פיקסל מהאלמנטים השכנים.

אובדן איכות של גרפיקה רק לעיתים רחוקות קשור לפורמט עצמו. את הווקטור שוברות קווי מתאר שהופכים בזמן הקטנה לקו דק כחוט השערה; טקסט שהושאר כבלוק טקסט ודורש גופן שאינו קיים במכשיר; תוספות ראסטר בתוך הקובץ; מסכות, פילטרים וטשטושים שחלק מהפלטפורמות אינן משחזרות. כל זה עולה בבילד, ולא בפריסה, ולכן מתגלה מאוחר.

ערכת נושא כהה — נקודת כשל נפרדת. אייקון עם מילוי כהה מוקשח על רקע כהה הופך לבלתי נראה, ורקעית בהירה בתוכו שוברת את הקומפוזיציה. זה נסגר לא בערכה שנייה של קבצים, אלא במילוי שיורש את צבע הממשק ובעובי קווים אחיד.

סעיף ההוצאות השלישי — משקל הבילד של האפליקציה. בקבצים נשארים שכבות מוסתרות, מטא-נתוני שירות של העורך, חיתוכים שאינם בשימוש; באיחוד של עשרות אייקונים לערכה אחת מזהים חוזרים על עצמם, וחלק מהפלטפורמות מציירות בשקט צורה לא נכונה.

לכן הכנת אייקונים הופכת לתהליך שוטף: גריד אחיד, צבע מילוי ניטרלי, ניקוי קווים מיותרים ובדיקה אוטומטית לאי-התאמות בכל עדכון של הערכה — ולא ייצוא ידני חד-פעמי.

להלן נפרק כיצד לבנות את התהליך כך שהתוצאה לא תהיה תלויה בקפדנות של מעצב בודד.

מה משתנה לאחר הכנה נקייה של גרפיקה וקטורית

הניקוי מתחיל במיפוי מלאי: מה באמת נכנס לבילד — מטא-נתוני העורך, שכבות מוסתרות, קבוצות כפולות, הגדרות שאינן בשימוש, קואורדינטות שבריות. אופטימיזייטור כמו SVGO מסיר את רוב זה אוטומטית, אבל חלק מהתיקונים נשארים ידניים — אחרת הפישוט אוכל את הזיהוי של האייקון בגדלים קטנים. לאחר הדחיסה מספר הצמתים בעץ הנתיבים יורד פי 2-3, וערכת הגרפיקה בבילד — ב-40-60%.

האפקט השני — גרפיקה אדפטיבית. כש�לאייקון אין מידות מוקשחות, והפרופורציות נשמרות בגריד אחיד, הוא מצויר באותה חדות גם על מסך קומפקטי, גם על טאבלט, וגם בהגדלת גופן מערכתית. אין צורך בעותקי ראסטר לרזולוציות נפרדות — הבילד לא גדל עם כל צפיפות מסך חדשה.

השכבה השלישית — ביצועי הממשק ויציבות הציור. פחות נתיבים — הצגת המסך הראשונה מהירה יותר, מעברים ואנימציות מגיבים יותר, וההפעלה הקרה מעניקה לגרפיקה פחות זמן באופן מורגש.

שיעור כשלי הציור — אייקון שנעלם, ריבוע שחור במקום סמל, אנימציה שנשברה במכשיר חלש — שואף לאפס: בפריסה לא נשארות מבנים שפלטפורמות תומכות בהם באופן שונה.

הכלל פשוט: בודקים את הווקטור לפני שהוא נכנס לפריסה, ולא אחרי כשל בייצור. אז המשקל, המהירות והצפויות של הגרפיקה נראים בדוח הבילד, ולא בתחושות.

אופטימיזציה של SVG: גאומטריה, פלטה וקווים

ייצוא מעורך גרפי כמעט תמיד מוסר יותר ממה שצריך: קבוצות מקוננות, שכבות מוסתרות, מטא-נתוני שירות וקווים בעובי שונה. בצד האפליקציה זה הופך למשקל בילד מיותר ולאייקונים שנראים שונים באותו תפקיד — חלק מהקווים דקים יותר, חלק מוזזים בשברי גריד, חלק לא נצבעים מחדש בהחלפת ערכת נושא. ההבדל בין אפשרויות ההכנה אינו בקפדנות הביצוע, אלא באופן שבו הערכה מתנהגת כשהמוצר מתרחב.

אופטימיזציה של SVG נתקלת במגבלות בצד האפליקציה: את הקווים יש לתרגם לעקומות, אחרת הרינדור תלוי במימוש והאייקון "שט" בפלטפורמות שונות, והפלטה מצטמצמת לערכה קצרה של צבעים — ואז ערכת הנושא מוחלפת בהחלפת משתנה אחד, בלי ערכה שנייה של קבצים. לכן ניקוי הקווים ופלטת האייקונים נעשים פעם אחת ככלל, ולא כניקוי חד-פעמי לפני ייצור.

כיצד אנו מכינים גרפיקה: שלבי העבודה ההנדסית

סדר העבודות זהה לאפליקציה חדשה ולפרויקט שמתפתח שנים: תחילה מקבעים את מה שכבר נמצא במאגר, אחר כך משנים, ורק לאחר מכן מעבירים את הכללים לצוות. כך אפשר לתקן את הגרפיקה בלי חשש שהפריסה תתפרק או שחלק מהאייקונים ילכו לאיבוד.

1. מיפוי הגרפיקה. סופרים את כל קבצי הווקטור בפרויקט, מסמנים כפילויות בשמות שונים, תמונות ראסטר מוטמעות בתוך הווקטור, אייקונים בלי סגנון אחיד. התוצאה — מפת הערכה עם רשימת בעיות לכל מסך.
2. סכמת שמות. האייקון מקבל שם לפי תפקידו בממשק, קבוצת המידות וערכת העיצוב. זה מסיר תיקונים "לפי העין" וקונפליקטים במיזוג ענפים.
3. ניקוי קבצים. מסירים שכבות מוסתרות, קבוצות ריקות, תמונות וסגנונות מוטמעים, וחוצצים את הקנבס לפי הציור בפועל. הקובץ קטן פי כמה, המראה לא משתנה.
4. צינור בניית הנכסים. האופטימיזציה והאחידות מופעלות אוטומטית עם הוספת קובץ, ולא ידנית. בפלט — וריאנטים מוכנים לערכת נושא כהה ולצפיפויות מסך שונות.
5. בדיקת אייקונים. מעבר על ערכות המסכים והמצבים של האלמנט: מילואים, קווים, התנהגות בהחלפת צבע, מידות אופטיות. שגיאות צפות לפני הייצור, ולא לפי תלונות משתמשים.
6. מסירת הנוהל. כללי השמות, דרישות לקבצי מקור, סדר ההטמעה וצוות הבילד מתוארים בקצרה ובאופן חד-משמעי. אייקון חדש עובר את אותו מסלול בלי מעורבות מפתח.

ערכת מסירה: קבצי מקור, כללים, נוהל עדכונים

ערכת מסירה היא לא ארכיון של תמונות, אלא מערכת כללים עובדת: לפיה המעצב שלכם או קבלן חיצוני יוסיף אייקון בלי לשבור את הפריסה ובלי לחזור אלינו בשאלות. אנחנו מרכיבים אותה כך שכל תיקון בגרפיקה יהיה פעולה צפויה, וקבצי המקור ב-Figma יישארו בחשבון שלכם, ולא רק אצלנו.

• קבצי מקור מטוהרים: מכל קובץ הוסר המיותר — שכבות מוסתרות, מטא-נתוני העורך, מסכות מקוננות, קווים כפולים. נשאר קו שמצויר באופן זהה גם במארקאפ וגם במנוע הווקטורי של הפלטפורמה.
• מבנה תיקיות הפרויקט: הנכסים מסודרים לפי מודולים ולפי צפיפות מסך, שמות התיקיות תואמים לשמות המסכים בפריסות — קובץ חדש נופל למקום ברור.
• כללי שמות לנכסים: סכמה "מודול_פונקציה_מצב", אותיות קטנות בלבד, בלי רווחים ובלי תעתיק; משם הקובץ מיד ברור היכן הוא משמש.
• מפת התאמה: טבלת "מקור → נכס באפליקציה → מסך", ולפיה התיקון הנדרש נמצא תוך דקה, ולא תוך שעה של חיפוש בקוד.
• נוהל עדכון הגרפיקה: מתואר מי, מתי ובאיזה אופן שולח אייקונים חדשים, כיצד מתאשרת ההחלפה ומה קורה לערכות ישנות.
• בדיקות בזמן בילד: בקרת תקינות המארקאפ, הגודל והכפילויות — נכס שבור או מנופח נופל בבילד, ולא בייצור.
• גרסאות של הערכה: אפשר להחזיר את ערכת האייקונים הקודמת בלי לבנות מחדש פריסות, והחזרה לאחור אינה הופכת למשימה נפרדת.

נוהל העדכון — הסעיף הכי פחות מוערך: בלעדיו, כעבור חצי שנה חיים בפרויקט שלושה סגנונות שונים לאותו אייקון, וכל תיקון חדש עולה יותר. הערכה סוגרת את זה מראש — הגרפיקה מפסיקה להיות צוואר בקבוק במסירת משימות.

מקרה בוחן: כיצד ניקוי הווקטור צמצם את משקל הבילד

לפני: כיצד הצטבר המשקל

אלינו הגיעה אפליקציה עם קטלוג גדול: ערכת אייקונים ואיורים קטנים נאספה במשך שנים, וכל ייצור הוסיף ייצואים טריים מהפריסות ב-Figma. הקבצים גררו אחריהם קבוצות מקוננות, שכבות מוסתרות, קווים, מסכות חתוכות וראסטר מוטמע — בחלק מהמסכים זה יצר ארטיפקטים נראים לעין ועבודה מיותרת בציור.

מדידות לפני העבודה: ערכת הגרפיקה שקלה יותר מכל שאר הגרפיקה של האפליקציה יחד, מדור הקטלוג נפתח לאט באופן מורגש מהמדורים השכנים, ושיעור הפניות לתמיכה על ציור לקוי — קצוות חתוכים, קווים מטושטשים, גאומטריה שהתפרקה — עמד על אחד מכל ארבעה.

אחרי: מה השתנה בבילד

הניתוח הראה שהסיבה אינה בווקטור עצמו, אלא באופן שבו הוא נכנס לבילד. קיבענו כלל ייצוא אחיד: אייקון אחד — קבוצה אחת בלי קינון, עקומות במכל משותף, קווים מתורגמים למילויים, צמתים מיותרים נחתכים, תוספות ראסטר או מוקטרות או מוצאות כנכס נפרד. מעל זה הוצבו בדיקות שלא מכניסות קובץ עם שכבות מוסתרות, מסכות מקוננות או שם מחוץ לתבנית.

משקל הנכסים ירד בערך פי שישה, הקטלוג נפתח בקצב של שאר המדורים, והפניות על ציור לקוי ירדו למקרים בודדים. תופעת הלוואי התבררה כחשובה מהמספרים עצמם: אייקון חדש מתווסף בייצוא אחד בלי תיקון ידני, וגודל הבילד הפסיק לגדול מייצור לייצור.

מה לעשות אם הגרפיקה כבר התפזרה בין בילדים

אם ערכת האייקונים כבר התפזרה בין בילדים, אי אפשר לשכתב אותה במכה אחת: במכשירים של המשתמשים חיים גרסאות קודמות של האפליקציה, והן ממשיכות לבקש שמות נכסים ישנים. המשימה מתפצלת לשתיים בלתי תלויות — לטהר את קבצי המקור ולא לשבור את האפליקציה שכבר יצאה.

הסכמה העובדת — החלפה הדרגתית: אייקונים חדשים מוסיפים תחת שמות חדשים, וישנים נשארים כהפניות אליהם. את שכבת התאימות מסירים כשחלק ההתקנות בגרסאות בלי עדכון יורד מתחת לסף מוסכם — בדרך כלל שניים-שלושה ייצורים.

המגבלה כאן אינה בקבצים עצמם, אלא במטמון ובמשקל הבילד: כל עוד שתי הערכות חיות, האפליקציה כבדה יותר, ובדיקות צילומי המסך צריכות לרוץ על שני ענפי הממשק. תאימות בודקים על מטריצת גרסאות שעוד מוחזקות בידי משתמשים — ואז הניקוי לא הופך לרגרסיה בהתקנות חיות.

את סדר העבודות בוחרים לפי נתונים מהמכשירים: תחילה רואים אילו גרסאות עוד פעילות, אחר כך מקבעים את לוח הזמנים להסרת שמות ישנים. כך הערכה מתפזרת בין בילדים באופן נשלט, ולא נשארת "כמו שהיא" לשנים.

ספקות טכניים: פורמטים, תאימות, לוחות זמנים

ההסתייגויות לגבי גרפיקה מצטמצמות לשלושה סעיפים: האם הווקטור ישרוד גרסאות מערכת ישנות, כיצד למסור רזרבה ראסטרית, ומה יהיה עם אייקונים באפליקציה שכבר יצאה. נפרק כיצד כל אחד נסגר ברמת הבילד וכללי מסירת הנכסים.

איננו מתרגמים את השכבה החזותית בעיוורון. תמונות, טקסטורות ואפקטים מורכבים נשארים בראסטר; אייקוני ממשק, אינדיקטורים, לוגו ותרשימים עוברים לקווים. בפלט — שתי ערכות נכסים וכלל בחירה לפי גרסת המערכת וצפיפות המסך.

כמה זמן לוקחת החלפת ערכת אייקונים באפליקציה חיה?

בדרך כלל מחזור ייצור אחד-שניים, בלי הקפאת שאר העבודה. הנכסים מוחלפים ממוקד: מיפוי מלאי וניקוי קבצי מקור, ייצוא, חיבור, הרצת הממשק ובדיקת גודל הבילד. אין צורך לשכתב מסכים אם מבנה הערכה נשמר.

האם נאבד איכות בהחלפת פורמט הגרפיקה?

הווקטור לא מאבד חדות — קווים, גרדיאנטים ומסכות אינם תלויים בצפיפות המסך. יש להסיר תוספות ראסטר מוטמעות: הן מוסיפות משקל וארטיפקטים בהקטנה. לכן לפני המסירה לפרויקט מבוצע ניקוי — קבוצות מיותרות, שכבות מוסתרות, הגדרות שאינן בשימוש.

נדון במשימה: שלחו ערכת אייקונים ופריסה

כדי לדון במשימה באופן ענייני ולתת הערכה של העבודות, ולא טווח "מכאן ומכאן", נדרשת ערכת קלט. ככל שקבצי המקור מלאים יותר, כך יש פחות הנחות בהערכה ופחות תיקונים בשלב שבו האפליקציה כבר נבנית והגרפיקה יוצאת לייצור.

• אייקונים ואיורים בקבצי מקור וקטוריים — קובץ Figma, Illustrator או Sketch, ולא ייצוא SVG שטוח שבו הצורות איבדו שמות וקשרים.
• רשימת המסכים והמקומות שבהם מופיעה הגרפיקה: ניווט תחתון, סטטוסים, מצבים ריקים, אונבורדינג, ערכת נושא כהה.
• המצבים של כל אייקון — רגיל, פעיל, לא פעיל, לחוץ — אם הם נבדלים חזותית.
• כללי השמות ומבנה התיקיות הנהוגים בפרויקט, או אישור להציע משלנו, כדי שהשמות יתאימו לקוד.
• כיצד הגרפיקה נכנסת לבילד כרגע: ידנית, דרך מאגר משותף או ספריית קומפוננטות.
• מגבלות: היכן נדרשת אנימציה, היכן האייקון חייב להיות זהה בשתי הפלטפורמות, והיכן מותרים הבדלים.
• איש קשר של המעצב או המפתח שיענה על הבהרות בנוגע לשכבות, מסכות וקבוצות.

הניתוח לוקח מעט זמן: המהנדסים שלנו בודקים היכן בקבצי המקור נותרו שכבות מוסתרות, קווים ומסכות מיותרים, כיצד בנויים המילויים ומה מזה ייכנס למשקל האפליקציה.

על סמך התוצאות אנחנו מחזירים הערכת עבודות, תוכנית הכנת הגרפיקה עם סדר השלבים — נרמול שמות, ניקוי, אופטימיזציה, בדיקה על בילד מורכב — הרכב הצוות ותאריך תחילת הפרויקט.