Memory monitor

Here is a piece of analytical data on memory consumption by a single Android application. As you can guess, abrupt downward cliffs are triggered by the Java garbage collector.

If the "jumps" were more abrupt, then it would be possible to conclude that there are obvious memory leaks in the code and, in principle, inefficient use of memory.

But what can be said from this data? Is it possible to unequivocally say how economically / uneconomically memory is used here?

PS

The code is quite large, I don’t see any reason to bring it, but it is worth noting that it is dominated by the operations of creating small “non-living” (up to 30 seconds) objects.

Pps

But this example (the same application after attempts to make optimizations) can be regarded as a less efficient use of memory compared to the example above: enter image description here

  • 9
    Hm In my opinion, without looking at the code, nothing can be said. It turns out some kind of diagnostics on the photo. - VladD
  • one
    Maybe normal or maybe not. I'm not sure that this question has a concise answer. - LEQADA
  • 3
    Well, the frequent creation of small short-lived objects is definitely not very good. But without knowing even approximately why it is being done, it is impossible to say whether it is possible to do something more effectively. - xkor
  • 2
    @xbor Still the opposite. In java, short-lived objects are preferable. He lives a little - is quickly removed from the memory by a quick trash sweeper. Long-lived move to trash sites that are removed by a slow global sweeper. Or is everything different in android? - Sergey
  • one
    If the GC runs quickly and the frame drop is not noticeable, then you can ignore it. It is better to look at the phone, where VM size is more than 32 MB, there crests are likely to be larger - lsillarionov

1 answer 1

Actually, relying on a garbage collector is not a good practice. if you explicitly destroy objects, the schedule should be compared with the same schedule, but with a more aggressive policy of garbage collection. If this comparison is also not visible leaks, in the most general sense it will be possible to argue that there are no leaks. But in general it is better to look also into the code, and also to build in it meters

  • 3
    In fact, Java does not have the ability to destroy objects explicitly , and nothing but relying on the garbage collector is necessary. In addition, it works quite well. Moreover, manually calling System.gc() does not make sense at all based on the algorithm of the GC itself. - Vladyslav Matviienko
  • Obviously - alas, no. But from my point of view in English, a great guide on stackoverflow.com/questions/11404964/… - Alexey Vesnin