Re: [android-developers] Re: Long running Android service is getting recreated over and over

On Wed, May 9, 2012 at 6:42 PM, William Kelley <williamtkelley@gmail.com> wrote:

As to RAM: RAM is a premium and yet when I look at the process running on my phone, the smallest is using 15M, while most of the others are 20M+, some up to 60M+. I don't know if this is faulty reporting from the task manager app I am using, but those numbers seem absurdly high. Why does a text only note taking app need 25M of RAM?

It is hard to address this without knowing more specifics about the device and platform version you are running.  There is no general world-shattering answer to give, but I can give a lot of qualified statements:

- On our current builds, the overhead of an empty Dalvik process (one that has been forked from Zygote) is a bit less than 3MB.  This gives you a fully warmed VM that has loaded and executed basic app code.

- Memory needs vary a lot depending on screen resolution and/or density.  A single frame buffer of a 480x800 screen is about 1.5MB.  A single frame buffer of a 1280x800 screen like the Galaxy Nexus is 4MB.  Each app window has two frame buffers, so just to get a full-screen window up on a GN you are taking 8MB (though only 4MB will be blamed on your process since this memory is shared with SurfaceFlinger).

- The memory footprint of bitmap assets likewise increases quickly as the density increases.  Any bitmaps you need to load for widgets (button frames etc) on an xhdpi screen are going to take about 2.5x the RAM of the same assets on an hdpi screen, and 4x an mdpi screen.

- Part of what Zygote does is preload common platform assets (window background, button frames, etc) for all processes so your process size will not increase significantly if you are using standard widgets.

- More extensive use of the GPU for drawing introduced in Android 3.0 is another big wrinkle on memory use.  At the very least, there is more overhead for various caches and textures that need to be generated for rendering on the GPU.  For example generally this will double the memory needed for bitmaps, since they need to be uploaded as a texture to be drawn.

- The reliance on the GPU also means that graphics drivers are much more important for overall RAM use.  For example, the OpenGL driver for the GPU on the Nexus S and Galaxy Nexus has a fixed overhead of 6-8MB just for opening it.  Different GPU drivers can have radically different RAM characteristics, for example I believe the Tegra drivers have a dedicated area of RAM they carve out that can be used across application for GPU resources, which wouldn't then be see in the normal memory use of those processes.

- If you are wondering about the memory use of a process, as of 4.0 a good initial tool is "adb shell dumpsys meminfo <pid|proc name>".  This will give a summary of different classes of memory in use by the process.

 

But all of these apps DO log GPS points fairly well and they all run as services indefinitely (I can quit out of the app). And they have good reviews with 4+ stars. So from my experience, users are not turned off by long running services - they are getting specifically the apps for this feature. They also know about the battery issues related to GPS.

There is a big difference between an application whose explicit goal is to run something in the background, which the user downloads to do that, and has clear UI to control when it runs in the background and indicators it is doing so...  vs applications that just start a service for no clear reason.

 

As I said, these GPS loggers all run indefinitely and don't seem to be killed at any time. I've personally run some for 6+ hours on a cross country drive, logging points every 10 seconds and they don't have any hiccups. How can these apps works if the logging service can be shut down at will by the OS and it takes 30-40 seconds to restart a service? And you can't do this type of logging with AlarmManager, can you?

If you use Service.startForeground(), that says that you want your service to remain running.  So if that is what you want, that is what you should use.  It comes with a requirement of posting a notification to the user about this, so they can be aware of what is going on.

As for battery life and cpu: GPS fixing is battery intensive, but I don't know the details on how CPU or RAM intensive the LocationManager is. Cutting battery consumption is one of the things I am implementing in my app, but it will require a bit more computation. Will this trigger the OS that my app is being abusive?

If you have used startForeground(), you are by definition not being abusive by doing work, because you have told the system "hey I am going to be doing something that the user is aware of and wants to happen, and here is the notification to post that proves it."

For example, background music playback.  You kind-of need a way to do this to implement stuff like that.

--
Dianne Hackborn
Android framework engineer
hackbod@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

--
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