טיפול במפות סיביות
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
כדאי לנסות את הכתיבה
Jetpack Compose היא ערכת הכלים המומלצת לבניית ממשק משתמש ל-Android. איך מציגים גרפיקה בכלי הכתיבה
יש כמה סיבות לכך שטעינת מפות סיביות באפליקציית Android היא מסובכת:
- קבצים מסוג Bitmap יכולים בקלות לגרום לאפליקציה לחרוג ממגבלת הזיכרון שהוקצתה לה. לדוגמה, המצלמה בטלפון Pixel מצלמת תמונות בגודל של עד 4048x3036 פיקסלים (12 מגה-פיקסלים).
אם נעשה שימוש בהגדרת מפת הסיביות
ARGB_8888, שהיא הגדרת ברירת המחדל ב-Android 2.3 (רמת API 9) ואילך, טעינה של תמונה אחת לזיכרון תתפוס נפח זיכרון של כ-48MB (4048*3036*4 בייטים). דרישה כזו גדולה לזיכרון עלולה לנצל באופן מיידי את כל הזיכרון שזמין לאפליקציה.
- טעינת מפות סיביות בשרשור של ממשק המשתמש עלולה לפגוע בביצועים של האפליקציה, ולגרום לתגובה איטית או אפילו להודעות ANR. לכן חשוב לנהל את השרשורים בצורה נכונה כשעובדים עם מפות סיביות.
- אם האפליקציה טוענת כמה מפות סיביות לזיכרון, צריך לנהל את הזיכרון ואת מטמון הדיסק בצורה חכמה. אחרת, יכול להיות שתהיה פגיעה בתגובה ובגמישות של ממשק המשתמש של האפליקציה.
ברוב המקרים, מומלץ להשתמש בספריית Glide כדי לאחזר, לפענח ולהציג מפות סיביות באפליקציה. ספריית Glide מפשטת את רוב המורכבות בטיפול במפות סיביות ובמשימות אחרות שקשורות לעבודה עם מפות סיביות ותמונות אחרות ב-Android.
מידע על שימוש ב-Glide והורדה שלו זמין במאגר Glide ב-GitHub.
אפשר גם לבחור לעבוד ישירות עם ממשקי ה-API ברמה נמוכה יותר שמוטמעים ב-Android framework.
מידע נוסף על האופן שבו עושים זאת זמין במאמרים טעינה יעילה של מפות סיביות גדולות, שמירה במטמון של מפות סיביות וניהול זיכרון של מפות סיביות.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[null,null,["עדכון אחרון: 2025-07-27 (שעון UTC)."],[],[],null,["# Handling bitmaps\n\nTry the Compose way \nJetpack Compose is the recommended UI toolkit for Android. Learn how to display graphics in Compose. \n[ImageBitmap →](/jetpack/compose/graphics/images/compare) \n\nThere are a number of reasons why loading bitmaps in your Android app is tricky:\n\n- Bitmaps can very easily exhaust an app's memory budget. For example, the camera on the [Pixel](https://www.android.com/phones/pixel/) phone takes photos of up to 4048x3036 pixels (12 megapixels). If the bitmap configuration used is [ARGB_8888](/reference/android/graphics/Bitmap.Config), the default for Android 2.3 (API level 9) and higher, loading a single photo into memory takes about 48MB of memory (4048\\*3036\\*4 bytes). Such a large memory demand can immediately use up all the memory available to the app.\n- Loading bitmaps on the UI thread can degrade your app's performance, causing slow responsiveness or even ANR messages. It is therefore important to manage threading appropriately when working with bitmaps.\n- If your app is loading multiple bitmaps into memory, you need to skillfully manage memory and disk caching. Otherwise, the responsiveness and fluidity of your app's UI may suffer.\n\n\nFor most cases, we recommend that you use the [Glide](https://github.com/bumptech/glide)\nlibrary to fetch, decode, and display bitmaps in your app. Glide abstracts out most of\nthe complexity in handling these and\nother tasks related to working with bitmaps and other images on Android.\nFor information about using and downloading Glide, visit the\n[Glide repository](https://github.com/bumptech/glide) on GitHub.\n\n\nYou can also opt to work directly with the lower-level APIs built into the Android framework.\nFor more information on doing so, refer to\n[Loading Large Bitmaps Efficiently](/topic/performance/graphics/load-bitmap),\n[Caching Bitmaps](/topic/performance/graphics/cache-bitmap), and\n[Managing Bitmap Memory](/topic/performance/graphics/manage-memory).\n\nMore resources\n--------------"]]
