I'm trying to detect my memory leaks.
After watching the video from Google and reading on StackOverflow, I'm starting to give it up because I don't find the issue.
My first Activity loads 4 images from resources (ImageView, for each one the width in pixels are not bigger than 400px), and I can find this on MAT (MainActivity):
then if I start the HomeActivity, this has more imageviews but all of them are short and small. So I load it and I get this:
but if I use regex with HomeActivity or MainActivity:
And this, are supposed to be my LEAKS:
I tried to not to set some images, delete an horizontalScrollView, deleting some items which could be a problem.
And I'm totally lost. Would you know what I'm doing bad?
Thanks in advance.
My first Activity loads 4 images from resources (ImageView, for each one the width in pixels are not bigger than 400px)
First, an ImageView is not a resource. It is a widget.
Second, the size of the ImageView is irrelevant by default when it comes to loading resources.
and I can find this on MAT
You are consuming ~26MB worth of heap for byte[]. If you expand that node in the tree you should see specific instances of this. If you find one of interest, right-click on it and examine its GC roots to try to identify what it is.
So I load it and I get this
This shows two specific byte[] at ~12MB and ~11MB each. Right-click on them and explore their paths to GC roots to try to identify what it is.
Would you know what I'm doing bad?
Not specifically. After all, we do not have any Java code, any resource XML, or anything much to go on.
If I had to guess, you added some large image files as drawable resources and are relying upon ImageView to scale them down to smaller sizes. That's fine, but ImageView does not reduce the heap used by the images themselves. That will be determined by the resolution of the image (width * height) and the bit depth of the image (usually 4 bytes per pixel for ARGB_8888). Resources are never released once loaded, compounding your problem. You can:
Scale the image yourself at compile time to something closer to what you will actually need at runtime, and/or
Use BitmapFactory and decodeResource(), with an appropriate BitmapFactory.Options instance and inSampleSize value, to load the image in more manually, downsampling it at runtime to consume less heap space, and loading it as a regular Bitmap (AFAIK, decodeResource() does not load the resource as an actual resource, allowing it to be better managed at runtime)
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.
For last 10+ hours I try to get a large (40+) amount of images (in ImageButton format) on a single Android screen without out of memory errors. The activity I work on is an image picker for a coloring book app. Images are of various sizes in the range of (500 to 1200)x(500 to 1200), PNGs (if that matters).
I have tried:
Horizontal Scroll View with images added from the code. The result is slow (I do it on UI thread) and consumes large memory space.
Horizontal Scroll View with images added from the code via AsyncThread. The result is fast but still consumes large memory space. I like the user experience of this one the most!
Grid View and List View - both are very choppy (testing on first Nexus 7). Memory usage is better.
What I am considering
View Pager - first results look better than Grid View from performance perspective (I have not completed it to the moment to assess the memory usage but it should be better from what I understand). Yet, I dislike the user experience and prefer a scrollable list of all images.
Conversion of my resources to JPG (will that get rid of Transparency byte?)
Downsizing the images to max 500x500px
None of the solutions seems as good as the Android Photo Gallery app available on all devices. This experience is what I would love to mirror. No idea how this is done though :(
Two questions.
What is the best way to get such thing (40+ Images scrollable on single screen) done? Is it really ViewPager? ScrollView with AsyncTask and well thought images resolution? Something I have not tried yet?
What is the memory limit I should try to keep below? Looking at Android heap size on different phones/devices and OS versions it seems to be 256 MB, is that fair assumption?
Thanks. Have a great weekend!
PS. On iOS all works like charm when I add all the buttons into a scroll view :(
Some basic calculations reveals your problem:
40+ images at 1200x1200 = approx 57MB, the comments are correct you need to subsample (i.e. thumbnail) the images or use a library such as the Universal Image Loader. Converting to JPG doesn't matter. That is a compressed storage format, the memory required to display the pixels remains the same.
There is a Android Developers article on Loading Large Bitmaps Efficiently with sample code. The following steps are covered in more detail in the article Android Bitmap Loading for Efficient Memory Usage.
The basic steps in loading a large bitmap are:
Determine the required size (from a known size or determining the
size of the target View).
Use the BitmapFactory class to get the bitmap’s size (set inJustDecodeBounds in BitmapFactory.Options to true).
Calculate the subsampling value and pass it to the BitmapFactory.Options setting inSampleSize.
Use the BitmapFactory to load a reduced size bitmap.
Actually I have for so long wish to know how to present graphics in a proper way.
In an activity, I have the following:
a background (png, full screen, 768*1280, 1.36MB)
3 icons (each icon has pressed and not pressed: 2 states, using 1 png 400 * 400, 300KB each), i.e. 3 icon * 2 pic * 300KB = 1.8MB
some more textviews
When the app starts off and directly goes to this activity, everything is ok, the activity can be presented properly.
Yet somehow when the app has run for some other activities, and then goes to this activity through a dialog box, then most of the time errors will occur, as follows:
Out of memory on a 15728656-byte allocation.
Question:
I have researched for sometime and some say to bitmap.recycle(), yet how to implement? through the onCreate? or actually 400*400 is too big?
If I want to change the background of an activity upon users' choice, i.e. when he presses button A, the background changes to bgdA, presses button B will change background to bgdB... in that way how that can be achieved?
Many thanks!
Depending on where your asset is stored is the amount of memory it might take, since scaling factor is calculated between the difference of densities, this is a little gray area because I haven't found any official android documentation that backs this info up, however I've seen that error so many times and this is the way I handle it.
1.- If you don't have the asset in the proper drawable-(density), this will cause problems because depending on the devices you are actually supporting, you should put the asset in drawable-xxhdpi or drawable-xhdpi, you will notice how the memory will decrease considerably
2.- If you don't want to mess with densities because it's a generic image which don't have much details(like a simple background), then add the asset in the drawable-nodpi folder, it will prevent android from trying to scale the asset it self..
3.- As good practice, try to create the asset with the proper size for the proper densities, 400 x 400 seems like too much for an icon, this will also prevent you from OOM, not only in this activity, but for other activities that might also need to load a good amount of assets, giving scalability to your app..
Always take on count that leaving the "resize" of an Image to the OS might cause huge amounts of memory allocated because the OS will try to resize it based on the formula width * height * 4bytes, the 4 byes are for ARGB of each pixel, 1 byte per color or alpha, so if your image is for example 1090 * 1920, it could easily become internally 8.3MBs even tho the actual image size is only a few KBs, and if it tries to scale it, it might double it's size too.
Hope this Helps
Regards!
Make sure you have a copy of your image for every drawable folder in you res, for example if you runnig your app on the S4 phone and you don't have all the images in the drawable-xxhdpi folder you will run out of memory even with reasonably small images.
Also if you need to change background at run time use setBackgroundResource.
Hope it helps
This is the common problem in android here is the proper solution
http://developer.android.com/training/displaying-bitmaps/load-bitmap.html
In easy words you have to scale the image down according to your requirement
My application use a little memory, it's about 3.4MB, in some old android devices such as GT-I9001. But when i running it in HTC one, my application use very more memory.
Look, the allocated memory is 26.881MB, it's too big, and the free memory only have 2.940MB. Then i use MAT tool check the memory leak, i find the resource bitmap use mach memory.
I can't explain the reason. My application often out of memory. I think Maybe the problem is caused by high screen resolution. If someone also encountered this problem, please join the discussion, thanks!
I debuged the problem, and found some reason:
The onCreate() function in my start activity, and you can see the breakpoint. The application only use allocated memory 3.4MB before calling the setContentView(R.layout.welcome) to load layout xml. Then the application run to next step, it use allocated memory 19MB. So i think this problem must be caused by loading the layout xml.
I modifed the "welcome.xml" file, deleted all widgets, that only have a "RelativeLayout"
But the program also use 19MB memory. Finally, i deleted the backgroud of RelativeLayout and the program memory return to normal size, it only use 3MB.
The size of pictrue "loading_background.png" is only 21KB, i think that perhaps the high screen resolution of high-end device changed the picture size in memory, i will try to use 9.png picture. If you understand this part of the problem, please join the discussion, thanks!
It's not a memory leak if you use big image for background.
File size doesn't matter. When it is loaded into memory it takes width * height of the image * 4bytes.
Use small 9-patch images or shape drawables when possible.
This problem can be solved using drawable-nodpi, look this:
Android background image memory usage
Just try to make a bitmap from 3MB PNG file. You will get a 20MB picture. That's why it's beter to convert your images from PNG to JPG. The quality is not so much different actually, but you will profit a lot from memory side.
just add high resolution images to the xxhdpi folder in drawable. this prevent android scale up the image to the ultra sizes
I am looking for a library or some idea on how I can load an image by parts from the disk or a url straight to the disk then in parts again to the ram. So the two ways I see that this can be done is loading the whole image onto the disk by reading and writing it from the url directly using the ram only for the buffer then when the image is on the disk some how creating bitmaps of only parts of the image, that way I DO NOT load it all and putting those in a ListView.
The issue is that I am dealing with extremely long images (10K + pixels long w/ a width of 4-600) and they hog up lots of ram if loaded all in one bitmap. I can not just scale them down like the Google android tutorial does in the handling large bitmaps section as that results in a width too small to deal with. So if I can somehow generate small bitmap slivers on the disk I can use them by loading them in a ListView preventing loading the image as a whole into ram.
Right now I am breaking the long images into slivers from a bitmap and I realized that that isn't really accomplishing what I am trying to do as the whole image is loaded into a bitmap in memory and is then broken up, then GC (So I am using up the full abmount of ram anyways). I am testing on a new top of the line android phone and the app works fine, but the heap size reaches 80mb+ with the larger images temporarily in ram as it breaks down the bitmap and this will be an issue with devices that have lower heap limits
You can try using this class, support from 2.3 http://developer.android.com/reference/android/graphics/BitmapRegionDecoder.html
If you are using Java you can work with InputStreamReader and OutputStreamWriter. Method read() accepts the buffer as one of the parameters, its length can be anything suitable. Of course you can create a new file for each buffer being written.
Is it what you're looking for?
edit
well its not. have you seen this Strange out of memory issue while loading an image to a Bitmap object ?
If you have control over the server from where you are fetching data, throw in another field in your response, such that it returns a thumbnail/smaller image. The server can then generate the required thumbnails for you, without you bothering about it.
Decoding bitmaps on the fly might be expensive, most of the times. If you can't change anything on the server, download and save the images, and after saving, generate their corresponding thumbnails and save them as well. In your list, use the thumbnails. Also, save the information about which images have been cached, and whose thumbnails you already have. This might look like a lot of work, but depending on the use case, this can be a better approach dealing with large images.
Problem with downsizing?
Well, you can come up with some kind of logic as to generate thumbnails, based on the original size of the image. For longer(vertically long images), you could use BitmpapRegionDecoder (http://developer.android.com/reference/android/graphics/BitmapRegionDecoder.html) as #Binh Tran has suggested.
Try maybe encoding the image to make the size small.