Android Memory: Reduce, Reuse, Recycle

迈不过友情╰ 2022-09-25 13:23 96阅读 0赞

[原文链接][Link 1]

Development on most platforms has it source of frustrations. Android is no different. One of the main sources of developer angst in Android is memory, as we never seem to have enough of it. Our apps’ heap space — the memory in which our objects go — could be as low as 16MB, though 32-64MB is more common nowadays. Still, this is a far cry from the memory you can use in, say, a Java Web app.

A lot of Android developers run into `OutOfMemoryError` messages. Some who do are quick to blame these small heap sizes, and they no doubt contribute to the problem. However, another reason for those errors is that Android does not today use a compacting or “moving” garbage collector. If you allocate a bunch of objects, and you free just some of them, you wind up fragmenting your heap. Android’s Dalvik VM will not move objects around in memory to try to compact the used memory space and allow all available memory to be allocated as once. If you get an `OutOfMemoryError` on Android, what Android is really saying is that there is no single block of memory big enough for your request, so while you may have enough free heap space, the allocation cannot succeed.

Google is working on replacing the Dalvik VM with the new ART runtime, and eventually it will offer a moving garbage collector. When your app is in the background, the moving garbage collector will clean up your heap to make it possible for you to allocate big blocks of memory again. But it will be years before ART is predominant on Android devices.

In the meantime, Android developers need to use the mantra adopted for consumer product packaging: reduce, reuse, and recycle.

We often get the `OutOfMemoryError` message when loading a bitmap, because bitmaps are typically the single biggest objects we try creating, and so they are the ones most likely to run into a case where there is no big enough free block. In many cases, you do not need the full image in memory, because your planned uses for it call for something smaller, such as a thumbnail of a photo. In those cases, you can use `inSampleSize` on your `BitmapFactory.Options` to tell the framework to sample the image, loading every Nth pixels, so that your resulting image takes up a fraction of the normal amount of memory. You may also be able to get away with using`RGB_565` representation for the pixels, which take up half the memory of `ARGB_8888` pixels, at the cost of reduced bit depth and no more alpha channel. And, beyond bitmaps, only load stuff into memory when you are sure that you need it — loading the entire contents of a database to populate a `ListView` is wasteful if the list is so long that the user would never scroll through the whole thing anyway.

Given that we have to allocate memory to get work done, it is better to reuse that memory, rather than simply allow garbage collection to “do its thing”. This is particularly true for bitmaps, as while we can allocate a large block of memory early on in our process’ lifetime, we may not be able to do so later on as the heap gets fragmented. Savvy developers will use techniques like`inBitmap` on the `BitmapFactory.Options` object, to tell the framework to reuse an already-allocated memory block for a bitmap, rather than allocating a fresh block. The developer can then maintain an “object pool” of bitmaps, reusing ones that are no longer needed elsewhere in the app. Such object pools are a common technique, particularly among game developers, to reduce the overhead of garbage collection.

Beyond that, the biggest thing to do is not not leak memory, as leaks tie up heap space that could be put to more productive uses. In a garbage-collected language like Java, a memory leak comes from when an object that will no longer be used is reachable from something static, like a thread or one of your own singletons. Android developers can use tools like Eclipse’s MAT to help identify memory leaks. Sometimes, though, the “leak” is really a cache, representing objects that could be rebuilt later but are being kept around to save on disk I/O, network I/O, etc. Developers need to make sure that their caches do not consume too much heap space. You can perhaps reduce your cache size when `onTrimMemory()` is called, letting you know that it is a good time to reduce your memory usage.

There are a number of patterns for improving memory usage in Android development. And since ART will not solve all problems, developers need to employ these patterns to avoid an `OutOfMemoryError` in production apps.

[Link 1]: http://wip.org/android-memory-reduce-reuse-recycle/