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.
Related
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.
My app is very slow, than ı searched web and find out there are memeory leaks on my app. But the problem is ı have tons of codes and too many activities. There are tons of refenrences and leaks. Its gonna be really hard work if ı do this way. Than I tougth if I transfer all codes to a services (as ı understand the services is not leaking memory) this would be easier for me. I wnant to ask that, if you had this statuation, than how would you try to solve it? I learned about memory managment 4 days ago and 10 hours of day learned about it. But ı dont want to go wrong direction again. And my app live on market and users still waiting for a update. I need to be fast and affactive more than I can be. How would you salve this leaks on fastest way ? Is servis realy a option ?Thanks..
I decided to clear all leaks and make a better codding. This is absolute way. By the way, for more performance, when a activity is hidden clear all data that took. and clear all images. if activity is active again reload all contents again.
also: create a clas and make a static instance of aplication context. then call this where you wrigth .getaplicationcontext(). this thecnic called by weak reference. by this your activities will be garbace collected.
and use this.isfinishing() method at onpost() method of every asyctask.
you can use onstart and onstop calls for this. my apps ram usage was 250 mb and now 70mb.
I am developing one sample application.
I want this application should not be garbage collected ever until i switch off the phone.
1. Is this is possible in android?
2. If it is possible. How can i do this?
No, it's not possible in Android. And there is a good reason for it : system manages memory as a limited resource and no application can remain active if not used to ensure memory is available to other apps.
Nevertheless, technically, you can use a foreground service to ask the system to keep your application running as long as possible, possibly longer than a "normal" app with no such a service.
But, all in all, what you want to achieve is not a good idea. The Android way is to create your app, persist its state and re-set new instances of your app in the same state. For persisting state there are multiple solutions like using SharedPreferences, files or a database.
I am creating a AppWidget that consists of a ImageView that gets filled with a custom rendered bitmap. This widget is refreshed every minute (using the AlarmManager).
All the rendering and storage is done in the AppWidgetProvider.
Being a good citizen I wanted to minimize CPU usage etc, so I had my Paint objects and other pre-calculated values stored in static fields in the AppWidgetProvider.
However, it turns out that my AppWidget process is very eager to die on me when it's hanging around with the cool kids doing nothing. I understand this is standard behaviour. However, with it's tragic death, it also takes my precious statically stored objects with it into the grave, never to be seen again, which is a lot less convenient.
My mourning doesn't solve anything, so I wonder: is there a way to deal with this? Or is there just no way to do that, and should I fall back to reinitializing everything on every redraw?
Not a real solution, but I solved it by not caching all the stuff.
I am doing something similar -- creating a clock widget -- and have discovered that it's even worse than you think. Android isn't merely killing the AppWidgetProvider when it gets tired of having it around. It's killing it IMMEDIATELY and recreating it for EVERY update (as print statements in the constructor demonstrate).
This is a problem if you, like me, are doing something memory-intensive like drawing a rather heavy object to a rather heavy offscreen bitmap.
The best solution I can offer you is to try handling the maintenance and storage of your objects in something more persistent -- say, the configuration activity, or maybe a service. Seems like overkill for Paint objects, though.
I'm not sure what sort of precalculation you are doing, or what sort of data is being saved, but Android will tell you when it is about to kill your AppWidget. You can use that as an opportunity to some sort of persistent store. You would still have some processing in serializing/deserializing the data, but it could be faster than recomputing.
I just read a pretty interesting article on how android (and i assume other OSs) work when low on memory. How is this done theoretically? Is it similar to Java's object serialization?
In a word: yes.
In a few more words, sort of. You have to handle more of it manually than personally I'd like. Essentially, all Android provides for you is a hash to shove a few serializable objects, referenced by strings, that is guaranteed to be safe across application shutdowns. So, whenever something happens that you'd like to preserve across a shutdown of your application, you are responsible for updating this saved state hash (and letting Android know that you've done so). This includes things like half-finished text entry in form fields. That means you have a lot to listen to.
Android will then call a particular hook in your Activity that handles restoring state to the Activity when it recycles your application and you need to do so. This doesn't happen for all recycles — there are various states of being/existence for your application.
The screwy part is that because you're expected to do this sort of tedious work anyway, Android gets lazy and implements things like screen rotation as a full recycle of your application.
I'm making it sound worse than it really is once you get used to it; it's really not a bad way of solving the problem in the confines of Java and mobile computing.
Of course, this is a response regarding Android. Other (desktop) OS's rely on Virtual Memory and Paging to deal with memory constraints.