English subtitles

← Use Heap Viewer

Get Embed Code
13 Languages

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

  1. Using heap viewer, we can see that after
    the first GC, only 1.39 megs is free.
  2. This may indicate that the garbage
    collector wasn't able to reclaim much
  3. memory due to a leak.
  4. After a second GC event, heap viewer
    indicates that the system has decided to
  5. accommodate a larger memory footprint
    for this app by allocating more memory.
  6. Increasing the heap
    size to 32 megabytes,
  7. which is up from 20
    megabytes in the first GC.
  8. This time,
    we have 12.9 megabytes free in our heap.
  9. At this point, the system is
    dynamically accommodating for
  10. the larger memory footprint of this app.
  11. If the expansion repeats, this may lead
    to an app crash if the system can no
  12. longer allocate more memory for the app.
  13. So remember, memory leaks are slow and
    they're insidious and require time and
  14. the proper test environment to confirm.
  15. Also, keep in mind that
    sometimes a pattern like this
  16. might represent
    a legitimate use of memory.
  17. For example,
  18. imagine an application that was designed
    to manipulate large graphics or photos.
  19. The takeaway here is be on the lookout
    for slow leaking memory, but
  20. always weigh the data you collect,
  21. against the memory implications
    of your app's core functionality.
  22. Now at this point, you should understand
    how memory leaks manifest in the SD.
  23. At this point, you should understand how
    memory leaks manifest in SDK provided
  24. tools such as Memory Monitor and
    Heap Viewer.
  25. But you might not know
    where they originate.
  26. Here are some best practices
    you can take to avoid a leak.
  27. Track the life of your objects
    throughout your code and
  28. clean up references when
    you no longer need them.
  29. Okay, so in the next slide,
  30. we'll identify what might
    be causing this leak.