Fresco: OOM in Android 5.0

Created on 25 Jun 2015  路  11Comments  路  Source: facebook/fresco

We are using fresco 0.5.1 in our app. We have created a custom view for displaying tile images. It is perfectly fine for Android 4.x. But in 5.x, we encounter OOM error. See if you can provide us any hint on this issue. Thanks. (FYI, as reported in Fabric, 100% OOMs come from Android 5.x)

BTW, in our code, we created a MultiDraweeHolder and added multiple DraweeHolder to it (could hold up to 10 images of 700*800) at init time. Is it a good way to do so? Or should we add/remove DraweeHolder when we are calling onDraw? Please advice.

Sample stack trace:

java.lang.OutOfMemoryError: Failed to allocate a 2240012 byte allocation with 246258 free bytes and 240KB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(VMRuntime.java)
at android.graphics.Bitmap.nativeCreate(Bitmap.java)
at android.graphics.Bitmap.createBitmap(Bitmap.java:812)
at android.graphics.Bitmap.createBitmap(Bitmap.java:789)
at android.graphics.Bitmap.createBitmap(Bitmap.java:756)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:55)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:30)
at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:260)
at com.facebook.imagepipeline.bitmaps.ArtBitmapFactory.doDecodeStaticImage(ArtBitmapFactory.java:131)
at com.facebook.imagepipeline.bitmaps.ArtBitmapFactory.decodeJPEGFromPooledByteBuffer(ArtBitmapFactory.java:119)
at com.facebook.imagepipeline.bitmaps.PlatformBitmapFactory.decodeJPEGFromPooledByteBuffer(PlatformBitmapFactory.java:106)
at com.facebook.imagepipeline.decoder.ImageDecoder.decodeJpeg(ImageDecoder.java:140)
at com.facebook.imagepipeline.decoder.ImageDecoder.decodeImage(ImageDecoder.java:84)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.doDecode(DecodeProducer.java:166)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.access$000(DecodeProducer.java:88)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder$1.run(DecodeProducer.java:112)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder$1.run(DecodeProducer.java:109)
at com.facebook.imagepipeline.producers.JobScheduler.doJob(JobScheduler.java:214)
at com.facebook.imagepipeline.producers.JobScheduler.access$000(JobScheduler.java:30)
at com.facebook.imagepipeline.producers.JobScheduler$1.run(JobScheduler.java:68)
at com.facebook.common.executors.SerialDelegatingExecutor.executeSingleCommand(SerialDelegatingExecutor.java:76)
at com.facebook.common.executors.SerialDelegatingExecutor.access$000(SerialDelegatingExecutor.java:24)
at com.facebook.common.executors.SerialDelegatingExecutor$1.run(SerialDelegatingExecutor.java:47)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)

needs-details

Most helpful comment

@sureshperiyasamy 230KB doesn't sound like a big number to me. Maybe you should check if there is any memory leak in your app first.

https://www.youtube.com/watch?v=P--rg1o7Cz4

All 11 comments

Are you following the rules for DraweeHolders? See http://frescolib.org/docs/writing-custom-views.html#responsibilities-of-custom-views.

Are you putting your custom views inside a ScrollView? Don't. Use a RecyclerView instead.

Yes. We have followed the rules and using ListView. The weird thing is that the problem happens in Android 5.x only. That's why I think our code is working fine.

I'm thinking maybe it is just because crashlytics can't log OOM outside Java. Since in < 5.0, it is not using the heap space...

Android 5.0 will always be the first to suffer OOMs, because it doesn't have the ashmem capability we had in Android 4.x. But that doesn't necessarily mean your app is correct.

The allocation you describe is of a 2.2MB image. On most devices, that's large enough to cover the entire screen. In that case, every other image on your screen should not be visible. Has your appropriate Activity / Fragment .onStop method been called?

OK. Probably it is our mistake. Sorry for that. Please help to close this issue. Thanks for the great library.

emm..i met this problem again..

@zhangxiaang Are you holding too many DraweeHolder in memory? That was our case before.

@alex621 : I am always getting Throwing OutOfMemoryError "Failed to allocate a 230412 byte allocation with 57936 free bytes and 56KB until OOM" While using Fresco.Can anybody help me.

@sureshperiyasamy 230KB doesn't sound like a big number to me. Maybe you should check if there is any memory leak in your app first.

https://www.youtube.com/watch?v=P--rg1o7Cz4

@alex621 : I have gone through the above video and i did debugging with tracking and got allocation files.In that Simple drawer view is taking around 95 Percentage of sizes. How to over come this..

@alex621 : I have gone through the above video and i did debugging with tracking and got allocation files.In that Simple drawer view is taking around 95 Percentage of sizes. How to over come this..

Any reply for above scenarios

Was this page helpful?
0 / 5 - 0 ratings

Related issues

stephen-workpop picture stephen-workpop  路  4Comments

goodev picture goodev  路  4Comments

sungerk picture sungerk  路  3Comments

rhettor picture rhettor  路  3Comments

stevenmtang picture stevenmtang  路  3Comments