Can I recommend glide
https://github.com/bumptech/g...

Use Glide

1. Check whether the system has code that uses large memory or an infinite loop.
2. You can add JVM startup parameters to limit memory usage: -XX:-UseGCOverheadLimit

1. You can add attributes to fresco and change the size of the image

Same recommendation as glide. The code is simple and automatically compresses cached images

In systems below 5.0 (that is, API21), Fresco places images in a special memory area. Of course, when the picture is not displayed, the occupied memory will be automatically released. This will make the APP smoother and reduce OOM caused by image memory usage. It’s written in the fresco Chinese document

And now the latest one is compile 'com.facebook.fresco:fresco:0.13.0', you can try it

First of all, I am here to support you.

I don’t know what those people think about using Glide. Can you even tell me why you use Glide (although I always use glide)

When you encounter a problem, you should solve it. Changing the library is one way, but at least you should try and fail before changing.

I have a question, why does fressco oom? Isn’t it said that it is the most popular in the industry?

Let me tell you my thoughts:
If the poster really takes this library out of OOM, I think it is quite powerful. You might as well check the code to see what is unreasonable. If you think you are right, you might as well send an issue to github

I have encountered your problem before when using Fresco. At that time, I suspected that it was a problem with Fresco itself, but later I found that it was a problem with my own code. Under normal circumstances, Fresco itself will not trigger OOM. It is recommended to check your own code first.

同 Glide

This is the compilation process oom, not the runtime oom, and has nothing to do with what library is used.
The compilation process produces oom, and the compilation parameters need to be adjusted, as @wordplat said

android {

dexOptions {
    javaMaxHeapSize "4g"
}
}

Your problem is actually an OOM generated during code compilation, not a problem caused by the framework itself, so you only need to adjust the size of the JVM heap memory.

dexOptions {
    javaMaxHeapSize "4g"
}

Sometimes it’s convenient to post the code