CODEWITHSUNDEEP
androidout-of-memory
最白目
最白目

Reputation: 3644

Activity Stack full: OutOfMemoryError

My App is designed with a side menu, so that basically you can start any Activity from any Activity. If I start the activity with the default behaviour of the back stack of Android, the Activities get stacked on each other until the memory of the phone is full and it results in a very scary

02-09 15:43:12.807 1860-1868/? E/System: java.lang.OutOfMemoryError: OutOfMemoryError thrown while trying to throw OutOfMemoryError; no stack trace available

Now my questions are:

  1. Should I launch the activities with another launch mode (REORDER_TO_FRONT, CLEAR_TOP), but all that stuff makes the back button behavior worse?
  2. Would the GC actually collect some Activities if the memory gets to full, and my problem is maybe I just have some strong references pointing to them left, making them unable to get cleared from memory?

Can someone explain please, thank you!

Upvotes: 0

Views: 1541

Answers (1)

Philippe Banwarth
Philippe Banwarth

Reputation: 17725

When an activity is put on the back stack, Android usually keeps the instance in memory. When the memory is low, back stack activities are shut down (this includes calling onSaveInstanceState() onDestroy()), but the system keeps the information needed to recreate them, in case the user navigates back.
The retained information is small and should not be a problem, unless you have hundred of activities stacked. On the other hand, once destroyed, the activity instance will never be reused and must be garbage-collectable, otherwise it constitutes a Context leaks, which mays not be obvious to spot.

A few suggestions :

  1. Enable StrictMode and in particular detectActivityLeaks() to detect Activity (and other Android's objects) leaks

    StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
        .detectActivityLeaks()

        // or even
        .detectAll()

        .penaltyLog()
        // or
        .penaltyDeath()

        .build());

  2. Use Android Studio's memory profiler. Heap dumps can show you where references are held. The older memory monitor had analyzer tasks to find leaked activities. As far as I know there is no equivalent in Android Studio 3.0

  3. Try with and without enabling the Don't keep activities option in the device's developer options. Enabling it makes the activities lifecycle more predictable.

  4. Use a library like LeakCanary

Upvotes: 2

Related Questions