Why does heap memory increase when re-launching an

问题:

This question concerns memory in Android.

My method:

I have two activites, A and B. From A, I launch B like this:

Intent i = new Intent(A.this, B.class);
startActivity(i);

On button click in B, I do this:

B.this.finish();

• In B, I override the onDestroy method and set all references to null.
• I do not allocate new memory in the onResume method of A.
• I am not leaking a context.
• I am not using multiple threads.
• I am not using services.
• All variables in B are private class variables, and all of them are set to null in the onDestroy of B.
• Also, ImageViews in B have their background set null in the onDestroy of B.
• I am certain that B gets destroyed.

The result:

When I am in Activity A, heap memory is at 7.44 MB. Then when I start B and call finish on B(and thus returning to A), heap is increased by 0.16 MB. Repeating this process again, heap is increased by 0.08 MB every time.

• I'm not looking at the heap limit, I'm looking at the allocated heap.
• I'm calling System.gc() at the end of the onDestroy method of B.

Additional info:

-I have used MAT to analyse memory allocations and try to find this leak. Something strange is that Activity B seems to have 5 instances. As it so happens, I was repeating the startActivity/finish process 5 times. The bottom entry is the Activity, the others are listeners in the activity:

And this is screenshot of the dominator tree. I can't find anything unusual or suspect.

-I have watched both google IO videos on memory usage(and leaks).

Question:

Is it possible that this 0.08 MB of heap will always be allocated(and not collectable by the GC) no matter what I do? If not, any idea of what might be causing this?

Update:

1. I tried to launch activity B without setting a content view in B. This means that B is a completely empty activity. The result was that the heap memory did NOT increase when I'm relaunching the activity several times. Note, however, that this is no solution. I must be able to set a content view.

2. scorpiodawg: I tried running my app on an emulator, and the heap still grows. Good try though.

3. ntc: I changed all occurences of "this" to "getApplicationContext()" where it was possible. I could not call setContentView(getApplicationContext()); because setContentView wants a reference to a layout file, not a context. What I did instead was to create an empty layout file and call setContentView(emptylayout); in the onDestroy method of Activity B. That did not help.

4. I tried to remove all the code so that only setContentView(mylayout) gets called. Problem persisted. Then I removed all the gui elements in the layout XML file. Problem persisted. The only thing that was left was the container views, a couple of nested linear, relative and scrolllayouts. I tried to remove setting the "android:scrollbarDefaultDelayBeforeFade" attribute in the scrollbar. The result was great, the memory leak had vanished. Then I put back all the code I previously removed but didn't set the "android:scrollbarDefaultDelayBeforeFade" attribute and the memory leak was back. How strange is that?

回答1:

If you have 5 instances of activity B, then you are not managing the activity stack correctly. I find the best way to check it is with the CLI command:

adb shell dumpsys meminfo 'your apps package name'

I had a similar problem in a two activity project when I switched between them. Every time I switched I got a new instance on the stack as revealed by the above command. I then set the flags for the launched activities to FLAG_ACTIVITY_REORDER_TO_FRONT with code like:

Intent i = new Intent("com.you.yourActivityB");
i.setFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);
startActivity(i);

Once I'd done this, then the adb shell command did not show more instances of my two activities when I switched between them

回答2:

Seems that you have a memory leak within that activity.

Probably you are leaking the context (the activity in this case). So ensure that all the references to the context are being cleaned when you call the onDestroy method in the activity. More details here.

Also take a look to possible content observers not being unregistered when you finish the activity.

回答3:

What i think is, its a typical java question. And killing an Activity does't mean that its associated objects should be removed from the heap, even if they are in lost land (their reference are null). because its completely dependent on virtual machine when it calls Garbage collector (Irrespective of you saying System.GC()). so when there the condition is like nearly out of memory it calls it and cleans it(cannot be sure again, may be immediately after their reference becomes null), So i don't think you should be worrying about it.

edited: call setContentView(getApplicationContext);

and where ever you are this keyword to pass a context, change it to this.getApplicationContext()

回答4:

Consider using

android:launchMode="singleTask"

in your AndroidManifest.xml. See this.

回答5:

Is it possible that this 0.08 MB of heap will always be allocated(and not collectable by the >GC) no matter what I do? If not, any idea of what might be causing this?

The 0.08MB of heap, if unused, will be reclaimed when the system considers that it needs it. Garbage Collection does not happen as soon as you call System.gc(), it more like a request for GC to happen as soon as it is possible. There is often a LONG time between an object being allocated and it being removed from memory. The Java Virtual Machine Specification and Java Language Specification specify the lifetime of the object undergoing the following stages:

1. Created
2. In use (strongly reachable)
3. Invisible
4. Unreachable
5. Collected
6. Finalized
7. Deallocated

Note that when an object is Unreachable, it merely becomes a candidate for garbage collection, as and when it may happen. Even with a small footprint JVM like Dalvik, I don't think an object will undergo the full lifetime in a span of time that short. GC is an expensive operation, so is done only as when its needed.

If you have objects that need to be removed from memory quickly (for some reason), then try WeakReference . Or maybe you could provide some more context as to what you're trying to do, and someone could be able to help you out better that way.

For more info on how GC happens in Java, this is a pretty good article