I have a problem: (I wouldn't be here otherwise ;)
I am creating an app that has a feature for displaying "3D" models. This part is really a collection of images taken from many angles and allows the user to "rotate" the "model".
This idea is working fine, but the problem lie in the loading of the images.
I have found that there are two ways:
Load all the images into memory, and then simply switch them for the correct angle.
Load the images as we need them - we can load a few ahead of time.
However these have problems:
If I was lucky, the images would fit into memory, but they don't. They are about 1.5-2MB each and there are about 75-100 images per model. This brings the total size to about 115MB at the minimum.
If I was lucky, the image would load quicker than the user could "rotate", but they don't. The user can easily switch to an angle that is not loaded yet, resulting in a black screen for a few seconds.
I have created a loader that allows me to simply add the images that I need to a stack and the loader will then one-by-one load the images. This works fine if the user scrolls fairly slowly. My loader takes care of releasing memory when it is finished, so no matter how many images I load, the app usually won't crash as long as I specify the max images to store in memory. My loader can load the images very quickly, but there is still a few milliseconds (~250ms) for it to load the large image into memory.
Of course, the loader is on a different thread, and the loading in no way hinders UI response. That is why if the user swipes back and forth quickly, no image will actually display, as the loading and unloading are all working at the same time to result in no images :)
So, my problem: How do I provide a smooth and user-pleasing rotation of the images without loading all the images into memory?
Don't load (or store) resolution you don't need. If your user needs to zoom, an out-of-memory binary image pyramid is a cheap way to let you load only the level of zoom necessary. If your user needs to pan through an image larger than your display area, you can break your large image into smaller tiles, and only load the ones you need.
If you want to get fancy, you can write a UI-aware cache manager to preemptively load tiles you think you might need soon, and mark tiles you're pretty sure you won't need soon for preemption.
Better compression can fit more image data into memory, and speed up load time. So, pay attention to individual image compression, and don't load image quality you don't need, either.
As an extraordinary measure: since images from slightly different angles are similar to each other, you may be able to save time and space by representing the difference, instead -- look up lightfield compression. You will still need to convert from compressed form to a particular bitmap you can draw, but if the compression allows the dataset to remain in memory, you could potentially gain a lot of speed.
If you can't fit your compressed dataset into memory, there's a good chance the user will be able to swipe back and forth quickly enough to defeat your cache. So, if smoothness is your main goal, you could try for a "UI solution" by restricting the rotation rate (or the per-swipe rotation range?) to something your data loader can follow.
My only suggestion is for loading them efficiently. I assume that you are using techniques described here
If the images are of higher resolution than the screen you can calculate the sample size of the image you want to render then you can load an image that fits your screen rather than the full size image which will use much less memory. If you are already doing that then to me it seems like how you are doing it efficiently already. Perhaps you could show the user some kind of placeholder graphic while an image is loading so they won't just have blank space.
Thanks for the answers. I laughed at myself and then went to bed after reading the answers.
Let me share how I resolved this problem - it uses some pieces of the answers:
I was trying to cache the large images in memory - this is unnecessary, why not store a lower res version and then load the hi res when the user stops scrolling? Then the user can scroll as fast as he likes and there will always be images in memory to quickly paint. When the user stops/slows scrolling, we load the hi res image.
Because he will be scrolling fast, he won't be able to see the lower res' lower quality.
And, as there will only be one hi res to load, the ~250ms delay is hardly noticeable.
This really combines the best of both cases. And I can use the Android's methods for loading a lower res version of the Bitmap.
Related
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
So, I've been researching on bitmap scaling using the bitmap factory.
http://developer.android.com/training/displaying-bitmaps/load-bitmap.html
I'm doing so because the application I'm working on requires a gallery that allows users to submit their photos to be added to the gallery. These photos will then be read from a URL.
My theoretical problem is this: Considering the android devices can have as low as 16MB of memory, even scaling down the images is only delaying the inevitable unless only handling a single image. Whereas in my case, the amount of images that will be loaded could be hundreds. Meaning that even if they're scaled down, eventually one will reach that limit.
My only idea thus far are to load one image at a time, which is not preferable since users will have to wait between photo transitions.
That being said, is there anyone who has experience developing applications on android that handle 100's of images? If so, is there any theory you could share on handling all these images fluidly? It can obviously be done, as there are gallery applications available. I am just unsure how they accomplished it given the restraints.
Please note this is not a request on how to use the bitmap factory to scale images, as that question has been answered many times.
Rather a request on handling data amounts you know will exceed limitations.
The gallary apps should not be storing all thousands of images in memory. Use the Viewholder pattern such that the image views displayed will get recycled (this is forced upon you if you use RecyclerView). On backend use an image cache and keep a limit on it size.
See e.g. What is the benefit of ViewHolder? and How to release memory of bitmap using imageloader in android?
The Android gallary app source may be a good reference: https://android.googlesource.com/platform/packages/apps/Gallery/+/android-5.1.1_r18/src/com/android/camera
I am developing an android application. I have a custom view which is a functional circular progress bar. It has 12 circles uniformly distributed over a bigger circle.
Since the design is simple and geometric I can achieve the desired results by having a one small circle and rotate it around the center. That will cost me one file on disk, one bitmap on memory - which is kinda small, around 300kb on memory- and some amount of cpu power on rotating and drawing the bitmap.
Another option come to my mind is that I can have all 12 images ready on disk, load all of them on memory, and draw the appropriate one each time. This option doesn't have rotating overhead.
Now my question is, which one is more viable/reliable in general, and specifically for android. You can assume 10 fps is more than enough. And if you think it wont make a noticeable difference please let me know.
I'd rather have 1 image and rotate it at runtime. That isn't too costly an operation, and loading N bitmaps into memory can take up a bit of memory, which apps are already hurting for.
In general. I prefer having minimizing my resources as much as possible. Rotating a small bitmap like that won't cost too much power and packaging 12 of those (12*300kb) is a considerable increase in app size. However, you have to consider this in relation to your overall app size and requirements. If you need to minimize size, rotate it and if not, load them all into your app.
I am working on a wallpaper app. I have all my images stored in Drawable folder.
I am getting OutOfMemoryError when I add more than 30 wallpapers. I want to know how to overcome this.
Should I save all my images in SQLite Database and then load from there or should I have to do something else.
I have tried resizing bitmaps through Decode Bitmap Factory but it did not serve my purpose as the quality of images is reduced.
Resizing images at decode-time will only move your OutOfMemoryError ahead in time. That error means that your application leaked memory, or tried to use more memory than the available one. When working on bitmaps on Android, this happens quite often, because the limit is set around 25MB, and high resolution screens are increasingly common.
You have to redesign your application. There's no need to keep 30 images in memory, because they can't fit in a single screen - well, if they are thumbnail-size, you resize them all when you decode, and the total number of pixels in memory is the same as a single big picture, so you don't run out of memory.
You have to find a way to recycle() bitmaps when they are not visible. If you better describe your application, we can help you find the appropriate moment, also to preload images to have a responsive application and a better user experience.
I think what you need to do is display Thumbnails instead of drawable image on your screen. You can generate Thumbnails and display as per your size requirements. And whenever user click on Thumb, just take original path and set wallpaper.
Another option is you can use Universal Image Loader which helps you to buffer your image in disc (like SD card or your application's Internal memory). So issue of Out of Memory can be resolved.
If you want to control the crash of your Application then write your code in Exception block:
try {
...
}
catch(OutOfMemoryError error) {
//decide what to do when there is not more memory available
}
Also please the this link:
link
I have a ListView where each cell contains a bitmap that is downloaded from the internet. To avoid out of memory errors I was wondering what the best way is to deal with this.
I have looked at softreferences for the bitmaps but I was wondering what happens if I am in the current activity and the the application begins to run out of memory. How does it decide what bitmaps to recycle?
Is a better way to write the file to disk and load it into memory when I need it? Are there any examples?
Thanks
I dealt with that a while ago. Experimented with performance too. Here's what I got.
This answer is beyond lazy loading of images because it deals with performance.
First of all: Forget about SoftReferences on android. Very bad for caching because of misbehavior (released to soon). I ended up using LruCache (source for API < 12) with a fixed byte size for the cache.
When loading images through network you want to persist the loaded images (in private app data folder or SD card). Otherwise the user is forced to load (unnecessary) data on every app startup. Here's the routine:
image is requested
check for image in memory cache (jump to 6. if available)
is persisted locally (jump to 5. if so)
load from network and persist
load bitmap into cache
load bitmap from cache into view
Now some words for performance. If every list item has another image and they have a fixed size (e.g. 40 x 40 dip) you would waste cache memory when loading full images (e.g. 800 x 600 px) and your device would have to calculate a lot for scaling.
First solution is to prescale the bitmap on step 5. before loading image into cache. You'll get the best performance when you persist the scaled image and load it next time.
You can find an example in my CoverCache helper (CD covers - but can be used for any kind of image data). It deals with persisting, scaling and caching images at the same time.
There is a lot of implementation of a list view with lazy loading of images with reuse of the views via the convertView mecanism. For example, take a look here : Lazy load of images in ListView
There are quite a few solutions there.