One challenge to developing for the Android platform is how to squeeze everything into 16 megabytes of heap space.  App-phones with 16GB and 32GB are common, but that is solid state storage and not RAM.  For Android applications, the limit for each application is 16MB (24MB on newer Droid and Nexus One phones).

Images, audio, and video are memory-intensive items, and many apps have these features. There are tools to help monitor memory use (e.g. Eclipse MAT, Android DDMS), and these tools are good for diagnosing problems, but you still need to understand enough to be able to fix memory leaks.

Here are some ideas for reducing the memory footprint of your application:

Reduce image sizes:  Lower the width, height, pixel bit-depth, and compress your images as much as you can.  Of course when an image is uncompressed and loaded into a Bitmap object then it takes up more memory, but you can reduce the memory footprint by lowering the image quality (for example see: View.setDrawingCacheQuality and View.DRAWING_CACHE_QUALITY_LOW) or even disabling the cache on views containing images.

Lower audio and video bitrates: I don’t know this for a fact, but I would guess that a lower-bitrate audio stream may have a smaller memory requirement during playback.  For example a mono-48 kbit/second audio file would require decoded fewer samples per second than a stereo-192 kbit/second file. (Please comment to this post if you test this theory or know the answer.)

Destroy or reuse objects: When you can, re-use objects and make sure that old objects are fully-destroyed. when they are no used anymore.  Even better, never create objects in the first place if possible.  This is especially true for bitmap objects – be sure to call the Bitmap.recycle() method. Remember to clear callback methods of objects before destroying them, because otherwise an object may not be properly returned to the memory heap during a java garbage collection operation.

Use final and static:  Virtual methods take up more space, and are slower, than static methods.  Final variables and arrays are stored in code space and not the memory heap.  Granted the difference is very small compared with 16MB of space, but every little bit counts!

Separate applications for localization:  If you are developing apps for multiple languages, consider creating separate applications instead of including all the language-specific strings, images, audio files, and videos in a single application.

Rely on external storage:  If you know that there is smart-card memory available, use that to store data instead of in memory.

Revert to an earlier Android SDK: When we reverted our most-memory-challenged Android application from Android 2.2 to Android 1.5, we gained two important things: first, we are now compatible with almost all existing Android phones; and second we reduced our memory footprint by almost a megabyte.  This latter statement is extremely interesting, since it indicates that the Android framework is getting bloated by all the new features added between versions 1.5 and 2.2.