BUG memory-leak during display-rotation with integrated skeleton in RecyclerView (sample-app)

[ajans]

Describe the bug
After about 50 display-rotations, there is a significant increase in memory-usage of the sample-app in the demo-2 branch.
After the initial start of the app on an API-29 emulator, the usage was about 80mb.
After the rotation-marathon, it peaked to about 148mb. After the last rotation, in rest, the usage only went down to around 129mb.
It took around 2:30 minutes to reproduce this level of memory leakage.

If I can do something to help reproduce or fix the issue, please let me know.
This is the best skeleton-library I have found so far (and the only one working comfortably with CardViews in RecyclerView, for sure), so I still want to use it in our app-project.

To Reproduce
Steps to reproduce the behavior:

1. Go to branch demo-2
2. Compile and run the sample-app on an emulator
3. With the app running, rotate the emulator display in rapid succession (Hotkeys: Ctrl-Left, Ctrl-Right), with a short delay to let the UI display itself, for at least 20 times. To reach the aforementioned increase, around 50 rotations are necessary.
4. No error is posted, the app is stable by itself, but it is only a matter of rotation-count to bring the app to a crash

Expected behavior
I expected the memory usage to stay around 80mb. In my own app-project, my app is itself also around 80mb and stays there with 4 RecyclerViews loading stuff from the internet. Integrating the Skeleton-Bones library shows the same behavior as in the sample-app, memory increased to the double amount after 40-50 rotations. This should not happen.

Screenshots

Smartphone (please complete the following information):

• Device: Emulator 30.3.5 with Android 10 API-Level 29 x86 ABI
• SDK Version 29
• Version tested with demo-2 sample app and library 1.3

Additional context
I did an analysis of the sample-app demo-2 with LeakCanary as described here:
https://square.github.io/leakcanary/fundamentals-fixing-a-memory-leak/#3-find-the-reference-causing-the-leak

The LeakCanary-dump is this:
skeleton-bones-demo2-sample-leak.log

[EudyContreras]

@ajans Thanks for discovering and reporting this issue. I will be taking a look at it.
Since I am unfortunately very busy at the moment it might take some time before I can produce a solution.

[FernandoDiCostanzo]

Testing the application with FunesDroid ( a black-box tool used to find memory leak : https://github.com/reverse-unina/FunesDroid ) noticed that some activity leaks.

FunesDroid shows a snapshot of the difference between heap memory area before experiment begin and after and so it can show remained objects in memory.
So if there some remaind objects that should means that some activity leaks and caused that remainder.

[1] Here we can view wich exeperiment finds a memory leak

[2] Here we can view the details of the exeperiment ( that found memory leaks ) an so analize the specific ativity that leaked

FunesDroid shows principally 3 indicators:

1. Activity leaked : numer of leaked activity;
2. Total shallow heap : The shallow heap is the amount of memory consumed by an object, so the Total shallow heap it's the amount of memory consumed by all objects.
3. Total retained size : The retained size of the same object is the amount of heap memory that is freed when the object is garbage collected.

Since any object can be GB, the retained size is equal to 0 .

So you can may investigate on the objcect shown in table [2] that remain in memory ( by following their reference chain ) and find the memory leak's cause.

I hope it will be useful to you.

[ZeeOne]

Thank you for the awesome library! It certainly is much prettier than others I have tried. I also have encountered the memory leak. In my case, I am using SDK Version 31 and the skeleton view is in a fragment (for incase this might help at all).

[EudyContreras]

Hey @ZeeOne and @FernandoDiCostanzo I will look into this and solve the issue once I can allocate some time. Thank you for reporting 🙏