Right now I'm developing a game in Android (OpenGL ES 1.1) and I'm seeing that whenever I create a new SurfaceView (GLView) its thread is created. That's ok. The problem comes when I want to finish the Activity that holds the SurfaceView (and go back to the menu). It seems that the activities are not released because each GLThread is referencing it. This may finish with an OOM error.
Some MAT pictures:
The first picture: the MarkitActivity represents each single instance of the Activity that deals with SurfaceView.
The second picture: The list of all the activities in memory.
The Third Picture: What is holding the Activities from GC.
If any code is needed I will post it. Nevertheless I have already tried the following things:
->Weak reference of the Activity Context to the renderer and to the surfaceview.
->Application Context instead of Activity Context (in normal and weak mode).
->Trying to stop (in a hard way) the thread (interrupt) and waiting for join (Which the program does it, but the thread does not care, it is still there...)
->Trying without debugging, just in case in debugger mode the values changes (the MAT pictures are without debugger).
->Trying the Activity as singleInstance mode. Weird results and errors everywhere.
->onPause and onResume are correctly controlled for the view.
Any hint, idea, question or help will be really appreciated. Thanks in advance!
Carlos.
I had a similar problem with threads (but not using OpenGL), and end up solving it using a simple trick.
Before exting activity (in onPause() or onStop(), try nulling the thread like this:
myThread = null;
It seems that it makes the Thread GC collectable, and therefore you activity becomes also collectable.
It worked for me, as well as for some people with similar problems to whom I gave the same suggestion.
Regards.
Related
in my android project i scan a image and then gets redirected to a new activity. In onPause i release my camera and in onResume i re-create it.
When using my back-button to go back to the camera-view; i get the feeling that it reacts slowly. I know for a fact that this i because the program dont change view before i created new camera instance in onResume.
My question is: How can i make the program show camera-activity view before making the camera instance to make everything "look" faster?
Hope i am clear! :)
refer to Android Camera online document:
Caution: On some devices, this method may take a long time to
complete. It is best to call this method from a worker thread
(possibly using AsyncTask) to avoid blocking the main application UI
thread.
Yes, you can open() camera in a background thread. I am not sure that this is what slows your activity display.
Code is probably too complex to post here in full, but here is the basic schema: I have two Activity subclasses, each of which hosts a ListView. Each ListView has an adapter of a custom class, which generates View instances also of a custom class. These lists are showing data items that are generated asynchronously in another thread; as it needs to know where to send updates to, the data objects it manipulates have WeakReference<> objects that are set to hold references to the adapters displaying their contents when they are initialised. When an object in the list of the first activity is selected, I start the second activity with an intent that instructs it to look up the item and display its contents. I then use the 'back' button to close the second activity and return to the first. For some reason when I run this with StrictMode checking enabled, it always crashes after a few iterations of switching between the two activities, complaining that there are too many instances of one of my Activity classes.
I have arranged for a heap dump to be written just prior to the crash (see Android StrictMode and heap dumps). These heap dumps always show that there is 1 instance of each of my two activities on the heap at the time of termination. First of all, is this not to be expected when I have recently switched between the two, and if that is so, why is StrictMode complaining about this? If it isn't expected, how can I arrange to avoid this? Examining the heap dump, both objects are referenced from the main thread stack, over which I don't seem to have any useful degree of control. Each also has a reference from android.app.ActivityThread$ActivityClientRecord, which I also do not seem to be able to control.
So, basically, any ideas how I avoid this situation? Does this actually represent an activity leak, or is StrictMode just being overly sensitive?
I know that this is old post. Just for guys who is looking for solution and explanation to this problem.
In case there is InstanceCountViolation exception it means that there is a real problem that Activity leak. Otherwise there can problem which is related to how detectActivityLeaks check is implemented in Android SDK.
To identify if this is a problem I can recommend the following post: Detecting leaked Activities in Android. If you will see that there are objects holding a reference to this activity which don't related to Android Framework then you have a problem which should be fixed by you.
In case there are no objects holding a reference to this activity which don't related to Android Framework than it means that you encountered with the problem related to how detectActivityLeaks check is implemented. In this case to fix the problem with failed activity without turning off detectActivityLeaks you can simply run System.gc() before starting activity in debug configuration like in the following example:
if (BuildConfig.DEBUG)
{
System.gc();
}
Intent intent = new Intent(context, SomeActivity.class);
this.startActivity(intent);
More information are available in this answer.
I am experiencing a very strange phenomenon (test device: HTC Desire HD, Android 2.3.5). I know that System.gc() is needless and discouraged, and I don't try to suggest otherwise, but the point is that it shouldn't cause issues either (i.e. it should be useless at most).
I have an application which contains a GLSurfaceView in its view hierarchy. The GLSurfaceView is instantiated and added in the Activity.onCreate(). Normally, the application works like this:
User starts the app and goes to mainmenu
User chooses a mainmenu item which sets the GLSurfaceView to View.VISIBLE
User plays with the in-built game on GLSurfaceView
User goes to mainmenu and exits the activity (=> Activity.finish() is called)
My Activity.onPause() looks like this:
mGameThread.pause(); // gameThread is my custom thread class for the in-built game
mGLView.onPause(); // pause the renderer thread
So far so good, everything works fine. However, issues appear after I add the following code to onPause() (for the case when the user exits the game from the mainmenu):
mGameThread.pause(); // gameThread is my custom thread class for the in-built game
mGLView.onPause(); // pause the renderer thread
if (isFinishing()) {
System.gc();
}
In details: if the Activity is started for the first time (= i.e. the app process didn't exist before), everything works fine. However, starting from the 2nd start of the activity (= after the first exit from the mainmenu, i.e. after the first Activity.finish()), the framerate of GLSurfaceView is reduced by 40-50%, the in-built game becomes slow.
If I remove the System.gc() call, the problem disappears. Moreover, if I do the following, it also gets rid of the problem:
mGameThread.pause(); // gameThread is my custom thread class for the in-built game
mGLView.onPause(); // pause the renderer thread
if (isFinishing()) {
// 1. get layout root of View hierarchy
// 2. recursively remove (detach) all Views
// 3. call GC
System.gc();
}
I didn't add concrete code because it's complex, so I used comments. If I just detach the GLSurfaceView via removeView(), it is not enough. The entire view hierarchy needs to be cleared.
Note that I couldn't find any memory leaks (no Activity leak via drawables/statics etc.). Moreover, of course, the gameThread properly exits when the app is closed (I just didn't include its source code).
Any ideas, guesses? Apparently, System.gc() seems to cause some issues for the Activity/layout destroying mechanism of Android. Again, as I said, if I remove System.gc(), the problem disappears.
I have experience of Android Game Programming. I used to clear all the view in hierarchy because when running threads if you call System.gc() sometimes it happens that your thread has a reference to some of your view, even if you call system.gc() this view won't get removed and if you keep playing again and again this game you will notice that your heap memory is started growing.
It depends upon the memory leak, if you are leaking some KB memory it will take more time to crash your game. The best way it to use Eclipse Memory Anlyser (Eclipse MAT) and compare your stacks.
Step1:
take memory snap shot when you start your game for first time
Step2:
take memory snap shot when you start your game second time
Step3:
Now compare your both stacks of snapshots it will tell you the difference.
It is a very useful tool. I was having huge memory issues in my game Apache Attack. I fixed them using this awesome tool.
Follow this ECLIPSE MAT TUTORIAL
I have activity A, which launches activity B via an intent. Activity A has no references to Activity B, there are also no references to Activity B in the Application singleton I am using.
When I create Activity B, several thousand objects are created. That's okay, it's an activity with a very populated ListView with lots of images.
But, when I press the back button and return to Activity A, only about a dozen of the several thousand objects are released. onDestroy() is also called for the activity. I'm using DDMS to view the heap info, and am pressing 'Cause GC' several times to force it to free memory.
I've done the same test on other apps (that use list views too) and 100% of their objects are destroyed on pressing the back button then 'Cause GC', so it's certainly not a bug.
Any advice please? :-) I've read the material in the android docs about leaking contexts, but that's not helpful since i'm not referencing the activity (or anything in it) being destroyed elsewhere. Also, I have many other activities which work the same way, and don't release all memory on destroy. I must be missing something obvious?
Edit: I just realized i'm using AsyncTasks which have references to the activity (either passed as arg into doInBackground() or accessible via outerClass.this. Could they be hanging around in the thread pool, even after onPostExecute() ?
Edit: It leaks even if I go back before running any asynctasks :-(
Edit: No leak before running asynctasks if I remove admob code, but still leaks in the activites which do use asynctasks.. so asynctask is still a good candidate :-)
I believe there's a bug in the ListView implementation. Take a look at this question: Android: AlertDialog causes a memory leak.
Here's a bug report: http://code.google.com/p/android/issues/detail?id=12334. It's declined but in my opinion it must be reopened.
I'm getting an OutofMemoryError for my android application, and am a bit confused as to whats going on. Basically what happens is, I'm able to run it the first few times, but when I try to quit out of it and then open it again quickly and repetitively, I get an out of memory error.
I've tried researching this topic, and have found that the recycle() method has commonly been the problem. However, I've called the recycle method on each of the bitmaps (which are stored in an object container, stored in an arraylist), but was still getting the problem.
After doing this, I tried using the Eclipse Memory Analyzer to look at heap dumps, when I came across something weird. After quitting out of the activity (back into the launcher activity, and then opening up the activity again via a button, I took screenshots of the heap dump using the memory analyzer. It turns out, with each time I quit and re-entered the activity, another instance of the activity object was being created, and the old ones weren't being released, even though the onDestroy() method was being called (which also had the recycle/cleanup code.
I then tried overriding the finalize method to see if it was being called when the activity quit out back into the launcher activity, but it wasn't being called. I read on some other stackoverflow threads that finalize() isn't always called, so in the end, I'm still not sure whats going on.
Ultimately, my question is this:
How am I supposed to ensure that the Activity object (the activity object itself, not the stuff created from the activity) is released after quitting out from the activity into another activity?
Sounds like you application suffers from memory leaks, i recommend you to follow the links below:
Avoiding Memory Leaks
Memory management for Android Apps
One option is setting the launch mode to singleInstance or singleTask in your manifest file. This would make sure that another instance of the Activity is not created.
Documentation Example
One way to release your object of activity is calling it onDestoy() method..Take an object of your activity make it public static and make it null in onDestroy()
Public static Your_activity obj;
And then in onCreate method initalize obj by this
obj=this;
and in onDestroy() method do this:
obj= null;