Of course the most fundamental solution is to reclaim memory at the appropriate time. For example, the sliding interface you mentioned can be judged in the adapter. If the interface is not displayed, the image will be recycled and reloaded when the sliding display is displayed
Single pictures generally won’t be OOM, but if there are multiple pictures, they don’t need to be high-definition. A large number of high-definition images are difficult to process, so try to use asynchronous loading, compression (after compression, it is no longer high-definition), multiple recycling, and sliding pause loading.
There is no need to use a large number of high-definition images on the same interface. It is best not to exceed the size of the View, otherwise it will be meaningless,
Then you can choose to lower some quality to reduce occupancy...
Then you have the option to reclaim the memory when doing other operations...
glide is slightly better than Picasso (glide is improved based on Picasso). If it is an APP that uses a lot of pictures, but it uses Fresco, FaceBook's black technology, the picture cache and the memory space opened by itself, it is amazing. (There are also some preloaded blurry images, but they are a little troublesome to use. Personally, because you need to give the image at least a clear height or width value, otherwise the two wrap_contents will not be displayed)
What about using picture frames such as glide? It may be better if it automatically compresses the pictures
I have also encountered it, and I have not completely avoided it, but I can try my best
1. Load local images with appropriate compression
2.Add in application:
Of course the most fundamental solution is to reclaim memory at the appropriate time. For example, the sliding interface you mentioned can be judged in the adapter. If the interface is not displayed, the image will be recycled and reloaded when the sliding display is displayed
Single pictures generally won’t be OOM, but if there are multiple pictures, they don’t need to be high-definition. A large number of high-definition images are difficult to process, so try to use asynchronous loading, compression (after compression, it is no longer high-definition), multiple recycling, and sliding pause loading.
There is no need to use a large number of high-definition images on the same interface. It is best not to exceed the size of the View, otherwise it will be meaningless,
Then you can choose to lower some quality to reduce occupancy...
Then you have the option to reclaim the memory when doing other operations...
glide is slightly better than Picasso (glide is improved based on Picasso). If it is an APP that uses a lot of pictures, but it uses Fresco, FaceBook's black technology, the picture cache and the memory space opened by itself, it is amazing. (There are also some preloaded blurry images, but they are a little troublesome to use. Personally, because you need to give the image at least a clear height or width value, otherwise the two wrap_contents will not be displayed)
Simple method, convert the image format to webp, the quality of the image will not be reduced much, but the size of the image will be greatly reduced