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