WEBVTT

00:00:00.280 --> 00:00:04.310
Una de las mejores cosas
del lenguaje Java de Android

00:00:04.310 --> 00:00:08.470
es que es un ambiente
de memoria administrada

00:00:08.470 --> 00:00:11.750
es decir, no hay que ser súper cuidadoso
con la creación o destrucción de objetos.

00:00:11.750 --> 00:00:12.680
Si bien esto es genial,

00:00:12.680 --> 00:00:17.330
hay algunos problemas de desempeño
acechando bajo la superficie.

00:00:17.330 --> 00:00:20.330
Recuerda que las pilas de memoria
en los tiempos de ejecución de Android

00:00:20.330 --> 00:00:23.720
están segmentadas en espacios
basado en el tipo de asignación

00:00:23.720 --> 00:00:27.980
y en cómo el sistema organiza mejor
las asignaciones para eventos GC futuros.

00:00:27.980 --> 00:00:30.580
Y cada espacio tiene su propio
tamaño de memoria reservada.

00:00:30.580 --> 00:00:34.140
Cuando el tamaño combinado
de un objeto en un espacio

00:00:34.140 --> 00:00:38.050
se acerca al límite máximo
se inicia un recolector de basura

00:00:38.050 --> 00:00:40.250
para liberar espacio y eliminar
objetos innecesarios.

00:00:40.250 --> 00:00:43.935
Éstos eventos GC generalmente no son
un problema de desempeño perceptible.

00:00:43.935 --> 00:00:46.369
Pero, muchos de ellos
ocurriendo una y otra vez

00:00:46.369 --> 00:00:48.915
pueden terminar consumiendo
todo tu tiempo de recuadro.

00:00:48.915 --> 00:00:50.725
Mientras más tiempo pasas con los GC

00:00:50.725 --> 00:00:54.492
menos tiempo tendrás para otras cosas,
como renderizar o transmitir audio.

00:00:54.492 --> 00:00:57.632
Una situación común en la cual
caen muchos desarrolladores, que causa

00:00:57.632 --> 00:01:00.792
que causa que ocurran GC
se conoce como fuga de memoria.

00:01:00.792 --> 00:01:04.272
Las fugas de memoria son objetos
que la aplicación ya no utiliza

00:01:04.272 --> 00:01:07.402
pero que el recolector de basura
no reconoce como "sin utilizar".

00:01:07.402 --> 00:01:09.502
El resultado es que permanecen
residiendo en la pila,

00:01:09.502 --> 00:01:13.282
ocupando espacio valioso
que no se libera para otros objetos.

00:01:13.282 --> 00:01:14.542
A medida que se fuga memoria,

00:01:14.542 --> 00:01:17.802
el espacio disponible en la generación
de la pila va disminuyendo

00:01:17.802 --> 00:01:22.230
más y más, lo que implica que habrá
más GC ejecutándose con más frecuencia

00:01:22.230 --> 00:01:25.490
para tratar de liberar espacio para
ejecutar normalmente los programas.

00:01:25.490 --> 00:01:28.530
El encontrar y reparar fugas de memoria
es cosa complicada.

00:01:28.530 --> 00:01:30.040
Algunas fugas se crean fácilmente,

00:01:30.040 --> 00:01:33.790
como al hacer referencias circulares
a objetos que el programa no utiliza.

00:01:33.790 --> 00:01:35.410
Mientras que otros no son tan simples,

00:01:35.410 --> 00:01:39.680
como el mantener objetos cargadores
de clase mientras se cargan.

00:01:39.680 --> 00:01:42.440
En todo caso, una aplicación rápida
y que se ejecuta con fluidez

00:01:43.160 --> 00:01:45.640
debe estar consciente y ser sensible
ante posibles de memoria.

00:01:45.640 --> 00:01:48.160
Porque tu código se va a ejecutar
en un universo de dispositivos

00:01:48.160 --> 00:01:49.270
de diferentes tipos

00:01:49.270 --> 00:01:52.150
y no todos van a tener el mismo tamaño
y consumo de memoria.

00:01:52.150 --> 00:01:55.420
Por suerte, hay una sencilla herramienta
que nos ayudará a detectar

00:01:55.420 --> 00:01:57.610
si existen fugas, dentro del kit SDK
de Android.

00:01:57.610 --> 00:01:58.800
Veamos.