1 of 38

Get rid of all Memory Leaks

Piotr Krystyniak

2 of 38

Objects Graph

3 of 38

Objects Graph

4 of 38

Garbage Collection - mark live objects

5 of 38

Garbage Collection - mark live objects

6 of 38

Garbage Collection - sweep

7 of 38

New Object Graph

8 of 38

Memory leak?

Part of memory which is not longer needed but is not released

9 of 38

Graph with leaked activity

10 of 38

Graph with leaked activity

11 of 38

Graph with leaked activity

12 of 38

Graph with leaked activity

13 of 38

What causes memory leaks?

  • Registering callback to a singleton (f.e event bus) and not unregistering
  • Passing callback to a long running task or never-ending task and not canceling
  • RxJava - missing Subscription#unsubscribe()
  • In general - passing Context to Objects that live longer than that Context

14 of 38

Example 1

15 of 38

Example 2

16 of 38

Example 3

17 of 38

Example 3

18 of 38

Always unsubscribe

19 of 38

RecyclerView example

20 of 38

RecyclerView example

21 of 38

RecyclerView example

22 of 38

RecyclerView example

23 of 38

RecyclerView example

  • LinearLayoutManager#setRecycleChildrenOnDetach(true); // false default
  • Each LayoutManager handles this differently

24 of 38

WeakReference

25 of 38

WeakReference

26 of 38

WeakReference

27 of 38

WeakReference

28 of 38

WeakReference

29 of 38

WeakReference

30 of 38

SDK have leaks

31 of 38

How to find a memory leak?

32 of 38

LeakCanary

33 of 38

LeakCanary

34 of 38

LeakCanary

35 of 38

LeakCanary - upload leak report

36 of 38

Android Studio Memory Analyzer

  • Works with heap dumps (hprof file)
  • Allows to inspect all objects and their references

37 of 38

Summary

  • Don’t pass Context to objects living longer than Context
  • Always unregister/unsubscribe
  • Check if unregister/unsubscribe is really called
  • Use WeakReference if you must
  • Use tracking tools
  • Memory leaks are like bugs, there is no general approach to solve them

38 of 38

Questions?