I'm currently facing several performance issues (out-of-memory) when handling a vast amount of bitmaps. As this is just a problem that can be fixed I'm wondering if anybody can explain me the difference in using the following methods.
If I only want to load an image into an ImageView I usually use:
imageView.setImageDrawable(getResources.getDrawable(R.drawable.id));
If I want to sample the drawable beforehand I usually use (here without sampling):
Bitmap bm = BitmapFactory.decodeResource(getResources(), R.drawable.id);
imageView.setImageBitmap(bm);
My question is related to performance optimisation. I'm wondering whether it is better to provide as many drawables as possible using the different drawable folders (so these drawables nearly fit the required resolution for the different devices) or if it is better to sample high-quality drawables? What is setImageDrawable doing internally? Does it decode the resources using the BitmapFactory, just without sampling? There seems to be a trade-off between the actual size of the app and the cpu- and memory-load during runtime.
if you're concerned about apk size, then having as many drawables as possible is not the ideal way to go. but dont forget, when you decode a bitmap, you can pass a sample size so it will scale down to the screen size and only give you the pixels you need, so older phones with smaller screens wont need to decode 8mp images.
check BitmapFactory.Options and here
Related
In my app I'm generating a bunch of Bitmaps at runtime to show in a GridView. The generated Bitmaps consist only of rectangular shapes and about five different colors.
If I make them big, they get scaled down nicely, but I get OutOfMemoryExceptions. But when I make them small, they're not scaled up to fit the column width. I think ImageView can't help me, because it doesn't know the final column with. Setting stretchMode to columnWidth in the GridView didn't help.
Setting adjustViewBounds to true on the ImageView helped with large Bitmaps, but it doesn't help for upscaling.
Is it somehow possible to scale the ImageView with the underlying Bitmap to the maximum column width of the GridView? This would be my preferred solution.
If not, can I determine the columnWidth of the GridView in advance to just generate the bitmap accordingly? (I don't like this solution that much, because I suspect that on devices with large screens I might run into OutOfMemoryExceptions again.)
You have two choices.
METHOD 1:
Optimize your images by using any online image compression sites . For example https://tinypng.com .TinyPNG uses smart lossy compression techniques to reduce the file size of your PNG files. By selectively decreasing the number of colors in the image, fewer bytes are required to store the data. The effect is nearly invisible but it makes a very large difference in file size!
METHOD 2:
Load your images using third party libraries like Universal Image Loader, Glide .. these libraries aims to provide a powerful, flexible and highly customizable instrument for image loading, caching and displaying. It provides a lot of configuration options and good control over the image loading and caching process.
Since you generate the bitmaps in your app, you can use libraries like Picasso to display them. Picasso will handle the memory on your behalf and you need not worry about OutOfMemory Exceptions.
I've seen the blogpost about how android handles drawables and how to save memory using mutations, creating different constant states.
Lets say I have a bitmap pic1.jpg which I use it in some part of my app and I have a ScaleDrawable that scales down the resource pic1.jpg.
Q1: Will they share the same constant state?
Q2: Will android load 2 images in memory (pic1 and the scaled version of it) or just pic1 ?
Q3: Is this better, regarding loading performance and memory consumption, than having 2 resources with different sizes?
Update:
ScaleDrawable doesn't seem to be working, at least I've tried it out and the drawable is not shown.
Firstly I am aware of the recommended approach of using inJustDecodeBounds and inSample size to load bitmaps at a size close to the desired size. This is however a fairly broad approach that only gets an image approximate to the target.
I have though of utilising options.inDensity and options.inTargetDensity to trick the native loader into scaling an image more precisely to the desired target size. Basically I set options.inDensity to the actual width of the image and options.inTargetDensity to the desired width and I do indeed get an image at the desired size (aspect ration happens to remain the same in this case). I then set image.setDensity(DENSITY_NONE) on the resulting image and all appears to work OK.
Anyone know of anything wrong with this approach? Any thoughts on memory efficiency and image quality?
I have always got better image management with Opengl 2.0 and surface views.
Sounds brilliant to me! (Can't believe android devs wrote the code but didn't expose the functionality in a sane and sensible way).
I do have one concern. I have good reason to believe that Android is unable to deal with instantiated bitmaps that are larger than 2048x2048 pixels in either dimension. If the internal code to do the rescaling isn't sufficiently intelligent, it may fail when loading bitmaps larger than 2048x2048.
I was thinking about this my self, using inDensity and inTargetDensity to scale up/down bitmap on decode. It works well, but unfortunately it yields very bad performance (animation) results. I was hoping I could use this as a "universal" aproach to scale up/down on decode, similar to inSampleSize which is unfortunately only for down sampling. Seems like there is different native implementation: inSampleSize performs well, no obvious performance impact, where inDensity/inTargetDensity introduced noticable performance impact (like slow motion).
Or am I missing something?
I have an application that displays lots of images, and images can be of varying size up to full screen dimensions of device. The images are all downloaded, and I use imagemagick to reduce colors of image to compress the file size, while keeping dimensions the same, to reduce download time. The reduced color space is fine for my application.
The problem is that when I load the image into a Bitmap in android the file size is much larger because of androids Bitmap config of ARGB_8888, I do need the ALPHA channel. Since ARGB_4444 is deprecated and had performance issues I am not using that. I am wondering if there is any other way to reduce the memory footprint of the loaded Bitmap while keeping the dimensions the same as the original?
---- Update ---
After discussions here and lots of other searching/reading it does not appear that there is a straight forward way do this. I could use ARGB_4444 which stores each pixel as 2 bytes, rather than 4 bytes per pixel. The problem there is that ARGB_4444 is deprecated, and I try not to use deprecated parts of the API for obvious reasons. Android recommends use of ARGB_8888 which is the default, since I need alpha I have to use that. Since there are many applications that do not need such a complex color space it would be nice to see ARGB_4444 or something similar become part of the supported API.
If you don't need alfa (transparency) you can use:
Bitmap.Config.RGB_565
which uses 2 bytes per pixel, instead of 4, reducing size by half.
You should also look at BitmapFactory.Options:
inSampleSize
inScaled
These values correctly set for your requirements, may have a very positive effect on Bitmap memory requirements.
Regards.
Read a similar answer I posted here
Basically, bitmap recycle is required for Pre honeycomb devices to reduce memory usage
I'm working on an image processing application for Android that recognizes music notation from pictures taken of music sheets.
I tried to load the entire image into a Bitmap using the BitmapFactory.decodeFile(imgPath) method, but because my phone doesn't have enough memory I get a "VM heap size" error. To work around this, I'd like to chop the full image into smaller pieces, but I'm not sure how to do that.
I also saw that it was possible to reduce the memory size of the Bitmap by using the inSampleSize property of the BitmapFactory.Option class, but if I do that I won't get the high resolution image I need for the music notation recognition process.
Is there anyway to handle this without going to NDK?
Android 2.3.3 has a new API called android.graphics.BitmapRegionDecoder that lets you do exactly what you want.
You would for instance do the following:
BitmapRegionDecoder decoder = BitmapRegionDecoder.newInstance(myStream, false);
Bitmap region = decoder.decodeRegion(new Rect(10, 10, 50, 50), null);
Easy :)
If it's from a camera the image will likely be jpeg format. You could use an external jpeg library - either in java or via the NDK, whatever you can find - to give you better control and load it a piece at a time. If you need it as an android.graphics.Bitmap then I suspect you will then need to re-encode the subimage as PNG or JPEG and pass it to BitmapFactory.decodeByteArray(). (If memory is a concern then do be sure to forget your references to the pieces of the bitmap promptly so that the garbage collector can run effectively.)
The same technique will also work if the input graphic is PNG format, or just about anything else provided you can find suitable decode code for it.
I think that by loading the image piecewise you are setting yourself an algorithmic challenge in deciding what parts of it you are really interested in the full detail of. I notice that BitmapFactory.Options includes the option to subsample, that might be useful if you want to analyse an overview of the image to decide what regions to load in full detail.
If you're dealing with JPEG images, see my answer to this question as well as this example.
I don't know how possible it is to get libijg on Android, but if it is, then it's worth a shot.