3

I have a problem in some devices like Galaxy Nexus, where if you keep opening activities, you hit out of memory error. I thought I had some memory leaks which prevent activities from collected, but I couldn't find it. So I wrote this small activity (purely for test purpose.)

public class Test extends Activity {    
    private byte[] imageData = null;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            Button iv = new Button(this);
            imageData = new byte[1024 * 1024 * 2];
            iv.setText("Open");
            iv.setOnClickListener(new OnClickListener() {
                    @Override
                    public void onClick(View v) {
                            startActivity(new Intent(Test.this, Test.class));
                    }
            });
            setContentView(iv);
    }
}

So basically, it allocates 2MB of memory, and you can open another instance of the same activity. On Galaxy S and Kindle Fire, if you keep opening, memory usage increases to a certain point, and then it starts destroying old activities for new activities.

However on Galaxy Nexus, it just goes up until 64MB and crashes with out of memory error.

So is there something I do not know about android memory management, or is this a bug on some devices? If it's a bug, how can I work around it?

Thank you.

dasony
  • 3,708
  • 2
  • 22
  • 20

2 Answers2

1

As far as I know, Android Provides specific Memory to each Application, if you try to run more than that you'll get VMBudgetOutOfMemory error. Nexus Series uses generic Build of Android OS with minimum customization, and it totally depends OEM that how much they customize their device OS and hardware (in your case along with Memory Management). So it's better to handle control of Activities by yourself,if not then Android will handle it.The behaviour will totally depend on particular Device Specification.

Yuvi
  • 1,344
  • 4
  • 24
  • 46
  • Thank you. So if I can't rely on the system to get rid of background activities, is there any way to destroy them manually, without removing them from back stack? I'd like the activities to be released, but still be restored when users click the back button. – dasony Feb 07 '12 at 07:24
1

I asked Dianne Hackborn about this (one of the Android framework engineers), and here's the advice she gave:

The point at which old activities are destroyed is an arbitrary number, based on the total number of activities across the entire system. This has always been the case. Relying on activities being destroyed to reclaim memory like that is never going to be stable; the activity manager doesn't know anything about the amount of RAM in a process or the limit on its RAM or how much RAM a new activity is going to take to actually have an idea when it should try to destroy activities in each process.

In other words: You can't rely on the system destroying Activities as a means of memory management within your own app. You still need to be frugal about memory usage, and have your activities clean up their own memory usage when possible.

In this case, it might be wise to deallocate your memory once onStop() or onPause() is called.

Trevor Johns
  • 15,682
  • 3
  • 55
  • 54
  • "The point at which old activities are destroyed is an arbitrary number, based on the total number of activities across the entire system" -- what I find curious is that this runs counter to another SO answer where Ms. Hackborn indicated that activities are never destroyed to free up RAM, only processes are: http://stackoverflow.com/a/7576275/115145 Any chance I can con anyone over there in Googleland to perhaps write up an Android Developers Blog post with a definitive statement here? :-) – CommonsWare Feb 09 '12 at 00:42
  • (and note that I'm not quibbling with your recommendation, which is spot-on AFAIK, just trying to get to the bottom of whether activities ever do get destroyed purely for memory reasons) – CommonsWare Feb 09 '12 at 00:46
  • @CommonsWare (1/2) I agree this answer seems contradictory to the other answer by Ms. Hackborn you linked to. However I'm just curious if all confusion over this matter can't be definitively put to rest by looking at AOSP source code. Unlike several other matters related to android behaviour where often people cite source code, in matters related to activity/process lifecycle, I mostly see theoretical answers (which I'm not disputing; obviously google engineers know better). – bitbybit Sep 12 '16 at 19:15
  • (2/2) Now, it seems to me (I could be totally wrong) that code related to decisions about killing processes/activities won't be in the application framework, probably somewhere in native code. If I had to get to the bottom of this to get a definitive answer, where in AOSP would you recommend I look for code related to this issue? Also, if you know any answer or post where this is discussed with actual implementation cited, could you please link to it? – bitbybit Sep 12 '16 at 19:15
  • @bitbybit: "where in AOSP would you recommend I look for code related to this issue?" -- I have no idea, sorry. – CommonsWare Sep 12 '16 at 19:16
  • @CommonsWare that's ok. I imagine AOSP codebase is nothing short of gigantic. Thanks anyway :) – bitbybit Sep 12 '16 at 19:26