The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
RAM. Developers nowadays are used to having lots of it, and a virtual machine capable of using as much of it as exists (and more, given swap files and page files).
“Graybeards” — like the author of this book — distinctly remember a time when we had 16KB of RAM and were happy for it. Such graybeards would also appreciate it if you would get off their respective lawns.
Android comes somewhere in the middle. We have orders of magnitude more RAM than, say, the TRS-80 Model III. We do not have as much RAM as does the modern notebook, let alone a Web server. As such, it is easy to run out of RAM if you do not take sufficient care.
There are two facets of memory issues with Android:
This part of the book examines memory-related issues, with this chapter focusing on the application heap. Another chapter will deal with system RAM issues. These are not to be confused with any memory-related issues inherent to graybeards.
Understanding this chapter requires that you have read the core chapters and understand how Android apps are set up and operate, particularly the chapter on Android’s process model.
When we think of “memory” and Java-style programming, the primary
form of memory is the heap. The heap holds all of our Java objects
– from an
Activity to a widget to a
Traditional Java applications have an initial heap size determined by the virtual machine, possibly configured via command-line options when the program was run. Traditional Java applications can also request additional memory from the OS, up to some maximum, also configurable.
Android applications have the same basic structure, with very limited configurability and much lower maximums than you might expect.
The original Android devices had a heap limit of 16MB. As screens increase in resolution, the heap limit tends to rise, but only to a point. 32MB to 64MB of heap space is fairly typical, but less-expensive devices, such as Android One models, will tend towards the lower end of that range.
This heap limit can be problematic. For example, each widget or
layout manager instance takes around 1KB of heap space. This is why
AdapterView provides the hooks for view recycling — we cannot
ListView with literally thousands of row views without
potentially running out of heap.
API Level 11+ supports applications requesting a “large heap”.
This is for applications that specifically need tons of RAM, such as
an image editor to be used on a tablet. This is not for applications
that run out of heap due to leaks or sloppy programming. Bear in mind
that users will feel effects from large-heap applications, in that
their other applications will be kicked out of memory more quickly,
possibly irritating them. Also, garbage collection on large-heap
applications runs more slowly, consuming more CPU time. To enable the
large heap, add
android:largeHeap="true" to the
element of your manifest. Finally, bear in mind that your “large heap”
may not be any bigger than your regular heap would have been, as
the “large heap” size is determined by the device manufacturer and
takes into account things like available system RAM.
The preview of this section was last seen in the Bermuda Triangle.
The preview of this section was fed to a gremlin, after midnight.
The preview of this section was lost due to a rupture in the space-time continuum.
The preview of this section was the victim of a MITM ('Martian in the middle') attack.
The preview of this section took that left turn at Albuquerque.
The preview of this section was traded for a bag of magic beans.
The preview of this section is out seeking fame and fortune as the Dread Pirate Roberts.