ייצוא נכסי PDF ל-iOS: היכן נשברת הרינדור
סמל רסטרי נשמר ברשת פיקסלים קבועה, אך מסכים שונים בצפיפותם. אותו קובץ, שנמתח לקנה מידה אחר, מטושטש על ידי אינטרפולציה: הקצוות מאבדים חדות, קווים דקים מתמזגים, ובחלק מהמכשירים מתקבלים סמלים מרוחים במסכים שונים. לכן הכנת גרפיקה ל-iOS מתחילה לא בחיתוך, אלא בבחירת פורמט אחסון.
חיתוך ידני של גדלים מכסה זאת רק כלפי חוץ. המעצב מספק מספר מכפילים לכל סמל, המכפילים מחושבים מחדש באופן ידני, והוספת סמל אחד חוזרת על כל המחזור. עובי הקו בסקיצה השתנה — הרשת נבנית מחדש, והפער בין המכפילים מתגלה כבר במכשיר חי.
משקל הבנייה של האפליקציה בגישה זו גדל באופן לינארי ממספר המכפילים. אותו סמל מונח בהפצה מספר פעמים, קטלוג הנכסים מתרחב, ומסכים חדשים לא מתווספים. ייצוא נכסי PDF מסיר את שתי המגבלות: מתאר וקטורי נשמר פעם אחת ומרונדר לצפיפות המסך הנדרשת במקום. הסמל נשאר חד גם במסך קומפקטי וגם במסך גדול, ובפרויקט מונח קובץ מקור אחד במקום סט קבצים.
להלן נבחן היכן בדיוק נשברת הרינדור בעת העברת וקטור לקטלוג, כיצד מוגדר כלל הרינדור ואילו פגמים של המתאר המקורי צפים כבר לאחר הבנייה.
מה משתנה לאחר המעבר לסטים וקטוריים של גרפיקה
בעבר כל סמל חי בפרויקט כסט חיתוכים רסטריים לצפיפויות מסך שונות: בנפרד למכשירים קומפקטיים, בנפרד לגדולים. החלפת חלק אחד חייבה ייצוא חדש של כל הסט, סיכון לשכוח גודל וחוסר סנכרון בין הסקיצה לאפליקציה.
עם סטים וקטוריים של גרפיקה, מקור הסמל האחיד הוא PDF בקטלוג הנכסים, והמערכת בונה את קני המידה הדרושים בעצמה בעת הרינדור.
מכאן רינדור ממשק יציב: וקטור לא 'מרוח' ולא נחתך בקני מידה חלקיים, ונראה זהה במכשירים נוכחיים ועתידיים. בד בבד נעלם סוג שלם של פגמי פריסה — שוליים שהתפרקו לאחר עריכת הסקיצה, גרסאות שונות של אותו רכיב במסכים סמוכים, חדות שאבדה לאייקונים קטנים.
הפחתת משקל הבנייה היא תוצאה של אותו סדר. במקום ארבעה-חמישה קבצי רסטר לרכיב, נשאר וקטור קומפקטי אחד, ובספריית סמלים גדולה זה חלק ניכר מהארטיפקט, ומאגר קבצי המקור מפסיק להתרחב בעותקים לכל גודל.
אנו מקפידים על כלל ההפרדה: וקטור — לסמלים, לאייקונים ולגרפיקה לינארית, רסטר — לתמונות ולאפקטים מורכבים עם צללים ומצבי מיזוג, אשר ב-PDF מועברים באופן בלתי צפוי.
המעצבים מוסרים קבצי מקור מ-Figma כבר בפורמט הנדרש, והבנייה בודקת את הקטלוג לאלמנטים שבורים ומיותרים — פערים נראים לפני השחרור, ולא באפליקציה המוגמרת.
דרכים להכנת גרפיקה: השוואת אפשרויות עבודה
כאשר סקיצה בנויה מסמלים וצורות פשוטות, אופן אחסון הגרפיקה קובע כמה שוקלת הבנייה וכמה עבודה ידנית תושקע בכל שינוי. וקטור, סט גדלים רסטריים ורינדור בקוד נותנים תוצאה זהה על המסך, אך נבדלים בתחזוקה: אפשרות אחת שורדת החלפת צפיפויות בלי קבצים חדשים, האחרת — לא.
מה בוחרים בפועל
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| וקטור בקטלוג הנכסים | סמלים, לוגואים, גרפיקה לינארית, אלמנטים שמתאימים לקנה מידה לכל צפיפות | לא מתאים לפוטוריאליזם, צללים רכים, טקסטורות רסטריות וגרדיאנטים מורכבים — עובר רסטריזציה בשלב הבנייה, ולא בהרצה |
| סט גדלים רסטריים | תמונות, צילומי מסך, איורים עם רעש ושקיפות חלקית | כל צפיפות חדשה — קובץ נפרד וייצוא נפרד; משקל הבנייה גדל ביחס למספר הווריאציות |
| רינדור בקוד | צורות פשוטות, מחוונים, אלמנטים שמשנים צבע וגודל לפי מצב | מוגבל ליכולות הרינדור; לשכפל צורה מורכבת בקוד יקר יותר מאשר לייצא קובץ מקור פעם אחת |
ההבדל מתגלה בעריכות: באפשרות הווקטורית משתנה קובץ מקור אחד, רסטר דורש לבנות מחדש את כל סדרת הגדלים, וקוד — לסנכרן את הצורה עם הסקיצה ידנית. לכן סט משולב הוא הנורמה: וקטור לסמלים, רסטר לתוכן, קוד לאלמנטים דינמיים.
שלבי יישום: מביקורת קבצי מקור ועד מסירה
סדר העבודות בנוי כך שפגמי גרפיקה יתגלו בשלבים מוקדמים, שבהם התיקון אורך שעות, ולא הופך לבנייה מחדש של השחרור. תחילה מתעדים את מצב הקטלוג הנוכחי, אחר כך קובעים כללים ורק לאחר מכן מפעילים המרה גורפת.
סדר העבודות
- ביקורת קטלוג הנכסים. עורכים מלאי של קבצי המקור, מסמנים כפילויות, מצבי כפתורים מיושנים ואלמנטים ללא רקע שקוף. בפלט — מפה: מה עובר לוקטור, מה נשאר רסטר ולמה.
- סכמת שמות לגרפיקה. קובעים פורמט אחיד לשמות לפי תפקיד הרכיב, גודל ומצב, כך שהמעצב והמפתח יפנו לאותו משאב. זה מסיר חיפוש ידני וחוסר סנכרון בין הסקיצה לקוד.
- המרה לוקטור. מעבירים אלמנטים מתאימים ל-PDF תוך שמירה על שכבות ושקיפות, ומסירים שוליים מיותרים. הקטלוג מפסיק להחזיק מספר עותקי רסטר לגדלי מסך שונים.
- בדיקה במכשירים. מריצים מסכים מרכזיים במכשירים אמיתיים מדורות שונים: בודקים חדות בהגדלה, דיוק צבעים והתנהגות במצב כהה.
- תקנון עדכון גרפיקה. מתארים כיצד להוסיף אלמנטים, מי אחראי על ההמרה ואילו בדיקות מתבצעות לפני השחרור.
- מסירה. מוסרים את הפרויקט, סכמת השמות והוראות קצרות, כדי שהצוות ימשיך לעבוד עם הגרפיקה בלעדינו.
מה מוסרים לידיים: קטלוג, סכמות ותקנונים
מסירת גרפיקה אינה תיקייה עם תמונות, אלא ערכה שלפיה הצוות משחזר את הבנייה בלי הסכמות בעל פה. להלן מה בדיוק נמסר ללקוח יחד עם האפליקציה ולפי אילו מסמכים הגרפיקה מתנהלת לאחר מכן.
- קטלוג נכסים בנוי. קבצי מקור וקטוריים מסוג PDF, מסודרים לפי סטים עם קני מידה ומצבי רינדור תקינים; הבנייה לוקחת גרפיקה ישירות ממנו, בלי ייצוא ביניים והחלפת קבצים ידנית.
- מבנה הקטלוג. עץ תיקיות לפי מודולים וייעוד, עם הפרדה בין משאבים משותפים למשאבי מסך: רואים מה אפשר לשנות בלי לפגוע במסכים אחרים.
- כללי שמות. סכמה אחידה בצורה «ייעוד_מצב_קנה מידה», איסור על רווחים ורישיות שונה, הגנה מכפילויות — השמות תואמים לשמות בסקיצות, וחיפוש משאב אורך שניות.
- סכמת קשרים בין מסכים לגרפיקה. מפה שבה מסומן איזה משאב משמש באילו מסכים — לפני עריכה רואים מיד את רדיוס השינויים.
- תיעוד גרפיקה. פלטה, רשתות ושוליים, גדלי אזורים פעילים, מצבי כפתורים ושדות, כללי מצב כהה: המפתח לא משחזר זאת לפי הסקיצה.
- הוראות למעצבים. כיצד לייצא וקטור, אילו שכבות לאחד, כיצד לבדוק מתארים ומילויים, ומה לוודא לפני מסירה לבנייה.
- תקנון הוספת סמלים. מי יוזם, דרך איזה ענף עוברת העריכה, מי בודק, כיצד מתעדכן קטלוג הנכסים וכיצד לחזור לגרסת הגרפיקה הקודמת.
הערכה מכסה סיכון אופייני: העיצוב עובר לצד חיצוני או שמחליפים ספק, והגרפיקה ממשיכה להיבנות לפי מסמך, ולא לפי הזיכרון של אדם מסוים.
מקרה בוחן: הסרנו סמלים מטושטשים והאצנו את הבנייה
מה היה לפני
הלקוח — שירות משלוחים עם אפליקציה ל-iOS. בסט המשאבים היו כ-60 סמלים ואיורים, כל אחד יוצא בחמישה גדלים לצפיפויות מסך שונות — יותר מ-280 קבצים, המקושרים לקוד ידנית.
עריכת סמל אחד חייבה ייצוא מחדש של כל הסט, ובמסכים חדשים חלק מהתמונות נראו מטושטשות: רסטר מתוח נתן קצוות לא אחידים ופינות מעוגלות מרוחות.
מה שינו
העברנו את הגרפיקה לוקטור: קובץ PDF אחד לרכיב, את הגודל הסופי המערכת בוחרת בעצמה בעת הרינדור. בהגדרות הסט הפעלנו שמירת נתונים וקטוריים ומצב שבו הסמל נשאר חד בכל צפיפות. המעצבים מוסרים קובץ אחד במקום חמישה — Xcode בונה מהם קטלוג אחיד בלי שיוך ידני של כל גודל.
מדדים לפני ואחרי
- קבצים בסט: 280+ ← 60, מקור אמת אחד לסמל.
- זמן בניית האפליקציה בשרת הבנייה: הצטמצם בכשליש בערך — עיבוד של מאות עותקי משאבים מיותרים הוסר.
- פניות על פגמי רינדור: מ-10–12 בחודש ל-1–2, וגם אלה לא על גרפיקה.
- עריכת סמל: החלפת קובץ אחת במקום חמישה ייצואים ובדיקה ידנית של קשרים.
חודש לאחר המעבר, צוות הלקוח הסיר שלב נפרד של ייצוא גרפיקה מתהליך השחרור. הזמן שהתפנה הוקדש לפונקציונליות, ולא לניתוח ארטיפקטים ובדיקות חוזרות במכשירים.
במה שונה מתאר PDF מסט רסטרי בעת שינוי קנה מידה?
מתאר PDF שומר גיאומטריה: קווים, עקומות, מילויים וסדר ההלבשה שלהם. אין בו רשת נקודות קבועה, לכן בעת שינוי קנה מידה המערכת מחשבת מחדש את הצורה לגודל הנדרש ורק אחר כך מרנדרת אותה. הסמל מגיע למספר הנקודות הרצוי — ולא נוצר על ידי מתיחת וריאציה סמוכה.
סט גדלים רסטרי בנוי אחרת: אלה תמונות שנחתכו מראש לכל מכפיל צפיפות מסך. כל עוד הצפיפות המבוקשת תואמת לתבנית, חדות הסמלים מושלמת. אבל במצב ביניים — קנה מידה מערכתי מוגדל, גודל ממשק לא תקני — אין קובץ מתאים, ונלקח הקרוב ביותר. אינטרפולציה מטשטשת קצוות, קווים דקים ופרטים קטנים מתמזגים.
משקל — תוצאה של אותה טבע נתונים. מתאר משרת את כל הצפיפויות בקובץ אחד: מסך חדש לא מגדיל את החבילה. סט רסטרי גדל באופן לינארי, כל מכפיל מונח כעותק נפרד, וגזירת וריאציות מיותרות היא פשרה בין משקל לחדות במכשירים ספציפיים.
גם למתאר יש מחיר: הוא מרונדר במכשיר, וצללים רכים, גרדיאנטים ושקיפות חלקית בעת וקטוריזציה מתנהגים באופן בלתי צפוי — ולעיתים קרובות הם בכל זאת מומרים לרסטר. מכאן פרקטיקה משולבת: גיאומטריה פשוטה, לוגואים וסמלי ממשק מרוויחים ממתאר, איורים פוטוריאליסטיים יציבים יותר בסט רסטרי. כדאי לבדוק בכל הצפיפויות שהאפליקציה תומכת בהן.
ספקות טכניים: מפרקים שאלות נפוצות
קווים דקים, סמלים ומצב כהה — מה שבדרך כלל מעכב את המעבר של גרפיקה ל-PDF וקטורי. להלן שאלות שנשאלות לפני תחילת העבודה והתשובות שלנו לכל אחת.
מדוע מופיעים ארטיפקטים על קווים דקים?
קווים דקים מפיקסל המסך עוברים רסטריזציה בעת הרינדור. אנו מגדירים קווים ביחידות וקטוריות ובודקים את התוצאה בקני מידה שונים — המתארים נשארים אחידים.
יש לנו כבר סטים רסטריים — הכול לעשות מחדש?
לא. הקטלוג מורחב בשלבים: תחילה מעבירים סמלים, שבהם שינוי קנה המידה מורגש ביותר, שאר הסטים פועלים לצדם ומוסרים בהתאם למוכנות.
כיצד גרפיקה מתנהגת במצב כהה?
נדרשים וריאנטים נפרדים: היפוך אוטומטי שובר סמלים מרובי צבעים. אנו אוספים את שתי הגרסאות בסט אחד, המערכת מציבה את הנדרשת בלי מעורבות קוד.
האם סמלים מרובי צבעים ישרדו שינוי קנה מידה?
כן, אם כל צבע מוגדר בשכבה נפרדת ולא מעורבב במתאר אחד. אז הגוונים לא «שוחים» בגדלים גדולים — סיבה נפוצה להחזרות לתיקון.
של מי קבצי המקור נדרשים להחלפת גרפיקה בקטלוג?
אנו עובדים גם עם קבצי מקור מהלקוח וגם עם סקיצות בקווים. אם יש רק קבצי רסטר, המהנדסים שלנו מציירים מחדש את המתארים — זה שלב נפרד בהערכה.
נדון במשימה: נחזור עם הערכה ותוכנית עבודה
כדי שהערכת היקף העבודה תהיה עניינית ולא מקורבת, להתחלה די בגישה למאגר או לארכיון הפרויקט, בסט קבצי מקור של נכסים וברשימת מכשירים וגרסאות מערכת נתמכים. אם הייצוא כבר מוגדר — הראו את הנתיב הנוכחי: כיצד סקיצה וקטורית הופכת ל-PDF ומגיעה לקטלוג הנכסים.
בהמשך נבהיר פרטים: באיזה שלב בנייה נוצרים הנכסים, מי הבעלים של קבצי המקור, מהן הדרישות לשינוי קנה מידה למסכים שונים וכיצד בנוי מחזור השחרור. בנפרד נדון בנסיגה — מה קורה לסמלים ולתמונות אם הבנייה תוחזר לגרסה קודמת.
- הערכת היקף העבודה לפי שלבים: מלאי נכסים, הגדרת ייצוא, בדיקה במכשירים מיועדים;
- תוכנית יישום עם סדר שלבים ונקודות שבהן נדרש משוב מהצוות שלכם;
- הרכב העבודות עם גבול אחריות: מה אנחנו מכסים, מה נשאר בצד המפתחים שלכם;
- סכמת קטלוג נכסים וכללי שמות, כדי שסקיצות חדשות ייכנסו אליו בלי עריכה ידנית;
- רשימת בדיקות: כיצד לוודא שנכסי PDF נבנים ומוצגים כראוי בכל התצורות;
- אפשרות להשקה מדורגת, אם אי אפשר לעצור את השחרור בזמן השינוי;
- לוח זמנים לכל שלב ודרישות גישה שיידרשו בהתחלה.
תארו את המשימה בצורה חופשית — עם קישור לפרויקט או דוגמה לנכס בעייתי. נחזור עם הערכה ותוכנית עבודה, ואת הנקודות השנויות במחלוקת נדון בשיחה עם המהנדס שילווה את הפרויקט.