Memory Analyzer Tool (MAT)
If you're not familiar with Eclipse's MAT you should be. MAT should be your first stop for dealing with memory problems. Not only is it useful for finding out what's hogging memory, it can also be used to find memory leaks.
An important note about using MAT - almost all memory problems I've run into relate to Bitmaps. In versions of Android previous to 3.x, Bitmaps were stored in native memory (rather than the heap) and thus not viewable in MAT. This makes it much harder to debug memory problems on 2.x devices, so you might want to stick to 4.x devices for investigating memory issues.
High-Resolution Bitmaps
Bitmaps in memory are uncompressed (even if they were compressed in your APK). This can cause serious issues if you have high-resolution assets. For example, we had tablet backgrounds which were the full resolution of the N10 (2560x1600). That's fine with the N10's beefy heap size, but when scaled down to smaller devices (like the N7) the scaled image would take up 1/8th of the app's memory! Imagine doing that multiple times and you can see why we ran into memory issues.
Bitmaps in memory are uncompressed (even if they were compressed in your APK). This can cause serious issues if you have high-resolution assets. For example, we had tablet backgrounds which were the full resolution of the N10 (2560x1600). That's fine with the N10's beefy heap size, but when scaled down to smaller devices (like the N7) the scaled image would take up 1/8th of the app's memory! Imagine doing that multiple times and you can see why we ran into memory issues.
We solved this problem one of two ways: first, we reduced the resolution of the asset. Some of these backgrounds were blurred, meaning we could lower the resolution greatly without losing quality. When we couldn't lower the resolution without quality suffering greatly, we would sometimes replace the normal asset with a backup color (when we detected low memory situations).
BitmapFactory.decodeResource()
When you're decoding resources yourself (rather than using something like ImageView.setImageResource()), there are a couple things to look out for.
If you're decoding the same resource over and over again, you might want to cache it. This problem hit us because we had an ImageView in a list show a default asset before we load an image from the network. If you scrolled through a list quickly, and each one is loading its own default asset, you could create a burst of memory usage that runs you out of memory. By caching this default, we not only saved memory but also improved performance.
When you're decoding resources yourself (rather than using something like ImageView.setImageResource()), there are a couple things to look out for.
If you're decoding the same resource over and over again, you might want to cache it. This problem hit us because we had an ImageView in a list show a default asset before we load an image from the network. If you scrolled through a list quickly, and each one is loading its own default asset, you could create a burst of memory usage that runs you out of memory. By caching this default, we not only saved memory but also improved performance.
Another issue we ran into with decodeResource() involves device density and BitmapFactory.Options. If you are using them you should know that the default is to not auto-scale the asset at all. So if you've only got an xhdpi version of the asset on an mdpi device, you're going to load them in at xhdpi size, taking up more memory than you expected. So make sure to set that if you're manually loading assets with Options. (If you're not passing BitmapFactory.Options you don't need to worry, as the default decodeResources() handles density for you.)
LruCache
Having an in-memory LruCache of Bitmaps loaded from the network is all the rage these days. However, it can easily lull you into a false sense of security. Just because you've limited your Bitmap cache doesn't mean you'll never run out of memory! If your LruCache is 1/4th the size of available memory, but your app (at one point) needs all of it not to crash... well, you've got a problem.
Having an in-memory LruCache of Bitmaps loaded from the network is all the rage these days. However, it can easily lull you into a false sense of security. Just because you've limited your Bitmap cache doesn't mean you'll never run out of memory! If your LruCache is 1/4th the size of available memory, but your app (at one point) needs all of it not to crash... well, you've got a problem.
Things got better for us once we started manually clearing the LruCache at key moments. Having a DiskLruCache helps a lot if you do this, as you can clear the memory cache but then quickly reload images if you need to without going to the network.
Resources and sPreloadedDrawables
This is a red herring! You may see in MAT that Resources is taking up a whole ton of memory with a variable called sPreloadedDrawables. Unfortunately, you can't avoid sPreloadedDrawables; it's a pre-defined set of system resources that are preloaded into memory for every app. Don't spend any time thinking about them.
This is a red herring! You may see in MAT that Resources is taking up a whole ton of memory with a variable called sPreloadedDrawables. Unfortunately, you can't avoid sPreloadedDrawables; it's a pre-defined set of system resources that are preloaded into memory for every app. Don't spend any time thinking about them.
Recommendation
Overall, what you should do is find an old phone and use it as your primary development device. That way you know from the start that your app runs on all phones. It's much harder to discover these limitations later on.
For example, the Nexus 4 (my primary device) has a whopping 192MB of memory. Even with all xhdpi assets that thing is difficult to run out of memory on a standard app. Compare that to what QA was using - devices with 24MB to 32MB. It's a very different game when you're trying to design a beautiful app to run in 24MB on hdpi!
Good tips, thanks for sharing.
ReplyDeleteI am thinking that in this time you should give a try to this new app NiceLock (Ad-Free) Apk : which is now most trending app in the world.
ReplyDelete