אם לא מקפידים על כללים מסוימים, העבודה עם תמונות עלולה לגרום לבעיות בביצועים. כשעובדים עם מפות סיביות גדולות, קל מאוד להיתקל בOutOfMemoryError
. כדי להבטיח שהאפליקציה תפעל בצורה הכי טובה, מומלץ לפעול לפי השיטות המומלצות הבאות.
טוענים רק את הגודל של מפת הסיביות שצריך
לרוב הסמארטפונים יש מצלמות ברזולוציה גבוהה שמפיקות קובצי תמונה גדולים. אם אתם מציגים תמונה במסך, אתם צריכים להקטין את הרזולוציה של התמונה או לטעון את התמונה רק עד לגודל של מאגר התמונות. טעינה קבועה של תמונות גדולות יותר מהנדרש עלולה לגרום למיצוי של מטמון ה-GPU, וכתוצאה מכך לעיבוד פחות יעיל של ממשק המשתמש.
כדי לנהל את גדלי התמונות:
- כדאי להקטין את קובצי התמונות ככל האפשר (בלי להשפיע על תמונת הפלט).
- כדאי לשקול להמיר את התמונות לפורמט WEBP במקום לפורמט JPEG או PNG.
- מומלץ לספק תמונות קטנות יותר לרזולוציות מסך שונות (ראו טיפ מספר 3),
- משתמשים בספרייה לטעינת תמונות, שמקטינה את התמונה כך שתתאים לגודל התצוגה במסך. כך אפשר לשפר את ביצועי הטעינה של המסך.
מומלץ להשתמש בווקטורים במקום במפות סיביות (bitmap) כשזה אפשרי
כשמציגים משהו באופן חזותי על המסך, צריך להחליט אם אפשר להציג אותו כווקטור או לא. עדיף להשתמש בתמונות וקטוריות ולא במפות סיביות, כי הן לא עוברות פיקסול כשמשנים את הגודל שלהן. עם זאת, לא כל דבר יכול להיות מיוצג כווקטור – אי אפשר להמיר תמונות שצולמו במצלמה לווקטור.
אספקת משאבים חלופיים לגדלים שונים של מסכים
אם אתם שולחים תמונות עם האפליקציה, כדאי לספק נכסים בגדלים שונים עבור רזולוציות שונות של מכשירים. השימוש בפורמט הזה יכול לעזור להקטין את גודל ההורדה של האפליקציה במכשירים ולשפר את הביצועים, כי תמונה ברזולוציה נמוכה תיטען במכשיר עם רזולוציה נמוכה. למידע נוסף על הוספת מפות סיביות חלופיות לגדלים שונים של מכשירים, אפשר לעיין במאמר בנושא מפות סיביות חלופיות.
כשמשתמשים ב-ImageBitmap
, מתקשרים אל prepareToDraw
לפני שמציירים
כשמשתמשים ב-ImageBitmap
, כדי להתחיל את תהליך ההעלאה של הטקסטורה ל-GPU, צריך להתקשר אל ImageBitmap#prepareToDraw()
לפני שמציירים אותה בפועל. כך המעבד הגרפי יכול להכין את הטקסטורה ולשפר את הביצועים של הצגת רכיב ויזואלי על המסך. רוב הספריות לטעינת תמונות כבר מבצעות את האופטימיזציה הזו, אבל אם אתם עובדים עם המחלקה ImageBitmap
בעצמכם, כדאי לזכור את זה.
מומלץ להעביר Int
DrawableRes
או כתובת URL כפרמטרים לרכיב הניתן להרכבה במקום Painter
בגלל המורכבות של העבודה עם תמונות (לדוגמה, כתיבת פונקציית שוויון עבור Bitmaps
תהיה יקרה מבחינת חישובים), ה-API של Painter
לא מסומן במפורש כסיווג Stable. מחלקות לא יציבות עלולות לגרום להרכבות מחדש מיותרות, כי קומפיילר לא יכול להסיק בקלות אם הנתונים השתנו.
לכן, עדיף להעביר כתובת URL או מזהה של משאב שאפשר לצייר כפרמטרים לקומפוזיציה, במקום להעביר Painter
כפרמטר.
// Prefer this:
@Composable
fun MyImage(url: String) {
}
// Over this:
@Composable
fun MyImage(painter: Painter) {
}
לא כדאי לאחסן מפת סיביות בזיכרון יותר זמן מהנדרש
ככל שטוענים יותר מפות סיביות לזיכרון, כך גדל הסיכוי שייגמר הזיכרון במכשיר. לדוגמה, אם טוענים למסך רשימה גדולה של רכיבי Image שאפשר להוסיף, כדאי להשתמש ב-LazyColumn
או ב-LazyRow
כדי לוודא שהזיכרון מתפנה כשגוללים ברשימה גדולה.
לא מומלץ לארוז תמונות גדולות עם קובץ ה-AAB או ה-APK
אחת מהסיבות העיקריות לגודל גדול של קובץ להורדה של אפליקציה היא גרפיקה שנארזת בתוך קובץ ה-AAB או ה-APK. כדי לוודא שלא אורזים קובצי תמונה גדולים מהנדרש, אפשר להשתמש בכלי APK analyzer. אפשר להקטין את הגודל של התמונות או להעלות אותן לשרת ולהוריד אותן רק כשצריך.
מומלץ עבורך
- הערה: טקסט הקישור מוצג כש-JavaScript מושבת
- ImageBitmap לעומת ImageVector {:#bitmap-vs-vector}
- שמירת מצב ממשק המשתמש בכתיבה
- שלבים ב-Jetpack פיתוח נייטיב