I am using 10 png images of size 20-30kb in imageView, but the allocated memory increases from 70mb to 270mb when this activity loads.
So why this too much of memory is allocated to these images.
This is the screenshot of memory allocation
This is one of my image
File size doesn't matter. No, matter your image is of 20kb but its resolution is quite big. When image is loaded into memory it takes memory equal to totalNoOfDotsInImageBitmap * 4bytes
and totalNoOfDotsInImageBitmap = width *height of image.
4 bytes - because of ARBG ( 1 byte per argument) for single dot of bitmap
so reducing width and height of image may solve your problem.
Depending on where you are putting the assets it may be trying to load a file that is too large.
For instance, if you have it on drawable or nodpi-drawable a device with a low density will try to load a potentially large image.
Also, bear in mind that the actual file size is not that important as it is probably small due to compression, but the image has to be converted to bitmap when it gets drawn, so if the actual size is too much that can also cause an OOM.
If you have access to the original I would recommend using a vector drawable (it's a simple shape so should be ok) and AS will generate the required PNG files for older versions.
I have to use large images (about 4000x3500 pixels) and to avoid memory problem im using the lesson found on the Xamarin site to optimize the use of such images (https://developer.xamarin.com/recipes/android/resources/general/load_large_bitmaps_efficiently/).
However the resulting bitmap seems to be bigger than the original jpeg. The jpeg is about 2MB while the bitmap size i get by AllocationByteCount is about 33000000 Bytes, is it normal ? Is there something i am missing ? (im new on mobile development).
Thank you
Searched and only find solutions for scale the bitmap to reduce its dimensions and size. But I am looking for a way to reduce the bitmap's memory byte count and don't change its dimension.
The images are from remote sources, they are not in our control. , after save the images to device locally, they will be shown as thumbnail later. Noticed it frequently throws OOM exception. The first step was to scale down the bitmap to a smaller dimensions when loading from the file (such as 500x500, or 300x300), here has some suggestions, which helps a little bit.
A closer look find the scale downed bitmap may still have large byte count (from a few hundreds k to over one meg).
Since for this case the bitmap with lower resolution in memory should be ok, so is there a way it can keep the bitmap's dimensions but reduce it memory byte count?
Thanks!
You can read it in as RGB_565 instead of ARGB_8888, to reduce the bit depth from 4 bytes/pixel to 2 bytes/pixel. However, that's all you can do, as the memory footprint of a Bitmap is the number of pixels times the bit depth per pixel.
I have a frame animation with 135 frames that should swap 25 times per second. The frames are 700X1000 pixels with 240 dpi. The problem I have is that whenever I define in the XML animation file more than 5 frames the application crashes. The frames are found in the drawable folder. I tried copying them to the drawable-xhdpi but this did not solve the problem.
Thanks,
Simon
Problem that loading images consumes all heap memory (memory that has your application avaliable) which is 32MB or 64MB. Images are loaded in on heap as Bitmap in ARGB - 4 bytes per pixel. Try to subsample animation images. Your animation has 135*700*1000*4 bytes = 360.5 MB.
You can use method decodeResource with BitmapFactory.Options opts that has parameter inSampleSize where you can set subsampling of image. Also parameter inPreferredConfig can be used to set RGB_565 instead of ARGB_8888 in case when you don't need transparency in images.
The error clearly says that you are trying to use more memory. This directly points to the image sizes. So, you need to resize your images to use lesser memory. One which can be used for this reason is BitmapFactory.Option. Or else go with manually resizing your images take care that it suit all your needs.
Heap size is the amount of memory allocated to an application to
execute.
The heap size for android applications are determined by the device
RAM. For example if the device has RAM of 179 MB, the android
applications will only get the heap size of 18MB.
Find about it more here. more on how to Load Large Bitmaps Efficiently is found here.
As the stack trace says, it's causing OutOfMemory error.
Since the frames are with higher resolution and no.of frames are also more, it's giving this exception.
I am joining two images using the code below but it throws an OutOfMemory error my images are around 1MB each.
private Bitmap overlayMark(String first, String second)
{
Bitmap bmp1, bmp2;
bmp1 = BitmapFactory.decodeFile(first);
bmp2 = BitmapFactory.decodeFile(second);
if (bmp1 == null || bmp2 == null)
return bmp1;
int height = bmp1.getHeight();
if (height < bmp2.getHeight())
height = bmp2.getHeight();
Bitmap bmOverlay = Bitmap.createBitmap(bmp1.getWidth() + bmp2.getWidth(), height,
Bitmap.Config.ARGB_8888);// Out of memory
Canvas canvas = new Canvas(bmOverlay);
canvas.drawBitmap(bmp1, 0, 0, null);
canvas.drawBitmap(bmp2, bmp1.getWidth(), 0, null);
bmp1.recycle();
bmp2.recycle();
return bmOverlay;
}
Update: I tried below two answers but it still not allwoing me to create bitmap of such big size the problem is that the resultant bitmap is too large in size around 2400x3200 so its going out of memory.
How can I join large images without running out of memory?
Without loading the image into memory, you CAN get the size of the image, using inJustDecodeBounds. The Bitmap returns null, but all the parameters are set. You can scale down the image accordingly.
If your JPEG images are 1 MiB each, conversion to a BMP will take a lot of memory indeed. You can easily calculate its BMP equivalent by the dimensions of the image. Conversion of such a large image is expected to crash indeed. Android limits its apps to 16 MiB VM only.
Also use RGB_565 instead of ARGB_8888.
So your only solution is:
(a) To use BitmapFactory.Options.inSampleSize to scale down the image
or
(b) Use Android NDK where the 16 MiB limit isn't there.
I use this simple rule of the thumb:
the heavy lifting (both memory/CPU) is done on the server.
So write some servlet that takes the image, resizes it to a specified dimension (probably reduces the pixel depth too) and returns the result.
Piece of cake and it works on any mobile device you need.
Good luck!
I think a solution sort of like Sumon suggests might work.
Figure out the size of the final
image based on what will fit on the
screen.
Get the size of the first image using
the inJustDecodeBounds technique.
Figure out the size of the first
image in the final image. Calculate
re-sizing parameters.
Resize image, loading into memory.
Write resized image back to disk.
Recycle the bitmap. (This will help
when resizing the 2nd image)
Repeat for the second image, only you
can skip the writing to disk part.
Load first image.
If you only need to display, then just do that. If not then you can combine into a single bitmap at this point and write to disk. If this is the case, it may be difficult because you wil have essentially 2x the screen size in memory. In that case I would recommend resizing smaller. If you can't go smaller, then you will have to go the NDK route, thought I'm not sure how much that will help. Here's an amusing intro to the NDK and JNI. Finally, I would highly recommend developing this using a phone running Android 2.3+ since its use of heap-allocated bitmaps will make debugging much easier. More about those here.
It's not necessary that the space taken by in-memory representation of bitmaps correspond closely with file size. So even if you have 3mb memory available to jvm, you might still get OutOfMemoryException.
Your code is creating three in-memory images simultaneously. If you can find the size of both images without reading the complete files, you can modify the code in a way to have only one of the source images in memory at a time. If even that doesn't prove to be sufficient you might need some sort of streaming method of reading the images.
you may get some idea from here.
Are you trying to display this super large image or are you just trying to save it?
If your trying to display it. Cut the images into tiles. Then only display the tiles that are being viewed. If the user zooms out you need to reduce the size of the bitmap before showing the whole thing.
If your trying to save it, try saving it in sections to the same file by cutting the image up.
Loading 2 1m files in memory then creating a 2m file leaves you with 4M in memory for your images alone. Dynamically loading and unloading the memory solves this issue similar to tiles on Google maps or dynamic zooming in other map oriented solutions.
If you need to return that huge 2400x3200 bitmap as your result, there is no way to actually realize this goal. The reason is that 2400*3200*4 bytes ~ 30 Mb! How can you hope to implement this method, when even you can't even fit the return value into your limited heap space (ie 16Mb)?
And even if you used 16-bit color, it would still fail because you would end up using about 15MB, which would not leave you enough space for the language run time.