I created an app in android studio that plots a graph(using mp android chart) from the data received from a source. Here's the problem: when I try to plot the data at high frequencies (like 150hz plus) the app slows down and then crashes. At lower frequencies it can keep plotting for as long as I like so I know its not running out of memory. Maybe it needs a minimum amount of time to clear its memory? Is their anything I can do that can help me clear the memory when I want?
You can call System.gc() manually to invoke garbage collection, but Android will still kick in a GC when you are running out of memory.
Note that a garbage collection can easily take 100ms and when you have a refresh rate of 150hz you only have 1000/150 = 6.667 ms for your calculations together with garbage collection. So your first step should probably be to check your object allocations and try to minimize those. (in fact, in your methods which are called every frame you should have no object allocations at all)
Related
I have some memory problems about my android appwiget,
(It's small toy appwidget based drawable animation repeat)
So I watched my memory viewer in Android Studio.
I found my app's memory increased at initial time, but when it doesn't enough memory it automatically release some memory.
I want to know what android function make this.
Can I control this release function with java code?
*I tested at real device android ver 4.42
You are talking about Garbage Collection, which is the process of removing from the memory the objects that are no longer required. You can have a good idea of how it works in Java here.
In Android (and Java in general) you can suggest the virtual machine to do it with the System.gc() call. Note, though, that it:
Indicates to the VM that it would be a good time to run the garbage collector. Note that this is a hint only. There is no guarantee that the garbage collector will actually be run.
I have two problems:
1.What is trigger conditions of LOW_MEMORY and OUT_OF_MEMORY in android memory automatic cleaning mechanism?
I check the reference LOW_MEMORY is done automatically every once in a while, and OUT_OF_MEMORY is conducted in system out of memory. Is this right? If it is right, is the recovery of memory strategy the same？
2.What conditions perform memory of the recovery in android task manager？
The detail condition is testing phone memory 512; the user available memory is 230. The visual inspection is 50M. It can trigger the memory recall in 20M. That is to say 50M and 20M are the stable memory. But sometimes it has not the trigger recycle when the memory less than 3M.
Is the trigger recycle need special condition? Where the trigger recycle code should be put?
In android is each application has fixed memory limit.. it change from device to device... for ex if phone memory is 512.. and app memory will be 30 to 50 mb if your app cross using this memory it will get crash...
onLowMemory is the method in the activity.. it notifier when memory is low... it is like warning .. OUT_OF_MEMORY is exception which you cant handle(catch)..
OUT_OF_MEMORY exception max raise normally when we deal with bitmap...
Garbage collector is available in android also but when we deal with bitmaps it may fail in some cases.. for bitmap we are responsible to recycle..
I'm developing a videogame in Android using OpenglES. But I'm having a problem with the main game loop or the renderer, because the game lags every 3 seconds (more or less) and I don't know why. The only thing I know is that it happens all the time, no matter what is going on in the game.
I have a main loop in where I call the gameInput, gameLogic and gameRenderer. When I call the gameRenderer, I wait until it finishes to continue... There are 20 fps every second.
Have this happened to anybody? Or do anybody have a clue about what's going on?
In theory if it's garbage collector you can pass something like this -Xms2G -Xmx2G (heap size) as VM arguments then garbage collector will not run before VM eats all 2G so lag should disappear and you will know that it is garbage collector problem.
Do you use java, right? It look like garbage collection. Try to disable parts of code and check if lag disappears. You can localize place where problem occures.
Also if you use Eclipse plug-in has DDMS thing. You can use Allocation Tracker from there to see which objects are created and how many of them.
I am working on a cannon game for Android, which requires procedural generation of levels. As the player flies through the air, new sections get added on to the end of the level to keep it going indefinitely. As those sections are added, sections that the player has already passed are deleted. The problem is that the creation of a section usually leads to a GC_FOR_ALLOC, which pauses the game for around 30ms and causes noticeable lag.
The free memory stays fairly consistent, as objects are deleted while others are added, so there doesn't seem to be a memory leak.
The engine I am using is the cocos2D-android-1 port from iOS.
I saw many solutions along the lines of "don't initialize things while the game is running", but the nature of the level generation requires this, since an indefinite-length level can't be created right at the start of the game.
Thanks for your help!
You are not very specific. If the lag is too big, you must try to reduce it.
One way could be to collect more often - resulting in shorter, but more often occurring pauses.
For example you might create smaller or only partial sections and try to nudge the garbage collector afterwards to run. You would use System.gc() for this. But be aware that System.gc() is not guaranteed to result in it actually starting to run.
An even better solution would be to reuse objects. Objects that were created before the level was started. This way even an endless level would not result in any garbage collection since no garbage accumulates. But be sure to not create any non-pooled objects!
my android application works well but it's performance(speed) is slow. In my logcat i saw frequent garbage collection operation like
11-02 15:07:20.647: DEBUG/dalvikvm(12571): GC freed 295 objects / 38448 bytes in 93ms
Is this the reason for low performance?? How can i improve my applications performance???
anybody please help
If you use the emulator don't worry - it is slow by itself. GC is not responcible for this i think, 93 ms is time you won't even notice. So try your application at the real phone and if there are preformance issues - use the profiler.
Your application performance in terms of user interface and memory is quite related.
In this case 93ms means that your device could be dropping about 6 frames in the ideal scenario. If the GC is executed often this could be a problem.
The Android ART/Dalvik virtual machine is a version of the Java Virtual Machine where the Garbage Collector implementation is based on generations. This means that your application process has a heap associated separated by different generations where the GC is going to act once a generation is full. You can think of these generations as buckets or arrays of memory.
Once a generation is full the Android virtual machine will start the garbage collector process. As the Android virtual machine can not collect and fragment your application heap while the app process is running the garbage collector event will stop all the threads in your app while the garbage collector is working. That's why your application can be dropping frames if the app garbage collector is invoked so repeatedly.
Here you have an example:
Last week I discovered my app was leaking memory. I discovered this because after 20 minutes using my app I noticed the UI was performing really slow. Closing/opening an activity or scrolling a RecyclerView was really slow. After monitoring some of my users in production using http://flowup.io/ I found this:
The frame time was really really high and the frames per second really really low. You can see that some frames needed about 2 seconds to render :S.
Trying to figure it out what was causing this bad frame time/fps I discovered I had a memory issue as you can see here:
Even when the average memory consumption was close to the 15MB at the same time the app was dropping frames.
That's how I discovered the UI issue. I had a memory leak in my app causing a lot of garbage collector events and that's was causing the bad UI performance because the Android VM had to stop my app to collect memory every single frame.
Looking at the code I had a leak inside a custom view because I was not unregistering a listener registered into a Android Choreographer instance. After releasing the fix, everything became normal :)
If your app is dropping frames due to a memory issue you should review two common errors:
Review if your app is allocating objects inside a method invoked multiple times per second. An example could be creating new instances of an object inside a onDraw custom view method.
Review if your app is registering an instance into the Android SDK but not releasing it. Registering a listener into a bus event could also be possible leak.
Disclaimer: The tool I've been using to monitor my app is under development. I have access to this tool because I'm one of the developers :) If you want access to this tool we will release a beta version soon! You can join in our web site: http://flowup.io/.
If you want to use different tools you can use: traveview, dmtracedump, systrace or the Andorid performance monitor integrated into Android Studio. But remember that this tools will monitor your connected device and not the rest of your user devices or Android OS installations.