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

1. Title:
   Memory Leaks
2. Description:

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