My android app will work for both normal and hdpi device. I don't want to create two sets of images assets for normal and hdpi screen.
So, could I just create image assets for hdpi only, and use them for both normal and hdpi device. Of course, the hdpi images will be auto scaled to fit normal screen devices. Is it OK? How much performance overhead will be caused by auto scaling hdpi images to fit normal screens?
Thanks.
The answer is "it depends".
If you are filling a listview of 10,000 items with images, then there will be a major performance difference.
If you are running a game engine with even fairly simple graphics, then there will be a major performance difference.
If you are making a custom button background scale, don't worry about it.
As far as simple UI's go, providing multiple resources makes it look better but doesn't really affect performance.
The real performance concern is with sprite scaling in games and other high framerate applications.
None. Do the scaling once at startup and keep the scaled image in memory.
You can generate performance statistics using android.os.Debug class
Start tracing by executing Debug.startMethodTracing() and stop it with Debug.stopMethodTracing(). File with the trace will be created on sd card.
Then you can analyze it using TraceView tool.
This should answer you how big is performance overhead of image scaling in your application.
In your position I would generate hdpi set of images and add it to the project.
Related
Apologies in advance for such a basic question, but this is my first app and I can't quite find a clear answer for my situation. All the images in my app are stored in the drawable folder, I'm NOT downloading any images from the internet. All the information I come across when it comes to multiple image sizes seems to refer to the occasion when the app is fetching images from the internet.
So currently most the images in my app are one size, customized for the largest size - xxxhdpi. However, I understand the app is doing some work to "shrink down" those images for the xxhdpi size screens.
I'm having second thoughts about this one size fits all approach. I'm thinking that perhaps the app doing the work to shrink the image down might take up extra memory and negatively impact performance. I've been looking at the Android Studio Profiler and I've been trying to understand the Graphics Process when I look at the Memory Graph.
More generally speaking, is there a benefit to having the smallest size images possible, even for the xxxhdpi? For example, does it hurt (memory wise or in some other aspect) to use a .png image when I could use a lower quality jpg? Again, just to super clear, this is just in the scenario when the app has all of its images in the drawable folder. My app has options where players can change the game background and other images so I want to be sure I'm optimizing how the images for best performance. Thanks.
Memory. If you load a bitmap of x by y pixels, in memory that takes 4*x*y bytes. For a full screen image, you can expext that to be 4000*1000*4 or 16 MB. That's a good chunk of memory to a small device, which also tends to have less RAM. If instead it needed one at half the resolution, you would have 2000*500*4, or 4 MB.
Obviously this scales with size. The smaller your images, the less memory wasted. I wouldn't argue that you need to provide every size, but if you're using large images I'd provide more than one. Also, for anything that isn't incredibly complex (like icons) I'd consider vector images instead (although that's a CPU time vs memory tradeoff).
You mentioned png vs jpg. There's two things to consider there: apk size and image quality. JPG is smaller, so it will lead to a smaller apk size. PNG is lossless, so it will have higher quality (although whether that matters requires a human visual check- it matters less than you'd think on a lot of things). Interestingly it doesn't effect the amount of memory used at runtime, because both are held in the Bitmap object uncompressed.
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.
Why do we have to provide images for all screen sizes when developing mobile applications? Wouldn't it be more efficient to just have 1 very large image for each unique image and then scale the image down whenever the app is being run on a smaller device? It would definitely make the game's file size much smaller.
In lots of cases, it wouldn't look as good.
If you find a set of well designed icons, you'll see that they've been independently designed for each resolution: the smaller ones will deliberately have less detail in, because downscaling just doesn't produce as good results.
Here are two GNOME icons, for the same thing, but one at 256x256 and one at 48x48. You can see that the 48x48 one has less detail in the writing on the letter, but the writing is also designed rather differently: on the 256x256 one it looks like the middle page of a document, and on the 48x48 one it looks like the opening of a letter, with an address at the top.
It would make the size of the .apk file significantly smaller, but it would have more undesirable tradeoffs for runtime efficiency.
Having to load large bitmap objects and scale them down is an un-necessary load for the device's processor. But more importantly, having to load large bitmap objects into memory makes the VM's memory fill up more quickly. This means that the VM has to do garbage collection more often, which can cause noticeable delays at runtime (this can cause animations to lose frames and look rougher).
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'm quite new to Android development. My understanding is that you can create several versions of the same image with different sizes and put them into the folders drawable-ldpi, drawable-mdpi, drawable-hdpi.
It seems obvious to me that you can handle this problem "the lazy way" by just resizing one image depending on the device's pixel density. For this I programmatically find out what density the device has, like ldpi. The implementation itself is not the problem. I'm just afraid of any drawbacks (that prevent me later from running the app on different devices).
So, are there any (major) drawbacks of scaling images automatically ?
In which of the three folders do I put the image so that the compiler can find it?
You would put the image in your regular drawable folder. That way any phone can find it.
While you can programatically shrink images, shrinking usually has the effect of reducing image detail and causing jaggies.
Adding in smaller assets will also reduce memory usage on smaller phones. Keep in mind that some Android phones are notoriously bad with memory (see: HTC Status), so any and all savings help.
I would recommend just photoshop scaling images down large images yourself. For smaller images, it is not as big a deal.
Android does auto-scale and it works fine in some cases, but it doesn't work for many, notably small images with important details like text. Scaling a larger image down blurs those details. Scaling a smaller image up is worse. This is why icons files have been multi-resolution since the very early days of GUIs. To wit, text scaling is hugely complicated. Ask any font designer, and note Adobe built a company on algorithms to do it automatically.
it's on mdpi folder. It'll change the size automatically. But is not recommended since the image quality drops.