I am currently developing a game application for Android. My problem is that it sometimes crashes and displays the "Unfortunately...has stopped" dialog. But running the application again does NOT force close the app when getting to the same point, it will just appear every so often.
What are some potential reasons that this might happen? I've done some research but couldn't really find anything
You should review your logcat for possible Exceptions.
If you have no Exceptions causing your app to crash -meaning your code is aparently "ok"- there's the chance the application is consuming lots of memory. If your application is making your Garbage Collector to overwork, Android may shut down your application.
You must take care you are not overcreating objects, or leaving a load behind to be cleaned by the Garbage Collector. This means, if you can reuse objects, that's a good idea.
There's an <application> element in the Android Manifest. You can set there an attribute named android:largeHeap="true". In this way Android will assign more memory for your application. But do do this as a last resort. Try to first improve the object management in your app. This ain't easy task, so good luck.
Related
I'm using Firebase Performance Monitoring SDK (on Android, but will also on iOS) and for one particular use case it's hard to know whether a started Trace will ever be stopped. And given there is no apparent way how to cancel an already running trace, I figured I'd just start it every single time and then eventually stop it only under the right circumstances. (and leave intact otherwise).
Shall I expect issues? I figured the trace would not be logged if not stopped (that's what I need), but I'm scared of memory leaks and also some general resource waste.
I could also potentially clear the reference to the trace and hopefully let GC sweep it (provided Firebase doesn't store a reference to each running Trace)
If you start a trace but never stop it, a very small amount of memory will be leaked for that Trace object as it waits for you to stop it. It's probably not a big deal, but a leak is a leak. Clearing the reference when you would like to abandon the trace will allow it to be garbage collected.
I have noticed that dialogs (not sure about DialogFragments) will report a memory leak when you put in the app in the background and then dismiss it while in the background. Of course the way to handle this is to clean it up in onPause so its not really an issue, but my question is:
What are the impact of memory leaks if they are occurring as the app is exiting? It is talked about here https://developer.android.com/training/articles/memory.html under "Switching Apps"
but the way it is worded leaves me to think maybe it is just referring to apps put in the background, not apps being closed hence the reason it is under Switching Apps.
Any clarification or pointing to additional resources would be greatly appreciated.
Thanks
This question already has answers here:
Meaning of Choreographer messages in Logcat [duplicate]
(5 answers)
Closed 8 years ago.
I am building a new game with andengine and for some reason i keep getting this debug statement in the logcat:
01-31 21:29:50.503: I/Choreographer(697): Skipped 152 frames! The application may be doing too much work on its main thread.
Im not really sure what is causing this error exactly during my game. I am checking a lot of collisions, but they arent initiated until after the game play scene has started.
I also noticed on my galaxy S3 the game causes my phone to "flicker" when swiping changing home screens and pulling down the task bar at the top.
I think this error has something to do with it, but i am not sure. What do you guys think?
Also each time the user goes to another level i initialized the collision detectors all over again. But i dont unregister or stop the last collisions that were started. I thought they would be automatically cleaned up when the new one is initialized.
What do you guys think?
It sounds like you're aware of what the message is telling you, i.e., your frame rate is lagging. Your follow up question, "why?" is going to be impossible to answer without more information. You've provided some possibilities: is it the collision handling? Is it processing of unnecessary collisions? Is it some problem in the scene transitions? The answer is, maybe. Maybe it's any of those things. Maybe it's something else. At the moment all we can do is guess, because we're not looking at the code.
But the good news is, you're not without recourse! What you need to do is test your code and find where the bottlenecks are. A good place to start is to throw in some calls to clock the milliseconds between blocks of your code that you suspect are the problem. You may discover that things you'd assume we're slow are actually happening pretty quickly, and conversely, things you thought were fast are happening slowly. Focus on the latter! Put more calls in there to see where exactly things are taking longer. And look at your code to see why it might be running slowly there. Are a lot of objects being instantiated there? Is it reading from disk? Etc.
When you're ready for them, there are some great third party tools to get deeper into the testing, but it's worth spending some time to clock and review your own code first. You have the advantage as the author of suspecting where the problems may be. Start investigating!
Side note, I'd provide some links to third party tools, but I'm writing this from a jacuzzi. I'll update later.
In my app, I use a static variable to hold the current user id. There is a bug that is very hard to reproduce of this user id simply disappearing. While it could be related to a bug in how this variable is set during application loading (I still wasn't able to reliably reproduce this situation in a controlled environment, so I'm not really sure exactly what happens), I'm starting to think this is related to how memory gets reclaimed from static variables (something I didn't consider before).
So, when can my static variable simply disappear?
As far as I understand, static memory can get reclaimed if the OS reports low memory - can it happen while the app is in the foreground? Or only background?
Are there any possible ways static memory is getting reclaimed without a low memory condition? I think sometimes the variable disappears without the app even going to the background and I'm not sure any low memory events occur (AFAIK low memory refers to the whole OS, not the app's memory)
What is a good way to simulate static variables getting reclaimed by the OS to see how the application behaves and subsequently fix the bugs?
Anything adding more clarity to my understanding will be appreciated.
Thank you.
This is question super, super old, but I was writing a blog post and mentioned seeing this. I have no idea if you're still working on this app (doubtful), or if you're still seeing this issue (also doubtful). My guess is you set these statics in the Activity that your app launches with. Of course, if your app gets shut down, then restarted, you won't go through that activity.
Lazy loading statics, or initializing them in a custom Application object generally takes care of this.
I've done a fair amount of research on the "statics removed in low memory" idea, and the basic answer is it doesn't happen. Ever.
I suggest you are not using static variable to hold the current user ID as the static variable is not one of the best way to store your data (I assume userID as a data which will remain on every session of your app, except when the user is logout).
The simplest way is to go with Shared Preferences. Look at the Android Data Storage to read the best (practice) way to store your data in Android.
From your need, I guest you should go on with SharedPreferences. No more problem and you don't even need to simulate any variables reclaimed by the OS.
I've an application that has some foreground activities and also a service that updates some widgets.
The problem is that, as the process remains for the service, the memory from the other activities ,if they are opened, is never reclaimed.
Looking at that response from Roman Guy it seems that can be normal. But it is? For how much time android keeps the resources of not used activities? They can live for hours?
How can I know easily if the activities are leaked or are simple not reclaimed? I've tried with a program from AndroidMarket (FreeMemoryRecover) and it's cleared but I suspect that it kills the process and then restart the service...
Any help or suggestion will be heavily appreciated.
Note 1: I've investigated with a HeapDump + Eclipse MAT and I don't see strange references holding my activities
Note 2: I've already asked some questions about this problem:
Post 1
Post 2
The ability for Android to have multiple Activities, in different states, is a design principle as it allows users to quickly switch between activities without consciously having to shutdown whatever they were doing before. They can then quickly return to a previous activity.
If Android needs to pause an Activity, and quickly unpause it, it's going to need to keep the Activity's resources available to it.
If the memory is part of a terminated Activity, then it's leaked (very unlikely as the Linux kernel will reclaim all memory that was used when the process terminates), else it's either being actively used or is potentially about to be used.
What is that concerns you about this memory?
I would try the following :
Launch your app play with it to be sure it is fully loaded and use as much memory as it can.
Then hit the home button and launch the navigator, open techcrunch.com, lemonde.fr, youtube.com, dailymotion.com, launch a video from youtube, open up and play angry bird and last but not least open up a pdf document.
After that Android will have needed the memory back quite for sure. If your app is still there, you might have a problem, if its not, then everything went smoothly.
By the way, good on you to put so much concern in being a good citizen in AndroidLand !!
See my comment below your question.
See Romain Guy's post about Android memory leaks.
Specifically, look at the comment on the solution in the Launcher app. (look at unbindDrawables code here)
Use Context.getApplicationContext() whenever possible instead of your activity's context.