Is there any drawback in only using xxhdpi images and letting android scale the images?
(Yes it might be more cpu intensive, but is it notable?) I tested it on a samsung s2 and the difference were small.
Is there a restriction to only use this if set minSdk to XX, becaus there were no xxhdpi?
Here are a couple drawbacks I can think of:
More CPU intensive to resize the images, the app will use more battery and might feel more sluggish, especially on older devices.
The images that you are going to load will be bigger and will use more memory. On mdpi/hdpi devices, the VM in which your app run will only have a smaller amount of heap memory available, and you might run into Out Of Memory Exceptions much more frequently if you only load high quality images.
The quality of the image might not be as good on mdpi/hdpi devices, because of the resizing. This really depends on what image you are loading, but images with sharp lines might appear a little blurred. But I also want to point out that this only applies if you are really making pngs for each size from a vector graphic. If you are just resizing your xxhdpi png into smaller one, you're probably doing the exact same thing that android is doing on the fly, so there will be no difference at all.
Yes, drawable xxhdpi was introduced in API 19.
If you want to run your app in a lower API level, you wont get any image because the system can't access the xxhdpi drawables.
This is also true if you only use only xhdpi with Android 2.3.
I'm not so sure there is going to be an image quality difference: even if you do provide the different versions of the graphic, they're likely just downscales of the original anyway. I'm willing to bet the difference between doing it at run-time and design-time is not going to be significant enough for a user to notice on a mobile phone screen.
I'm also not sure about a performance difference - however, even you admit that there is likely to be a non-zero negative impact. Given that fact, I think it's worth asking "Why not provide pre-scaled graphics?" There are tools (like the Android Asset Studio Icon Generator) that bring the level of effort required to make that happen almost to 0.
In mobile, any deal where you trade nearly 0 work for any potential performance enhancement is a deal you should take.
In addition to Stephane answer I must say that an image quality would be bad especially on mdpi devices.
Related
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.
I've read this question but am still uncertain of the value of different DPI targets.
Doesn't supporting multiple density images add to the .apk file size, whereas just using high-res images offers a solution for all screens (using automatic scaling)? There's still only one binary for users to install unless one limits the app to phones and tablets, so the smaller the file, the better.
Is downscaling of images dependent on hardware implementation and sometimes messy nearest-neighbour resampling is used, or can I be confident it'll be a bilinear resampling no matter the hardware, which is fine for photos? And is there a significant performance gain in providing suitably presized bitmaps?
It seems to me that the extra meg or two of asset files may be more cost than gain.
I was toying with the same thing myself. Eclipse makes it easy to add every resolution as you can simply add an Android Icon Set which automatically creates the right sizes for you, it makes the app a bit bigger. Apparently XHDPI is only supported from Froyo (API 8) so if you're going to support before that you need to include HDPI. Also older devices, the rescaling doesn't look as nice and it's slower but the new devices, there's no real difference. At the Google IO I recall them saying it's okay just to use the XHDPI if you're targeting at and above API 8.
I had an android app built especially for medium screen size android devices.
Now it was required to build that same app for a device called nook-color (by Barnes & Noble)
So for this we made all the images bigger & size & changed the layouts.
The result is that the apk which was 97.5 Mb earlier has now become 124 Mb in size.
Now the testers have complained that the application has become slower and it takes a little longer for any screen to open up. I am wondering whether this is due to bigger images or there is something else.
Can you please tell me what could be the reason for this.
124 Mb for an app seems to be a little bit excessive. I'd suggest trying to scale down the image assets, use Nine Patch images, as well as using PNGCrush
Yes. The delays are (at least in part) due to loading larger images (de-compressing them to bitmaps, to be more exact). Unless you can't help it, you should attempt to convert as many of these images to 9-patches : http://developer.android.com/guide/developing/tools/draw9patch.html.
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.
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.