In my apps so far I have mostly only included high density bitmaps and declared my ImageView sizes in dp (of course). I've gone through Supporting Multiple Screens again and I still do not see much of a point in including lower density bitmaps since the system will just scale them appropriately for lower density devices.
I can't imagine scaling a bitmap down in Photoshop is going to provide much of a better image than the Android system's scaling. It can be time consuming to scale bitmaps in Photoshop, especially if you want to change something later. The extra bitmaps will increase the .apk size to some degree.
I can see there is a possible performance hit when the system must perform the scaling at runtime, is it ever noticeable? Am I missing something else?
still there are so many lower end devices(screen and performance ) in market.
for sake of optimization should included at least mdpi and greater.
Related
Regarding Android's call to provide multiple versions of a bitmap/image, why can't only the highest resolution image be used?
E.g if the xxhdpi image is available - will that be able to scale down to all lower density versions or will it just mean it will scale bigger than the allocated size (View)?
PS: If I'm using a background image, does scaling matter? E.g. should I still provide multiple versions of 1 image to fit different pixel densities?
Usually image scaling operation is resourceful and the outcome might be worse than using pre-scaled image.
It has already been answered several times, but I will answer it again. Btw I'm not myself a big pro in Android, but I will try to answer in the best way possible.
Automatic scaling is a thing in Android, but using that is a waste of resource, we already know that using a PNG Graphic asset is a waste of CPU/GPU power when we can use XML for basic designs (which uses less resources), so why waste more power for downscaling it (which increases app opening time and makes it laggy), simply creating multiple sized images for different display sizes is the best option.
A simple and convenient option is to use a free software like Adobe XD which supports export into different sizes.
Simple answer: Avoid using PNG(or other image format), but when you don't have other options do create multiple sizes to save resources.
I don't get why it's recommended to have a drawable (image) for all densities (ldpi, ..., xxhdpi).
Would it not be better to add one file with the highest needed density (xxxhdpi) and than programmatically scale that image down (e.g. for tab icons I could just set a explicit dp size)?
Therefore I would only have to manage one file and the APK file size would be smaller. I think the performance disadvantage should not be significant.
Update 1:
To be more specific: I never noticed any quality loss when using a high density image (PNG file) which was scaled down to a explicit dp value on my mdpi device.
So I was considering if the disadvantages of managing multiple image files as a coder without a designer (and the higher APK file size) might outweigh the advantages. Especially if I'm going to target newer devices (API >= 17).
Update 2:
In my case I'm more a coder than a designer. In the microphone example image of #mes I could just use a high density version of the left microphone and scale it down with no significant disadvantages?
There's no significant advantage, when designer or you simply reduce image size and put inside the ldpi, actual meaning is to paint another image for small size, because there are many cases, when simply reducing an image size produces inacurate and low quality image, and a good designer will draw another image, with few details in it, this is an example, only in this case worth to put different images in different folders
Therefore I would only have to manage one file and the APK file size would be smaller. I think the performance disadvantage should not be significant.
Yes, you are right, there no significant performance improvements, and also apk size is increases, that's why not worth to downscale the same image.
There are two reasons for this:
Typically, devices with lower density screens also tend to have less powerful hardware for image & graphics processing, along with lower memory.
Its not just the density, it is also the file size and image dimensions that are scaled accordingly.
The Android way of having different drawables for different screen form factors is thus appropriate from a technical standpoint.
First advantage is what mes mentioned: different images for different sizes.
Second advantage is memory/code efficiency: a 1000x1000 pixels image on android will take 1000x1000x4 ~= 3.8 mb of memory which is really wasted on smaller screens which can have 16mb available memory per app. You could try loading the bitmaps efficiently but that's a lot of code to put/maintain for each image and also will have performance issues on some cases.
My app supports various screen densities from ldpi to xhdpi. It contains some drawables (images) that need to be displayed properly on all densities.
I'm wondering how many various resolutions of the drawables are actually necessary to provide, considering that Android runtime is scaling resources when it cannot find one for the appropriate density.
If you provide only mdpi drawables, they will be scaled up on hdpi/xhdpi (blurry) and scaled down on ldpi screen.
However, if you provide only xhdi resources, then they will be scaled down on all lower density screens. Scaling down doesn't make them blurry and they will look fine.
So why bother providing drawables for other densities than xhdpi?
There are several reasons to used prescaled drawables:
Scaling down to lower resolutions takes resources (CPU time, memory and it drains your battery faster), especially if you have a lot of images this might be undesired.
Scaling down a large image might result in worse quality than using a 'pre-tuned' smaller image. Especially if your images are based on a vector original. Or they contain very fine lines or details, which will get lost when due to the scaling.
For example:
becomes
See here for the source of these images and more information on scaling artifacts.
On lower resolutions the image pixels are larger (or the image gets smaller), so it might be required to remove certain aspects of the image to keep it clear/understandable.
Your assumption about scaling resources isn't correct. Some large images may still look nice when they are scaled down, but this isn't the general case. If the image has smooth transitions and no gradients, it will be nicely scaled down. Images that contain sharp transitions or contain text for example will look ugly in lower resolutions.
If you make the scaling down yourself the result might be better compared to auto scaling plus your app doesnt consume resources for scaling if the drawables are prepared.
Not necessary but for example, you can use different layouts with different drawables for different screen resolutions. You have the option to do it. If you and your users are satisfied with the result, then cool. If you need different behavior in different densities and resolutions, then this feature comes really useful.
i am NOT an android developer and im trying to understand what they need in terms of graphical resources to make an app that functions across many android devices.
i have (tried to) read this page http://developer.android.com/guide/practices/screens_support.html , but find it somewhat bewildering. they talk as if screen density is the important thing "Supply alternative bitmap drawables for different screen densities" but then, if you dont know the size of the screen, you cant really think in terms of layout. is the idea to make buttons and logos that are the same size on all screens with the same density, such that on a large screen there is just a bunch of space, and on the small screen its all packed in tight? i dont understand how just thinking in pixel density gets me any closer to knowing what to provide.
are you supposed to create resources for every screen size AND pixel density? say it aint so.
anyway can somebody tell me... if you were developing an app what do you need for graphics? is it possible to provide graphics that are large and just let them scale down? is it inevitable that the devloper will have to mess with the graphics himself anyway? or can he be provided with sets of png files of certain sizes that will be ready to use?
thanks!
Here's what we do at my work place. Suppose we get a desing for the app. We make our designer create 3 psds versions for the same desing. the 3 psd's are for the 3 ranges of desnity. The size used for the psd are
240*320 (Low Density)
320*480 (Medium Density)
480*800 (High Density)
Most of the time when I write layouts, I use wrap_content which means a view must take the size of the content it wraps. Which works most of the time as I have a density specific version of the design so the image i use as background should be suitable. The thing to note is that, in android you can can put the 3 sizes of the same image in different folders such as drawable/ldpi, drawable/hdpi.
Eg: you have a bg.png and have a version for large phones and a version for small phones. You put the big bg.png into hdpi folder and the small png in the ldpi folder. Android will automatically select the appropriate image based on the phone density. But you need to make sure the file name is the same.
There are cases where you need to resize you background images without makeing the image looking too scaled. For this android uses the draw9patch tool. With this tool you can specify areas which can scale and areas that shouldn't scale.
9 Patch png's are your friend. Read up on them here:
http://developer.android.com/guide/topics/resources/drawable-resource.html#NinePatch
and here:
http://developer.android.com/guide/developing/tools/draw9patch.html
Those are your best bet for any kind of graphic that will stretch nicely (i.e. not gradients, they will come out slightly pixelated on some screens probably) The power of these types of images is that you can tell the system which pixels to repeat if it needs to stretch the graphic. This means that stretching can be done without loss of image quality (again depending on your image and how you choose to make the nine patch. The "show bad patches" button in the draw9patch program will show you potential problems. Hint: keep your repeatable pixels down to 1 on left and 1 on top and you'll have no problems with bad patches) Any graphics that can be made in to 9 patches will only need 1 size since the system can effectively make it whatever size it needs.
are you supposed to create resources for every screen size AND pixel density?
You may if you like. This would ensure that the application will look great across all devices. I understand that this is not feasible for all projects though. In general if you make separate resources for the different densities you'll get something that looks acceptable on most of the devices out there. All of the devices are classified as ldpi, mdpi, or hdpi (there may be an "extra high" level now too, I am not certain off the top of my head) So if you supply graphics for those 3 densities then the system will know where the device falls under and will pull the correct graphics.
is it possible to provide graphics that are large and just let them scale down?
Yes the system will scale down your graphics if needbe. But be aware there are consequences with this approach. First every time the system hast to scale a graphic up or down it is going to taking up CPU and memory to do so. This may not be an issue if you have relatively few things to scale, but if you have many it could cause noticeable lag time during on the lower power phones. Second, To my knowledge all of the graphics in android are raster, which means if you are letting the system scale something up or down image quality is going to decrease some. Again depending on the specific images this may be more or less noticeable on the actually device at runtime.
My best advice is supply them with resources of a few different sizes and run the app on as many different devices as you can. Once you see how your different resources look on the devices of different sizes you'll have a much better feel for which ones you need to supply to get the UI looking as consistent as possible across the largest swath of screen sizes and densities.
If you're planning to support LDPI, MDPI, HPDI, and perhaps XHDPI in the near future, is it ok to only include XHDPI drawables in the project and let the devices scale them to their desired resolution?
I've tested to resize the drawables into MDPI and HDPI in Photoshop and then compared the result with XHDPI drawables only resized by Android, and I can't see any difference at all. Is it bad design to take this shortcut? It would be nice to not have to resize each and every drawable into 3 different resolutions.
Planning to use target SDK is 2.1 or 2.2.
BR
Emil
I guess that's a good way to go. The only downside I can think of is the resource overhead on small scale devices and possible artifacts because of the downscaling. Actually at this year's Google IO Chris Pruett recommended embedding only high resolution assets and let opengl handle the scaling.
As of Android 1.6, different densities are handled, including XHDPI (which wasn't officially added until 2.2). Your app will first look for an image matching its density, but it can look into larger "buckets" like XHDPI and then perform the scaling for you.
It's best to include specific assets for the densities you want to support. An image that's 100x100 takes 40kb; and image that's 200x200 takes 160k (uncompressed). So, any XHDPI assets used on MDPI devices have four times the amount of data that you need, which has to be handled when the app starts and your resources are prepared. Lower memory use means greater efficiency, less chance for an OutOfMemoryException.
Further, specific types of images will look bad when automatically scaled. In particular, images with fine lines or fine patterns will have their detail muddied. When you shrink the images by hand, you can choose the algorithm that best matches your needs (linear, bicubic, lanczos, etc.).
If you're worried about the time it takes to do the resizing yourself, you can incorporate a batch process or use tools such as Nine Patch Resizer: http://code.google.com/p/9patch-resizer/
I tested in a simple app (develop for Android 2.1) using only xhdpi images and it works fine in small, medium and high resolutions... even I tested in an Android 2.1 (small resolution) and it opens the imagen without problem.
Maybe the thing with the memory is true, so its necessary someone test this.
I personally found that using just xhdpi folder works quite good in many apps and am a big supporter of this approach. In memory overhead is true but with todays devices I would consider it negligible. Also I think there is some caching involved after downscaling since I never noticed any slow down because of this. Including only one folder can dramatically reduce your APK size which end users will quite appreciate. You should keep in mind that some images will get scaling artifacts (fine patterns and stuff) but I personally never encountered nothing critical in my apps. Also for buttons and stuff be sure to use 9patches in order to reduce artifacts on rounded corners, you can even slightly reduce image size by using this approach. API level will not be a problem on older versions since I think that drawable-xhdpi is regarded as just drawable on versions that didn't support it.
Don't ignore chances to define some simple drawables in xml, for example it's really easy to create gradient background with just shapes and with this you save space and don't risk scaling artifacts.
XHDPI was only introduced in Android SDK API Level 9 (Gingerbread) (see http://developer.android.com/reference/android/util/DisplayMetrics.html#DENSITY_XHIGH) so if you plan to have a minimum SDK level of less than 9 you will also need to provide, at least, HDPI drawables as well otherwise devices with Froyo or below will display nothing.
Update: It actually seems like versions prior to Gingerbread will display xhdpi images: https://groups.google.com/d/msg/android-developers/yjYO91OmoJ4/v3he0ZbKo-UJ
It's OK to have only xhdpi resources. But note that xhdpi was introduced with api level 9 (gingerbread). That is, if you target api levels <=8 you need at least also hdpi resources.
This statement about extra memory usage is wrong.
If you put XHDPI sized drawables inside MDPI folder, then you will have memory problems.
But if you provide XHDPI drawables inside XHDPI folder, then no extra memory will be used since android downsamples the images by skipping parts of it.
This skipping is the reason why you need to provide drawables for every density you plan to support in order them to look good.
On the other hand, only certain images will look bad when downsampled (mostly small icons) so as long as the image has enough data to be thrown away, it will look ok. Or imagne if you have a grid as a drawable, so potentialy some grid lines can get thrown away and the image will look bad.
In the end, it is better for you to experiment with different devices, then you can tell which drawales need alternative resources for their density.