You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If these assumptions are correct
You can dump the memory at any time in the main thread in the app (this might cause the OS to show the app not responding dialog)
the stage where you dump memory is critical to find the leaks,
what I wanted to do is, in UI tests, dump the memory at different stages of activities lifecycle without changing the test itself,
to achieve this, I can add a lifecycle listener to the app in AndroidJUnitRunner and ask for heap dump whenever an activity goes to resume step or destroy step, etc.
At the end of the UI test ill check all heap files and look for leaks.
what do you think?
The text was updated successfully, but these errors were encountered:
It's a great idea! I have tried doing similar where I check for leaks every time we use Espresso to check for views (we have a thin API wrapper on top of Espresso so I could insert my code there). This worked but slowed down the tests quite a bit, and also it found so many leaks that I need to fix those leaks before I merge that change in our codebase. But anyway, yes, you should definitely try this.
If these assumptions are correct
You can dump the memory at any time in the main thread in the app (this might cause the OS to show the app not responding dialog)
the stage where you dump memory is critical to find the leaks,
what I wanted to do is, in UI tests, dump the memory at different stages of activities lifecycle without changing the test itself,
to achieve this, I can add a lifecycle listener to the app in AndroidJUnitRunner and ask for heap dump whenever an activity goes to resume step or destroy step, etc.
At the end of the UI test ill check all heap files and look for leaks.
what do you think?
The text was updated successfully, but these errors were encountered: