One major issue with my application is crashing, which happens a lot due to the huge amount of content my app contains (it is a content-sharing site client). I get many memory errors, and I can be using up to 170-180 MB of ram, which is ridiculous.
http://i.gyazo.com/6cd53e6cf6f0a9bfdd6a24b323a70b09.gif http://gyazo.com/b64d50f76b2ef608954a6d6cdd5d52d0
Those screenshots are just from loading 25 submissions and scrolling through them.
My current setup is like so: LruCache with size of
(Runtime.getRuntime().maxMemory() / 1024) / 8
which handles all submission images. When I load a submission photo or thumbnail, it goes into that cache. Albums are handled by a simple ArrayAdapter and WeakHashMap store for bitmaps, because it is rarely called (maybe 1 out of every 25-30 posts contains an album). Gifs are streamed through GfyCat to a VideoView, no real crashes occur on gifs or albums. The real errors occur when I am scrolling, which is strange because I load the images into the LruCache all at once to save mobile radio time (battery improvements).
The issue seems to be that android is trying to possibly put more into the LruCache than it can, because I get errors like this
java.lang.OutOfMemoryError: Failed to allocate a 3169972 byte allocation with 1400991 free bytes and 1368KB until OOM
even though my LruCache size is 24576kb.
Am I handling memory correctly? What steps can I take to improve stability but keep the app speedy?
Thanks!
You can also even enhance the picasso further by use this configuration
Picasso.with(this)
.load(YOUR_URL)
.config(Bitmap.Config.RGB_565).fit()
.into((ImageView) findViewById(
R.id.frame_main_main_layout));
it will decrease allocating the memory and make the performance better
I ended up switching from the Ion image loading library to Picasso, and have saved 33% of ram usage with automatic caching, so I got rid of the LruCache and all my stores, now it's working better than ever!
Related
I'm using vectordrawable for displaying images. The images are all resources which are bundled with the app (apk). My problem is, that the memory on every new activity massivly get higher until the app crashes with an OutOffMemoryException.
java.lang.OutOfMemoryError
at android.graphics.Bitmap.nativeCreate(Native Method)
at android.graphics.Bitmap.createBitmap(Bitmap.java:903)
at android.graphics.Bitmap.createBitmap(Bitmap.java:880)
at android.graphics.Bitmap.createBitmap(Bitmap.java:847)
I've looked into MAT for memory leaks, but did'nt find out any more than the bitmap errors.
What are the efficients way to display vectordrawables? Maybe the general architecture of my app isnt right with the activity lifecycle?
I didn't find any informations about the common memory ussage of other apps (facebook, aibnb, whatsapp,..). My usage is around 40-70MB.
There are a few things to be careful about when dealing with images:
Are you loading your images every time when you show them? This can be a potentially very memory consuming operation. It's better to load the images into memory once and then reuse them across the app.
Are you cleaning the memory occupied by the images you no longer use? If you are sure that an image is no longer needed, you should clean the allocated bitmap memory by calling bitmap.recycle(). This invalidates the bitmap and frees all the occupied memory, making it available for other operations.
Are the images too large? There is a limit for the maximum size of a single image. Trying to load a bigger image will also cause an OutOfMemoryError, even though memory can be available. In that case, you may want to optimise the image files that you are trying to load.
Go though your app and check for those potential problems one by one. Also, there are good profiling tools available for the Android platform. They can show you potential problems with the memory management, like excessive memory allocation, etc.
Good luck.
I have been trying to fix a memory leak in my app for a long time, and I keep running into dead ends. The app is heavily image-centric, so I use the Picasso library to handle caching and memory use. I passed the high ram use (up to 100-170mb for my app) to bad memory management on Picasso's part, but I did some testing and disabled memory caching for Picasso, which loads all my images, and there was not a very noticable drop in RAM usage. It was still using 90 to upwards of 170 mb of RAM. I did a full heap dump into a hprof file and opened it with MemoryAnalyzer to see this:
http://i.gyazo.com/6b8d884852fa7cae546fc4cad1fc44c9.png.
If I go to Path to GC Roots, it shows no roots and no parents. There is no link to any of these over 50,000,000 bytes in these 25 massive byte arrays, and I really don't know where to start looking for the cause of it.
Do you have any suggestions on what the bug could be and any possible fixes?
Thank you very much for helping me out!
Try to use LeakCanary to find the memory leak.
Also, you can try Fresco for image loading & displaying, it stores images in the native memory region, so you won't use too much memory from the managed region, GC won't take too much time and you could avoid OutOfMemoryErrors.
Guess what, another Android-Bitmap-OOM question!
Background
Whilst stress testing our application it has been noted that it is possible to max-out the app's process memory allocation after sustained, heavy usage (monkey runner like) with OutOfMemory exceptions being recorded within the ensuing stacktrace. The app downloads images (around 3 at a time) when a page under a ViewPager is selected. There can be 280+ images available for download when the length and breath of the app is exercised. The application uses Picasso by Square for it's image downloading abstraction. Notably, at no point in our application's code are we manipulating Bitmaps directly...we trust that the very talented Square Inc. employees are doing it better than we can.
Here is a picture
The below plot shows the heap allocations over time recorded under the dalvikvm-heap log message. The red dots indicates a user bringing a fresh set of articles into the application in order to bolster the amount of work outstanding and stress the app...
DALVIKVM heap allocations http://snag.gy/FgsiN.jpg
Figure 1: Nexus One heap allocations; OOMs occur at 80MB+
Investigation to-date
Against a Nexus S, Nexus 4, Wildfire, HTC Incredible and a myriad of further test devices, anecdotal testing has shown the memory management to be sufficient with the DVM GC 'keeping up' with the heavy lifting work being completed by the app. However, on high end devices such as the Galaxy S II, III, IV and HTC One the OOM are prevalent. In fact given enough work to do, I would imagine all of our devices would eventually exhibit the failure.
The question
There is clearly a relationship between screen density (our requested image sizes are based off the size of the ImageView), the process memory allocation and the number of images at a given size that would result in the app exceeding it's heap limits. I am about to embark on quantifying this relationship but would like the SO community to cast their eyes over this problem and (a) agree or disagree that the relationship is worth making and (b) provide literature indicating how best to draw up this relationship.
It is important to note that if we destroy the image quality our OOM all disappear but alas the UX is poorer which is why we are wanting to be dicing with the most effective use of the available heap.
Side note: Here is the portion of code responsible for loading these images into the views that have been laid out;
picassoInstance.load(entry.getKey())
.resize(imageView.getMeasuredWidth(),
imageView.getMeasuredHeight())
.centerCrop()
.into(imageView);
The 'dashing of image quality' mentioned above is simply dividing the imageView.getMeasured... by a number like '4'.
First you need to manage the memories allocation ,its a big issue in android as bitmaps takes lots of memories ,for that memory allocation can be reduce by following ways
put all those images which are huge in size to assets folder instead of putting them in drawabable folder . because drawable resources takes memory for caching them .if you load from asset folder the image will not cache .and will takes less memory .
study Lrucache which use for efficient memory management .
put resources in tiny formats for that check TinyPNG
if your images are too large in resolution , then try to use SVG files for images and load SVG file instead of image . check this SVG FOR ANDROID
finally i am not very good in English hope it may helps you.
This post is a little old but I also had this issue recently. Maybe this will help someone else.
General Overview of this massive thread/What helped me.
-Make sure you are using a Singleton Instance of Picasso
-Use fit()
-For large Images or many Images or when used in a FragmentPager/StatePager you should probably use skipmemorycache() and/or largeHeap declaration
Read the thread for more tips. At the time this question was posted nobody had posted this issue on picassos github.
https://github.com/square/picasso/issues/305
This is one of the most asked question by beginners but still I couldn't get any help unfortunately. In an activity I have a viewflipper to which I assign imageviews with images programatically ( around 100 images added to viewflipper using for loop ). Might be due to image size or due to the large no of images I get OutOfMemory Error for bitmaps. My Questions are:
If this is because my drawables take memory space, is there any way by which I can release the space occupied by them?
Can garbage collection be the reason for this? If so what's the solution?
Since am using a viewflipper, is there any way by which I can only load my current, previous and next view of viewflipper? Will this help occupy less memory?
Please let me know if my question is confusing or is not understandable. This is an important topic to me as I am facing this problem in almost all my apps.
to avoid,aquire large heap using this in manifest:
android:largeHeap="true"
and almost all problem solutions are present on these links related to memory out of error,hope that one of them may solve your problem:
meomry-out-of-error
Memory Leak and Out of memory Error using List,LinkedList and HashMap
Memory Leak and Out of memory Error using LRU Cache
Memory Leak and Out of memory Error using Disk LRU Cache
Bitmaps are handled by native memory. This means that when the GC collects the bitmap's reference, the bitmap's memory is not immediately removed. To clear the bitmap's memory immediately, you can call bitmap.recycle().
As for the ViewFlipper, you going to want to find a way to manually unload and reload images as they are displayed to the user. Remember to use recycle(), and don't try to display a bitmap that already was recycled.
Hope this helps :)
Now what happens over here is every app in android is alotted a specific amount of heap size that is as little as 20mb
Bitmaps take up a lot of memory, especially for rich images like photographs
so whenever you load a heavy image or array of heavy images it exceeds the heap size and android automatically shuts down the app because it was using more than the allotted heap size
Read Documentaion
So whenever you are working with heavy images
Load a scaled down version
Asynchronously process the image
and then final display it in an imageview
To start, thanks for taking the time to look over my question. I am currently having problems with memory spiking in the application I am developing.
My intent is to be able to download and process large amounts of HTML data, currently the cause is from large base64 encoded images nested in the HTML which I understand is not ideal for use on a mobile platform. For the record, I am currently testing on a Samsung Galaxy S. Also, this problem does not occur on the Galaxy Nexus due to more memory allocation per application.
My problem is that while processing a large chunk of HTML data of approximately 2.8mb, the memory heap increases to around 27-29mb but the allocated memory never passes beyond 18-19mb. When the HTML has been processed, saved and displayed the allocated memory returns to around 3-4mb. If I was to then download and process this HTML again, the process repeats and I get the same memory use, except it seems to increase the heap further (which to me doesn't seem necessary), at this point I receive an Out of memory error.
When I do receive this error it is normally while downloading the HTML using HttpGet or while extracting the data from disk using a StringBuffer. Occasionally it is caused by a Bitmap during an XML inflation.
Any help would be greatly appreciated.
There is little you can do if you really need that amount of memory. Phones have limited memory.
Dealocating memory is not instantaneous. It might take several iterations to free all the memory (and each iteration might be executed a few seconds apart).
It's frequent to have problems with too much memory used by images/drawables. Some times it's a memory leak; other times it's not possible to say what is causing it.
I've also had problems parsing large xml files. My solution was spliting those files into smaller ones. Another possibility is considering the advantages and disadvantages of different xml parsers (first google result: SAX parser vs XML pull parser). Maybe using some thirdparty implementation specially developed with memory usage concerns? One third option is using a server to convert the xml file to a more efficient format.
The best practice is not to allocate lots of memory. Process the data in-stream as you're reading it from the network, or stream it to disk and then read from there. The android:largeHeap option is available on all devices running Android 3.0 or above, but that only increases the amount you can allocate not remove the limit altogether.