RAM and Android; Android and RAM. Sooner or later this will come up. So, let's get the discussion under way.
In a very rudimentary way, Android works like this:
Memphis turns his device on from a powered down state, Android loads everything up, and is ready to go. He then opens App #1 for the day. After using it for a few moments, he opens App #2, uses it, and then goes to the homescreen and goes about his day.
A little later, he opens up App #1 again, and it loads a bit faster.
'Switching Apps
Instead of using swap space when the user switches between apps, Android keeps processes that are not hosting a foreground ("user visible") app component in a least-recently used (LRU) cache. For example, when the user first launches an app, a process is created for it, but when the user leaves the app, that process does notquit. The system keeps the process cached, so if the user later returns to the app, the process is reused for faster app switching.'
http://developer.android.com/training/articles/memory.html
Memory management
Android manages the apps stored in memory automatically: when memory is low, the system will begin killing apps and processes that have been inactive for a while, in reverse order since they were last used (oldest first). This process is designed to be invisible to the user, such that users do not need to manage memory or the killing of apps themselves.[SUP][67][/SUP][SUP][68][/SUP]However, confusion over Android memory management has resulted in third-party task killers becoming popular on Google Play store; these third-party task killers are generally regarded as doing more harm than good.[SUP][69][/SUP]
http://en.m.wikipedia.org/wiki/Android_(operating_system)
Here is the why: The device Memphis was using had App #1 loaded in RAM. Android did not have to spend the extra time (which can be equated to battery power) loading the app from the internal storage and launching.
Now, not everyone uses just one app, we open several. The OS needs to have certain things loaded to help apps and related files and operations executable (think images, and radios). This done multiple times, eventually will bring RAM to nearly full.
'What happens now?'
RAM is nearly full and Memphis really needs to open up App #3. Android will look at the recent apps and sees that App #2 that Memphis opened at the beginning of the day, and hasn't been used since, can be killed to make room for App #3 to launch. App #3 then launches without a problem.
'Ok, so what is the big deal?'
The big deal is here is where users start to diverge into two main groups: Those who use task killers and those who do not.
Empty RAM is wasted RAM
The classic rule of thumb for Android. To add to it, misspent RAM is almost as bad. Take for example, when I got my S3 from Sprint. One of the widgets was from the Associated Press. Always kept up on RAM usage, even though I never opened it. In fact, I didn't know I had it until I had the device for a month. All that time, AP was sucking up RAM (albeit a fairly small amount) that could have been used elsewhere. May not seem like much of a problem, but take a device that is very inexpensive, and that extra RAM sucked up is a bad thing. Also, add all the other garbage that is bloat that not many people use, and the misspent RAM adds up, and quickly, even on a high end device.
Android has greatly changed since the days of old. Most people would agree that Gingerbread on most devices was, at best, horrible at RAM management. Back then, automated task killers were almost a necessity. But for the most part, Android can do it quite well on it's own.
'So, what about Task killers?'
Task killers can be as hard on the battery as they would do good. Many kill almost any running task, which Android then restarts because it needs it, spends battery firing up the CPU, bringing it out of memory and loading it. The Task killer then sees it again, and kills it. This brings about an endless cycle, thus draining the battery more than it should be drained.
Image taken from: http://developer.android.com/reference/android/app/Activity.html
To determine which processes should be killed when low on memory, Android places each process into an "importance hierarchy" based on the components running in them and the state of those components. These process types are (in order of importance):
http://developer.android.com/guide/topics/processes/process-lifecycle.html
[NOTE]Depending on the application, it may restart on it's own, due to coding in the app. Take for example the Associated Press widget that I had. In that instance it would be better for me to disable it as opposed to a task killer killing it all the time.[/NOTE]
The down side to task killers is they are often non discriminatory in what should and should not be killed. Let's say for example, John Doe uses Task Killer Extraordinaire and uses it to kill Nova Launcher (I checked this against a common task killer, this is possible). This will cause errors to come up, and he may not know why.
Something that has to be kept in mind is most users who have an Android will probably equate it to a Windows PC. In the subject of RAM, Android is not Windows. Windows likes to have RAM somewhat empty on standby. That is the way Windows OS works; more RAM is typically better to an extent (there is a critical mass idea of after a certain point, the extra RAM becomes irrelevant). Android, conversely, likes filling it, so it can use the cached data to reload the application easier.
Memory management
Since Android devices are usually battery-powered, Android is designed to manage memory (RAM) to keep power consumption at a minimum, in contrast to desktop operating systems which generally assume they are connected to unlimited mains electricity. When an Android app is no longer in use, the system will automatically suspend it in memory – while the app is still technically "open", suspended apps consume no resources (for example, battery power or processing power) and sit idly in the background until needed again. This has the dual benefit of increasing the general responsiveness of Android devices, since applications do not need to be closed and reopened from scratch each time, and also ensuring that background applications do not consume power needlessly.[SUP][[/SUP]
http://en.m.wikipedia.org/wiki/Android_(operating_system)
In a very rudimentary way, Android works like this:
Memphis turns his device on from a powered down state, Android loads everything up, and is ready to go. He then opens App #1 for the day. After using it for a few moments, he opens App #2, uses it, and then goes to the homescreen and goes about his day.
A little later, he opens up App #1 again, and it loads a bit faster.
'Switching Apps
Instead of using swap space when the user switches between apps, Android keeps processes that are not hosting a foreground ("user visible") app component in a least-recently used (LRU) cache. For example, when the user first launches an app, a process is created for it, but when the user leaves the app, that process does notquit. The system keeps the process cached, so if the user later returns to the app, the process is reused for faster app switching.'
http://developer.android.com/training/articles/memory.html
Memory management
Android manages the apps stored in memory automatically: when memory is low, the system will begin killing apps and processes that have been inactive for a while, in reverse order since they were last used (oldest first). This process is designed to be invisible to the user, such that users do not need to manage memory or the killing of apps themselves.[SUP][67][/SUP][SUP][68][/SUP]However, confusion over Android memory management has resulted in third-party task killers becoming popular on Google Play store; these third-party task killers are generally regarded as doing more harm than good.[SUP][69][/SUP]
http://en.m.wikipedia.org/wiki/Android_(operating_system)
Here is the why: The device Memphis was using had App #1 loaded in RAM. Android did not have to spend the extra time (which can be equated to battery power) loading the app from the internal storage and launching.
Now, not everyone uses just one app, we open several. The OS needs to have certain things loaded to help apps and related files and operations executable (think images, and radios). This done multiple times, eventually will bring RAM to nearly full.
'What happens now?'
RAM is nearly full and Memphis really needs to open up App #3. Android will look at the recent apps and sees that App #2 that Memphis opened at the beginning of the day, and hasn't been used since, can be killed to make room for App #3 to launch. App #3 then launches without a problem.
'Ok, so what is the big deal?'
The big deal is here is where users start to diverge into two main groups: Those who use task killers and those who do not.
Empty RAM is wasted RAM
The classic rule of thumb for Android. To add to it, misspent RAM is almost as bad. Take for example, when I got my S3 from Sprint. One of the widgets was from the Associated Press. Always kept up on RAM usage, even though I never opened it. In fact, I didn't know I had it until I had the device for a month. All that time, AP was sucking up RAM (albeit a fairly small amount) that could have been used elsewhere. May not seem like much of a problem, but take a device that is very inexpensive, and that extra RAM sucked up is a bad thing. Also, add all the other garbage that is bloat that not many people use, and the misspent RAM adds up, and quickly, even on a high end device.
Android has greatly changed since the days of old. Most people would agree that Gingerbread on most devices was, at best, horrible at RAM management. Back then, automated task killers were almost a necessity. But for the most part, Android can do it quite well on it's own.
'So, what about Task killers?'
Task killers can be as hard on the battery as they would do good. Many kill almost any running task, which Android then restarts because it needs it, spends battery firing up the CPU, bringing it out of memory and loading it. The Task killer then sees it again, and kills it. This brings about an endless cycle, thus draining the battery more than it should be drained.
Image taken from: http://developer.android.com/reference/android/app/Activity.html
To determine which processes should be killed when low on memory, Android places each process into an "importance hierarchy" based on the components running in them and the state of those components. These process types are (in order of importance):
- A foreground process is one that is required for what the user is currently doing. Various application components can cause its containing process to be considered foreground in different ways. A process is considered to be in the foreground if any of the following conditions hold:
- It is running an Activity at the top of the screen that the user is interacting with (its onResume() method has been called).
- It has a BroadcastReceiver that is currently running (its BroadcastReceiver.onReceive() method is executing).
- It has a Service that is currently executing code in one of its callbacks (Service.onCreate(),Service.onStart(), or Service.onDestroy()).
- A visible process is one holding an Activity that is visible to the user on-screen but not in the foreground (its onPause() method has been called). This may occur, for example, if the foreground Activity is displayed as a dialog that allows the previous Activity to be seen behind it. Such a process is considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.
- A service process is one holding a Service that has been started with the startService() method. Though these processes are not directly visible to the user, they are generally doing things that the user cares about (such as background mp3 playback or background network data upload or download), so the system will always keep such processes running unless there is not enough memory to retain all foreground and visible process.
- A background process is one holding an Activity that is not currently visible to the user (its onStop()method has been called). These processes have no direct impact on the user experience. Provided they implement their Activity life-cycle correctly (see Activity for more details), the system can kill such processes at any time to reclaim memory for one of the three previous processes types. Usually there are many of these processes running, so they are kept in an LRU list to ensure the process that was most recently seen by the user is the last to be killed when running low on memory.
- An empty process is one that doesn't hold any active application components. The only reason to keep such a process around is as a cache to improve startup time the next time a component of its application needs to run. As such, the system will often kill these processes in order to balance overall system resources between these empty cached processes and the underlying kernel caches.
http://developer.android.com/guide/topics/processes/process-lifecycle.html
[NOTE]Depending on the application, it may restart on it's own, due to coding in the app. Take for example the Associated Press widget that I had. In that instance it would be better for me to disable it as opposed to a task killer killing it all the time.[/NOTE]
The down side to task killers is they are often non discriminatory in what should and should not be killed. Let's say for example, John Doe uses Task Killer Extraordinaire and uses it to kill Nova Launcher (I checked this against a common task killer, this is possible). This will cause errors to come up, and he may not know why.
Something that has to be kept in mind is most users who have an Android will probably equate it to a Windows PC. In the subject of RAM, Android is not Windows. Windows likes to have RAM somewhat empty on standby. That is the way Windows OS works; more RAM is typically better to an extent (there is a critical mass idea of after a certain point, the extra RAM becomes irrelevant). Android, conversely, likes filling it, so it can use the cached data to reload the application easier.
Memory management
Since Android devices are usually battery-powered, Android is designed to manage memory (RAM) to keep power consumption at a minimum, in contrast to desktop operating systems which generally assume they are connected to unlimited mains electricity. When an Android app is no longer in use, the system will automatically suspend it in memory – while the app is still technically "open", suspended apps consume no resources (for example, battery power or processing power) and sit idly in the background until needed again. This has the dual benefit of increasing the general responsiveness of Android devices, since applications do not need to be closed and reopened from scratch each time, and also ensuring that background applications do not consume power needlessly.[SUP][[/SUP]
http://en.m.wikipedia.org/wiki/Android_(operating_system)
Last edited:
Let the OS do it's job!
Facebook
Twitter
Instagram