> 1. Open browser
> 2. Open maximum number of windows by using "open in new window" (set to
> open new windows in background, in case that matters), all with
> different content (so not all the same link)
>
> 3. Switch to a different application (in my case I clicked an e-mail
> address from the browser, which launched the Gmail app)
> 4. Then switch back to the browser, either via a long hold on the Home
> key or from the Home Screen Launcher
>
> Log: http://www.narcotic-symphony.de/simon/androidlog.txt
>
> Relaunching the browser (Step 4) takes place at around line line 161.
>
> Can you make heads or tails of it?
Well...
First, your Browser process dies. It's not a hard crash (e.g., SIGSEGV),
so I am guessing it is dying due to low memory -- more on this below.
Then, ActivityManager#appDiedLocked() is checking to see if there are
any background processes. Finding none, it logs the "Low Memory: No more
background processes" message, then is ripping through all existing
processes, telling each to garbage collect. The combination of that plus
the Browser process being gone has freed up enough memory to allow the
Browser to re-open when you return to it, albeit sans state.
-----------------
You stated in an earlier message:
> As a reference, I have around 30-40MB of free memory when this starts
> happening - so it's not likely to be caused by too much stuff running in
> the background.
Bear in mind that not all memory is created equal, and Browser is likely
to be stranger than your average app. Most apps are Java apps (either
SDK or internal Android apps), with limited heap sizes (16-24MB).
The Browser is based on WebKit. It's memory management has little to do
with Java -- WebKit is written in C/C++. Hence, I'm not sure that the
"30-40MB of free memory" necessarily represents memory that WebKit is
able to use. And, as Frank Weiss noted, Web pages can chew up a fair bit
of RAM.
You then wrote:
> I'm pretty sure the browser is using a lot of memory, and the OS is
> perfectly within its rights to close the application when it's in the
> background - but not without saving the state first.
I do not think it is getting a chance to complete saving its state
before it dies. Android has the right to terminate processes directly to
free up RAM if it needs it.
> Is it possible that the saved states are placed in the same storage
> space that installed applications occupy?
That's fairly likely. And, as Brad Fitzpatrick noted at Google I|O 2010,
flash writes get slower as flash gets closer to full.
So, one possible scenario is that the Browser is trying to save its
state across all your windows but runs out of time due to slower flash
writes, and Android winds up having to proactively kill it off to free
up the RAM for Gmail.
Generally speaking, memory management works more smoothly. However, this
is one of the reasons why I advise developers to go with more smaller
activities than one big fat one, so that state-saving and memory
reclamation can be done in tiny chunks.
The tactical workaround: limit yourself to only a few Browser windows,
or try an alternative browser that might do it state-saving in a
different way that will hold up better with more windows open.
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
_Android Programming Tutorials_ Version 2.0 Available!
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment