I am trying to understand the reason for having multiple image sizes. I know there are different size screens with different densities, but wouldn't it be acceptable to just have the largest resolution image and load it to the size you need rather than have lots of different images?
Scaling an image takes considerably more processing power than just loading a pre-rendered one. Also, a naive/simple image scaling algorithm would look pretty low quality compared to one that had been actually properly rendered at the right size in the first place.
You could, I suppose, but what about
Bandwidth
Size of original image
Computational overhead
You are right it is acceptable.
As always this is just about trading speed for disk space.
You decide if you increase the size or have your graphics resize at runtime... it depends on your usecase.
It is because you do not have to be processiing a long file over and over again, imagine lots of visitors onto your site all of them requesting the same image they have different resolutions is better to have different images instead being processing the largest image to have a new one for each request, this is because of performance on the server side with an important concurrency in your site this may carry issues for the Heap Space you must care about data process performance. some times you have to choose in between resources Heap Space, Processor and DataSpace.
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.
Does android want that we put different version of an image (for different dpi) to avoid resizing-artifact because their scaling algorithm is not quality-efficient (to be fast i think) ?
But anyway, it's obvious that android will scale all image just for maybe some pixels, so, resizing-artifact does ONLY appear when we do a big resizing ?
Through this questions , i want to understand the utility of putting different size of image and why we don't just put a big resolution image and let android scale down every time.
(I have also a suppositon that i want to confirm, maybe the algorithm take more time when the scale factor is important)
Thx.
If you put the highest quality images in your app, your app consumes more memory (RAM) and if the device has less memory than your app freezes more frequently. This will not provide a good user experience as we all want that our app should be smooth in performance.
Besides all, I had also tested that if we put larger images and try to display them, Sometimes the app also crashed by giving an error of out of memory.
If you want to only place one image in your app to reduce the size of your app than I advise you to do it with .svg images. These images are scalable and the CPU does not have to do extra processing to display them.
I hope it will help you. Thank You
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 would like to get advice, pros and cons, about using different resolution graphics or resize them with dip size.
I mean, if my ap will have all possible resolution, one way is to create the pngs for each one, ldp/mdp/hdp/xhdp, but I am thinking that to save work and time maintaining the app, maybe is easier, to include pngs with maximal resolution, xhdp, and to specify the size well in the .xml or in the .java with dip or relative size depending on the screen.
What is your opinion on that? Pros and Cons?
Regards,
Cons (against having only one size): Unnecessary use of memory.
Images are memory-hungry objects, and when you multiply its resolution twice you multiply its memory cost by 4.
Low-resolution devices are likely to have less memory as well and loading unnecessary big images could cause memory exceptions.