LeakCanary: Detect all Android memory leaks

corner.squareup.com

11–12 of 12 posts

Re: LeakCanary: Detect all Android memory leaks

#11

Post by on_and_off » Sat, May 09, 2015, 5:02 PM UTC

wyldfire wrote: post #2

Is this a true "leak"? Maybe I'm naive but I would think you couldn't have a leak without using JNI. Maybe a reference cycle is hard/impossible to GC? >Later, in a background thread, it checks if the reference has been cleared and if not it triggers a GC. > If the reference is still not cleared ... Sounds to me like it's not a leak so much as unbounded-memory-growth. But sounds like a useful tool. And I guess you can…

The most common large leak I have seen in Android apps is created that way : -create an object containing a strong reference to an Activity. Activity is kind of a god object in the Android framework. It can loosely be defined as a screen in the app. Views for example always contain a reference to their parent activity.

-Make a screen rotation and persist that object.

-During the rotation, the Activity reaches the end of its lifecycle and a new one is created.

-The retained object keeps a reference to its Activity. It should be collectable by the GC by now but it is not possible because of this object holding a strong reference to it. It does not stop here, the Activity almost certainly contains references to many other objects that similarly cannot be reclaimed.

It might not be very similar to the leaks encountered in c/c++ but it is very easy to create such issues in GC languages such as Java.

Re: LeakCanary: Detect all Android memory leaks

#12

Post by eonwe » Mon, May 11, 2015, 8:56 AM UTC

georgemcbay wrote: post #5

wyldfire wrote: post #2

Is this a true "leak"? Maybe I'm naive but I would think you couldn't have a leak without using JNI. Maybe a reference cycle is hard/impossible to GC? >Later, in a background thread, it checks if the reference has been cleared and if not it triggers a GC. > If the reference is still not cleared ... Sounds to me like it's not a leak so much as unbounded-memory-growth. But sounds like a useful tool. And I guess you can…

> Is this a true "leak"? By most people's definition of the term, sure. It ends up being a loss of memory within an object or set of objects that no longer have any practical use to the application and the irreclaimable memory can grow over time. > Maybe a reference cycle is hard/impossible to GC This is basically the issue. It is relatively common (particularly among younger programmers who haven't been bitten by th…

Android has precise GC so it will free the unused memory even if there are loops within it.

What it won't help with are cases like: public class MainStuff { private byte[] myBuffer;

      public void doStuff() {
          myBuffer = new byte[20 * 1024 * 1024];
          doStuffWithBuffer(myBuffer);
      }
  
      private void doStuffWithBuffer(byte[] buffer) {
          /* omitted */
      }
  
  }

Here, we program keeps myBuffer around as long as MainStuff lives which can be very long if it is, say, a main class of your program.

It's just that the cases where the memory is kept around are not as easy for the programmer to spot as this example for reference-hierarchies are deeper.

Post reply on HN