App freezes when idle after "Background concurrent copying GC freed" log messages

Question

Steps to reproduce the problem:

The way I reproduce this problem is

1. I run my android application & I enter the MainActivity
2. I leave my phone idle for about ten minutes or more, having configured the device in its settings to not sleep if idle less than 30 minutes.
3. While waiting, in Android Studio's "Run" tab I see messages such as this one:

Background concurrent copying GC freed 237478(18MB) AllocSpace objects, 52(1756KB) LOS objects, 69% free, 5507KB/17MB, paused 217us total 164.170ms

4. After 5 to 10 messages as the one above, I see this couple of messages:

Background concurrent copying GC freed 257288(11MB) AllocSpace objects, 0(0B) LOS objects, 66% free, 6204KB/18MB, paused 86us total 165.671ms

Background young concurrent copying GC freed 217214(10MB) AllocSpace objects, 0(0B) LOS objects, 56% free, 8108KB/18MB, paused 112us total 129.379ms

5. If I wait more, I keep receiving the above couple of messages and if I touch the screen nothing is interactable and the whole app seems frozen. Also, the device's "Home" & "Back" buttons don't do anything. If I minimize the app when I try to maximize it again there's a great delay and when the app finally opens, everything keeps not responding (buttons don't do anything and you can't even scroll). So, I am forced to kill the app.

Observations & Notes:

• The problem described in the above steps doesn't always occur. But, when I try to reproduce it, it occurs about half of the times that the app is run.

• I have run my app using the profiler while reproducing the problem and the memory consumption remains at the same level from start to finish, throughout all the above steps.

• Keep in mind that I have seen and reproduced this problem in a Xiaomi Mi A2 Lite device, which has only 3GB RAM. I haven't tried to reproduce it in any other devices.

• The Activity where this problem occurs contains some views with many images. When I don't populate some views from the Activity's layout with any images, then the above log messages report more free memory percentage. The problem still occurs at times but you have to leave the phone idle for much more time for the app to freeze. Also, the greater the size of the images is, the easier it is for this problem to be reproduced.

My conclusion:

I've observed that when I receive the above log messages the free memory percentage gradually decreases and the app starts freezing when it reaches values below 60%. So, I assume that the device's memory can't handle that much data and that's why the garbage collector keeps reallocating the memory for optimization purposes. Of course, the easiest solution would be to have a device with more memory or use less and smaller size images, but I'd prefer a more robust solution.

Questions:

1. I'd like to know if someone else has observed this same kind of behavior in their app and how they have dealt with it.

2. In the beginning I receive log messages that start with "Background concurrent copying GC freed" (see step 3) and after a bunch of them I receive the couple of messages (see step 4) where the first message starts with "Background concurrent copying GC freed" and the second message starts with "Background young concurrent copying GC freed". Does that "young concurrent" mean anything different or should I ignore this change?

3. Is there any other tool that may help me investigate this matter any further?

Answer 1

I solved the problem, it turns out that a colleague of mine had created a new thread that kept being alive even when idle. As a result, the message "Background young concurrent copying GC freed" appeared and the device gradually started running out of memory. So, for anyone that observes the same messages or behavior I would suggest they check analytically their app's memory consumption and especially the multi-threaded functionalities.

Answer 2

When the same situation happened to me, I noticed that when I tried to use my ListenerRegistrations that were listening to data in firebase again For example;

private var dataListener: ListenerRegistration? = null

Before operating this object after making a definition in the form of

dataListener?.remove()
dataListener= null

do it. And now you can use this object again for different or same purpose

Answer 3

@thanasis-m I know it's been a long time, but I'm facing the same problem. On a page with graphics, on average, there are updates every second more frequently, and when that page is open for a long time, I get the same error message and then all the buttons become dysfunctional. You stated that you solved this problem, but I did not fully understand the solution. Can you give more details about the solution and help?

Thank you.