English subtitles

← Memory Leaks

Get Embed Code
13 Languages

Showing Revision 4 created 05/25/2016 by Udacity Robot.

  1. One of the best things about Android's
    Java language is that it's a managed
  2. memory environment that is, you don't
    have to be super careful about handling
  3. when objects are created or destroyed.
  4. While this is generally great,
  5. there's some hidden performance problems
    lurking under the surface here.
  6. Now remember,
    the memory heaps in Android's runtimes
  7. are segmented into spaces,
    based on the type of allocation and
  8. how best the system can organize
    allocations for future GC events.
  9. And each space has its
    own reserved memory size.
  10. When the combined size of an object in
    a space begins to approach its upper
  11. limit, a garbage collection event
    is kicked off to free up space and
  12. remove unneeded objects.
  13. These GC events aren't generally a
    noticeable problem to your performance.
  14. However, a lot of them recurring
    over and over and over and
  15. over again can quickly
    eat up your frame time.
  16. The more time you're spending doing GCs,
  17. the less time you have to do other stuff
    like rendering or streaming audio.
  18. One common situation that developers
    can fall into that cause a lot of
  19. these GCs to occur is
    known as memory leaks.
  20. Memory leaks are objects which
    the application is no longer using, but
  21. the garbage collector fails
    to recognize them as unused.
  22. The result is that they
    stay resident in your heap,
  23. taking up valuable space that's
    never freed up for other objects.
  24. As you continue to leak memory,
  25. the available space in your heap's
    generation continues to get smaller and
  26. smaller and smaller, which means that
    more GCs will be executed more often
  27. to try to free up space for
    normal program execution.
  28. Finding and
    fixing leaks is tricky business.
  29. Some leaks are really easy to create,
  30. like making circular references to
    objects which the program isn't using.
  31. While other are not so simple,
  32. like holding on handles to class loader
    objects as they're being loaded.
  33. In either case, a smooth running,
    fast application needs to be aware and
  34. sensitive to memory
    leaks that may exist.
  35. I mean, your code's going to be
    running on a federation of devices and
  36. different types, and
  37. not all of them are going to have
    the same memory footprints and sizes.
  38. Thankfully, there's a simple tool that's
    available to help us see where these
  39. leaks might exist
    inside the Android SDK.
  40. Let's take a look.