Showing Revision 6 created 02/13/2016 by QA_SP_6_SP.

1. Title:
   04-04 Memory_Leaks
2. Description:

   04-04 Memory_Leaks

3. 280 0:00 - 0:04
   Una de las mejores cosas
   del lenguaje Java de Android
4. 4310 0:04 - 0:08
   es que es un ambiente
   de memoria administrada
5. 8470 0:08 - 0:12
   es decir, no hay que ser súper cuidadoso
   con la creación o destrucción de objetos.
6. 11750 0:12 - 0:13
   Si bien esto es genial,
7. 12680 0:13 - 0:17
   hay algunos problemas de desempeño
   acechando bajo la superficie.
8. 17330 0:17 - 0:20
   Recuerda que las pilas de memoria
   en los tiempos de ejecución de Android
9. 20330 0:20 - 0:24
   están segmentadas en espacios
   basado en el tipo de asignación
10. 23720 0:24 - 0:28
    y en cómo el sistema organiza mejor
    las asignaciones para eventos GC futuros.
11. 27980 0:28 - 0:31
    Y cada espacio tiene su propio
    tamaño de memoria reservada.
12. 30580 0:31 - 0:34
    Cuando el tamaño combinado
    de un objeto en un espacio
13. 34140 0:34 - 0:38
    se acerca al límite máximo
    se inicia un recolector de basura
14. 38050 0:38 - 0:40
    para liberar espacio y eliminar
    objetos innecesarios.
15. 40250 0:40 - 0:44
    Éstos eventos GC generalmente no son
    un problema de desempeño perceptible.
16. 43935 0:44 - 0:46
    Pero, muchos de ellos
    ocurriendo una y otra vez
17. 46369 0:46 - 0:49
    pueden terminar consumiendo
    todo tu tiempo de recuadro.
18. 48915 0:49 - 0:51
    Mientras más tiempo pasas con los GC
19. 50725 0:51 - 0:54
    menos tiempo tendrás para otras cosas,
    como renderizar o transmitir audio.
20. 54492 0:54 - 0:58
    Una situación común en la cual
    caen muchos desarrolladores, que causa
21. 57632 0:58 - 1:01
    que causa que ocurran GC
    se conoce como fuga de memoria.
22. 60792 1:01 - 1:04
    Las fugas de memoria son objetos
    que la aplicación ya no utiliza
23. 64272 1:04 - 1:07
    pero que el recolector de basura
    no reconoce como "sin utilizar".
24. 67402 1:07 - 1:10
    El resultado es que permanecen
    residiendo en la pila,
25. 69502 1:10 - 1:13
    ocupando espacio valioso
    que no se libera para otros objetos.
26. 73282 1:13 - 1:15
    A medida que se fuga memoria,
27. 74542 1:15 - 1:18
    el espacio disponible en la generación
    de la pila va disminuyendo
28. 77802 1:18 - 1:22
    más y más, lo que implica que habrá
    más GC ejecutándose con más frecuencia
29. 82230 1:22 - 1:25
    para tratar de liberar espacio para
    ejecutar normalmente los programas.
30. 85490 1:25 - 1:29
    El encontrar y reparar fugas de memoria
    es cosa complicada.
31. 88530 1:29 - 1:30
    Algunas fugas se crean fácilmente,
32. 90040 1:30 - 1:34
    como al hacer referencias circulares
    a objetos que el programa no utiliza.
33. 93790 1:34 - 1:35
    Mientras que otros no son tan simples,
34. 95410 1:35 - 1:40
    como el mantener objetos cargadores
    de clase mientras se cargan.
35. 99680 1:40 - 1:42
    En todo caso, una aplicación rápida
    y que se ejecuta con fluidez
36. 103160 1:43 - 1:46
    debe estar consciente y ser sensible
    ante posibles de memoria.
37. 105640 1:46 - 1:48
    Porque tu código se va a ejecutar
    en un universo de dispositivos
38. 108160 1:48 - 1:49
    de diferentes tipos
39. 109270 1:49 - 1:52
    y no todos van a tener el mismo tamaño
    y consumo de memoria.
40. 112150 1:52 - 1:55
    Por suerte, hay una sencilla herramienta
    que nos ayudará a detectar
41. 115420 1:55 - 1:58
    si existen fugas, dentro del kit SDK
    de Android.
42. 117610 1:58 - 1:59
    Veamos.