Optimizing graphical content for Android devices
One commonly overlooked problem that can arise in Android app development is optimizing the graphics to look great across all ranges of devices.
There are many different Android devices and since there are no particular rules on what size the screen should be, what the resolution should be, or the aspect ratio of screens, creating a good looking app can quickly become a daunting task. Throw tablets into the mix and one could quickly foresee a headache in their future.
To help grasp the seriousness of the situation, imagine that you have assigned a background image to fit perfectly to a certain device. On another device with a different aspect ratio and resolution, the image will fit much differently, can could look skewed, distorted, stretched, or cause memory issues because the device was expecting a much smaller image knowing it has a much smaller resolution.
Thankfully Android does provide solutions to these issues. Take a look at the specs of some popular android devices.
Take Notice of all the different Screen Sizes, Resolutions, and Aspect Ratios. This is a designer's nightmare! There must be a way to deal with this, and there is.
This is where screen sizes and densities (which can be found by the ppi (pixels per inch)) that android has broken into Density Categories come into play.
Much like iOS lets you define a 'normal' and 'retina' resource for images, Android allows you to define different images and layouts for different screen sizes and density categories. Each category is designed to hold the image that should be shown on a device with a density that falls into that category. However since large tablet screens can have a higher resolution and a lower ppi because of their large screen size, the density categories can be broken down further into a basic screen size.
First the default or 'phone' set of resources, can be defined and placed into the following categories
| Device | Screen Size (inches) | Resolution | Pixels Per Inch | Aspect Ratio | Density Category(DPI) |
| Galaxy Note | 5.3 | 800x1280 | 285 | 5:8 (10:16) | xhdpi |
| Galaxy Note II | 5.55 | 720x1280 | 267 | 9:16 | xhdpi |
| Galaxy S II (I9100) | 4.27 | 480x800 | 219 | 3:5 | hdpi |
| Galaxy S III (I9300) | 4.8 | 720x1280 | 306 | 9:16 | xhdpi |
| Galaxy S4 (I9500) | 5 | 1080x1920 | 441 | 9:16 | xxhdpi |
| Galaxy Note 10.1 | 10.1 | 1280x800 | 149 | 8:5 (16:10) | |
| Galaxy Note 10.1 (2014 Edition) | 10.1 | 2560x1600 | 299 | 8:5 (16:10) | xhdpi |
- drawable-ldpi
- drawable-mdpi
- drawable-hdpi
- drawable-xhdpi
- drawable-xxhdpi
- drawable-xxxhdpi
- drawable-large-mdpi
- drawable-large-hdpi
- drawable-large-xhdpi
- drawable-xlarge-mdpi
- drawable-xlarge-hdpi
- drawable-xlarge-xhdpi
Here are the categories further broken down into some usable information.
| ldpi | mdpi | hdpi | xhdpi | xxhdpi | xxxhdpi | |
| scale factor | 0.75 | 1 | 1.5 | 2 | 3 | 4 |
| suggested icon size | 36x36 | 48x48 | 72x72 | 96x96 | 144x144 | 192x192 |
| approx pixel density | 120 | 160 | 240 | 320 | 480 | 640 |
I know that creating 12 version of each resource can seem like a daunting task, but it is a necessary one if the app demands to be heavily image dependent, and it wants to look good across all devices. Further more we can actually define completely different layouts (or arrangements of the contents of the screen) for different screen sizes, so a small screen, can have a different layout than a medium screen, which can be different from a large one's layout.
One problem that can be ran into with this, is the size of your app. By including so many images, that size will grow rapidly. Google has created a solution for this problem, in which you release the same app multiple times. So technically you will have multiple types of the same app out, each one targeting different hardware, but the app will still be listed as the same app. Here is an excerpt from google about it
Multiple APK support is a feature on Google Play that allows you to publish different APKs for your application that are each targeted to different device configurations. Each APK is a complete and independent version of your application, but they share the same application listing on Google Play and must share the same package name and be signed with the same release key. This feature is useful for cases in which your application cannot reach all desired devices with a single APK.
With this in mind, we can create a phone version, small tablet version, and large tablet version of the same app, and eliminate issues with the size of the app.
Another thing you can do is only include every other Category of resources, so instead of including ldpi, mdpi, and hdpi, include only ldpi and hdpi. eliminating some of the categories in this style can save memory, time, and often have a very small effect on the app visually. Android will automatically pull the closest to correct size resource it needs, and scale if for you. If it doesn't quite look right, you can always include it later.
Finally, the best optimization is try to eliminate large images altogether! The design trend is moving towards solids and flats, but Android can even create gradients and some more complicated shapes and backgrounds through cheap, scalable, and easy to use .xml drawable files. By using .xml drawable files for backgrounds, you can save memory at runtime and the size of the app, all while improving performance. This could be a post all in itself, how to use android .xml drawables, and it may well be: just remember that more is possible with these gems then you might think, and they look amazing across all screens.
Real quick I want to touch on another topic that could be its own post, or series of posts. Cutting out the android resources from a reference file or artwork, is much different than doing so for iOS. In iOS you can assign the background image, and then place views according to the image. In Android you can not do this, due to everything mentioned above (differing resolutions, ratios, and sizes). Each Icon will need to be cut out on its own. If you look at the reference image, and can pick out separate parts of the image, like a green textured bar here, or a special background behind a certain item, those images will need to be cut separately. Views in Android are placed relative to other content, not relative to the resolution, ratio, or size of the screen. As such each piece of content needs its own graphics.