Spanish subtitles

← 04-02 Memory,_GC,_and_Performance

04-02 Memory,_GC,_and_Performance

Get Embed Code
13 Languages

Showing Revision 7 created 02/08/2016 by sp16.

  1. Ahora que todo nuestro código
    se ejecuta rápido y genial, hablemos
  2. un poco más acerca de la memoria y cómo
    afecta el rendimiento en nuestro sistema.
  3. Muchos lenguajes de programación
    conocidos por ser cercanos al hardware,
  4. o más bien, de alto desempeño
    como C, C++
  5. y Fortran, los programadores suelen tener
    que administrar la memoria ellos mismos.
  6. Los programadores son los responsables
  7. de asignar un bloque de memoria
    y, posteriormente, desasignarlo
  8. cuando han terminado de utilizarlo,
  9. dado que uno mismo define cuándo y
    cuánta memoria asignar, toda la
  10. calidad de la administración de memoria
    depende de tus habilidades y efectividad.
  11. Es mucha responsabilidad.
  12. Y la realidad es que los programadores
    no siempre son los mejores en controlar
  13. todos esos trocitos de memoria.
  14. Piénsalo, el desarrollo
    de productos es laborioso y
  15. agitado, y muchas veces la memoria
    acaba no siendo liberada correctamente.
  16. Esos bloques de memoria sin liberar
    son llamados fugas de memoria, y andan
  17. por ahí acaparando recursos
    que podrías utilizar en otra parte.
  18. Para reducir este caos, estrés, e incluso
    grandes pérdidas monetarias,
  19. causadas por fugas de memoria, se crearon
    los lenguajes de memoria administrada.
  20. Los tiempos de ejecución de estos
    lenguajes rastrean las asignaciones y
  21. liberan memoria al sistema
    cuando ya no le hace falta
  22. a la aplicación en sí misma. Sin ninguna
    intervención por parte del programador.
  23. Este arte, o más bien ciencia,
    de recuperar memoria en un ambiente
  24. de memoria administrada, se conoce como
    "recolección de basura", el concepto
  25. fue creado en 1959 por John McCarthy para
    resolver problemas en el lenguaje LISP.
  26. Los principios básicos de recolección
    de basura son: número uno,
  27. encontrar objetos de datos en un programa
    al que no se puede acceder en el futuro,
  28. por ejemplo, cualquier memoria que ya
    no esté referida por el código.
  29. Y número dos, recuperar los recursos
    utilizados por dichos objetos.
  30. El concepto es simple en teoría,
    pero se vuelve bastante complejo
  31. cuando tienes 2 millones de líneas
    de código y cuatro gigas de asignaciones.
  32. Piénsalo, la recolección de basura
    puede ser realmente irritante,
  33. si tienes unas 20.000 asignaciones
    en tu programa ahora mismo,
  34. ¿cuales ya no se necesitan?
  35. O mejor, ¿cuándo debes ejecutar un evento
    de recolección de basura
  36. para liberar memoria sin utilizar?
  37. Éstas preguntas son realmente difíciles y
  38. afortunadamente, hemos tenido unos
    50 años de innovación para mejorarlas.
  39. Por eso el recolector de basura
    en el tiempo de ejecución de Android
  40. es bastante más sofisticado que
    la propuesta original de McCarthy.
  41. Ha sido creado para ser tan rápido y
    no invasivo como sea posible.
  42. En efecto, las pilas de memoria
    en los tiempos de ejecución de Android
  43. están segmentadas en espacios
  44. basado en el tipo de asignación y
  45. en cómo el sistema puede organizar mejor
    las asignaciones para futuros eventos GC.
  46. Cuando se asigna un nuevo objeto,
  47. estas características son tomadas en
    cuenta para ajustarse a los espacios
  48. más adecuados, dependiendo de la versión
    del tiempo de ejecución Android que uses.
  49. Y aquí viene lo importante:
  50. cada espacio tiene un tamaño específico.
  51. A medida que se asignan objetos, se van
    se van vigilando los tamaños combinados
  52. y cuando el tamaño empieza a crecer, el
    sistema tendrá que ejecutar un evento
  53. de recolección de basura, intentando
    liberar memoria para futuras asignaciones.
  54. Vale destacar que los eventos de GC
    se comportan de forma diferente
  55. dependiendo de cuál tiempo
    de ejecución de Android se utilice.
  56. Por ejemplo, en Dalvik, muchos eventos
    de GC detienen los eventos mundiales,
  57. así, cualquier código administrado
    que se esté ejecutando se detiene
  58. hasta completar la operación.
  59. Lo que genera problemas cuando los GC
    tardan más de lo normal, o cuando
  60. ocurren muchos al mismo tiempo.
  61. dado que van a consumir parte
    significativa de tu tiempo.
  62. y, seamos claros,
  63. los ingenieros de Android han invertido
    mucho tiempo en asegurarse de que
  64. estos eventos sean lo más rápidos posible
    para evitar interrupciones.
  65. Dicho esto, pueden causar problemas en el
    desempeño de aplicaciones en tu código.
  66. En primer lugar, entiende que, mientras
    más tiempo pase tu app haciendo GC
  67. en cierto marco, menos tiempo tendrá para
    el resto de la lógica que necesita para
  68. mantenerte bajo la barrera de
    renderización de 16 milisegundos.
  69. Así que, si tienes muchos GC, o
    algunos muy largos que ocurren uno
  70. tras otro, eso podría ubicar tu tiempo de
    procesamiento de cuadros por sobre
  71. los 16 milisegundos
  72. que es la barrera de renderización, lo
    que causaría ralentización o fallas
  73. a tus usuarios.
  74. En segundo lugar, entiende que el flujo
    del código puede estar haciendo cosas
  75. que obliguen a eventos GC más frecuentes
    o más largos de lo normal.
  76. Por ejemplo, si estás asignando muchos
    objetos en la parte interior
  77. de un lazo que se ejecuta durante largo
    tiempo, contaminarás
  78. tu pila de memoria con muchos objetos
    y acabarás generando muchos GC
  79. rápidamente, debido a ésta
    presión adicional sobre la memoria.
  80. Incluso considerando que estamos en
    un ambiente de memoria administrada,
  81. pueden ocurrir fugas de memoria.
  82. Aunque no es tan fácil crearlas
    como en otros lenguajes.
  83. Estas fugas pueden contaminar tu pila
    con objetos que no se liberan
  84. durante un evento GC, reduciendo
    efectivamente el espacio utilizable y
  85. obligando a que ocurran
    más eventos GC con regularidad.
  86. Así que eso es,
  87. si quieres reducir la cantidad de GC
    que ocurren en un cierto plazo,
  88. debes enfocarte en optimizar
    el uso de memoria de las apps.
  89. Desde una perspectiva de código, puede
    ser difícil detectar de dónde
  90. salen éstos problemas, pero
  91. afortunadamente, el Android SDK pone
    un juego de poderosas herramientas
  92. a tu disposición.
  93. Veamos.