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.
Related
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.
I have designed an in-app keypad for my Android application and I need to provide an image for every key. Currently I've only loaded one large image for each one that is being scaled down to adjust to the layout. Also, this looks nice in every resolution.
Is this approach acceptable or should I provide different images for different screen densities? Currently I've placed those inside the generic drawable directory.
You should. Some mobiles with lower resolution, usually won't have much memory. Loading large images in small screen takes too much memory, which might end up crashing. So if you give different images, then according to density it will take appropriate images. check this out.
It's acceptable in some cases but certainly not optimal.
For best memory performance and the least amount of artifacts I would still recommend to provide alternative bitmap resources for different densities, like the Android documentation recommends.
I am developing an android application which displays an image as background. I have read the documentation and it says that Mdpi should be the base line and all other dpi's should be relative to it. But I am not able to decide what should be the resolution of background image in pixels I should for all the dpi's?
Any suggestion?
The best approach depends but, to save space and retain resolution at all densities, include only a single image in your app. When your activities load, use a scaled load based on the the DisplayMetrics of the device. If you aren't worried about resolution, then scaling up from MPDI is fine (but I'm pretty sure you're asking because resolution at the higher densities is a concern, and based on your background image size).
The advice for "starting" with MDPI has to do with the numeric scaling that is needed and being able to conceptualize it. In other words, it is easiest to "think" about how scaling works on Android when you start with MDPI. After that, your use-case is far more important.
There are many examples for scaling images based on your needs. Do not forget to use caching whenever possible, if your application loads several.
Another thing to consider is the extended heap memory, if you encounter OOME because of iamge handling issues.
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.
I've been through this post (and others) as well as through the documentation about supporting different screen resolutions in Android, but I couldn't find a clear answer to a (simple) question:
Is it ok to just use "res/drawable" for images in an android app?
Background: The only images that are needed in this specific app are the app icon itself and an icon for a notification, there won't be any images in any layout.So in my understanding, if no "hdpi"-, "mdpi"- and "ldpi"-folders are found, Android will use "res/drawable" as the fallback.As the only pitfall with different screen-resolution seems to be that Android will scale images for a specific resolution if no special one is found, this should only be a problem when UPscaling, because the image will get blurry. But if I provide all "hdpi"-images in "res/drawable" (instead of 3 different ones), won't Android just DOWNscale those images if the size is too big?If that's true, I could save some APK-space by just a third of the images.
Follow-Up question: I read that for API-level 3 a dir by the name "drawable-v3" is required. Is that true or is "drawable" the fallback for this API-level also?
Any hint is appreciated.
The images in the drawables folder are assumed to be at mdpi resolution, so they will get scaled up/down if you don't provide the others.
Scaled up images will be low-resolution and look fuzzy. Scaled down images will have pixels missing and look jaggy.
So your app will "work" with only one set of default images, but will look awful on many devices. I strongly advise that you create the images in different sizes, so it looks great on all devices - it's a bit boring, but not hard to do.
It won't be long before we have xhdpi devices, so while you're at it you may want to create those too.
I assume you've read this
Not a complete answer, but: highly downscaled images can and usually do look just as bad as upscaled images (but in a different way), because graphics libraries almost exclusively use interpolation methods for resizing, and interpolation methods are limited in terms of how much they can shrink an image before serious information loss (to about 50% for linear methods and down to about 25% for bicubic methods). This is why most platforms have evolved conventions (like hdpi, mdpi etc.) that let you embed images that are best for each screen size.
I use drawable/ all the time, and then I go to BestBuy and all the local wireless stores and test my apps on small/large/huge(tablet) devices and they look just fine.
Unless you have some reason to target pre-Donut devices (now only 4% of the devices according to http://developer.android.com/resources/dashboard/platform-versions.html), then you should put your bitmaps in one of the -Xdpi directories. The generic "drawable" directory is a synonym of "drawable-mdpi" for compatibility reasons, but a modern well-written app should be putting its drawables in a directory matching the density they are designed for.
res/drawable is the fallback
the caveat is that scaling not only degrades the image but takes processing time too.
I have not even read the API-Level 3 docs yet, sorry for 1/2 an answer
For what it is worth I found the image handling of Android to be tedious and unreliable. The concept of including different size images for different screens will result in large application files bloated with images. There are already screens that don't fit in the standard resolution ranges. I have found it is best not to let android handle the scaling, it seems to create a base image for the smallest screen you target and then scale it up resulting in ordinary looking images on large screens. This happens even if you made the image specifically for the large screen.
My solution that seems to work on everything from a 2" samsung phone to a Sony Tablet is to create images at high resolution and use Bitmap.createScaledBitmap() to get the size I need.
caveat: I am new to Android and have lots to learn.