When starting my Android wallpaper application, the application consumes slowly more and more memory. I am trying to figure out why this is happening and haven't been very successful yet.
At one time I got an information in logcat as "Low memory no more background process". At this time my app quit for a few seconds and restart it again.
Am calling two native functions repeatedly on the background to draw the wallpaper. Is this problem?
Please read: http://android-developers.blogspot.co.uk/2009/01/avoiding-memory-leaks.html
You are probably using static members and reusing widgets with old Context and that makes android unable to free the memory of old contexts that expired long ago.
Don't use static members when you can avoid it
Under no conditions should you set a widget to public/default static always use private
Use final as much as you can
Do more research online
Related
I just try to understand the reason of it. Our app is really stable and optimized, but time to time it just switch off during the work on foreground mode. User is using it, and it' just closed without any crash or ANR messages - really bad experience. What we already did:
use UncaughtExceptionHandler and print logs to the disk for analyzing. Logs are empty, not information about crashes for these cases
used Firebase crashlityc - is empty too
checked app with help profiler and leakcanary - no leak, memory using ~200 Mb
A bit words about our app:
clear arhitecture, Kotlin, MVVM, coroutines, dagger, retrofit, room, one single activity app
app should work all time, infinitely. App is an interface for hardware terminal.
the most part of fragments are stored into the backstack and reused again, it help to make screen opening faster after first fragment using. No leak with it, no fragment or viewModels duplicates
we use glide for downloading and previewing user avatars. I'm afraid, that leaks could be a part of bitmaps or jpg. Profiler doesn't show it after 1-2 hours tests, but I didn't test it during for ex. one week
possible app interruptions happen more often, when device is uncharged or just started (first 10-20 minutes after device start)
the most part of clients has a bad WIFI connections
we have ~10 modules, the most part of them are own canvas libs
crashes happen in random moments...
we also have ANR problem for some clients, but we added ANR watchdog, so soon we will know the reason of it.
we have 50-60 singletons. I'm not sure, that is bad or good. The first plan was using much memory to make app faster.
For me it looks like a native crash or system kill, but how to repeat it? I still don't understand the real reason of it. If you faced with similar problem, please describe your experience, it could be helpful for us. Thx!
I have created a simple game using a class a which extends SurfaceView and implements Runnable. In the game the drawing is done inside the public void run. Which is targeted by a thread as soon as the activity launches. The game is taking a lot of time(sometimes 10-15 sec) to load. As well as when the game is paused(thread. join()) and resumed(thread = new Thread(this); thread.start()) it takes too much time.
What might be making the game load slow? And what can be the solutions?
The most common cause is resource loading.
I/O operations are very slow, so, if you try and load all your bitmaps before actually drawing, this can cause significant delay before the drawing actually starts.
One strategy to avoid this is to preload your assets before you actually need to start using them. A lot of games do this in the so - called Splash screen. Also, don't be too fast to recycle your assets and free the memory they are using. This means that you will need to reload them the next time you start.
Overall, there is no exact recipe of how to do it - there is a constant trade - off between load times and memory consumption. You just need to experiment and try to see what fits your use case best.
Be sure to profile your app, examine the object creations and memory allocation calls using your IDE. Most of the time you can easily pinpoint the causes of problems there.
I found that the game was loading slow because the thread has been running continuously, without any sleep. So just adding Thread.sleep(15); inside the run, with all exceptions handled, solved this problem. Thank you for supporting.
Is it normal and "ok" for a static instance of a class to be GC'ed so much? I built a subset of graphs and once I execute my graphing option in my app, I see the GC and my static instance get wiped.
I'm not having issues, just looking for some learning feedback. This trace test was done on my Galaxy Nexus.
This is normal because your app (a content provider perhaps?) is only kept running by the OS as long as necessary.
Let android do its thing.
I have an Android app that in the onCreate() method, preloads a lot of graphics.
When I test my app on my HTC Aria and launch it, it runs fine. However, if I press the back button to exit my app, and then launch the app again, it crashes with an OutOfMemoryError: bitmap size exceeds VM budget. If I then launch the app for the third time (right after it has crashed) it launches fine. Then if I close and re-launch it, it crashes again with out of memory. It continues this every-other-time-crashing pattern forever if I keep trying.
I checked to see what life cycle methods were being called and onStop() and onDestroy() are both being called when I exit the app, yet I have a feeling that something is not yet being cleaned up and that by "crashing" the app when I try to launch it the second time, it somehow free's the memory.
Any thoughts on what could be happening or how to remedy this? Please let me know if you need me to post more info. Thanks!
Info:
My app is fairly simple and only has 1 activity that plays some frame animations.
Maybe you are unnecessarily holding onto Context references? Check Avoiding memory leaks for some tips, as well as Attacking memory problems.
It sounds like something in the Activity life cycle is not quite right. Are you sure you have every start covered? http://developer.android.com/reference/android/app/Activity.html
You have onStop but do you have onDestroy? You're probably missing one of those that you need.
You may find some useful information the many answers to this question:
Strange out of memory issue while loading an image to a Bitmap object
Also, I second the "Avoiding Memory Leaks" blog post. Especially if you can trigger the same problem with orientation changes. Using "this" context when creating display objects is a sneaky way to leak the Activity context. In my own app, I managed to leak a whole chain of contexts, and would very rapidly run out of memory when doing orientation changes.
I'm writing an app that has a foreground service, content provider, and a Activity front end that binds to the service and gets back a List of objects using AIDL. The service does work and updates a database.
If I leave the activity open for 4-8+ hours, and go to the "Running Services" section under settings on the phone (Nexus One) an unusually large amount of memory being used is shown (~42MB).
I figure there is a leak. When I check the heap memory i get Heap size:~18MB, ~2MB allocated, ~16MB free. Analyzing the hprof in Eclipse MAT seems fine, which leads me to theorize that memory is leaking on the stack. Is this even possible? If it is, what can I do to stop or investigate the leak? Is the reported memory usage on the "Running Services" section of android even correct (I assume it is)?
Another note: I have been unable to reproduce this issue when the UI is not up (with only the service running)
I'm writing an app that has a
foreground service, content provider,
and a Activity front end that binds to
the service and gets back a List of
objects using AIDL.
If that's all just one application, get rid of the AIDL and get rid of the content provider. Or, at least, don't use them yourself -- those are for other applications to use. They add overhead that you do not need for stuff inside your own VM.
...which leads me to theorize that memory is leaking on the stack. Is this even possible?
Not really. The main application thread stack is trivially small. Other threads have stacks that could get a lot bigger, but I'll be surprised if you are chewing up 42MB that way.
If it is, what can I do to stop or
investigate the leak?
Since you already did a "spike solution" of testing sans UI and determining that is OK, I'd slowly reintroduce the UI and see when you start getting the problem. One likely candidate problem area would be updating the activity from a background thread, so you might turn that off and see what happens.
Since your problem isn't in the heap itself, my guess is that your problem is tied to bitmaps or other things that have lots of off-heap RAM usage. The camera in your avatar is another hint in this direction. :-) Make sure you are recycle()-ing your bitmaps and such, and see if that helps any.