[Motorola Droid 4] Septfox:
Long post!

I've been noticing some extreme slowness lately when it comes to launching apps after the phone has been running for a while. Probably not due to recent changes or anything, I would guess because I'm using my phone more and loading more things into it.

Usually coinciding with this slowness is a "low" memory situation. Specifically, once at around the 200mb free mark (as reported by Cooltool), it's like the phone is running through syrup when doing in-app tasks, and when actually launching apps, hitting a brick wall. I would guess this has something to do with working space for caching and memory fragmentation making the actual available RAM less than it appears, but I really don't know. End result is, memory <200mb=sluggishness...which is kind of a bad thing, what with 200mb being 1/2 of our "usable" memory (the other 400mb+ is in constant use by the O/S).

This post will do nothing to fix this apparent limitation. Just going to say that now :v

If you're experiencing this kind of slowness yourself, a quick way to test would be to go to Settings>Developer options, scroll to the bottom and "Background process limit" to 1. Within a short time, Android should clear out most (non-service) background processes from memory. If following this your phone runs considerably better (try launching some apps), then you're probably having memory problems.

Unfortunately, anything over 1 wasn't (in my experience) enough to keep the required memory free. 1 allows the most recently-launched background process to stay in memory though, which is enough for fast-swapping (via double-tapping Home) between two apps. Speed without completely killing multitasking.

Don't take the above as gospel, of course. Try 2 or even 3, YMMV. Keep in mind that whatever you set, it'll revert to default at reboot.

Note that this isn't the same thing as using a task killer. Task killers kill everything they can, including non-system services. I suppose it's the same apparent effect (freeing memory), but it's a pointless waste of power and potentially your time, since said services will usually then borrow the CPU and some disk I/O to reload themselves anyway. Task killers in Android are bad unless you specifically need the nuke-everything functionality.

Anyway, it's possible that setting the above will be sufficient for many people. If not, another thing that will help is keeping the number of persistent services running as low as possible. This is what Settings>Apps>Running Apps reports for my phone, it's not an exhaustive list (many things are hidden from the user) but should give you an idea of how minimally you want to be running:

To summarize: a few "light" services, Play Services minimally running (that's the GCM service for my mail iirc), and one or two "heavy" service of your choosing, probably Facebook and something else for most people. That leaves the phone with a bit over 200mb free as reported here, over 300mb (sometimes as high as 400mb) as reported by Cooltool (probably actual free vs immediately freeable).

I used Amplify to trim down the number of Play Services running, as well as the services from other apps I have installed (you would be amazed how many app writers think you want/need constant notifications and run non-optional services to provide them). There are other, free alternatives for disabling services, though they're a bit messier to use. I could offer a list of what I have blocked if there's interest.

You're probably sitting there going "but we only need to float over 200mb. why go as far as 400mb?". I'm going to spoiler this, since it's a bit of babbling that may or may not be correct to begin with and this post is long enough already.

Well, some applications are more hungry than others, and depending on your background limit (we'll assume 1), you can easily run out.

Say you have App A. App A eats 50mb of your memory once it settles and has loaded everything it's going to.

Then you load App B. App B eats 100mb of memory once it does the same. In total, of your 400mb you have 150mb used, leaving a 50mb margin before "running out". Sounds good, right? You could easily only keep 350mb free and be ok.

On the other hand, lets say you have App C; it eats 100mb of memory once it's settled.

And then you load App D, which loads another 100mb. Woops, now you're in the "danger" zone. If you have ~400mb free from the outset, you might not even notice you're "out" of memory, but more heavily-laden phones will probably dip under 200mb free and notice a slowdown while doing things in App C/D if multitasking between them via fast-swapping.

This isn't nearly as important if you only change between apps via your launcher or Recents menu, though. Launchers are apps in and of themselves, Recents appears to work as one (is it an instance of systemui?), so either will bump the "oldest" app out of memory.

With the background limit in place, my phone now launches things when I tell it to, not 5 seconds later. Apps have to completely relaunch more often, but it's considerably faster to have them do so rather than wait for things to get shuffled around in memory.

I'm curious as to why the lowmem killer isn't set to prevent hitting 200mb of free memory, though. As I recall, there was a commit a while back that lowered the limit even further than it is, and it turned out to be nearly unusable, potentially within minutes of booting. That was reverted and brought us to where we are.

Watching memory usage on current nightlies the absolute lowest free memory I've seen is around 150mb, but usually it gets down to the area of ~170mb and floats around there; maybe adding another 25-50mb to whatever the limit is currently set to would be beneficial? Sure, it would lower multitasking capacity, but given the choice between having the phone drag along "at capacity" or be speedy while juggling one or two fewer processes...I think most would go for the latter.