question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Load gif too much cause OOM

See original GitHub issue

I use this code block to load gif image.

                final SimpleDraweeView src = gifShowView.getSrc();
                GenericDraweeHierarchy hierarchy = src.getHierarchy();
                hierarchy.setPlaceholderImage(R.drawable.placeholder_white_big, ScalingUtils.ScaleType.CENTER_CROP);
                hierarchy.setActualImageScaleType(ScalingUtils.ScaleType.CENTER_CROP);
                hierarchy.setProgressBarImage(new CircleShapeProgressDrawable(activity));
                DraweeController controller = Fresco.newDraweeControllerBuilder()
                        .setUri(gif_url)
                        .setAutoPlayAnimations(true)
                        .setOldController(src.getController())
                        .setControllerListener(new BaseControllerListener<ImageInfo>() {
                            @Override
                            public void onFinalImageSet(String id, ImageInfo imageInfo, Animatable animatable) {
                                super.onFinalImageSet(id, imageInfo, animatable);
                                ImageView progressButton = gifShowView.getLoadButton();
                                progressButton.setVisibility(View.GONE);
                            }
                        })
                        .build();
                src.setHierarchy(hierarchy);
                src.setController(controller);

we have a viewpager contain some fragments, each fragment have a recyclerView, every recyclerView have 10+ and more gif images in adapter. most of gif size is from 200k to 5M.

java.lang.OutOfMemoryError: 
Failed to allocate a 10800012 byte allocation with 335920 free bytes and 328KB until OOM
                                                                       at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
                                                                       at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
                                                                       at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:613)
                                                                       at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:446)
                                                                       at android.graphics.drawable.Drawable.createFromResourceStream(Drawable.java:1080)
                                                                       at android.content.res.Resources.createFromResourceStream(Resources.java:2952)
                                                                       at android.content.res.Resources.loadDrawableForCookie(Resources.java:2684)
                                                                       at android.content.res.Resources.loadDrawable(Resources.java:2580)
                                                                       at android.content.res.MiuiResources.loadDrawable(MiuiResources.java:387)
                                                                       at android.content.res.Resources.getDrawable(Resources.java:824)
                                                                       at android.content.res.Resources.getDrawable(Resources.java:789)
                                                                       at com.facebook.drawee.generic.GenericDraweeHierarchy.setPlaceholderImage(GenericDraweeHierarchy.java:456)
                                                                       at com.gif57.android.helper.ImageLoaderHelper.loadGifWithStrategyInternal(ImageLoaderHelper.java:154)
                                                                       at com.gif57.android.helper.ImageLoaderHelper.loadGifWithStrategy(ImageLoaderHelper.java:144)
                                                                       at com.gif57.android.ui.base.vh.BaseTopicViewHolder.bindBaseUI(BaseTopicViewHolder.java:119)
                                                                       at com.gif57.android.ui.fragment.first.home.HomeChildListFragment$HomeQuickAdapter.convert(HomeChildListFragment.java:108)
                                                                       at com.gif57.android.ui.fragment.first.home.HomeChildListFragment$HomeQuickAdapter.convert(HomeChildListFragment.java:95)

hprof file while run we used

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:8 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
erikandrecommented, Jul 4, 2017

@zhudongya123, OK that’s good 😃

It’s still a bit strange that when loading the original placeholder image was trying to allocate 10800012 bytes instead of the expected 1200000 bytes (6005004). The first number is almost exactly 9 times the expected (or exactly 9.00001).

I’m wondering if the device is somehow resizing the image incorrectly. It would be interesting to see what the actual dimensions are of the loaded placeholder (could be found out by getting the Bitmap from the loaded BitmapDrawable).

0reactions
zhudongya123commented, Jul 5, 2017

@erikandre Your mean a picture with resolution of 500 * 600 in ARGB_8888 can consume 500 * 600 *4 bytes in application. And I found the original placeholder (500 * 600) is in the ‘drawable’ folder, no suffix. When I moved the file to the ‘drawable-xxhdpi’ folder , the problem was sovled, no more crash happened, when I move the file to ‘drawable-mdpi’ or ‘drawable-ldpi’ folder, the same crash happened again. So, like you mentioned, imaged placed in wrong drawable folder may be the reason.
I tested my app on RED MI NOTE 3, the resolution is 1920 *1080, 5.5 inch, and dpi is 400,using drawable-xxhdpi folder. Image allocated 9 times than origin space allocated, I guess the image was enlarged 3 times both in height and width. a mdpi(160) resource placed in xxhdpi(480) folder, the allocation will be enlarged by (480/160)^2 times.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Gif consumes lot of memory in iOS that leads app to crash with ...
We are loading 19 heavy gifs in a raw and consume around 200 MB, earlier it was getting crash as memory consumption shoots...
Read more >
[Image] If use a gif url, it will take more than 300m memory
Small GIFs work fine (as they always have), large GIFs will probably still cause an OOM.
Read more >
105370 - huge memory use loading a 2M animated GIF
The attached gifs still cause a lot of memory allocated because GIFs are always decoded to 24bits, so large animations will take a...
Read more >
How to Improve Your Site's Performance When Using GIFs - Moz
As such, usage of GIFs leads to heavy page weights and poor user experiences resulting from slow page load speeds.
Read more >
swift - Loading GIFs in iOS consumes too much memory
I've been testing around a lot of open-source animated-gif libraries to load GIF files into our Swift project.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found