Static variables and onDestroy() being called after onCreate()

1,313 views
Skip to first unread message

Ratamovic

unread,
Sep 29, 2011, 2:30:41 AM9/29/11
to android-ndk
Hello everybody,


I am investigating the "static variable" subject and saw some
discussions about it, e.g.:
- http://groups.google.com/group/android-ndk/browse_thread/thread/23c1d511379cbc92
- http://groups.google.com/group/android-ndk/browse_thread/thread/2530238bc9001809?pli=1

Basically, it is claimed that Android can call onDestroy() after a new
instance of the Activity has been created. This could lead to memory
leaks and/or corruption as native code and its static global variables
survive meanwhile and may get destroyed after being recreated.
Hopefully there are a few solutions already indicated there.

My problem is that I never noticed this behaviour on recent releases
of Android (2.2 and 2.3) whereas these discussions seems to talk about
Android 1.6 (but are unclear about later versions)...


So would anyone have additional information on this subject?

Olivier Guilyardi

unread,
Sep 29, 2011, 2:53:42 AM9/29/11
to andro...@googlegroups.com
Hi,

On 09/29/2011 08:30 AM, Ratamovic wrote:
>
> I am investigating the "static variable" subject and saw some
> discussions about it, e.g.:
> - http://groups.google.com/group/android-ndk/browse_thread/thread/23c1d511379cbc92
> - http://groups.google.com/group/android-ndk/browse_thread/thread/2530238bc9001809?pli=1
>
> Basically, it is claimed that Android can call onDestroy() after a new
> instance of the Activity has been created. This could lead to memory
> leaks and/or corruption as native code and its static global variables
> survive meanwhile and may get destroyed after being recreated.
> Hopefully there are a few solutions already indicated there.

Yes, as thoroughly described in the second thread that you mention, there is a
solution: don't use static variable. Or live with the consequences of your
design choice. It's nothing Android specific, it's just about code sanity.

Good luck

--
Olivier

Tim Mensch

unread,
Sep 29, 2011, 1:43:38 PM9/29/11
to andro...@googlegroups.com
On 9/29/2011 12:53 AM, Olivier Guilyardi wrote:
> Yes, as thoroughly described in the second thread that you mention,
> there is a solution: don't use static variable. Or live with the
> consequences of your design choice. It's nothing Android specific,
> it's just about code sanity.


I'm not going to re-read the thread, so I may be restating things here, but sometimes it simply DOES make sense to have static variables. Period. I'd rather not rehash the religious debate here. Sometimes it simply makes sense, and if you can write your app without needing statics, that's great. You can't rewrite mine (with my requirements) without needing statics, so let's not argue about it.

And in the cases where you do need statics, don't dispose of them in onDestroy(). Instead, expect that their life will survive many onCreate/onDestroy pairs, and code appropriately. If you do get an onDestroy(), expect that it can happen after another onCreate(), and refuse to destroy your statics unless the Java Activity is the same as the one that was last onCreated.

Ideally (following the "Android Way") you wouldn't keep large blocks of memory around after an onDestroy(), but it comes down to the fact that if Android needs the memory then it will kill the process, so you won't break anything if you do keep memory around.

I keep a lot of cached textures around even after onDestroy(), because, frankly, it's necessary for a decent user experience. My app start-up is dominated by the loading of textures. With cached textures, my app can resume in "only" a second or less, instead of having to wait 5+ seconds to reload everything (on older phones).

The "Android Way" makes no sense in my use case, and so (if I care about my users) I have to do it my own way. From what I can tell, most other games do the same thing.

Tim

Dianne Hackborn

unread,
Sep 29, 2011, 10:17:26 PM9/29/11
to andro...@googlegroups.com
There is nothing especially wrong with keeping lots of memory allocated in statics in onDestroy(); it just means that on devices with less memory there will be fewer processes that can be kept in the background and your own process is going to be killed more quickly.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.



--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

Ratamovic

unread,
Sep 30, 2011, 7:18:46 AM9/30/11
to android-ndk
Thanks all for your answers. I think they give a good overlook of
problems related to static variables.
So to answer my initial question, should I expect onDestroy() to be
called after onCreate() in latest releases 2.2 and 2.3?

I understand it's better to avoid them when possible but as said,
sometimes it can be complex to avoid, in which case we have to handle
successive onCreate() events (or onCreate()/onDestroy() if it was
working). I am asking this question because I need to give
recommendations and more importantly justify them.

Thanks again.


On 30 sep, 04:17, Dianne Hackborn <hack...@android.com> wrote:
> There is nothing especially wrong with keeping lots of memory allocated in
> statics in onDestroy(); it just means that on devices with less memory there
> will be fewer processes that can be kept in the background and your own
> process is going to be killed more quickly.
>
>
>
>
>
>
>
>
>
> On Thu, Sep 29, 2011 at 10:43 AM, Tim Mensch <tim.men...@gmail.com> wrote:
> > **
> hack...@android.com

Dianne Hackborn

unread,
Oct 1, 2011, 3:52:43 AM10/1/11
to andro...@googlegroups.com
The times onDestroy is called hasn't changed from Android 1.0 to the most recent version.
hac...@android.com
Reply all
Reply to author
Forward
0 new messages