אופטימיזציה של ביצועי התמונות

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

צריך לטעון רק את הגודל של מפת הסיביות הדרוש לכם

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

כדי לנהל את הגדלים של התמונות:

• יש להקטין את קובצי התמונות כך שיהיו קטנים ככל האפשר (בלי להשפיע פלט תמונה).
• מומלץ להמיר את התמונות לפורמט WEBP במקום לקובצי JPEG או PNG.
• כדאי לספק תמונות קטנות יותר לרזולוציות מסך שונות (ראו טיפ מס' 3),
• להשתמש בספרייה לטעינת תמונות, שמגדילה את התמונה כדי להתאים גודל התצוגה שלך על המסך. זה יכול לעזור לשפר את ביצועי הטעינה של במסך.

שימוש בווקטורים במפות סיביות ככל האפשר

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

יצירת משאבים חלופיים למסכים בגדלים שונים

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

כשמשתמשים בפונקציה ImageBitmap, צריך להתקשר למספר prepareToDraw לפני השרטוט

כשמשתמשים ב-ImageBitmap, כדי להתחיל את תהליך העלאת המרקם אל GPU, קוראים לפונקציה ImageBitmap#prepareToDraw() לפני שמשרטטים אותו בפועל. הזה עוזרת ל-GPU להכין את המרקם ולשפר את הביצועים של הצגת ויזואלי במסך. רוב הספריות לטעינת תמונות כבר עושות את האופטימיזציה הזו, אבל אם אתם עובדים בעצמכם עם הכיתה ImageBitmap, מדובר בעבודה חשוב לזכור.

אני רוצה להעביר Int DrawableRes או כתובת URL כפרמטרים לתוכן הקומפוזבילי במקום Painter

עקב המורכבות של הטיפול בתמונות (לדוגמה, כתיבת הערך הפונקציה עבור Bitmaps תהיה יקרה מבחינה ממוחשבת), ה-API של Painter לא סומן במפורש כמחלקה יציבה. כיתות לא יציבות יכולות שמובילות להרכבת מחדש לא נחוצות, מכיוון שהמהדר לא יכול להסיק בקלות אם הנתונים השתנו.

לכן מומלץ להעביר כתובת URL או מזהה משאב שניתן להזזה בתור פרמטרים. לתוכן הקומפוזבילי, במקום להעביר Painter כפרמטר.

// Prefer this:
@Composable
fun MyImage(url: String) {

}
// Over this:
@Composable
fun MyImage(painter: Painter) {

}

לא כדאי לשמור מפת סיביות בזיכרון יותר זמן מהדרוש

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

אסור לארוז תמונות גדולות באמצעות קובץ AAB או APK

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