Short explanation of Android Memory usage for new people

Matt262

Member
Nov 8, 2010
68
9
This is by far NOT to be considered ALL of how Android manages memory, just a baseline explanation. You can read further either through xda-developers, or a Google search for Let me google that for you.

If you're coming from a Windows machine, you already know the rule of thumb -- the more processes in the background, the slower the machine -- this is where Linux/Unix differs, and since Android is built on the Linux kernel, it's only appropriate that it manages memory the same way.

When you start Linux, a ton of daemons (of course "ton" could be more or less depending on how many packages you have installed) start and stay in the background. When not in use, these daemons are "sleeping." A sleeping daemon does not actively use memory, but rather occupies a small amount just so it can be woken more quickly. In Windows, all processes in the background are considered active and on the loose.

In Android, it has a built-in mechanism for managing these sleeping processes so that whenever the internal memory reaches a certain low point, the least used process is GRACEFULLY shut down (in it's proper sequence, NOT kicked loose like in task killers). This is why task killers (though in some uses, are useful, if you know what you're doing or if you have something lock up) are not great for Android. These hard-coded killoff points are already in there, but their set from the manufacturer pretty low, so doing a multitude of things and multitasking even though it won't freeze the device, will make it slow because there's clutter in there not being used.

Autokiller (root required and free from the market) allows you to adjust these killoff points using presets. You don't need to have an in-depth working knowledge of what you should set for each parameter, just choose a preset. Android will still boot with it's factory defaults, but Autokiller will start automatically and re-adjust them to the preset you chose.
 
If people are wondering why their machine is running slowly. This describes one cause. Just like PCs the more free RAM, the happier your tablet is. The killoff points and how many apps you have loaded can impact performance and stability.
 
I should also add if you try Autokiller, don't ante up and pick the highest preset, could cause BIG problems...start low on "Moderate" and see how it acts...if you're an overclocking, non-multitasking guru then maybe you want "Optimum"...for reference, I have a Haipad M701-R using Launcher Pro, uninstalled the factory task manager with Titanium backup, and have Autokiller set to "Optimum" and my tablet runs smooth as glass. Haven't tried any of the higher settings though...and the more widgets (I'm not using any), the more memory you want as a cushion...if you have widgets on all homescreens, then maybe you should go with "Moderate."
 
Not enough people listen to this.

The one thing that bugs me with AutoKiller is that the dev is implementing some memory display features that eat up RAM. If you are on a ROM that supports bootup scripts, it's better to just echo the line directly into /sys somewhere... Marginally anyway. Once your devices has around 180MB RAM total it's not as big of a deal.

One place where you want to ignore this advice is with the Archos 7 Home Tablet and anything based on Rockchip RK2808 not running the lowmemkiller driver some modders compiled. The built in memory management driver was never built for some reason for that platform. Failure to manually kill apps results in the system slowing down to a complete halt forcing a hard reboot.
 
One place where you want to ignore this advice is with the Archos 7 Home Tablet and anything based on Rockchip RK2808 not running the lowmemkiller driver some modders compiled. The built in memory management driver was never built for some reason for that platform. Failure to manually kill apps results in the system slowing down to a complete halt forcing a hard reboot.

Sounds like something that should be fairly simple for a dev to implement...I wonder why it hasn't come to fruition? If I knew anything about writing code or programming period I'd rip lowmemkiller out of another ROM and start tweaking to make it right (per chipset) for these devices
 
There is an app in the Android Market called "Auto Memory Manager". I use it on my Motorola Backflip, which has Android 2.1 with 256MB. Auto Memory Manager will help. You can set thresholds in it, if the phone or tablet goes past the threshold, it will start by shutting down non essential apps. If configured right, the app work wonders.

There is another way to get around the low memory problem also. If you have rooted your Android phone or tablet, you can Google about creating a swap partition on your SD card. Swap partitions in Linux work like virtual memory in Windows. It is the same concept. The OS needs extra memory, it allocated an area of the hard disk (PC, but in the case SD Card) for RAM.

More memory in most cases equals more speed and response.
 
Last edited:
+1 on the swap partitions...but people should be informed that using a partition editor can most DEFINITELY brick your device with the greatest of ease if not done 100% properly (I know you were referring to SD but in case someone stumbles on a partition editor thinking that's the right one). There is a custom recovery out on the interwebs called firerat's custom MTD mod which lets you re-partition your phone. But, this doesn't give you more RAM, just virtual memory as you mentioned...won't be as "fast" *technically* because RAM is considered faster than filesystem memory, but these devices use flash memory so I can't see where there would be any speed degradation.

I haven't looked into the SD swap thing though...very interesting...I'll have to take a look around at that. What happens though, if your SD kicks bricks or you accidentally format it, or you just decide you want to go bigger? I know about Darktremor which enables an EXT partition on the SD card and lets you install apps2sd via script...makes since that this method would work, my only hangup is what-if (I realize it's a BIG what-if) an SD card failure occurs and the boot partition can't find the swap partition, or something gets corrupted?
 
I have read about people adding the Linux swap partition to their SD cards and doing a few commands (On command line) on their rooted phones and running Android just fine. If you have a phone or tablet with only 256mb, this could be something to try. I have also saw a swap app in the Android Market that supposedly works without going to the command line, but again, you have to have a rooted phone.

I think someone ought to suggest to Google that a swap partition option on the SD should be an option in Android. Maybe this option would only be offered when you insert are band new SD card. Or maybe Google could take GParted (Open source Linux partition app) and make a light version to only create swap partition and move data if the SD card has data.

And to answer your question of SD failure. I don't think it would matter, Android would use the memory on the device. Of course your phone might be lagging bad and you might need to delete some of your widgets that you used after you you created your swap.
 
Last edited:
Anroid apps are really a revolutionary thing in the IT field and I , being a non it person would like thank you for your description. it has helped me a lot in gaining proper understanding about anroid....
 
-1 on swap usage, in terms of the full picture, id much prefer to keep things in RAM as opposed to sd.

A) it will keep the sd card active and chewing up more power

B) it will increase the writes on the sd card, as they have a lot more limited write cycles than magnetic storage = less time before failure as although RAM is also non magnetic, can handle a lot more writes.

C) sd card is going to be incredibly slow compared to RAM.

I would say due to the fact we have the awesomeness of the linux page managment and things like 'decent thread managment', we should more actively focus on optimisation of the dalvik mem management, and the vmem kernel side management, secondary to this a slight bummer to using java for apps is the memory footprint is what I like to call 'bloated like crap' but to make android useful we needed it... (think of how much less android would have been used if it weren't for the market), id like to see the devices more heavy optimised, ram increased by manafacturers, and techs that can help with bloat used more fully (jazelle is a prime candidate).
To be honest any of those 3 things should make the tablet world smooth and quick for the most part.


Sent from my S7
 
Oh, forgot to answer why sd would be slow

Sd is not rated for speed, infact not even SSD's are made for speed, they are still limited by the interconnects they lie on I.e. sata or watever, ram however does not have this limitation, it doesn't have a tiny interconnect, even ddr 1 can handle many gigabytes a second throughput, crap even pc133 could...
Transfer a file from ram to a hdd with a known throughput, you won't even see a bottleneck, do the same from sd, and depending on your brand of sd and class of sd, you will get a decent bottleneck.
And that's read... the faster of the 2, writes will be either a little worse or way worse.

Sent from my S7
 
Thirdly, swap is different in linux to windows,
Also its called paging, you have pages of memory, pages of data to write to disk, etc.

Windows pages to swap from the moment its turned on, thus why even with 64Gb of RAM it doesn't use it all, it doesn't cache much of the disk, it just kinda waits for apps to fill it up.

Linux and thus android do not page to the swap unless they have to.
When linux has free mem, it prefetches highly used pages of data, windows does this aswell but a lot less efficiently, then it drops them when apps require ram, (malloc ftw), there is marginal to no swap usage until the system runs dry of RAM.
This is prefered and as most sys admins will tell you is very very sexy in terms of performance.

Id more fully explain things but my hand is tired from not using a keyboard

Also free memory is bad its inefficient.

Sent from my S7
 
Android applications are, at least on the T-Mobile G1, limited to 16 MB of heap. It's both a lot of memory for a phone and yet very little for what some developers want to achieve. Even if you do not plan on using all of this memory, you should use as little as possible to let other applications run without getting them killed. The more applications Android can keep in memory, the faster it will be for the user to switch between his apps. As part of my job, I ran into memory leaks issues in Android applications and they are most of the time due to the same mistake: keeping a long-lived reference to a Context.
 
Oh, forgot to answer why sd would be slow

Sd is not rated for speed, infact not even SSD's are made for speed, they are still limited by the interconnects they lie on I.e. sata or watever, ram however does not have this limitation, it doesn't have a tiny interconnect, even ddr 1 can handle many gigabytes a second throughput, crap even pc133 could...
Transfer a file from ram to a hdd with a known throughput, you won't even see a bottleneck, do the same from sd, and depending on your brand of sd and class of sd, you will get a decent bottleneck.
And that's read... the faster of the 2, writes will be either a little worse or way worse.

Sent from my S7


SD Class = speed rating -- Class 6, should be no read/write degradation to the naked eye (100th's of a second can't be seen) -- some ROM developers implemented moving dalvik cache to SD, but specified you MUST have a class 6 at a minimum or else it would slow everything down -- this tells me Class 6 would be sufficient for swap

RAM, SD and SSD are all considered flash memory...which doesn't rely on magnets...true, they are different forms of flash memory, in that SD and SSD can keep things in memory after power is removed, but because there are no magnets or spinning parts its faster than a hard drive, and more reliable.

To say that RAM doesn't have a throughput limitation implies that advancements from PC133 to DDR3 were pointless and a waste of resources and all in all, a gimmick...I know personally going from DDR2-533 to DDR2-800 I noticed a difference in speed (going from 2GB to 2GB, just changing the speed of the RAM).

To close, I still disagree in use of a swap partition for the same reason you do -- RAM = faster and more preferred always...but...if your hell bent, bound and determined to run a bunch of stuff (for whatever the reason) on your budget friendly tablet, and RAM is not something you have plenty of, then a swap would be the only alternative...I don't see why, however, anyone would want to have 30 widgets and 100 apps on a device unless you spend ALL your time on Android, in which case, maybe the Motorola Atrix and the lapdock would be the best device...

(to be clear, not trying to flame or bash anyone or anything, just ironing out the facts and my $0.02)
 
RAM is volatile memory, it's used to hold the running program and it's associated data. Take your battery out and the data in RAM disappears.

SD and SSD are electronically the same - just different packaging, they retain data when there is no power.

SD has one bad feature, each bit of memory has a finite maximum number of uses, and the max uses is quite low this makes it ideal for mp3s etc but not good for using in areas that get written many times. This makes it BAD for swap. It's also bad for using for ext3 file systems

Pete, on the move...
 
Back
Top