Home » Android » android – Other processes call GC which slows down my game

android – Other processes call GC which slows down my game

Posted by: admin May 14, 2020 Leave a comment


I’m writing a real-time arcade game for Android >= 2.1. During gameplay I’m not allocating memory, to not seduce GC. Beacuse if GC invokes, it takes processor for 70-200ms. User see this as “oh no, that game is lagging…”.

I checked LogCat. There are lots of GC_FOR_MALLOC or GC_EXPLICIT. But… not from PID of my process! My game is not causing them. They’re caused because other processes, running in the background. Some wallpaper, widgets, radio, email, weather checking and other services…

I don’t understand it entirely. When, for example wallpaper dissapears, its onPause() is called, I suppose. So, it should stop all its threads and certainly do not allocate any memory (or call System.gc()). Maybe it’s wrongly implemented? I don’t know. But there are some Android services, which are also causing GC from time to time… It’s odd.

Is it a big Android <= 2.2 architecture flaw?
Android 2.3 introduces concurrent GC, which takes less time.

What can I do to ensure that my game will run smoothly?

How to&Answers:

First of all, the things which you see in LogCat will differ from one device to another. If you are certain the GC is not coming from your app, you have absolutely nothing you can do. You will always find the GC doing..something.
Make sure you keep YOUR code clean and very lite.

Plus, remember that generally speaking, in the presence of a garbage collector, it is never good practice to manually call the GC. A GC is organized around heuristic algorithms which work best when left to their own devices. Calling the GC manually often decreases performance.

Occasionally, in some relatively rare situations, one may find that a particular GC gets it wrong, and a manual call to the GC may then improves things, performance-wise. This is because it is not really possible to implement a “perfect” GC which will manage memory optimally in all cases. Such situations are hard to predict and depend on many subtle implementation details. The “good practice” is to let the GC run by itself; a manual call to the GC is the exception, which should be envisioned only after an actual performance issue has been duly witnessed.

I do not believe it is a flaw on Android <= 2.2. Is it happening on higher versions? Have you tested it?