Looking at it plainly, Android is a software stack for mobile devices that includes an operating system, middleware, and key applications. The Android SDK provides the tools and APIs needed to start developing applications for the Android platform using the Java programming language.
Memory in Android
As we’ve said more than once, Android is a Linux-based operating system running kernel 2.6.x, simplified to handle most tasks. It uses open native C libraries. All the operating system’s basic operations — I/O, memory management, and so on — are handled by the Linux kernel.
Memory management is fairly standard. Just like Java and .NET, Android uses the runtime and the virtual machine to manage the application’s memory. Unlike either of those two frameworks, the Android runtime also manages process lifetimes. Android keeps the app responsive by stopping and killing processes that get in the way of smooth performance, freeing up resources for higher-priority applications.
Every Android application runs in its own independent process, inside its own instance of Dalvik, handing off all responsibility for memory and process management.
Dalvik and the Android runtime sit on top of a Linux kernel that handles low-level hardware interaction, including drivers and memory management, while the API set provides access to all the low-level services, features, and hardware.
The Dalvik Virtual Machine is a register-based virtual machine that has been optimized to ensure a device can run multiple instances efficiently. It relies on the Linux kernel for low-level memory management.
The Dalvik Virtual Machine
One of the key elements of Android is the Dalvik virtual machine. Instead of using a traditional Java virtual machine (VM), such as Java ME (Java Mobile Edition), Android uses its own custom virtual machine designed to make sure multitasking runs efficiently on a single device.
The Dalvik virtual machine uses the underlying Linux kernel to handle low-level functionality, including security, process scheduling, and memory management.
All access to Android’s hardware and system services is managed through Dalvik as a middle layer. By using a virtual machine to organize application execution, developers get an abstraction layer that means they never have to worry about any particular piece of hardware.
The Dalvik virtual machine launches Dalvik executable processes, a format optimized to keep the memory footprint to a minimum. These .dex executables are created by transforming Java-language classes, compiled using the tools provided in the SDK.
Process priority
The order in which processes reclaim resources is determined by the stored priority of the applications. An application’s priority is equal to the highest priority of its components.
When two processes have been running equally long and both have the same priority, the process that has held a lower priority gets killed first. Process priority is also affected by dependencies between processes: if an application depends on a service or content provider supplied by a second application, the second application will have at least as high a priority as the one it’s supporting.
Every Android application stays running and in memory until the system needs its resources for other applications.
It’s important to make sure a process’s priority matches the work it’s doing. If it doesn’t, the process could be killed while it’s in the middle of something important.
Process types, ordered by priority:
– Active Processes
Active, or foreground, processes are the ones the user is actively interacting with. In general there are only a few of these at any given time, and they’re only killed as a last resort.
Active processes include:
-Activities in an “active” state, meaning they’re in the foreground and responding to user events.
-Activities, Services, or receivers currently running an OnReceive event handler.
-Services currently running OnStart, onCreate, or the OnDestroy event handler.
– Visible Processes
As the name suggests, visible activities are visible, but they’re not in the foreground and don’t respond to user events. This happens when an activity is only partially shown (a screen that isn’t full-size or that’s transparent). In general there are very few visible processes, and they’re only killed in extreme circumstances, to let active processes keep running.
As for services, those that support running active processes are given a noticeably lower priority than active processes themselves, since services don’t interact directly with the user.
– Background Processes.
Background processes cover activities that aren’t visible but are still running. In general this won’t be a large number of processes.
– Empty Processes
Empty processes are kept around to improve the system’s overall performance; Android often retains applications in memory even after they’ve reached the end of their lifecycle. This memory cache is kept in order to improve app startup response times.
How to use memory efficiently
Android manages open applications running in the background. This means it closes apps when the system needs more memory, so there’s no need to fall back on secondary storage. However, most Android users aren’t entirely happy with how this is managed, because it sometimes leaves too many processes running, causing the well-known slowdown compared to iOS (iPhone, iPad…). To fix this, we can always use a task killer