RAM: What it is, how it's used, and why you shouldn't care

Why, in the name of all things holy, does the fastest, most powerful phone on the market have a widget warning me how many apps are open?

Many of you guys know me, and how I am (if you don't, imagine some godless mash-up of anal retentiveness and OCD), so you know this is something that just had to be addressed or I would never sleep well at night again. Which leads us to here and now. The answer to the question is pretty easy -- user madness and FUD forced manufacturers to add some sort of RAM-cleaning, task-killing, and problem-causing widget to current builds of their software. For most of us, the system running on our Android phones, and the way it handles RAM usage, is very different than what we are used to on our computers. If we take a few minutes to understand the way RAM is managed on our phones, we'll not only be able to better interpret what that widget is telling us, but also understand why it doesn't really matter. Let's do that, after the break.

The 'Task Killer' debate

Every discussion about Android phones and tablets, and how they manage memory will eventually get to the Task Killer debate, so we're going to start with it. Simply put -- task managers are good; task killers are bad. In the hands of someone who is aware of what will happen when they stop a running application, a tool that easily lets them do it is a fine thing for everyone. It's a function built into every operating system, including Android. It's a useful debugging tool, and great for developers and power users alike. The problem is that if you're here at Android Central reading, you're either a power user already, or a power user in training and understand more than most people who just install TASK KILLBOT 2000 because the Market description said it will make your phone ZOMG FAST. You realize that killing the Mail app will stop you from getting mail, or that killing the system clock will make you late for work. Harriet Housewife, who just picked up her shiny new Android phone at the Verizon store doesn't -- and she doesn't have to -- unless she gives in to the FUD (or worse, some kid at a store who thinks task killers are a gift from Zeus himself) and installs the task killer. It's not her fault though, as it seems like every time you turn around someone, somewhere is saying that to get good battery life and ZOMG FAST you need to use one.

You don't. You won't. And it makes Cory twitch a little and think about ammunition and clock towers. Keep reading. ...

What is RAM?

RAM (Random Access Memory) is storage used for a place to hold data. Think of it as a big filing cabinet that keeps things ready for the CPU in your phone to present it to your eyes and ears. It's infinitely (almost) re-writable, very fast, and used differently by different operating systems. Many of you guys understand what it is, how it works, and what I'm explaining -- but we're going to try and break it down so that more normal and well-adjusted people can follow along.

RAM is used for one reason only. Reading and writing to file storage (as in reading and writing to your hard drive in your computer, or your internal memory/SD card on your phone) is terribly slow. Solid-state "disks," like what's used in our Android devices and what a lot of geeks people use as hard drives in their computers, are faster than spinning disk platters (normal computer hard drives), but using it to cache the data we need is still a lot slower that using dedicated, solid-state RAM. RAM is cheap. The bus (a pathway for the electrical signals to travel along) between the CPU and the RAM is fast, and everything is kept orderly and easy to retrieve. It's also resource friendly to read and write to it. Without it, computers of all sizes would suck a lot more.

Running applications

Widgets and apps that monitor the apps "running" (quotes intended) aren't inherently evil. We're going to pick on Samsung here, but Motorola, HTC, and the rest all do the same thing in different ways. And what they are doing isn't inherently bad -- people have been using tools like Torsmo and Rainmeter to show a fancy graph of their RAM right where they can see it for a while, and nobody has been hurt (yet). But when that little widget turns bright red like it's screaming "Danger, Will Robinson!" with no explanation, it's time to step in and try to explain the process.

In Android, like many other operating systems built from Unix roots, all share one common thing about RAM:

Unused RAM is wasted RAM.

Android, like Mac OS and Ubuntu, wants to use all the RAM it can, because that's how it was designed to work. There are settings (in Android we call them "minfree" settings) to tell the system how much RAM to leave free and available, but the rest is designed to fill up as fast as possible and stay that way.

You're probably thinking "What's it filling up with?" That's a great question. After the system, graphics, radios, and any other tweaks to RAM are done loading, the rest is there to load apps into memory, right up to the point where the OS says to stop. Load the app as it's being used, and keep it there for the next time until it needs flushed to free space for something else. The more you use the system, the better it gets at keeping the right things loaded and ready to go. Think about how you use your phone -- you might have 100 apps installed, but there are a few you always are opening and using. Eventually, most of those apps will be stored in your RAM, simply because you're always opening them and loading them into the RAM if they weren't already there -- and "erasing" other apps that were there first. Loading an app from your storage takes longer, is harder on the battery, and overall worse than loading it from it's cached position in RAM.

Consider this -- Jerry did/said/thought something that made his wife mad (yes, she can read my thoughts), so he bought flowers from the 7-Eleven and wants to make a mix CD of her favorite Rod Stewart songs to give to her and get his ass out of the doghouse. It could happen. Consider which is more efficient:

Burn 20 songs to a CD, give to wife, and smile while she plays it.

Burn one song to a CD, let her listen, then erase it and burn the next song.

That's what your phone (or tablet) has to consider. Loading Google Talk to RAM once, and having it there to open almost instantly is far better than loading it each and every time you want to use it. So why kill it off? It's not like you'll never use it again, and nothing else is going to use that RAM while it's sitting empty -- at that point, it's wasted space. You will also use a lot more battery power re-opening Talk every time you get a message than you will by having the zeros held as ones on your RAM. The folks who built Android really did know what they were doing when it comes to memory management. After the parameters are set, and the amount the OS can use to "swap" for it's normal operations, the rest is simply wasted if we're not using it. What is cached in RAM is just sitting there, not using any CPU cycles, but ready to get pushed to the front and appear on the screen as fast as it can, and not use the extra battery needed to start it up from disk again.

But Task Killers and freeing RAM made my <insert old Android phone> better!

Having 4MB of RAM made old Windows 3.1 computers better, too. Android, and the hardware it runs on, evolves in our hands -- it gets better with every new release. The software is better, the hardware is better, and the folks writing the apps are getting better at it with better tools. We're going to use the HTC Hero as an example here, because we don't talk about the HTC Hero enough anymore.

By today's standards, the hardware and the software on the Hero suck. It sucked the same when it was new, but at the time we didn't have Bionic's or Thrill 4G's to compare it to. We only knew that there were three ways to make it run faster -- yank HTC Sense off of it, use a task killer, or tweak the system a whole helluva lot. Two of those options need root access -- so that puts 90+ percent of users out of the picture.

Normal people don't root their phones, and Harriet Housewife (or Tommy Textgod) are normal. They bought a phone that could do more than any other phone they ever used before, so they tried to do it all. Android and HTC Sense weren't near as good at managing themselves and their memory needs back then, and having the RAM full meant that there wasn't quite enough left over to run the user interface as fast as it did when the RAM was empty. Hackers soon found that tweaking the existing settings that decide how much RAM to keep free did a wonderful job at fixing that issue, and we all were happy. But if you didn't want to hack your phone, you had the option of just living with it being slow every once in a while or using a task killer to free up some RAM. I'll bet most people just lived with it (the number of people who installed a task killer is waaayyy smaller than the number of people who bought an old Hero, Eris, Cliq, or Behold), but people who spent any time on the Internet fell victim to the lure of a task killer. Soon, forums across the web filled with tales of woe about things not working right -- because everyone was randomly killing off important system processes and apps that needed to stay running.

There were also issues with apps. A correctly coded app that uses a ton of resources, let's say Plants vs. Zombies, gobbles up a bunch of your RAM while you're using it, but gracefully exits and purges itself when it's done. That means the RAM is free, being wasted, and needs filled up again when you load up Google Talk. When you're done chatting, Google Talk just gets sent to the background because it didn't have to take a ton of RAM and should stay loaded for the next time. When Android was shiny and new, a lot of apps that used an excessive amount of system resources didn't exit gracefully, and the OS struggled to purge RAM and load itself back to the foreground -- causing lag when you closed a big app. Sometimes the lag lasted a while, and people soon tired of it. Killing every damn process you can and jacking the free RAM up as high as possible, or even worse -- scheduling a task killer app to do it automatically every so often -- seemed like the best solution to a whole lot of people. We're mostly past that now. App developers are crafty, and the tools they have at their disposal mean that most of the time they get it right -- even on the first try.

Why it no longer matters

Nowadays, the hardware in our phones is amazing and the software is very much improved. Android can manage memory rather well (and the settings are still there to tweak if you just have to touch stuff) and having up to 300 percent more RAM makes a huge difference. There will be a few times where killing off a handful of tasks will speed things up, but overall you'll get the best performance out of your phone or tablet if you stop worrying about it and let Android be Android. If you need to live on the edge (and I know a lot of you guys do) root and hack your phone with some amazazazing custom ROM that has everything tweaked and allows you to travel forward in time -- I'm right there with ya, cause it's fun as hell.

But don't worry about how many apps are running on your phone, or about using widgets that tell you these things, because it just doesn't matter anymore. We can't blame OEM's like Samsung for doing it -- it was inevitable with all the brouhaha out there, and some may even say necessary with earlier phones. I promise, this just isn't going to happen:

Reader comments

RAM: What it is, how it's used, and why you shouldn't care

Okay, so I'm a little old school here. And to be honest I'm not really all that into the deeper side of smartphone tech. But as an old school PC man (which really that's what a smartphone seems to be, a handheld PC) i can tell you that one of the easiest, and cheapest, ways to jack up performance is to increase RAM.
Processing speed is only part of the equation, insufficient RAM means your processor is trying to manage traffic thru downtown Boston...
during rush hour...
...in a blizzard.
Double your RAM and suddenly your processor is cruising Autobahn style...in an Aston Martin.

Here's a question I really would like to see an answer to: Why in the name of the Elder Gods is my internal storage disappearing at such an alarming rate?! Ive dumped apps, uninstalled updates, orchestrated a mass exodus to the SD card, erased call logs, message logs...and still i have just barely enough left for the phone to run. I literally can not update anything on my phone or it starts coding (medically speaking). I just don't get it.

This article could be more accurate phones that only have one gigabyte or RAM are going to slow down lock up etc I just bought a new phone which has two gigabytes of RAM and its world of difference. So for the millions and millions of Android users out there that only have one gigabyte of RAM which is current they are still going to have problems using larger apps like Skype and Google maps and navigation apps etc all the same time it's just not going to work right and never has worked right for me I've always had to kill arie move some apps to get the phone to work correctly and this has been the same situation for the last for Android phones I've owned it's just that simple

if more RAM is available I'll buy the phone with more RAM because I want to be able to see video with no lag or buffering which occurs a lot on older 512MB RAM phones but not so much on 2 Gig Ram phones this blog is utter rubbish just because a device has a quad core processor and 512MB of Ram doesn't mean it will perform as well as a quad core with 2 gig of RAM. its not just about being able to go back to something quicker Ram speeds up internet searches hasn't anybody uprated their RAM in their home computer to see how much faster it makes an internet search it reduces the lag a lot, the time it takes to do something. it really makes a big difference between devices. but in saying that the match between processing power and RAM has to be made the manufacturers are currently bunging in old 512MB RAM because it is relatively cheap to use RAM is expensive and so is processing power but the phone industry seem to have the ability to buy cheap processors and still install the cheapest RAM. Mobile ram is even being used in cheap Laptops these days because it is somewhat cheaper than Decent proper computer laptop RAM. single data rate as opposed to double data rate or even DDR3. oh and core is spelt CORE not CAOIR as in the search bar.

Hmm... So this article makes a lot of sense where it explains what RAM is and how it is managed on Android.
But it makes for a very poor defence of Android OS per se, or why it is more efficient compared to other OSes including Desktop OSes:

Fine, Android uses RAM more efficiently and so won't matter much if apps are kept in the RAM or not. But Nobody, I say nobody on this forum has answered these questions, which have been already raised by quite a few sceptics:

1) Why does it choose to load many apps I never use. That seems like very poor management to me? And why does it not choose the correct apps to "pre-load" that I DO actually use?
2) Why is it that there are apps that are running (whether running actively or a stored mem location) for applications that I have not ever launched and do not ever plan too. I have never used "Peep" and others in my life....but yet it consistently appears as a running process. Why?
3) The phone is simple killing apps before the amount of free memory gets so low that the phone lags. But that's either ideal because that kills off multitasking. You leave your browser and the open tabs reload when u re-enter it. Or the (ill coded) game u left for checking your mail resets you to the main menu etc.. So clearly Android is only somewhat better at Multitasking, not a sure winner on this count, right?
4) People are advising that I should just the notifications off, instead of killing the Apps.. Why? Why should the OS randomly keep some Apps - that I never intend to use - in the memory (running or just sleeping) on its own, and then ask me to turn of the notifications so as to not get irritated? Is it not just simple and beautiful to not run those apps in the first place?
5) Yes there are buggy or poorly written apps and it's not Android's fault! Great. So there were viruses on PCs and that was surely not Windows' fault. We all loved vilifying Windows though!

I guess this whole exercise is just to provide an excuse so that apps such as Google services or Facebook are not killed by users (using App Killers, App Managers or by just asking Android to kill apps selectively from "Running Apps" list) and thus they keep to get their hands on the info shared by the users! Other apps are being defended only collaterally!

It is a terrible defence to say that Android keeps some apps in the memory since they're frequently used and/or I should not at all worry about it in the first place since Android manages the RAM really well. To me those Apps running are as good as spam-ware when I don't need them. If Android really manages RAM well, I'm fine with 100% of it getting filled up. But then let Android allow me to choose which are my frequently needed/heavy apps.

If Android was so intelligent to the extent of making that choice for me, those several faithfuls on this very forum - who've been using Android phones for more than a couple of years - won't have complained about facing glitches/lags/delays when starting new apps, or after leaving several apps unclosed for a few days.

Good response to Jerry's very misguided article.
"If you're not using it you're wasting it." is the dumbest thing I've ever heard.
What if you need to start up a resource-heavy app like Maps, but your RAM is already full of crap you don't need?
Quite often, Maps wiil take several minutes to start up, or cause my phone to hang indefinitely. (Samsung Galaxy S2). I often find my destination on my own, well before Maps was able to start up, at which point I rip out the battery, and restart the phone. However, Maps is far more likely to start up successfully, and runs much more smoothly, if I first kill all running tasks and clear the RAM... Clear evidance that Jerry is wrong.
The good news is that I think I have found one of the main bloatware culprits: Facebook!
The Settings->Battery usage graph was showing that Facebook was draining 30% of my battery each day, even though I never use it, and dont even have it logged in. Just doing a "Force stop" on Facebook did not make much difference, but once I uninstalled Facebook, it made a HUGE difference to my phone's overall performance. The Touch-wiz interface, and even Maps now scrolls smoothly, and Maps now starts up in well under a minute! And my Battery clearly lasts much longer too! Getting rid of Facebook was the best thing I could have done for my phone. Now, where can I find that great ZOMG Fast Task killer that Jerry was dissing?

LOL, I think the verdict is this...If you have a phone with less than 500mb of RAM, Task Killers may have a short term benefit to you. Generally though, Task Killers are bad because at the least, they will force the phone to use more power each time you want to access a frequently used app. Sounds like Task Killers are like giving your phone Alzheimer's; loss of all short term memory.

Have to put my two cents in. Whatever else these knowledgeable people know-I know this. Auto Memory Manager saved my life. I am on an Xperia mini 187ram I think. It was unbearable. I found this blog, and over a year I learned so much about which apps out there are system terrors. I also learned that its simply not true that RAM managers are useless. My experience is firmly otherwise. A good RAM manager can make even the most intractable phone, a joy to use. For anyone who knows the sheer frustration of a sticky system, try a good RAM manager. It doesn't hurt.

I'm going to try going a few days without opening up my task killer, just to give your advice a try. Hopefully, it will be as you said, and I will rarely ever have to press that task killing button again. And, hopefully, it will also save battery. My biggest concern is the apps that open in the background that I've never even opened. Are there any knowledgeable "android enthusiasts" that can offer me information about those processes?

I'm trying to get a new Android tablet this Black Friday. But that photo at the end of the article seriously scared me. I have a Palm Pixi Plus, and I get that message all too much. I think I actually heard the beep before looking down at my phone. :p

don't bother ur self with android,believe me u will spend more time fixing it and trying to tweak tweak the system to get the damn device to give u at least a day of work without charging it every few hours and u will give ur self a headache trying to figure out what's causing a jam here and a lag there and why it keeps freezing on this app and on that other app and u will keep jumping on the internet every couple days to figure out how to solve the random reboots and u will jump on the internet again to find out why it gave u this error and that other error !basically u will spent all this wasted time to fix this,that and the other THAN ACTUALLY USING THE DAMN device !!
trust me on this,wether u r a power user or NOT,u still want a device that last u at least a full day without having to charge it and u still want a device that will do the job without u having to worry about bad apps and good apps,without having to worry about ur super doper CPU which does fuck all anyway,and WITHOUT having to be here right now researching why ur phone is doing this or that or the other,trust me,get an ipad and save ur self all this headache and wasted time trying to get the damn thing to work,I know ppl r gona start talking about how limited ios is,and how thiefs apple r , bit the facts talk 4 them selfs : no matter how much ios isis accused of being limited,u will always find the app that serves u 99%OF THE TIME and the system is solid rock from head to toe. this is why apple rocks !

You may be shocked, but most people who use and like Android are doing all the tweaking, and fixing, and flashing custom ROMs, and this, and that mainly for fun and to satisfy the itch of making their device even better than it already is. Bottom line is that for a regular user there is no problem just using the damn device. :) Au contraire, the Apple way is for a user to accept the device exactly as it is, and assume the premise (I can't call it a fact, sorry) of this device being the best just because... because... heck, how could it not be, if Apple says so! :) It's a fundamental difference in mentality -- some people just would not accept a device, however good it is, without the ability to play with it in some ways they (not the manufacturer!) may want to.

I have nothing against Apple products; everyone should be able to use whatever works for them. But Apple fanboys (sincerely, no offence to any and all normal, reasonable Apple users, which there are plenty) are the most brainwashed lot one can possibly imagine... :)))

BTW, looking at your post, it seems like you type faster than you think. Try doing it the other way around, you might like it... :P

Getting back on topic, this was a great article to read, and fun, too. Kudos to Jerry!

I've read the whole article,and that's the bottom line and what it all comes down to : the user should never ever have to worry about these things,the user shouldn't even have any knowledge about these things,the truth and fact is : this is why apple has succeeded and this is why they will continue to succed until other OS makers start getting the idea that users shouldn't worry about any of this.a user wants a device that is power efficient and does the job,does what ever it claims that it can do without any problems,a user DOESN'T want a device that claims to do everything in the world but only does half the job.
the bottom line is: only one manufacturer in the world (until now) has got it right, APPLE .
BOTTOM LINE IS : APPLE ROCKS !!

None of this holds true with my infuse. When the ram becomes high the phone becomes almost unuseable. I always must make sure the ram stays down in order to use the phone properly. The Gingerbread update does not help anything either.

To be fair this article is well written and informative for the average joe. However it offers no details into how to tweak so that the built in memory management works the best and what not. This is what I really want to know. Read my whole comment to find out why. I currently use a samsung epic 4G. And I think android is a good OS. If I didn't I wouldn't still be using the epic I would have looked for something else or went with a frankendevice for webOS.

It took me almost a year to figure/find out on my own what I needed to tweak so that my epic wasn't laggy and didn't have poor battery life. Both are tied to this built in memory management. Out of the box, with large RAM devices there are far too many active tasks things left in RAM from preinstalled apps, widgets, or services and 3rd party apps widgets, or services you don't use. But do use the apps they are part of. The result is bad battery life and laggy OS and apps. Both big negatives everyone complains about.

Downside to this built in memory management is apps that are not currently the one on the screen end up appearing to be closed. Because switching back to an app you didn't "close" using the back button revert to a full or partial original state as if they had been closed. Requiring the user to take steps in the app to return to the state they left the app in. Another reason why information on how to best tweek the built in management should have been in this article. As this is a problem I'm still trying to solve.

This is a problem I do not have using webOS. I bring this up as it's shown in negative light as reason why androids memory management thing is better. Everyone should keep in mind there was a bug that caused the too many cards error to occur prematurely and there has been a fix for a long time now. webOS is similar to a desktop OS as far as running apps. Every app that is open is really open and remains open until closed by the user. So they don't suffer from incorrectly remembered states of apps from being ripped from RAM at the expense of another running app or memory leak (all platforms have this problem). So if the too many cards message wasn't there users would wonder why their app didn't load just like when on a desktop OS you would get a similar message when there is no more memory left to open an app.

App load time doesn't matter on an OS that works like webOS and desktop OSes if you leave frequently loaded apps open. After all most apps on these OSes are only consuming battery and CPU cycles when you are actively using them. Why should the OS dictate to me what apps are closed or left running? when I may need to use every app I just opened. And unless there is a way to tweek it so that the problem from the previous paragraph doesn't happen I will have to say that webOS and desktop OSes have it right in letting the user decide what to close or leave running.

The Too Many Cards error was purged on 1.4.5 Pre's pretty well. Then the Pre2 came out... and TMC was back in force! Fortunately the 2.1 update seems to have mostly fixed it on my Pre2 - but now the proximity sensor is scrambled. (or maybe dropped one to many times).

Informative material for the folks not keen on RAM management. Can there be a similar write-up for App Cache Memory? Can you explain the differences and why it's important?

I have an HTC Incredible. Since the beginning I did a good job managing overall memory. It baffled me that every few months my phone would start wigging out saying "Device Memory Full, Remove Apps to Free Space" followed by constant FCs and random reboots. Checking the device memory always showed ample free space in all areas.

Each time it happened I did a factory reset. Three times in HTC Sense Froyo and once in CM7 Gingerbread (reloaded rom). I was baffled why it kept happening. The folks at the Cyanogen Forum explained about the App Cache Memory. I discovered it is a designated area not always shown in memory stats. Apparently, certain apps like Facebook fill up the App Cache Memory and don't clear it. I started using a daily App Cache Cleaner to keep that area clear. So far I have not experienced the issue in 3-4 months. These apps show the status of the App Cache and what apps are using it up. Of course I am selective to which apps are cleared. As with the task killer I imagine clearing vital apps like widgets etc would screw things up. What is Android Central's take on App Cache Memory?

There are a few things in this article that make no sense to me. While I understand the concepts of what is explained for the most part...I do not understand a few aspects. Why is it that there are apps that are running (whether running actively or a stored mem location) for applications that I have not ever launched and do not ever plan too. I have never used "Peep" and others in my life....but yet it consistently appears as a running process...depending upon which ROM I am running at time of course, Stock ROM included. So the point of it learning and loading this ahead of time, doesn't seem too make much sense, since these apps are never loaded and takes up my RAM...no matter how little it is. Additionally this also means it is taking up power, as little as it maybe as too.

I also don't understand the unused RAM is wasted RAM? Perhaps this is because I am coming from a more Windows oriented background....why don't we always on PC's just fire up all of the programs we use on a daily basis....even if we aren't going to use them right away. I can tell you why....cause after having 25 chrome browsers and 15 windows programs, etc open....the PC starts to slow to a turtle's pace. It just doesn't make any sense to load this stuff when it is not being used. Let the CPU and RAM do its job of swapping the allocations. RAM is there so that you don't have to write to any type of swap space....not to be full of unused apps and then have the system abruptly manage the importance of the app and decide if it needs to kill a process or swap out what is needed.

You have to remember, though, that these devices are running on a *very* different kind of hardware than your Windows PC. Not only is Android running on top of a heavily modified Linux system, the CPU and memory architectures are completely different. It's setup to run this way because it offers the most efficient battery consumption.

On your home PC, if you launch Microsoft Word, the computer shows you the little hourglass (or blue circle if you're modern :) ) and the hard drive light flickers like crazy while Windows determines all the files that need to be loaded and does all it's calculations to determine the size of your screen and how big the tool bars should be and which icons you like to have available and reading your preferences file to know which document view you prefer and *then*, after all that, shows you the application.

The idea in a mobile environment is that the RAM consumes far less power to hold data, so it's more memory efficient to keep the application there once we've done all that work so that next time you want to launch the app, we don't have to do it again. It's already there, which no battery consumed by loading it from the SDCard or using CPU power to figure out all the initial settings.

Again, the way an Android device works is drastically different from a x86 architecture PC, and I think that's where a lot of people's confusion stems from.

TL;DR - The way Android does it is more power efficient than the way Windows does it, and the hardware in an Android device is *designed* for it to work this way. Hardware on a Windows device is not.

This makes more sense. But why does it choose to load many apps I never use. That seems like very poor management to me? And why does it not choose the correct apps to "pre-load" that I DO actually use?

In response to the "unused RAM is wasted RAM" question, I'd like to point out that it is rare to have much free memory on linux systems or modern Windows systems (Vista and Win7) for exactly this reason. Here are two articles about modern Windows memory management that both use similar phrases to describe how (modern) desktop PCs do it. Note that the caching mechanism being described isn't the same as opening all the applications when you start the PC. Windows can free up memory used for caching at any time, but it's not going to kill an application you are "running", so filling your memory with cached applications is VERY different from filling it with "running" applications...wven if you aren't doing anything with them at the time.

nice read
i can say android has had much progress since i'm with a very low end device - htc tattoo. use to slow down like hell when i was on 1.6 with htc sense. for a year now i'm running a custom rom. now it's running with a 2.3.5 version of android and the phone is faster that 2.2, light years away from 1.6....
don't use task killers, if i ever need to kill something i just do it from the manage apps in the settings.
there is a fast reboot app on the market - it also does a good job
:)

Sorry, cant say I dig this article because it leaves the most interessting points untouched. What makes the same device faster with more ram "free" than with less? And what about multitasking?

First of, having free ram isnt useless because it isnt really free (for the most part). It is used as a filecache! My Galaxy S1 really gets slow and laggy when I got less than 40 - 50 MB free.

Of cause, with everythin stock, this wont happen. The phone is simple killing apps before the amount of free memory gets so low that the phone lags. But thats either ideal because that kills off multitasking. You leave your browser and the open tabs reload when u reenter it. Or the (ill coded) game u left for checking your mail resets you to the main menu etc.

The main fault for this lies by samsung for puting just ~340 MB of ram usable for the OS and apps in the Galaxy S1 phones. The S2 with its whopping 1 GB doesnt have that problem at all. Just leave the mim-free-settings at stock and stay away from taskkillers.

But its wrong to say the problem is only in the head of the users. Many Mid- and Entry-Level smartphones still have the same problem, as well as some 2010 high-end devices!

I don't understand how people read this article and still don't get it. "Well, I use a task killer and get a performance upgrade." "Well, I use a task killer and my phone stops messing up." It makes me giggle on the inside.

That being said, excellent post Mr. Jerry. A couple of things I'd like to clarify or point out for those of you who are still misunderstanding the article.

1. From our dear OP: UNUSED RAM IS WASTED RAM. Period.

2. An extremely oversimplified hierarchy of a processor command sequence is as follows: Processor receives task X to do; processor searches all RAM for said program; processor searches all permanent storage for said program. Once found, if not in RAM, program X (or just the important stuff) is loaded into RAM. Processor accesses data from RAM. What this means is when you kill that task that is using all of that precious RAM.. you guessed it. Revert to number one.

3. Filled RAM does NOT use any battery life. If you have 1 million applications showing up as "running" on your task killer because they are all using RAM but no CPU usage, it will have no effect whatsoever on your battery. Killing them, however, will. Background applications that show up on task killers don't necessarily mean they are physically running. Remember, RAM has zero moving parts. The only thing that impacts battery performance in RAM is accessing it through a read/write command.

@mpnalvin: no, you don't get it. But I'm glad you know you don't =) "When you kill an app, it doesn't create wasted space. Either Android or the Linux kernel it runs on will fill that space with something else."

The phone performance you talk about by freeing up used RAM would have already been or could still be perfectly executed by the unused RAM at that point. Ergo, you ABSOLUTELY create wasted space. The only time you don't create wasted space by wiping RAM is if you use 100% of your RAM, 200% of the time. When you kill an app, most task killers wipe that application from all of our resources as if it were never ran. That includes the processor cache and RAM. Later that day, we open the same application. Our phone then has to repeat the exact same sequence it already did (#2 on the list). Not only does this unnecessarily kill the battery, it also makes the access time to that program slower the next time we open it. This doesn't even account for the battery usage for the app to be "killed". That RAM being temporarily used up for a non-running application will be filled with another application if needed anyways, you don't have to free it up for the system.

So you are saying that there is an issue in that the app killers are overzealous. Well, that might well be -- it's one of the many things I don't know, and in fact I do plan to look into this and understand exactly how the app killers work. I want to know, for example, if what the app killer is different from what Android does when it kills an app, and if so, why.

By the way, I am not one of those claiming any increased phone performance by freeing up RAM. My phone (Epic Touch) is capable enough that I doubt I could tell one way or the other. All I want to stop are backgrounded apps that eat my battery, in my case mostly through internet access. I would be very interested to understand how much battery is required to kill an app and reload it versus, say, how much you use for the screen or wireless. I suspect that killing apps and loading from flash to memory are very small loads, but I have no way to obtain data on that. I would much rather have a definite savings in battery from killing a backgrounded app that uses wireless, than a potential savings from reloading the app later.

Perhaps so, but Exynos is still the faster package. Dual channels rarely make a lot of difference and wont compensate for the fact that the OMAP4 is just not that fast. Exynos is king until Kal-El is available.

I'm really disappointed with this thread. Several people have brought up legitimate concerns and experiences, and instead of trying to answer them, the responses are
"I don't believe you"
"You're idiots!"
"Thumbs down."

So, what terrible, awful thing happens if you kill an app via an app killer? The only consequence I see in the article is that you might take a little longer (how much?) to load it back in the next time. That's it? That's the big deal -- loading from RAM instead of flash? For most apps, that delay is inconsequential.

When you kill an app, it doesn't create wasted space. Either Android or the Linux kernel it runs on will fill that space with something else. So you are freeing resources for something else to run, or for data caching to make the phone run smoother. Fine, Android will take care of killing things if resources become too constrained. In the meantime, some of those backgrounded apps seem to be able to use internet access and eat up battery. The argument is that this is preferable to using a task killer that might cause a slight delay the next time I open the app? I don't get it.

Based on my experience, I cannot trust Android apps to behave even if backgrounded. And I cannot trust Android to kill apps that are sucking battery. Could someone knowledgeable actually comment on this and not just tell me I'm an idiot for wanting to preserve my battery life?

OBAMA is President of the united Sates, that does not mean he knows what he is doing,
No offense hackbod,
beafdefx its much much deeper rabbit hole that is being told here.
and some ones position does not mean there beliefs are true.
there is truth in both sides, and we all need to open up our ears and listen to each other, that way we all learn.

from http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-...
""
Note that memory usage on modern operating systems like Linux is an extremely complicated and difficult to understand area. In fact the chances of you actually correctly interpreting whatever numbers you get is extremely low. (Pretty much every time I look at memory usage numbers with other engineers, there is always a long discussion about what they actually mean that only results in a vague conclusion.)""
BOY IS THAT THE TRUTH !

While I largely agree with you, @odonlow, what @hackbod is trying to do here is educate everyone how the Android OS is *designed* to manager memory. You are correct, though: that is a very complicated process. That's why it has (and I'm sure *is*) been refined so much since Android's inception.

The arguments to be made on the side of killing apps involve not trusting apps to shut down properly, and I agree with that statement. I guess my philosophy on it is that I uninstall apps I discover are eating a lot of juice.

I think that, if running an automated task killer actually makes your phone more stable or improves your batter life, then you have an application that should be removed and down graded in the market for being poorly written. You can use System Panel to monitor an application's active CPU usage and Traffic Monitor to see how much data each app is sending/receiving to the net. Both are free in the Market.

Except that is not how it works. When you use a task killer, you are just forcing Android to fill up the cache every time you kill your apps. This takes battery power and makes the phone more inefficient. In general, if an app killer is helping your battery it is because you have an app that is poorly written and causing the problem. Using an app killer to manage a poorly written app is throwing the baby out with the bathwater. You would be much better served by figuring out which app is the problem and uninstalling that and your app killer.

Android is just the OS, it cannot tell if you (or the developer) intended an app to run in the background using up battery. Poorly written apps are not the fault of the OS and using a task killer rather than leaving poor ratings for bad apps is just magnifying the problem.

I don't disagree with this at all. But I draw a different conclusion that you do. I assume the following:
1) There are badly written apps on the market that eat battery when backgrounded
2) It is not always easy to tell before installing that a given app falls into the battery-eating category. Maybe some versions of the app do and other don't. Maybe the key comment on this is comment #4000 out of 10000.
3) Even if an app does eat battery when backgrounded, it might be otherwise useful. It might be the only app available that fulfills some function, or it may be proprietary, or I might just like it apart from the battery-eating. In this case, I might not want to uninstall it.

In this situation, it seems quite reasonable to run the app, then kill it. The information from hackbod agrees with my assessment that Android cannot at present tell that the app is behaving badly. The choices are uninstall it, or run it and kill it.

Frankly, I can't believe that filling the cache is a huge battery drain. You're talking about a RAM-to-RAM copy. That should be one of the least energy and time-intensive functions on the phone. If that is killing my battery, I have way bigger problems. Even if it's flash-to-RAM, it's only doing the same thing as starting a new app would do. Do you believe that I should limit the number of apps I start to preserve battery life?

So here's what I'm saying and what I'm not saying. I'm not saying "look how stupid Android is -- it can't even manage its own memory." I'm not attacking Android. I'm not suggesting that everyone should run some automated task killer that kills things every 10 minutes. All I'm saying is that while we're waiting for an app developer to find my comment about battery usage on Android market and fix their code, I might nevertheless want to use that app, and if I do, using a task killer seems like a legitimate short-term workaround.

Trying to talk about this is difficult. This is not just because opinions are strongly held. It is also because memory and process management is complicated, and apparently on Android it is more complicated than most because it seems you have essentially two OS views of memory (Android and Linux) each with their own process and memory models.

Finally, on the issue of whether badly written apps are the fault of the OS, it is easy to say "it's not Android's fault." But I think even this issue is more complicated than it appears. Would you agree, for example, that viruses are not Windows' fault? Windows does not contain apis designed to support viruses, but the way it was written made it an easy target. So even though Windows was certainly not designed to be a host for viruses, the design enabled them and Microsoft took it upon themselves to modify the OS to prevent them. Could Android do something to prevent poorly written apps? Could it do more to help users recognize battery-intensive apps either in the market or as they are running? I don't know. But I do know that if I were working on Android, it's something I would be thinking about.

when i reboot my nexus s,the facebook app is always on the Running app section on Manage App even if i didnt open the app already.Does it means it was running and consume battery?Is it better to kill the app that you are not frequently use?

Running does not mean consuming power, it means the app is consuming RAM because it has said it needs to be kept around because it *may* need to do something and hasn't otherwise set up anything to have the system take care of launching it.

To take Facebook as an example, it may have a network connection being kept open all of the time to Facebook's servers, so that any time the server detects something that may be of interest to you it can immediately send that down to the app. Sitting there with the network connection open (mostly) doesn't take any battery power; battery will only be consumed when there is actual data activity on the connection.

Still, RAM is often a precious resource, and one really doesn't want 10 apps all sitting there with continually open network sockets. (Partly because in fact they do take a *little* power, because there does need to be some occasional data going through it to keep the connection alive. One won't be noticeable, but 10x that will start to be.)

Android has a number of facilities to allow applications to avoid this. A common one is to use the alarm manager to have the app wake up at a regular interval to check in with a server. You will often see this with for example e-mail apps, where you set them to update every 15 minutes or so. Note though that this actually can be more expensive on the battery than keeping a network connection open -- launching the app and establishing a network connection does take power, so doing this too often will causing a noticeable drain on your battery. That is why we recommend that apps don't do this kind of polling more than every 15 minutes.

Another solution is Google's "Cloud to Device Messaging" service. Google's own apps do need to keep a constant network connection open to Google's servers. This single connection is shared across all of Google's apps, from tickling gmail to tell it there are new messages it should fetch, to poking Market to have it install an app you have selected on the web site.

Google provides an API for this constant connection so that other developers can also make use of it. They can register with Google's application that maintains this connection, to have it wake up their app if data appears on it for that app. Then in their server they can connect with Google's server to have it send a tickle to a particular app on a particular phone, to have it wake up and do whatever is needed -- check for mail, get a status update, etc.

I don't understand why apps like Facebook & Skype continue to use RAM when I've turned off all auto refreshes and notifications. The reason I like to keep my RAM clear is because when it gets full, my app menu (stock Nexus) takes forever to load (does this mean it is getting kicked out?).

Just like Jerry said in the article, if you use the Facebook app a lot, Android has decided that it's advantageous to leave it cached in memory so that it can be accessed quickly. Your RAM should never really get "Full" unless you've got a badly written app that is allocating RAM and not properly releasing it when it's done. The OS has a "minimum available RAM" threshold, and when that is hit, it will unload those cached applications to make more room. Although I personally have noticed a big difference in battery performance between having the Facebook app's notifications turned off, If you've got them disabled, it should not be using battery just sitting in memory. Check how often the Accuweather app is updating. Some of those weather apps like to update like every 15 minutes and that can affect battery life.

I never actually see "Full", what I notice is that things start to get a little slow as Android "unloads" old processes to "load" things I'm trying to open (ie. App drawer). Since moving to GPA17 (from Stock), I've noticed this happening less often.

Here is a little information (from Android's App Manager)
All of these show up under Running Processes, NOT Cached Processes.

I had a Best Buy rep argue about this with me when I picked up my TBolt. Never mind the fact that this is my 4th Android phone, nor the fact that I had been using the platform for more than two years at that point. She told me it was ABSOLUTELY MANDATORY that I install a task killer first thing. I tried to talk some sense into her, and even told her that her advice was actually more harmful than good, but she refused to listen. I really wish the sales reps were a little more well versed with this. Thank you for telling the world the truth.

Great write up Jerry. I think people coming from a BlackBerry are more prone to installing and using task killers. Having helped a great many people get accustomed to their new Android devices, one of the first questions former BB users ask is, how do I close apps? I think most Verizon reps would rather just install ATK than explain what you have in this post.

Thank you. I cringed the other day when a friend sent me a link to a ZDNet article listing the top 20 Android apps of 2011, and Advanced Task Killer was #2. Here's the author's blurb about ATK:

"One of the realities of having a multitasking mobile OS is that you have to manage your apps so that they don’t hurt performance or battery life. Advanced Task Killer (ATK) is my favorite on Android. It even comes with a widget that you can tap once to kill all open apps and you can also set up ATK to kill all apps at periodic intervals. Some people will argue that task managers are irrelevant and unneeded in Android, but I still prefer to use ATK."

Ugh! One of the realities of having a multitasking mobile OS is that there will always be idiots out there claiming that the users has to do the work that the OS is already designed to do.

Well I'm new enough to Android that the last graphic was well over my head. It makes sense, although my understanding of RAM is coming from Windows (XP and more recently Win7). Thanks for clearing things up. When my contract is up I'm getting into Android. Thanks for clearing things up. I guess I need to do some research into a Task Killer vs. a Task Manager.

Thanks for the write-up. I look forward to more of these superb and informative articles

They're pretty much the same thing. Generally, though, when someone refers to a "Task Killer", they're talking about something that's automatically killing off memory-resident tasks on some kind of schedule. This will usually cause all kinds of flakiness with the phone since they often kill of important system tasks.

Say what you want, RAM does matter, I have found going from the 512MB Samsung Infuse to the 1024MB Epic Touch. The Infuse would run put of memory and reset or threaten to reset (freeze for long moments) regularly. Playing Chuzzle, whenever my Newsreader would fire off to update my feeds the phone would vibrate and if I didn't exit Chuzzle right away the phone would eventually freeze or reset. Having the exact same combination of apps running on the Epic and it hasn't happened yet. I suspect the OS was struggling to fulfill the memory requests of both programs and the other background and OS memory needs and starting spitting up. We can point fingers at one or the other of the programs all we want, but I want to run both of them at the same time and don't want the hardware to constrain me. This isn't the only time thie would happen, but the most recreatable.

I think it would be accurate to say their is a sweet spot for RAM and after a certain amount it's wasted. But, the more RAM installed, the programs can remain resident and the faster they will launch. That sweet spot might ave been 512m in the past, but I think it definitely is 1GB now, and as programs and systems needs grow more complicated in the future, we will want more in our future devices.

Remember the "nobody will ever need more than 640kb" quote attributed to Bill Gates? Well it is about as true in Android as it was for MS based systems. I agree that allowing task killers to automatically kill programs isn't a necessary, but there are still time where killing a running program are necessary, especially on phones with limited RAM installs and that my friends is why memory still matters.

You're probably spot-on here, but you're missing the point of the article. Jerry's not saying the devices shouldn't have more RAM. I don't think anyone's saying that. He's saying that running some kind of a automated task killer that arbitrarily kills off everything in memory every 15 minutes does not make the phone faster or more battery efficient.

It sounds like the problem you're having is exactly what you said: Chuzzle and your news reader probably both take up a huge amount of RAM and the system has difficulty coping. Android can kill off applications in memory that aren't active, but if you're actively trying to run multiple applications at the same time that require more memory than the phone has to give, nothing can help you there. Check and make sure you don't have something like Gun Bros or Wave Launcher running as a service and consider uninstalling them if you do. Try and free of memory that way. Might help...

I don't know ... it sounds to me like you're confusing backgrounded processes with memory caching. At the OS level, these are quite different. Say you load an app. That app will become a process, but in addition, the pages you read from "disk" will be cached. If you close that app and then load it again, the kernel will first look in the cache, so the hit you take on opening the app is not that big.

The difference between a backgrounded app and disk pages for an app in the cache is that an app in the cache is not running. It is not in the background chewing up battery life (an issue I consider just as important as ram). For example, I downloaded an airline app a couple of nights ago, planning for a trip. After doing some playing, I backgrounded it and went to bed. When I got up the next morning, I was surprised to see a big chunk of battery life gone versus normal. Android obviously didn't kill that app. It let it go on accessing the internet periodically, and eating up battery. Now let's say I still want to use the app. What is the alternative to killing it afterwards?

When process killing was introduced in Linux, it was not portrayed as "hey, Linux will take care of all your processes for you." On the contrary, it was more like "well, if there's no other option, we'll keep the system going by killing something." When Android kills a process, it does a hard kill. The app has no opportunity to save work, so if you were in the middle of something then backgrounded it to do something else, you might just lose all your work.

All this "Android managing your applications" stuff sounds like marketing to me. The truth as I understand it is that on a Linux kernel, the kernel will kill apps if it runs out of memory. Android has no say in the matter. It sits on top of Linux and uses Linux memory management. I've read through this article and the one posted by Milo from a Google engineer. Battery life is never addressed. Until it is, I still think there is a place for task killers.

Android doesn't work like a normal Linux system in this regard. It effectively treats background processes as a cache of available RAM. The system is designed so that any processes in the background are safe to kill at any time. When Android needs more memory, it can freely hard kill any of those processes to get it.

In fact there is a kernel module Android adds to Linux that does just this as part of the kernel's core memory management. This runs instead of the Linux kernel's normal out-of-memory handler, which just doesn't operate the way Android wants. The stock Linux version is really a last resort "OMG there is no RAM I've gotta get rid of something, anything, NOW" thing. Android has a much more managed approach, where it keeps processes in various well defined states indicating which processes can be safely killed, and strict ordering in how decisions are made about which to kill.

There are numerous ways that a poorly written application can drain your battery, and this doesn't have to involve it just doing stuff while it is in the background. For example, it can set up an alarm that repeats very often to cause it to wake up the device and briefly run (in the foreground).

Hopefully the battery usage UI will identify such apps for you, so you can get rid of them and give them a low ranking in Market. It isn't possible to force developers to write good apps, but we do want to give users enough information to know when apps are not working well so they can deal with them.

Excellent! This is much more in the ballpark of what I was looking for. I appreciate you taking the time to answer. I would like to know more about how Android process and memory management interacts with Linux process and memory management at an OS level. The docs I've found (including the one you posted) seem aimed more at developers, which is understandable. However this is probably not the right place to ask. Maybe I'll just have to dig into the AOSP code.

The procedure of ranking misbehaving apps in the Market is OK, I suppose, but I wish there were something better. For example, how about a system notification that says "hey, when you weren't using your phone, app X consumed a lot of battery power doing internet. Is that OK with you?" I believe you do have an API for detecting the power situation, and obviously you do keep statistics on what apps use the battery. The biggest problem for me as a user is that I don't want to have to play nanny to every app I install, checking to see if it is doing something bad, or has installed a service that is doing something bad. I would LIKE to trust Android to manage things. It would help if Android gave me more feedback, essentially automating the process you described above of using the battery UI.

Check out System Panel in the Market. For $3, you can get the Pro version that will give you historical readings on CPU activity and battery drain going back up to one week. That way, if you notice your batter took a big hit, you can fire up System Panel and see which apps have been using a lot of CPU time.

What you suggest would be nice. Maybe they'll get it in someday, but that's what I use for now.

The problem here is that somehow Android has to know when an application is doing something that you think is bad vs. when it isn't, or else it will be bugging you all of the time about things you don't care about. And not only would doing this require that it be able to identify a bad app from a good app (something that in most cases is impossible), it also actually has to identify apps that are doing things an individual user wants vs. what they don't.

I guess you could imagine a UI where it tells you about what is going on, and lets you say "oh I am fine with this" so it won't tell you about it any more (unless the app starts behaving differently in some way, in which case it will need to nag you again). For most users, I think this would be a terrible experience -- they just wants something that works and being told about things that they not only don't understand but are now being asked to make some judgement on is a nightmare.

If you are an advanced user who does care about this stuff, feel free to go into the battery usage and running services UI to see what is going on, which will give you all the information the platform has. (Oh and btw the Running Services UI in Gingerbread is greatly improved from earlier releases.)

Great writeup as always, Jerry. Like most of us, I am forced to having to use trial and error for the most part to solve problems on my Droid X. I had almost succumbed to using a memory management app to cure the spontaneous reboots every 3 days, or so, which seemed to correlate to the diminishing available internal memory.

At that point, I replaced the DX for a non-related mechanical problem, and to my surprise, the reboots are gone, even after 2 weeks, and available memory sometimes in the teen MB's. The long and short of it is that I'm back in the fold, and letting Android do its memory management.

RAM for your PC is cheap. RAM designed to fit inside such a small device and generate very little heat is not quite so cheap. Then, of course, there's always a limit to just how much space they have inside the thing. It's not magic :)

I have a CDMA Desire running.. CM7.. don't know if I flash it correctly with the latest stable mod, but something might not be right with the partition...

I have plenty of RAM I see currently 113MB used and 240 Free... but the Internal Storage is what is the problem, I only have 23MB left... I am constantly having to clear Cache and clearing Data on apps, cause I get that annoying... Low Storage Space warning...

What am I doing wrong... I moved all the apps I can move to the SD card, what is left are Widgets and System Apps...

And there are a lot more Apps I want such as Google Earth that simply won't fit...

If CM7 supports A2SD, you can create an ext3/ext4 on your SD. This is like the apps2SD feature of Android since Froyo, but a bit different. The partition will exclusively be used by your system to install apps. It will use it automatically. You don't have to manually move your apps to the secure SD folder and it works for all apps - even those not designed to be installed on the SD. It's like an extension of your phone's internal memory.

I use A2SD on my Nexus One running MIUI. Nexus One has a very limited internal memory - about 150-ish MB usable, which is just not enough. But with A2SD (I partitioned 1GB of ext4), I don't get the low mem notification anymore.

Solid-state refers to the physical makeup of the RAM (e.g. silicon circuits instead of a platter and head) and not to it's persistence. Solid-state devices consist of circuits and have no moving parts. Jerry's use was correct.

@galfert is correct, since their is no such thing as platter-based Random Access Memory. Solid-State "Memory" or "Storage" is a correct term (even if Memory is a bit misleading in that usage), but Solid-State RAM is a misnomer. All RAM is inherently solid-state.

I knew it sounded awkward. So thank you TenshiNo for clearing it up. Technically RAM is solid-state but it is a misnomer I agree. It is like saying "I'd like some French Champagne." Now I know that there are wine makers that label their stuff Champagne rather than sparkling wine but that doesn't make it right. If you know then you know.

Solid-state refers to the physical makeup of the RAM (e.g. silicon circuits instead of a platter and head) and not to it's persistence. Solid-state devices consist of circuits and have no moving parts. Jerry's use was correct.

In my experience, free RAM *DOES* matter... but not in the way the article states. I do agree that a task killers should only be used to shut down misbehaving apps (and with Gingerbread, you can simply use the Running tab instead of an application)

The problem that I've encountered on my Nexus One is that there can be too many things trying to stay resident -- mostly customizations like WaveLauncher, Go Launcher EX, etc. All of these fight to stay in memory.

What happens is that Android tries to squeeze all of these things into RAM ... PLUS the active application. If the application requests more RAM suddenly, Android OS has to stop to shut down other applications. This usually happens fairly quickly, but does introduce some noticeable stutter on occasion. HOWEVER, this may happen regularly depending on what's happening with the app.

For example, I got Dungeon Hunters from Gameloft's Labour Day weekend giveaway. Whenever I summoned a creature (mage skill) it noticeably chops up. It did this every time I summon it (which is frequent, as it's your "tank"). I uninstalled Smart Taskbar which freed up ~20MB RAM. It now only chops up the first time per level I summon it, instead of all the time.

I believe what's happening is that when DH is requesting RAM for the summoned creature, Android garbage collects parts or all of an resident app, then reloading (parts of) other applications when the creature dies (and RAM is freed). It then happens every time.

And yes, I have experienced a couple reboots while playing DH before I removed Smart Taskbar. The RAM situation may have contributed to it.

Thanks for the info on this. I was curious if anyone out there experienced these type of reboots before. My biggest reboot culprit is when I'm using google maps. I use it fairly often and sometimes while navigating I'll get an abrupt reboot. Sometimes i get 2 abrupt reboots and then I say something is wrong. It quite awhile for me to figure this out.

I first downloaded a task killer when I noticed Sprint Nav had been running on my Evo for 3 hours still tracking my GPS even though I had reached my destination. I use it almost never now though and only for apps I know I will not be using soon, are not system related, or I fear my be poorly coded or using resources. The thing that made me and many of my family want to kill tasks is when we would see demo crapware (blockbuster on sprint) constantly showing up even though we had never ever used the app and never wanted to. That was when I began loosing faith in the systems ability to kill apps and wanted a level of control myself. Carriers are loading up too much crap we never use and having it auto run even though we have never used it. IT'S THEIR FAULT FOR THE TASK KILLER OBSESSION

That was very very well explained.. Even this electric lineman/ android noooooob pretty much understood it.. Thank you..

When I first got my TB & realized how bad the battery was, I went to verizon to find out what I could do to make it last longer.. They turned everything off, all animations & what ever else but most importantly they put a big ole task killer on it & said... Make sure you use this after you use anything on your phone.. Apps, games, radio.. Everything.. I noticed that my battery that was lasting only 6 hours was now lasting 4.. So I went back to verizon being the noob I am and said my battery is worse.. Oh now its my charge port.. So Yup they sent me a promised new phone but I got a LIKE NEW one instead.. Well I was not happy.. Long story short. I googled android phones.. Went thru about 10 different sites until I found android central(not a joke).. I started reading & reading.. 1st thing I did.. DELETE THE TASK KILLER.. Phone was lasting 6 ish hours again.. Got an extended battery & followed some other advice I read.. Now my phone lasts 24 hours.. Usually.. I will never root Cuz I will destroy my phone.. So I have to do the basics. Anyway again.. Thanks for all the good advice & explaining things to an android idiot...

I think alot of people's paranoia come from not knowing if apps that are running and using RAM are using battery. For example if it didn't matter if blockbuster city id and v-cast were taking up RAM then how come we notice such an improvement in battery life when we remove or freeze it from our phone? I myself no longer use atk because I understand the value of having apps run off of RAM that are frequently used. When I did have atk all of the processes that would restart such as gmail text messaging or bloatware I would have on my ignore list. But I still am confused as to why I would receive better battery life with bloatware removed if it really doesn't matter if its running off of RAM.

Probably because those apps were "pinging" back to some internet server. Try an app called "System Panel" in the market. I like it because it will actually show you what state loaded app are in, like Background, Visible or Service. If an application is running as a service, that means that it is periodically doing some kind of work. Many of the free games like Gun Bros actually do this, and you will periodically get notifications about "Double XP Weekend!" or some such. Things like this will cause slightly more battery drain, since it's basically pinging the 'net every X number of a minutes to see if it should give you that message.

Also, we have to face the fact that much of the bloatware that the carriers place on these phones is not always the highest of quality code.

I heard that if you run out of ram your system could abrubtly reboot. Can canyone confirm/deny this? My OG Droid does this from time to time. I checked out running processes and ive elminated some of these apps and/or widgets. My phone is dreadfully slow from time to time. I did install a task killing program to keep things from popping up into memory from time to time (Google+, Google Googles). Yes I do use these but I use them when I want to use them. I dont need notifications to tell me certain things (I do disable notifications) but even after a reboot these program come and lurk into memory. So I have to restort to this until I get a replacement phone w/ more than 168Meg of useable memory. Any thoughts on this?

The system is designed to automatically "pull" applications that haven't been used in a while out of memory when the system reaches a certain threshold of available RAM.You shouldn't experience a reboot because the system ran out of memory. The only times you should really experience problems with "running out of" memory is if you have a rogue app that's eating up a ton of memory and not releasing it properly.

Like Jerry said in the article, you use significantly less power "holding" an application in memory than you do loading it from scratch off the SDCard.

I'm sure most people have Android phones that have 384MB of RAM or less, which means these apps are still useful for most. I found some apps I infrequently used would not close once I stopped using them. Photon's task manager helps with these apps. It seems to help.

If you want to cry myth, do it. But I own a Samsung Fascinate and left the stock Task Manager on it. You know why? Because my phone locks up so bad it becomes unusable until I KILL ALL APPS IN TASK MANAGER. Now I am not a genius and know much less than probably you, but whether it is a Ram allocation problem or application conflicts or whatever, THE TASK MANAGER FIXES MY PROBLEMS EVERY TIME. To make a blanket statement saying that all task managers are unusable is stupid. What arrogant journalism.

Sounds like you have one (or a few) apps that are misbehaving. Instead of killing all of them, try killing them one a a time and see if you can isolate whats causing the problem.

If this is the case, then you aren't right to generalize from "useful for fixing my problems" to "useful for most". It may well be right even if this isn't the case. My G1 needed a task killer running Andriod 1.x. Running unofficial builds of 2.x (admittedly heavily tweaked) it ran fine without one.

The myth is not that everyone *needs* a task killer, but that *everyone* needs a task killer. That's not true - or at least, not with modern versions of Android on modern phones. There may be people running poorly written apps, or unusual mixes of apps, that need a task killer. However, a poorly written task killer is more likely to cause problems than other applications, and task killers are much harder to write well than most application.

For instance, my Droid 3 runs *better* without Motorola's task killer than it did with it. The task used more memory than it saved. All it ever did was interrupt my music players and book readers if I used them for long periods of time - which was a common thing for me to do!

Bottom line - don't install a task killer because someone tells you you need one. If your phone starts misbehaving, try one and see if that fixes the problems. You can stop there, or you might try and figure out what is causing the problems, and decide if it's worth putting up with having a task killer and whatever problems that may cause to keep using.

I bet you if you kill just one app at a time, you'll soon find the app that's messing with your phone. It's not "ALL APPS" that need to be killed. You just have to find the wrong one you installed that isn't, for whatever reason, playing nice with your phone. These things sometimes happen, can't really help it. Once you find it, uninstall it and see how things go from there. I think you'll be much happier :-)

As of Android 2.2 (Froyo), task killers can not do anything that the platform itself does when it needs more RAM. That is, kill processes that are already in the background and in a state where they are safe to kill.

You're missing the point a bit, I think. No one is saying that task managers in and of themselves are bad. It's the ones that automatically kill of tasks that cause the real problems. The task manager that Samsung put on the phone by default is (hopefully) smart enough not to try and kill off important system processes.

I would say that if you repeatedly have this problem, you might try and track it down to a specific application that is not probably "sleeping" when it's placed in a background state. I have come across a few of these in the Market.

One task manager I really like is called System Panel, since it will actually show you all the active tasks in memory and even show you the amount of CPU being used per task, in addition or a master CPU usage graph. The paid version will even let you track CPU/Memory usage and battery consumption over time, which can really help track down apps that are not sleeping properly.

The concern here is to not over use task managers like a shotgun solution in a "kill everything" method. You *shouldn't* have to. I'd be willing to bet if you tracked down the real cause of your problems, not only would your battery life improve, but you'd spend less time having to get into task manager and hit the "Kill All" button :)

MOST may have loads of memory
but the old My touch 3g has 96MG and a task killer made that device run just fine, great even !
The Idea that killing the MAIL application will make you stop receiving Email is WRONG, and saying that , shows us you don't us or understand Linux at all, services will just restart, obviously you never tried it !

your point, tho , that Task killers are less needed is good for devices that have more memory, however some applications ARE poorly written, and killing them can avoid a reboot!

So to all of you " BLUE MEANIES " that just have to 'declare all task killers for any reason are evil', stop it, your dead wrong !
Task Killers are just another tool, in the tool chest.
not the end all of all tools, but useful sometimes.

MOST may have loads of memory
but the old My touch 3g has 96MG and a task killer made that device run just fine, great even !
The Idea that killing the MAIL application will make you stop receiving Email is WRONG, and saying that , shows us you don't us or understand Linux at all, services will just restart, obviously you never tried it !

your point, tho , that Task killers are less needed is good for devices that have more memory, however some applications ARE poorly written, and killing them can avoid a reboot!

So to all of you " BLUE MEANIES " that just have to 'declare all task killers for any reason are evil', stop it, your dead wrong !
Task Killers are just another tool, in the tool chest.
not the end all of all tools, but useful sometimes.

Most people? I'd be surprised if that was true. Even phones that are 18+ months old were released with 512mb RAM. I'd say 512mb is the majority, with most phones in the last year being 768mb to 1gb.

I realize a task killer may be beneficial to some in this case if they do have a really old phone with ~384mb RAM, but the problem is blatant misuse/lack of education with the task killer. It may speed up their phone in some spaces, but overall its hurting their experience constantly purging all the processes in RAM.

The problem is that so many Android fans in the days of old, who cut their teeth on android 1.2 have grown up and take jobs at mall kiosks selling Android phones.

They wear Id cards, wear ties, say Yes Sir, and continue to spout gratuitous nonsense about task killers. They will often install one for anyone that buys from them without even asking. They pontificate and sound all knowledgeable and serious.

And they are universally wrong.

Its our Duty to our fellow Android enthusiast to brow beat these clowns into submission. Grab them by the wattles and slap them till they spit if you have to, but don't let them install task killers on customer's phones.

you know i'm a fellow android enthusiast as well and i'm an agent for us cellular but i dont go around putting task killers or recommend them either..i always have to uninstall them for customers because they come in crying about there phone acting weird and i look and there running task killers...as an agent from us cellular all my employees know not to interfere with any task because of the way android was design to manage itself...i know plenty enough around android so i would appreciate that next time dont just say we all do that when we really dont. thanks a-hole.

You sound like the type of customer that I hate helping. I work for att and I hate when people come in the store with the know it all attitude trying to belittle the reps. To my knowledge none of my reps use a task killer and have warned custs about using them.

So to say we are all wrong is ignorant. And your rally cry against mobility reps really makes you sound like a dick head. Grow up little man

maybe you don't but the majority of reps do not and I know from experience....and I hate reps that think they know everything when they don't....their like vultures in cell phone stores just leave me alone you do not know as much as most of us that freguent sites like this...I'm a informed customer and don't need the reps telling me things I've known for years

I as an "Android enthusiast" do not plan to 'brow beat' anyone. If I go in to a store and notice they are recommending a task killer I would talk to them and ask them why. After hearing their explanation I would tell them what I know about Android RAM and tasks. Informing them in a constructive way.

Approaching it this way will go a lot further then acting like an ass.

OK, guys. He might have been a little mellow-dramatic in his wording, but he has at least a little bit of a point here. When I bought my Evo4G last year, the Sprint rep did exactly what @icebike is talking about. He activated the phone and then immediately installed ATK and set it to "Aggressively" auto-kill applications. Luckily, I knew better and had it uninstalled before I got to the car. I even had another rep try to re-install it when I brought the phone in with concerns about WiMax connectivity.

We realize that not *every* rep out there does this, but many do. I have had about 8 friends get Android phones in the past few months and almost all of them were running ATK or something similar. When I asked them about it, they all said "I don't know. The cell phone guy put that on there."

It *is* happening. And while I don't agree that we need to beat anyone up over it (I'm hoping he was just exaggerating to make a point), we should point out to these people why it's a bad idea. There are still self-proclaimed Android gurus out there extolling the virtues of automated task killers.

2. Android is not doing a good enough job managing memory on higher RAM devices.

#1 is pretty much self-explanatory, but #2 is where an explanation is probably needed. Oh, and for the purposes of the discussion below, "RAM" and "memory" mean the same thing.

The fact is, on ANY operating system, the thing that is going to give you your biggest "bang for your buck" performance increase is a RAM upgrade (up to the OS's point of drastically diminishing returns). Now, I don't mean to a faster rated RAM (you'd be lucky to see a benchmarked increase of 5%, which is practically unnoticeable in the real world), but rather MORE RAM (i.e. going from 2GB to 4GB or even 4GB to 8GB).

This is because with more memory, you don't have to swap the apps out of RAM to disk, or "permanent storage" if you prefer (hard drives are on the order of 3 orders of magnitude slower than RAM and flash storage is on the order of 1-2 orders of magnitude slower, with an order of magnitude being 10 to the power of (order of magnitude)).

Android is (NOW) great at managing memory for RAM constrained devices. However, the number one problem that high-end app programmers have to deal with right now is heap memory size allocation.

This is a problem because...

(a) large, complex, and powerful programs, like games, for example, require a lot of RAM BECAUSE of the size of the data sets they are dealing with, the actual program code is a small fraction of the size of the data sets and,

(b) no matter how much RAM a device may have (there was a dual boot tablet demo'd/announced for Windows/Android with 2GB RAM back in March, http://www.androidcentral.com/dual-booting-android-windows-7-viewpad-10-... ) Android will not increase the amount of heap RAM allocated to programs, (there is not even a mechanism for the developer to REQUEST a larger allocation, unless the device is rooted, which MOST aren't).

To add insult to injury, a developer can't just start multiple instances of apps and transfer data between them IN RAM (swapping to flash storage defeats the purpose because it is so slow and it is why you want to keep everything in RAM in the first place) because one of the greatest protections of the Java based Android is the sandbox that the OS creates for each running app so they won't crash each other and/or so a malicious app cannot do any damage to other running apps or the OS. OK, this last is both good and bad, but in the context I'm writing it, it is a negative to creating more powerful apps.

So, let's say you want to port your favorite game from the PC to Android. You have a game that only runs well in 8GB RAM with a high-end graphics card to take care of the current state-of-the-art graphics and physics engines. However, when you move to an Android device with about 512MB RAM per core (the current state of the art for single and dual core processors) AND you have to deal with the program memory allocation issue, it becomes practically impossible.

OK, there ARE a couple pretty good games on Android now... good compared to portable game players (and a testament to the genius of their programmers). However, will not even be in the same ball park as PC games in realistic graphics, physics, game play, etc. until AT LEAST the memory issue is resolved.

Now you might say, let's just develop in Adobe Flash's upcoming 3D version (Flash 12?). The problem is that because Flash is a (manageable) memory hog on the PC, it becomes a nightmare for complex stuff on Android.

The bottom line is that RAM is cheaper and provides a bigger bang for the buck than CPU power, but CPU is sexier.

For example, with Windows XP, the minimum requirements were 256MB RAM, with 512MB-1GB recommended. However, to get the best performance, you really needed a minimum of 2GB to get to the 90+% of the RAM based performance improvement. With Vista the min was 1GB, with 2GB recommended, with 4GB to get to the 90+% mark. With Win7, the specs are supposed to be the same, but really you want 6-8GB to get to the 90+% point. (90+% being my arbitrary point of drastically diminishing returns (for every day users, not hardcore gamers).

While Linux will run at a given performance level with about 1/2 the RAM of Windows, it still benefits approximately the same with increases in RAM.

So, even if your device had double or even quadruple the memory it currently has, you wouldn't be able to run more POWERFUL programs. The device would appear snappier because more DIFFERENT programs could be run at the same time, avoiding loading/unloading programs all the time, but not more powerful programs.

PS. Ok, this is a pet peeve of mine, but can we PLEASE stop calling hard disks and flash storage "memory"?!? Hard disks and flash storage should be referred to as either "disk" or "permanent storage" to avoid confusion.

(2) The memory allocation limit only applies to the Dalvik heap; most games are written in native code (because they build on C++ cross-platform game engines), so have never had such a constraint. (This does mean such apps need to take a lot more care in their memory management.... but that's native code for you.)

(3) An application can certainly run itself in multiple processes if it wants to, and each of these has its own Dalvik VM with its own heap and its own limit. I don't know why you are going in the direction of actually having multiple applications to do this, that doesn't really make sense.

Regarding #1 above, not all versions/manufacturer/carrier releases of Android support all of these features. If you want to support a wide variety of devices, your choices are more limited. In addition, even if you use native code, you still need to deal with Android garbage collection on the non-native code apps. The garbage collection is very aggressive and repetitive (meaning it will collect the stop for a bit, then collect again) and each time it collects memory, there will be a lag in the system as all other activities appear to wait while garbage collection is happening.

BTW, the getLargeMemoryClass () the link pointed me to just reinforces my point. I really don't get where you are coming from here as the discussion is about RAM constrained devices (pretty much all of the Android devices right now).

Regarding #2 above, even with native code you are still limited to how much memory you can use because of garbage collection issues (as mentioned above). Because of this, MORE RAM IS BETTER!

Regarding #3 above, yes, you CAN run an app in multiple processes, as I stated in my original post, but they cannot communicate (send data back and forth) with each other IN RAM. This is problematic if you have large data sets and are having to dump the data to flash storage (regardless of its speed (and file system), based on the current flash used in these devices) and pull it back again to process in another thread. If you can't figure out why running multiple processes is better than running a single process, especially on multi-core CPU's, then I can't help you there.

Regarding #4 above, I really don't see what is so complicated about what I've said. A single core Android device typically has 512MB of RAM. All of the dual core devices have 1GB of RAM. 1 core times 512MB = 512MB RAM. 2 cores times 512MB = 1GB RAM. As you said, "WTF?"

The bottom line is more RAM/memory the better for creating truly powerful apps, especially if you want to have apps that can truly take advantage of the current and forthcoming powerful CPU's that these Android devices will have in the next 6-12 months (and beyond). Frankly, I'd like to see double the RAM that is being put into the devices (i.e. 1GB per core, I'll let you do the math.)

While you are partially correct in some of your comments about adding more RAM providing performance boost, I'm not sure that you understand the concepts of coding for a "mobile" device. Firstly, adding more RAM is not quite as trivial as you make it sound, since these devices are substantially smaller than your average desktop PC and have limits to how many chips they can cram in there, and even tighter limits to how much heat they can generate. Event RAM will generate heat, and a small form-factor device like a cell phone doesn't have an active cooling system, so heat must be carefully balanced to performance.

The only changes you should see to the API, especially code written in C++ using the NDK, is between different versions of Android. I'm not of aware of any hardware manufacturer or carrier (past or present) "removing" features from the Android API. They wouldn't it would mean their device would run the risk of being incompatible with many applications out there and open the company up for a ton of flak from the community.

I'm also completely at a loss as to why you believe the garbage collector in some way limits how much RAM an application written using the native runtime has access to. The garbage collector's job is simply to free up memory that is no longer in active use. And that's mostly for the higher-level, managed runtimes. If the garbage collector is "killing" off blocks of memory while the app is still running (and still using those memory blocks), then you have coded something incorrectly. Perhaps you've let a pointer or variable reference fall out of scope?

You mentioned in your original post that it would be impossible to port "larger" games over to Android and that is also simply not true. Check out nVidia's latest Kal El demo on YouTube and you'll see them running Lost Planet 2 (Xbox360) on their prototype Tegra 3 device. The video even shows them playing the game at full frame rate (which makes me drool a little every time I watch it).

I understand where you're coming from, wanting to see more memory be included on these devices. I'm sure we all would. That's why many of us on here spend countless hours drooling over specs and fantasizing about upcoming devices. That said, however, it's not just a matter of "put more RAM in there". Hardware manufacturers are limited in terms of what I said before: size and heat. Cost plays a tiny factor as well, since RAM chips this small and heat efficient are more expensive than the RAM sticks you buy at Fry's or Circuit City or where ever and drop in your PC at home.

Really, you want to pull system design specifics into this generalize discussion of whether more RAM is good or not? :)

OK, the heat generated by RAM is inconsequential compared to that generated by the CPU and battery (as it is charged and discharged). The fact is that RAM is MUCH cheaper, both thermal and cost, than CPU. The fact is that you get a much bigger boost IN ANY SYSTEM by putting in more RAM (until you hit the OS/apps saturation point) than by adding CPU... PER DOLLAR! Which was my point... per dollar.

Also, with the density of high-end memory and its packaging, it is much easier to add another GB of RAM than to add a another core to a CPU and the needed battery and cooling. Frankly, the biggest limitation to phone packaging is battery, NOT RAM.

As for the API access, well, what you have access to depends on what the manufacturer has decided they will let you have access to. I mean just take a look at creating a basic camera app that will allow you to set the ISO. While Android has the API to do it, the manufacturer's implementation of the camera and what they will let you touch through the kernel is another thing entirely. Many devices will not let you set the ISO in an app.

When you go into the native code API and allocate memory, you are taking that much memory away from the Android runtime. Let's say you are writing for a device with 512MB RAM (usable will be something less than that). If you allocate 100MB RAM, then the native code will have to run in 412MB and that will force the garbage collector to be more active. Unless you know about some way to control the garbage collector or, in code, some way to kill various "unneeded" apps without the system being ROOTED. Then again, not killing apps programatically was actually the point of the article... leave it UP TO the garbage collector.

The vast majority of Android devices have tons of running apps, from live wallpapers, to clocks, to social media, etc. Because of this, when the memory available to Android is reduced, for whatever reason, the garbage collector has to be more aggressive in killing off processes and retrieving their memory. That killing off causes unexpected, untimely, and sometimes bothersome lags in the system.

Take away a sizable chunk of RAM from Android and you've made it that much harder for the garbage collector to decide which to kill. Add "bloat" services and apps that load as services and it really becomes a challenge.

If you have a way around this, I'd LOVE to hear about it. Stopping the garbage collector from kicking in has been a huge headache.

Also, when I define "larger" games, I'm referring to the data sets they have to manipulate. While game demos like you describe can seem impressive, it IS a DEMO.

There is a joke about Bill Gates dying and going to heaven and getting to choose between Heaven and Hell. After visiting the "partying, good time" Hell, he chooses Hell where he is immediately tortured. When asking what was up because he was just there and it was SO much fun, they told him it was just the DEMO, especially ironic considering some of the demos that Bill Gates has done himself (the full joke is better, but too long).

Anyway, I've seen ports hands on and while impressive FOR A PHONE/TABLET, there were obvious compromises due to the platform. CPU horsepower and RAM limitations were the most obvious. They were about equivalent to where games were 5+ years ago. Impressive, to say the least, but NOT equivalent to modern games.

As for "full frame rate" that has many meanings, depending on whether you are a hard core gamer (min 60fps acceptable, many want 100+) and whether or not you can accept the limitations of the platform. My bet is that to shoehorn the game onto Android, they had to make some compromises. One would be detail. Whenever you shrink something it looks better as the flaws are harder to see. Another would be game play. The number of intelligent objects in the scene. Etc.

I'll also bet that the game demo was done on a clean install and with a developer version of Android. Much different than with the various manufacturer/carrier releases (if not for any other reason than the launchers).

Look, no doubt there are issues with more RAM. Cost probably being the biggest (take the wholesale cost and multiply it by 3 to 5 times to get assembled, retail cost). However, the article's premise was "RAM: What it is, how it's used, and why you shouldn't care".

My point is and always has been, in the 30+ years I've been using PCs and other devices, that RAM is almost always the biggest limiting factor in the performance of any device (up to the "saturation point"). My systems experience ranges from PDAs to AS/400s. I've yet to find an exception or a situation where I didn't get much more of a bang for the buck with RAM.

If you don't believe me, write a quick native app that just grabs, say, 100MB RAM and then see what happens to the phone. I'll bet it becomes lag city.

However, if you have a solution, I'm all ears! Really! :-D Sometimes those ears make me look like a "donkey", but sometimes that is what is needed to learn something!

GlueFactoryBJJ, You sir are an idiot.
And obviously understand nothing of ARMs, RISC based architectures.

It really would require less work to tack on another core than increasing the addressable RAM ceiling. As the memory controller is part of the CPU, which would require a major redesign in condideration to the PoP RAM that is then essentially built into a second floor of the same package above the Application Processor (which is the smartphone equivelent of all the bridges, buses, controllers, and cpus that would make up the bulk of the motherboard on a conventional general purpourse computer). It's known as a System on a Chip for that reason.

The reason you can't just go and cram in loads of RAM is because of the limits of the cpu itself.
This is why even with moderm quad core phones. You don't see more than 1-2GB. RISC works very differently to the big iron CISC devices you've used all your life.

"BTW, the getLargeMemoryClass () the link pointed me to just reinforces my point. I really don't get where you are coming from here as the discussion is about RAM constrained devices (pretty much all of the Android devices right now)."

In your original post, you claim that Android will not increase the amount of heap available to apps on devices with more RAM. This is plainly not true -- as of Android 3.0 there is this API I am pointing to that allows an app to do just that. Yes this is a very new API that was introduced in 3.0, but it is only a matter of time until newer versions of this platform with this API appear on most devices, just as has been the case with every version of the platform. So, problem solved.

"Regarding #2 above, even with native code you are still limited to how much memory you can use because of garbage collection issues (as mentioned above). Because of this, MORE RAM IS BETTER!"

This is simply not true. The garbage collector runs on the Dalvik heap. The Dalvik heap is not the native heap. Allocations you do in the native heap have NO IMPACT at all on the Dalvik heap. They do not cause the garbage collector to run more. They do not cause it to run more slowly. They do not impact it in any way.

"Regarding #3 above, yes, you CAN run an app in multiple processes, as I stated in my original post, but they cannot communicate (send data back and forth) with each other IN RAM. This is problematic if you have large data sets and are having to dump the data to flash storage (regardless of its speed (and file system), based on the current flash used in these devices) and pull it back again to process in another thread. If you can't figure out why running multiple processes is better than running a single process, especially on multi-core CPU's, then I can't help you there."

Um, you have *so* many ways to get data between processes that don't require throwing stuff on storage and pulling it back out. Binder IPC, pipes, shared memory, etc.

Also there is *no* special benefit to using multiple processes on a multi-core CPU. None. Multiple threads in one process can make use of multiple cores just fine. The *only* reason to use multiple processes is to provide isolation between code so that crashes in one won't impact the other (in which case all of this nice memory isolation is critical), and secondarily you can use them in some ways to give yourself more than one Dalvik heap if you have some isolated larger parts of your app that need lots of RAM. (For example Google Maps does this -- its Navigation component runs in a separate process.)

"Regarding #4 above, I really don't see what is so complicated about what I've said. A single core Android device typically has 512MB of RAM. All of the dual core devices have 1GB of RAM. 1 core times 512MB = 512MB RAM. 2 cores times 512MB = 1GB RAM. As you said, "WTF?""

Yes, WTF. Just because it is common for dual core CPUs to have 1GB RAM has nothing to do with there being 512MB per core or whatever. It doesn't work like that at all. These are all SMP systems, all of the cores are running in the same shared RAM address space.

OK, over 97% of the devices out there running Android 2.x and you want to point out a call that only runs on less than 1%? We are talking about here and now, not the future. Still, the description for that call is below:

"Return the approximate per-application memory class of the current device when an application is running with a large heap. This is the space available for memory-intensive applications; most applications should not need this amount of memory, and should instead stay with the getMemoryClass() limit. The returned value is in megabytes. This may be the same size as getMemoryClass() on memory constrained devices, or it may be significantly larger on devices with a large amount of available RAM.

The is the size of the application's Dalvik heap if it has specified android:largeHeap="true" in its manifest."

First, the app must request a largeHeap. Second, it is up to the specific implementation of HC as to whether or not largeHeap is any larger. The examples in the two links above indicate default largeHeap sizes of 16MB or 24MB, respectively. I've yet to see any indication of where you can actually set the heap size to something you might want. Because of this, even on HC devices, there is no indication that you can have notably larger heaps than in GB or earlier releases. And, no, I don't have a ton of devices to test this on. So if you can provide some actual code that does it (or at least a link to code I can look at), I'd like to look at it, but otherwise I'm a bit skeptical.

As I noted above, the premise of the article is, "RAM: What it is, how it's used, and why you shouldn't care". My point has always been in this thread of discussions that RAM is important. Most likely more important than CPU speed or numbers of cores for real world Android OS and application performance... at least in a bang-for-the-buck perspective.

As for native code RAM used not impacting the garbage collector and the Dalvik heap, I've addressed that in a post above. I'm open to new information, but your claim that it doesn't have any effect just doesn't make sense. Any RAM used by native code is memory that isn't available to the Android system and will cause the garbage collector to get more aggressive because it will be like it is running on a reduced RAM device.

Your example of Maps/Navigator is exactly what I'm saying! IF you have large amounts of data. YES! That is the whole point. No, you aren't going to need a ton of RAM for a "Hello, world!" type app. My premise was more RAM is going to be needed for more powerful apps. Apps that can manipulate large amounts of data. Multi-stream video chat, graphics, presentations, etc. Even holding uncompressed jpg files in memory typically takes 3-5 times the compressed file size in RAM. Want to morph a couple together? More memory. Yes, there are ways to work around some of the issues, but not without doing a lot of transferring between RAM and flash storage, which will slow things down by a factor of 100+.

Memory per core is important from the standpoint of being able to keep the cores busy when multiple apps are running. If you do not have sufficient memory, then the cores wait for the apps to start or reload. Yes, I understand that this is Symetrical Multi Processing (SMP). SMP is a VERY old concept (in computer years). I understand the cores share memory rather than have dedicated RAM. Basic stuff. How those cores are kept busy is directly influenced to how much RAM you have.

Anyway, back to the point, RAM is important. You should care. More RAM will give more of a performance boost, per $, than CPU.

Thanks! As a newbie you have answered a few questions for me. I have the Galaxy Skyrocket and I would always go to my home screen and shut down any app I was done with. Now I know better.
Thanks again,
Joe