4

I am trying to understand where my app is using memory, and where I can make it more efficient in this respect.

In the Android Monitor part of Android Studio, I have dumped the Java Heap, and am looking at the generated hprof.

And I see a lot categorized under FinalizerReference:

enter image description here

What is this? How can I understand better what is causing it, and how to keep it down? Looking into the "Instance" panel doesn't help me much... doesn't make much sense.

I have tried looking at this but it's all slightly over my head at the moment.

Also, at the moment the memory monitor is reporting (in the live chart section) an Allocated memory of 10.58 MB. But on my device, in Application Manager > Running Processes, my app is showing a memory usage of 44MB. Why the discrepancy? If it's the ~33MB I want to try and reduce, I'm not apparently even seeing that in Android Studio, so no real hope of identifying what it is?

drmrbrewer
  • 11,491
  • 21
  • 85
  • 181
  • If you have memory leaks, see if this helps. FinalizerReference is fine, there should not be gc roots. http://ramannanda.blogspot.com/2015/04/analyzing-memory-leaks-in-android.html?m=1 – Ramandeep Nanda Mar 04 '16 at 06:53

2 Answers2

0

There may not be much you can do about FinalizerReference memory usage. See this question for more details - basically some objects implement finalize() and these are handled a little differently, such that they can end up sticking around longer. I haven't looked into it too closely, but I suspect that some android sdk objects do this and there's little you can do about it except for maybe tuning up your object caching/recycling to reduce it.

I'm not sure if this would help with FinalizerReference, but one thing I like to do to track down memory leaks is to find suspicious objects' connections to the GC root.

If you're using the Eclipse hprof analyzer (independent of the actual Eclipse IDE; works with hprofs generated by android studio), this is one way to access this:

  • Overview
  • Histogram
  • Right-click, "List Objects"
  • Right-click an object you suspect is leaking, "Path to GC Roots"

Now you should see a list of nested references leading back down from the gc root to your object.

I'm not exactly sure what is owing to the discrepancy - here is a similar question on that. Apparently the memory monitor tool may only be reporting heap allocations made by Java code, whereas the device reports the entire processes's memory usage.

Community
  • 1
  • 1
drhr
  • 2,261
  • 2
  • 17
  • 35
0

The Retained Size reported by the Memory Profiler for FinalizerReference is currently a meaningless number, as I argued in my answer to my own similar question.

To summarize: Treating FinalizerReference like any other class when profiling (as Memory Profiler does), leads to repeated counting of the same memory when calculating its Retained Size.

I view this as a bug in Android Studio's Memory Profiler, and have filed this issue.

HendrikFrans
  • 193
  • 9