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
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.
I am developing a small tamagotchi for a school project and I have huge problems with the amount of memory the app is using. At first I had 200MB allocated to the app and after a bit of researching I got a easy fix to reduce it to 50MB by renaming the drawable folder into drawable-nodpi. But this is still way to much. While investigating the problem I'm sure that it has something to do with my Layout and UI-Elements because i deleted all my Code and launched my app only with the Layout and the memory usage didn't drop at all.
Here you can see my Layout:
The image-sizes are in average about 30kb and if I calculate the maximum size of possible images in the memory I have around 1.5MB.
So where does all the memory come from? How is that even possible?
If you want to see the app by yourself you can get the project from github:
https://github.com/kruben95/TamaStudent
I would be happy if someone can help me or give me some tips.
I downloaded your project, and here is some suggestions:
1) images are big resolution even if on disk they take 30-40 kb - in memory they are bitmap and bitmap takes a lot of memory, for example body part - 1200x1980 pixels with 4 bytes per pixel this is 9,5 megabytes in memory!!?? now after this bitmap got it must also scale it - this is additional memory, and as you see you have more then 10 megabytes per only one image!! this is extremely HIGH.
2) make images lower resolution. no need to display them so high res.
3) remove from images invisible parts - as i see very big parts are clear
but it takes memory!
4) try to make some images programmatically, like circles etc.
5) in code - don't use alpha for view if you only need to do background, set this alpha directly in color: #00FFFFFF - here is white color with alpha 0. If u use alpha on view it will take additional memory for redrawing (lower performance).
6) google internet for your related topics with tag Best practices and you will find a lot of useful information )
In my android app I want to show a background animation.
I had done it using images by changing the images with time.
But my problem by using images for each frame of animation the app size was becoming huge
I know it is not a good way.
I want to do it in efficient and good way.
If I am doing this by using images which is the best way. How can I do that?
Images are always a thing which uses more memory in android. If you are using images there no way by which you can make application to use lesser memory it will just use memory depending on image size, but there is a way which I follow. If background animation with images was a need then I would use optimized images. Optimization's like using images that suits the screen resolution, size and so on. Further more I would go with having different sized images for different screen resolutions so that size of images would be lesser for lesser screen resolutions. Hope that helps you a bit at least.
Edit :
Here under Using configuration qualifiers you will find about having XML files. You should use timer for that as you need to change the images at timely manner. If you don't want to use timer then go with this.
After searching a while I came to know about this (http://www.edumobile.org/android/android-development/frame-animation/) solution.
I understand that Andengine gives us option to scale our scene to any size screen that the user may have.
My question is if it would be better to develop for a larger resolution, say 1280/800 and scale it down for smaller screens OR to go for smaller resolution, say 800/480 and scale it up on bigger screens?
I did try to test this in a sample game by developing it for 1280/800 and scaling down (by ratioResolutionPolicy) to 800/480, and the results weren't satisfactory, there was stutter every here and there the framerate on the debugger though showed 60+. Is it bad programming on my part or does it have to do with the scaling down of the pixels, should I develop for smaller screen and scale it up?
I guess it depends on what kind of graphics you are using.
Say, for example, you want to create something in a retro-gameboy-pixel style, then it makes more sense to use small images and develop for a small resolution (like 480x320). Pixel graphics can be scaled up without loosing quality, but not down (then the pixels loose form).
But if you want high resolution graphics you are most likely better of developing the whole thing for a big resolution and let the AndEngine scale it down.
In both cases the quality of the pictures also depends on the TextureOption of your TextureAtlases as well.
Anyway, I can imagine that neither scaling down, nor scaling up is more efficient. Scaling is done by openGL and should go quite quickly. The downside of using big resolutions though, is that the device has to hold huge images in it's memory and the of course processing big images always takes more time than processing small images. So maybe the best way is to develop for middle-size devices (e.g. 960x640) ?
I know this isn't much help, unfortunately it is a lot of try and error to get the best results for your specific requirements.
christoph
To achieve good result on all type of android device you have two ways to follow from my perspective.
First, you have to develop and use two graphics to handle all the type of devices. For example one with resolution 1024x600 and other with 480x320. Based on device current resolution you have to load specific one type of graphics.
Second, you choose any single resolution that best suits to you and have great share in the market. Develop and use graphics only for that resolution. For other resolution scale that graphics based on aspect ratio. For this you have to create super class of sprite and change value of x,y,height and with based on aspect ratio calculate.
This was my experience that I share with you. If you have any doubt then feel free to ask it.
I am building a mobile application that will target iPhone/iPad and Android phones. The application will involve users taking photos and uploading to my server and later on the users will be able to look at those photos on their mobile devices (although not necessarily their own photos so an Android user might be looking at a photo taken with an iPhone).
Which sizes should I save the photos to be able to cover the most use cases? iPads are 1.333 W/H, most mobile phones are 1.5 or 1.333 W/H with some rare 1.666 W/H. Specifically:
iPad: 1024x768, iPad3: 2048x1536, iPhone and some other phones: 960x640, 480x320, 800x480.
To be able to keep it manageable, I need to decide on a few certain image sizes and save the photos in those sizes. I am not really looking for help on the technical side. I can do image scaling on the server side etc. I am looking for recommendations / best practices / lessons learned about image sizes before I go too far into building it.
Which sizes should I save the photos in to cover the most use cases?
Do you recommend any client side scaling before uploading to server to save on transfer time (for example scaling down 2048x1536 iPad photos) or should I always transfer originals?
How should I handle incompatible image sizes (showing a picture taken with an iPad on an Android device for example)? Should I pre-cut those images on my server before sending to client or should I let the client phone handle image resizing?
There is also the issue of UI. There will be other things on the page other than the photo maybe a button or two for navigation. Should I go for something smaller than the full screen size while keeping the same aspect ratio when saving pictures?
I know some of these questions don't have one answer and the answers are relative but I wanted to get some opinions. Thanks.
For Android, I think the best place for you to start would be here, it has a lot of information including standard screen sizes and how to display images while keeping them in the best possible quality.
http://developer.android.com/guide/practices/screens_support.html
I'd also suggest doing as much image manipulation as possible on your server. Images are a pain to work with on Android due to memory constraints and fragmentation. Two phones may store pictures taken the same way with different orientations, and there is no simple way to handle rotations, though it can be done (thankfully, I've yet to encounter a phone that incorrectly records Exif data, but I wouldn't be surprised if they existed...). The more you rely on the phone to do, the more chances you have for error due to manufacturers putting wrappers around and otherwise customizing how it handles media.
As for how to display, ideally if your back end is already doing a bunch of different resizes, you can include your screen density when you request the images and send the best size based on the dev guide. If you want to keep differences to a minimum, at least support med or high density for phones, and extra high density for tablets.
Just my two cents, I'm sure you'll have a lot of opinions. Good luck.
I don't have a full answer for you, but I do have some thoughts...
1) I'd suggest reducing the image sizes before uploading. If I were using your application and I had to upload a 4 meg photo, everytime I wanted to use your application, I'd probably pass. And as we venture forward, we're hitting much better technology in terms of camera phones; Nokia has released a 41 megapixel camera, which I'm guessing will create rather large images. Users having to download a 4-6 MB image is also not a great idea. Just some thoughts from a user point of view.
2) I wouldn't cut the images. You don't necessarily know what parts of the image aren't important, so how would you know where to crop it? Let the phone size the pictures accordingly and rely on the ability to zoom into pictures to see things at a larger size.
3) You could try to make a UI that hides buttons. If you have something really simple (like just going forward or backwards) you could rely on gesture controls (swiping) to move around your application. You can implement sliding drawers and menus that take up space temporarily, when in use, but give you the space back when you want to look at the main content (pictures, in your case). I've typically found that hiding buttons doesn't work well and people seem to want/search for buttons that let them navigate, but the Android gallery works just fine with menu + swiping only, so who really knows.