הכנת נכסי Android: mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi

הכנת נכסים ל-Android: היכן הגרפיקה נשברת בגרסה

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

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

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

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

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

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

מה נותן סט נכסים מנוהל לאפליקציית מובייל

צפיפויות המסך הן כפולות של הבסיסית: mdpi, hdpi, xhdpi, xxhdpi ו-xxxhdpi — זה צעד של 1×, 1.5×, 2×, 3× ו-4×.

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

מקור אמת משותף לפלטה, לפינות מעוגלות ולעובי קווים שומר על סגנון ממשק אחיד; את אותה לוגיקת סקיילינג מתאר Material Design.

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

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

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

דחיסת תמונות בלי אובדן איכות אנחנו בודקים בהשוואה לתקן במסכי בקרה, ולא «בעין», ורק אחרי זה מקבעים את המקדם בכללי ה-build.

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

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

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

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

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

שלבי יישום: ממלאי ועד מסירה לצוות

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

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

סטים של גרפיקה, כללי חיתוך ותקנוני מסירה

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

• מבנה ספריות משאבים: הסטים מסודרים לפי צפיפויות — מ-mdpi עד xxxhdpi, בנפרד קבוצות כלליות ונושאיות. גרפיקה חדשה נכנסת לענף שלה, ולא מתפשטת בשורש הפרויקט.
• כללי שמות לקבצים: רק לטינית, אותיות קטנות, קידומת לפי מסך וסיומת לפי צפיפות ומצב — רגיל, לחוץ, לא זמין. שם הקובץ בעצמו מסביר את הייעוד, בלי להיכנס לעיצוב.
• מפת משאבים: טבלה «רכיב ממשק → קובץ → היכן בשימוש». לפיה כל רכיב נמצא תוך דקה, ולא בחיפוש בכל הספרייה.
• רכיבים וקטוריים ונמתחים: אייקונים ורקעים נמסרים בצורה ניתנת לעריכה, עותקי רסטר נשארים רק היכן שצריך מרקם. זה מסיר את הצורך לבנות מחדש לרזולוציות חדשות.
• תקנון עדכון גרפיקה: מי יוזם בנייה מחדש, אילו צפיפויות נבנות מחדש, איך בודקים שסטים מיושנים הוסרו ולא מונחים ליד החדשים.
• תיעוד למשאבים: ייעוד הערכה, מגבלות על מספר ומשקל קבצים למסך — ה-build מפסיק לגדול מגרסה לגרסה.
• קבצי מקור ומאסטר: שכבות, קווים מנחים, טקסט בלי רסטר. כל עריכה נעשית לפי המאסטר, בלי אובדן איכות ורינדור חוזר.

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

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

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

מה עשינו

• פרשנו את הגרפיקה לחמישה סטים של צפיפות — mdpi, hdpi, xhdpi, xxhdpi ו-xxxhdpi — כדי שהמערכת תיקח קובץ מוכן בקנה המידה הנדרש, ולא תחשב אותו תוך כדי.
• אייקונים, מחוונים ורכיבים קוויים הועברו לווקטור: הם הפסיקו להיות תלויים בצפיפות המסך לחלוטין.
• רקעים וכפתורים נמתחים נאספו לתמונות בתשעה חלקים — במקום עשרה איורים נפרדים לכל מצב.
• כתבנו כללי ייצוא ישירות בעיצובים של Figma, כדי שמסכים חדשים לא יחזירו את הבעיה.
• ניקינו כפילויות וקבצים לא בשימוש, והותרנו לכל משאב לוגי מקור אחד בדיוק.

תוצאה

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

במה גרפיקה וקטורית נבדלת מרסטר בפרויקט

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

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

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

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

ספקות טכניים שכדאי להסיר לפני ההתחלה

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

האם אפשר להחליף גרפיקה בלי להוציא גרסה חדשה?

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

אין לנו עיצובי מקור — רק צילומי מסך

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

האם ערכת נושא כהה היא סט גרפיקה שני?

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

נדון במשימה: מה לשלוח להערכת היקף העבודה

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

• קבצי מקור בווקטור או בשכבות: קובצי מאסטר של אייקונים, לוגואים, איורים — עם שכבות נפרדות, ולא עותקים «שטוחים».
• רשימת צפיפויות: האם צריך mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi במלואן או שמשהו מסתפק בשני־שלושה סטים.
• רשימת מסכים ומצבים: היכן הנכס מופיע, באיזה גודל, עם אילו וריאציות — לחוץ, כבוי, טעינה, שגיאה.
• אייקון האפליקציה ורכיבי מערכת: סמל ראשי, וריאציות אדפטיביות ועגולות, רקע עם שכבה קדמית, תמונה לחנות.
• דרישות לפורמטים: שקיפות, WebP או PNG, משקל קובץ מותר ואובדן איכות בדחיסה.
• ערכת נושא כהה, ערכות עיצוב נוספות וגרסאות שפה — אם יש יותר מעיצוב אחד.
• רפרנסים ומערכת עיצוב: פלטה, רשת, מרווחים, ייצואים שכבר נאספו — כדי לא לבנות מחדש את מה שעובד.

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