OutOfMemoryError in MaterialShowcaseView.onDraw

[mdivkovic]

Hey,

first off, thanks for the lib, it's really useful not having to develop something like this from scratch.

Now onto the problem. I'm using this in an app and seem to be getting quite a lot of OutOfMemoryErrors in the wild, with the following stack trace:

java.lang.OutOfMemoryError: Failed to allocate a 8294412 byte allocation with 417014 free bytes and 407KB until OOM
       at dalvik.system.VMRuntime.newNonMovableArray(VMRuntime.java)
       at android.graphics.Bitmap.nativeCreate(Bitmap.java)
       at android.graphics.Bitmap.createBitmap(Bitmap.java:939)
       at android.graphics.Bitmap.createBitmap(Bitmap.java:912)
       at android.graphics.Bitmap.createBitmap(Bitmap.java:879)
       at uk.co.deanwild.materialshowcaseview.MaterialShowcaseView.onDraw(MaterialShowcaseView.java:140)
       at android.view.View.draw(View.java:16060)
       at android.widget.FrameLayout.draw(FrameLayout.java:592)
       at android.view.View.updateDisplayListIfDirty(View.java:14991)
       at android.view.View.getDisplayList(View.java:15014)
       at android.view.View.draw(View.java:15781)
       at android.view.ViewGroup.drawChild(ViewGroup.java:3677)
       at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3471)
       at android.view.View.draw(View.java:16063)
       at android.widget.FrameLayout.draw(FrameLayout.java:592)
       at com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:2916)
       at android.view.View.updateDisplayListIfDirty(View.java:14991)
       at android.view.View.getDisplayList(View.java:15014)
       at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:275)
       at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:281)
       at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:320)
       at android.view.ViewRootImpl.draw(ViewRootImpl.java:2741)
       at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2573)
       at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2165)
       at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1180)
       at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6558)
       at android.view.Choreographer$CallbackRecord.run(Choreographer.java:777)
       at android.view.Choreographer.doCallbacks(Choreographer.java:590)
       at android.view.Choreographer.doFrame(Choreographer.java:560)
       at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:763)
       at android.os.Handler.handleCallback(Handler.java:739)
       at android.os.Handler.dispatchMessage(Handler.java:95)
       at android.os.Looper.loop(Looper.java:145)
       at android.app.ActivityThread.main(ActivityThread.java:5832)
       at java.lang.reflect.Method.invoke(Method.java)
       at java.lang.reflect.Method.invoke(Method.java:372)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1399)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1194)

These happen mostly on the Samsung Galaxy S3, Note 2 and some on the Galaxy S5 even. The background bitmap just gets too big to fit into the available memory.

[mdivkovic]

I can tell you what I did to fix the problem though I have no idea if this is acceptable for your project in general. For the app I'm working on it became absolutely necessary that I clone your project and modify things myself ASAP because this OOME quickly climbed to the spot of the most common crash cause for my users.

Turns out your Bitmap/Canvas caching retains a lot of memory which isn't so easy for the GC to reclaim, causing the OOME in question. It gets worse the bigger the screen resolution is, because that much bigger will the Bitmap be. I understand why you did it, because it was not possible to create a transparent hole inside the background mask on a view with HW acceleration enabled, without drawing it in a separate Bitmap first. During my tinkering I found out that, if I disable hardware acceleration for ShowcaseView in the init() method, just drawing both the mask and the hole directly on the Canvas passed to the onDraw method works well enough so I could completely get rid of the cached Bitmap and Canvas.

With your current approach, on a Nexus 5 emulator, when the ShowcaseView is shown I would see a spike in allocated heap by about 6-8 MB and this memory would not be freed until much later, when the entire activity is destroyed. With the modification I made the spike still happens but almost instantly gets reclaimed. I did a new release of my app with this fix and sure enough, I don't see this OOME happening at all anymore.

TL;DR: Bitmap/Canvas caching in ShowcaseView retains a lot of memory that can't be reclaimed until the Activity is killed and this causes OOMEs. If you disable hardware acceleration for ShowcaseView in init(), get rid of the cached Bitmap/Canvas and just draw both the mask and the hole directly on the Canvas you get passed in onDraw, without creating a Bitmap, the problem goes away without any noticeable performance impact.

It's your call if this is a satisfactory solution to adapt for the library.

[deano2390]

Thanks for your investigative efforts, I shall take a look into this.

[sandeepsmane]

@mdivkovic Can you please share your MaterialShowcaseView file after the changes you have made?
Thanks

[mdivkovic]

@sandeepsmane I'll tell you what, I'll do a pull request, and link it here when I'm done so you can see the changes, and then @deano2390 can decide if he want's to take it or not, but in any case you will get a fix for this problem. That sound OK to you?

[mdivkovic]

OK, @sandeepsmane here you go:

#40

Just apply the changes from there and you should be good to go.

[tom-anders]

I'm considering to use this library in my app, is this issue fixed yet?