0:00:00.280,0:00:04.310
Una de las mejores cosas[br]del lenguaje Java de Android

0:00:04.310,0:00:08.470
es que es un ambiente[br]de memoria administrada

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

0:00:11.750,0:00:12.680
Si bien esto es genial,

0:00:12.680,0:00:17.330
hay algunos problemas de desempeño[br]acechando bajo la superficie.

0:00:17.330,0:00:20.330
Recuerda que las pilas de memoria[br]en los tiempos de ejecución de Android

0:00:20.330,0:00:23.720
están segmentadas en espacios[br]basado en el tipo de asignación

0:00:23.720,0:00:27.980
y en cómo el sistema organiza mejor[br]las asignaciones para eventos GC futuros.

0:00:27.980,0:00:30.580
Y cada espacio tiene su propio[br]tamaño de memoria reservada.

0:00:30.580,0:00:34.140
Cuando el tamaño combinado[br]de un objeto en un espacio

0:00:34.140,0:00:38.050
se acerca al límite máximo[br]se inicia un recolector de basura

0:00:38.050,0:00:40.250
para liberar espacio y eliminar[br]objetos innecesarios.

0:00:40.250,0:00:43.935
Éstos eventos GC generalmente no son[br]un problema de desempeño perceptible.

0:00:43.935,0:00:46.369
Pero, muchos de ellos[br]ocurriendo una y otra vez

0:00:46.369,0:00:48.915
pueden terminar consumiendo[br]todo tu tiempo de recuadro.

0:00:48.915,0:00:50.725
Mientras más tiempo pasas con los GC

0:00:50.725,0:00:54.492
menos tiempo tendrás para otras cosas,[br]como renderizar o transmitir audio.

0:00:54.492,0:00:57.632
Una situación común en la cual[br]caen muchos desarrolladores, que causa

0:00:57.632,0:01:00.792
que causa que ocurran GC[br]se conoce como fuga de memoria.

0:01:00.792,0:01:04.272
Las fugas de memoria son objetos[br]que la aplicación ya no utiliza

0:01:04.272,0:01:07.402
pero que el recolector de basura[br]no reconoce como "sin utilizar".

0:01:07.402,0:01:09.502
El resultado es que permanecen[br]residiendo en la pila,

0:01:09.502,0:01:13.282
ocupando espacio valioso[br]que no se libera para otros objetos.

0:01:13.282,0:01:14.542
A medida que se fuga memoria,

0:01:14.542,0:01:17.802
el espacio disponible en la generación[br]de la pila va disminuyendo

0:01:17.802,0:01:22.230
más y más, lo que implica que habrá[br]más GC ejecutándose con más frecuencia

0:01:22.230,0:01:25.490
para tratar de liberar espacio para[br]ejecutar normalmente los programas.

0:01:25.490,0:01:28.530
El encontrar y reparar fugas de memoria[br]es cosa complicada.

0:01:28.530,0:01:30.040
Algunas fugas se crean fácilmente,

0:01:30.040,0:01:33.790
como al hacer referencias circulares[br]a objetos que el programa no utiliza.

0:01:33.790,0:01:35.410
Mientras que otros no son tan simples,

0:01:35.410,0:01:39.680
como el mantener objetos cargadores[br]de clase mientras se cargan.

0:01:39.680,0:01:42.440
En todo caso, una aplicación rápida[br]y que se ejecuta con fluidez

0:01:43.160,0:01:45.640
debe estar consciente y ser sensible[br]ante posibles de memoria.

0:01:45.640,0:01:48.160
Porque tu código se va a ejecutar[br]en un universo de dispositivos

0:01:48.160,0:01:49.270
de diferentes tipos

0:01:49.270,0:01:52.150
y no todos van a tener el mismo tamaño[br]y consumo de memoria.

0:01:52.150,0:01:55.420
Por suerte, hay una sencilla herramienta[br]que nos ayudará a detectar

0:01:55.420,0:01:57.610
si existen fugas, dentro del kit SDK[br]de Android.

0:01:57.610,0:01:58.800
Veamos.