Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

possible memory leak #653

Open
LionHere opened this issue Apr 27, 2019 · 4 comments
Open

possible memory leak #653

LionHere opened this issue Apr 27, 2019 · 4 comments
Labels

Comments

@LionHere
Copy link

Encountered a situation of possible memory leak, or was it a misusage?

My code was like this:

frequently_called_binding_function (My_GifImageView_Pool pool) {
    GifImageView gifImageView= pool.get();

    gifImageView.setImageBitmap(a small size bitmap as a thumbnail);

    runOnWorkerThread(() -> {
        ParcelFileDescriptor pfd = download a gif from server();
        runOnUiThread(() -> {
            GifDrawable gifDrawable = new GifDrawable(pfd.getFileDescriptor());
            gifImageView.setImageDrawable(gifDrawable);
            pfd.close();
        }
    });
}

That pool had a fix number of GifImageViews, and never re-created new GifImageView.
Runing this binding function a dozens of time bumped the natvie heap from 30mb to ~200mb, and forcing gc would not help.

I fix this by manually recycling GifDrawable before #setImageBitmap:

gifImageView.getDrawable().recycle(); // leaving out null check and cast
gifImageView.setImageBitmap(a small size bitmap as a thumbnail);

I'm not sure if this should be considered as a leak, and I'm sorry if I wasted anyone's time.

@koral--
Copy link
Owner

koral-- commented Apr 27, 2019

Could you share a minimal project which reproduces this issue?

@LionHere
Copy link
Author

Could you share a minimal project which reproduces this issue?

hope this could help: LionHere/AndroidGIFDrawableDemo

@koral--
Copy link
Owner

koral-- commented Apr 27, 2019

Thanks, I'll check this

@koral--
Copy link
Owner

koral-- commented May 6, 2019

Thanks, I haven't considered such usage.
It seems that there is no leak but due to the fact GifDrawable uses single Executor for all instances by default, subsequent actions are scheduled more frequently than they can be purged.

I'll analyze this deeper and get back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants