[null,null,["最后更新时间 (UTC):2025-08-21。"],[],[],null,["# Optimizing performance for images\n\nWorking with images can quickly introduce performance issues if you aren't\ncareful. You can quite easily run into an `OutOfMemoryError` when working\nwith large bitmaps. Follow these best practices to ensure your app performs at\nits best.\n\nOnly load the size of the bitmap you need\n-----------------------------------------\n\nMost smartphones have high resolution cameras that produce large image files. If\nyou're showing an image on screen, you must either reduce the resolution of the\nimage or only load the image up to the size of your image container. The\nconstant loading of larger than needed images can exhaust GPU caches, leading to\nless performant UI rendering.\n\nTo manage image sizes:\n\n- Scale down your image files to be as small as possible (without affecting output image).\n- Consider [converting your images to WEBP](/studio/write/convert-webp) format instead of JPEG or PNGs.\n- Supply smaller images for different screen resolutions (see [Tip #3](/develop/ui/compose/graphics/images/optimization#screen-sizes)),\n- Use an [image loading library](/develop/ui/compose/graphics/images/loading#load_an_image_from_the_internet), which scales down your image to fit the size of your view on screen. This can help improve the loading performance of your screen.\n\n| **Caution:** Using `painterResource` will **not** scale your image to the size of the Composable that is visible on screen. If you have a large image in a small Composable, be sure to use an image loading library which scales the image down for you to fit the bounds.\n\n#### Use vectors over bitmaps where possible\n\nWhen representing something visually on screen, you need to decide if it can be\nrepresented as a vector or not. Prefer vector images over bitmaps, as they\ndon't pixelate when you scale them to different sizes. However, not everything\ncan be represented as a vector - images taken with a camera can't be converted\ninto a vector.\n\n#### Supply alternative resources for different screen sizes\n\nIf you are shipping images with your app, consider supplying different sized\nassets for different device resolutions. This can help reduce the download size\nof your app on devices, and improve performance as it'll load up a lower\nresolution image on a lower resolution device. For more information on providing\nalternative bitmaps for different device sizes, [check out the alternative\nbitmap documentation](/training/multiscreen/screendensities#TaskProvideAltBmp).\n\n#### When using `ImageBitmap`, call `prepareToDraw` before drawing\n\nWhen using `ImageBitmap`, to start the process of uploading the texture to the\nGPU, call [`ImageBitmap#prepareToDraw()`](/reference/kotlin/androidx/compose/ui/graphics/ImageBitmap#prepareToDraw()) before actually drawing it. This\nhelps the GPU prepare the texture and improve the performance of showing a\nvisual on screen. Most image loading libraries already do this optimization, but\nif you are working with the `ImageBitmap` class yourself, it is something to\nkeep in mind.\n\n#### Prefer passing a `Int` `DrawableRes` or URL as parameters into your composable instead of `Painter`\n\nDue to the complexities of dealing with images (for example, writing an equals\nfunction for `Bitmaps` would be computationally expensive), the `Painter` API is\nexplicitly not marked as a [Stable](https://medium.com/androiddevelopers/jetpack-compose-stability-explained-79c10db270c8) class. Unstable classes can\nlead to unnecessary recompositions because the compiler cannot easily infer if\nthe data has changed.\n\nTherefore, it is preferable to pass a URL or drawable resource ID as parameters\nto your composable, instead of passing a `Painter` as a parameter. \n\n // Prefer this:\n @Composable\n fun MyImage(url: String) {\n\n }\n // Over this:\n @Composable\n fun MyImage(painter: Painter) {\n\n }\n\nDon't store a bitmap in memory longer than you need it\n------------------------------------------------------\n\nThe more bitmaps you load into memory, the more likely it is that you could run\nout of memory on the device. For instance, if loading a large list of Image\ncomposables on screen, use `LazyColumn` or `LazyRow` to ensure that memory is\nfreed up when scrolling a large list.\n\nDon't package large images with your AAB/APK file\n-------------------------------------------------\n\nOne of the top causes for large app download size is due to graphics that are\npackaged inside the AAB or APK file. Use the [APK analyzer](/studio/debug/apk-analyzer) tool to ensure\nthat you aren't packaging larger than required image files. Reduce the sizes or\nconsider placing the images on a server and only downloading them when required.\n\nRecommended for you\n-------------------\n\n- Note: link text is displayed when JavaScript is off\n- [ImageBitmap vs ImageVector {:#bitmap-vs-vector}](/develop/ui/compose/graphics/images/compare)\n- [Save UI state in Compose](/develop/ui/compose/state-saving)\n- [Jetpack Compose Phases](/develop/ui/compose/phases)"]]