WEBVTT

00:00:00.000 --> 00:00:01.680
>> Sintonice la
Xamarin Mostrar dónde

00:00:01.680 --> 00:00:03.360
mi buen amigo Alexi en hablar

00:00:03.360 --> 00:00:06.810
sobre la gestión de la memoria para
sus aplicaciones. Así que sintoniza.

00:00:06.810 --> 00:00:13.200
[MUSICA]

00:00:13.200 --> 00:00:14.280
>> Bienvenidos de nuevo, todos,

00:00:14.280 --> 00:00:15.405
a la demostración de Xamarin.

00:00:15.405 --> 00:00:16.650
Soy su anfitrión James Montemagno.

00:00:16.650 --> 00:00:17.820
Hoy, mi mejor amigo en

00:00:17.820 --> 00:00:21.270
el mundo entero Alexi con
yo. ¿Cómo te va, amigo?

00:00:21.270 --> 00:00:22.905
>> Estoy bien. ¿Y tú?

00:00:22.905 --> 00:00:24.960
>> Lo estoy haciendo fantástico.
Es un hermoso día

00:00:24.960 --> 00:00:26.640
aquí en Redmond, Washington todos los días.

00:00:26.640 --> 00:00:27.325
>> Lo es.

00:00:27.325 --> 00:00:29.085
>> Ahora, eres de nuestro móvil

00:00:29.085 --> 00:00:31.065
asesoramiento al cliente
equipo, ¿es eso correcto?

00:00:31.065 --> 00:00:31.920
>> Eso es correcto.

00:00:31.920 --> 00:00:33.450
>> Entonces, ¿qué significa eso?

00:00:33.450 --> 00:00:35.370
>> Significa que trabajamos con

00:00:35.370 --> 00:00:38.250
nuestros clientes y nosotros
aconsejarles obviamente.

00:00:38.250 --> 00:00:41.645
Pero sobre todo, trabajamos con desarrolladores
y ver cómo usan las herramientas,

00:00:41.645 --> 00:00:44.300
cómo funcionan con nuestra herramienta Xamarin,

00:00:44.300 --> 00:00:47.560
y cuáles son los comunes
escollos que enfrentan con.

00:00:47.560 --> 00:00:48.420
>> Perfecto.

00:00:48.420 --> 00:00:50.205
>> Hoy, quiero hablar de

00:00:50.205 --> 00:00:52.355
uno de ellos es la gestión de la memoria.

00:00:52.355 --> 00:00:53.780
>> Te tengo. Sí. Es muy importante

00:00:53.780 --> 00:00:55.730
porque a menudo hablamos
sobre todo lo fresco,

00:00:55.730 --> 00:00:57.155
características de lujo que puede hacer,

00:00:57.155 --> 00:01:00.440
pero queríamos tener este
serie de mejores prácticas

00:01:00.440 --> 00:01:02.340
porque te encuentras con problemas.

00:01:02.340 --> 00:01:03.820
Sucede. Es tan fácil de hacer.

00:01:03.820 --> 00:01:06.345
Gestión de la memoria,
honestamente, soy un noob.

00:01:06.345 --> 00:01:07.770
Realmente no lo sé. Estoy como,

00:01:07.770 --> 00:01:09.560
"Van a matar
mi aplicación en cinco segundos.

00:01:09.560 --> 00:01:11.705
No importa, ¿verdad? Pero
No debería pensar así.

00:01:11.705 --> 00:01:14.210
>> Eso es cierto. Eso es lo que vemos

00:01:14.210 --> 00:01:16.850
porque a nadie le importa
la gestión de la memoria.

00:01:16.850 --> 00:01:21.300
Tenemos tanta memoria
y nunca los revisas.

00:01:21.300 --> 00:01:24.750
Quiero decir, ¿cuándo fue la última vez que
comprobar el uso de la memoria de la aplicación?

00:01:24.750 --> 00:01:26.250
>> La última vez que tuve un accidente.

00:01:26.250 --> 00:01:29.510
En realidad, tuve un muy
buen ejemplo de esto.

00:01:29.510 --> 00:01:31.910
Te diré esto. éste
es un ejemplo del mundo real.

00:01:31.910 --> 00:01:35.120
Tengo un error en Xamarin Essentials

00:01:35.120 --> 00:01:38.375
que dice cuando llamo
este método 20.000 veces,

00:01:38.375 --> 00:01:41.570
mi aplicación se bloquea y
fue porque yo no era

00:01:41.570 --> 00:01:45.155
eliminación adecuada de un
objeto Nativo de Android,

00:01:45.155 --> 00:01:46.775
una ventana, una pantalla.

00:01:46.775 --> 00:01:48.170
Así que lo que está pasando es,

00:01:48.170 --> 00:01:50.480
Yo seguiría creándolo
y nunca llegaría

00:01:50.480 --> 00:01:53.135
basura recogida nunca porque
Nunca lo deshice.

00:01:53.135 --> 00:01:54.890
>> Eso es lo que vamos
para hablar de hoy.

00:01:54.890 --> 00:01:56.925
>> Sí. Impresionante. Vamos a hacer
eso. ¿Qué tienes para nosotros?

00:01:56.925 --> 00:02:00.435
>> Así que tenemos este pequeño
aplicación simple con dos ventanas,

00:02:00.435 --> 00:02:02.745
pantalla principal y pantalla detallada.

00:02:02.745 --> 00:02:06.375
Ese es un patrón muy común
Controlador de navegación de la interfaz de usuario.

00:02:06.375 --> 00:02:09.600
Este es un Xamarin simple
aplicación iOS, ¿verdad?

00:02:09.600 --> 00:02:10.305
>> Está bien.

00:02:10.305 --> 00:02:12.440
>> Lo que vamos
hacer es introducir

00:02:12.440 --> 00:02:14.930
fugas de memoria en muchos,
muchas maneras diferentes.

00:02:14.930 --> 00:02:19.025
Pero primero, quiero hablar de
las diferencias con el mundo nativo

00:02:19.025 --> 00:02:23.960
y el mundo administrado
rendimiento y memoria.

00:02:23.960 --> 00:02:25.340
Así que cada vez que tienes un proceso,

00:02:25.340 --> 00:02:27.995
sistema operativo dando
que un trozo de memoria.

00:02:27.995 --> 00:02:31.370
Usted debe ser consciente de que
porque una vez que te quedes sin memoria,

00:02:31.370 --> 00:02:33.670
la aplicación se bloquea o
el sistema operativo lo mata.

00:02:33.670 --> 00:02:35.355
En la memoria administrada,

00:02:35.355 --> 00:02:40.260
nuestro Xamarin Mono conseguir estos
pequeña parte de esta memoria.

00:02:40.260 --> 00:02:41.630
Ahí es cuando deberíamos estar

00:02:41.630 --> 00:02:43.670
cauteloso sobre cómo
usar esa pieza también.

00:02:43.670 --> 00:02:44.030
>> Está bien.

00:02:44.030 --> 00:02:46.640
>> Así que todavía debe ser
conscientede de la memoria nativa,

00:02:46.640 --> 00:02:48.905
y ahora, una vez que trabaje con Xamarin,

00:02:48.905 --> 00:02:50.320
también consciente de la parte de gestión.

00:02:50.320 --> 00:02:52.740
>> Lo tengo. Así que tienes
memoria nativa, iOS,

00:02:52.740 --> 00:02:55.980
Bits y piezas de Android,
¿Memoria administrada de .NET?

00:02:55.980 --> 00:02:56.640
>> Así es.

00:02:56.640 --> 00:02:57.090
>> Perfecto.

00:02:57.090 --> 00:03:00.530
>> Cada vez que se crea un objeto
y creas, digamos,

00:03:00.530 --> 00:03:02.330
un botón de interfaz de usuario, en realidad se crea

00:03:02.330 --> 00:03:04.950
un botón nativo de la interfaz de usuario y
clase de botón de interfaz de usuario administrada.

00:03:04.950 --> 00:03:06.680
Tienen un impacto de memoria diferente.

00:03:06.680 --> 00:03:10.310
Podrían causar diferentes
problemas de memoria porque hay

00:03:10.310 --> 00:03:14.135
también una forma nativa de recoger
basura y manera administrada.

00:03:14.135 --> 00:03:20.385
En Mono, usamos Mono single
generación de recolector de basura.

00:03:20.385 --> 00:03:23.460
En el mundo nativo, iOS usa ARC,

00:03:23.460 --> 00:03:26.680
Android usa su propio
Recolector

00:03:26.680 --> 00:03:29.420
pero deben trabajar juntos
lado a lado y debemos

00:03:29.420 --> 00:03:32.300
tenerlos porque se puede
introducir problemas mediante el uso de eso.

00:03:32.300 --> 00:03:32.690
>> Lo tengo.

00:03:32.690 --> 00:03:34.640
>> Así que el primero y

00:03:34.640 --> 00:03:36.950
el enfoque más simple para introducir

00:03:36.950 --> 00:03:40.830
un problema de memoria es una suscripción
sin dessuscripción.

00:03:42.040 --> 00:03:45.680
El recolector de basura debe saber
cuando hay una basura.

00:03:45.680 --> 00:03:47.180
Pero, ¿cómo podría saberlo?

00:03:47.180 --> 00:03:49.565
Debe ser capaz de construir

00:03:49.565 --> 00:03:53.915
un gráfico de árbol de accesibilidad
y comienza en las rutas.

00:03:53.915 --> 00:03:57.320
Nuestros eventos estáticos, variables estáticas,

00:03:57.320 --> 00:03:59.350
eventos estáticos o llamadas de rollo de subprocesos,

00:03:59.350 --> 00:04:01.910
todas son rutas accesibles y

00:04:01.910 --> 00:04:05.005
golosinas de recolector de basura
ellos como no basura.

00:04:05.005 --> 00:04:06.810
Así que cada vez que te suscribes así,

00:04:06.810 --> 00:04:09.560
vamos a tomar el plugin de conectividad.

00:04:09.560 --> 00:04:11.960
Lo sé, James, estás
familiarizado con este plugin.

00:04:11.960 --> 00:04:13.400
>> Lo soy. Sí. Sí, mucho.

00:04:13.400 --> 00:04:14.960
Me gusta eso. En
aquí, ¿somos sólo qué?

00:04:14.960 --> 00:04:16.220
Suscribirse a un evento,

00:04:16.220 --> 00:04:18.610
y podría ser cualquier
eventos como el evento de clic,

00:04:18.610 --> 00:04:20.360
tiene un evento de cambio de sensor.

00:04:20.360 --> 00:04:22.715
Básicamente, cualquier cosa en .NET.

00:04:22.715 --> 00:04:25.970
>> Sí. Es específico
no sólo a Xamarin.

00:04:25.970 --> 00:04:27.830
Es cualquier evento estático

00:04:27.830 --> 00:04:31.745
en .NET y conectividad
aquí es sólo un ejemplo.

00:04:31.745 --> 00:04:35.390
Lo que estoy tratando de decir, que
podría ser cualquier evento estático o

00:04:35.390 --> 00:04:38.960
cualquier evento proporcionado por singleton.

00:04:38.960 --> 00:04:40.880
Así que cada vez que nos suscribemos así,

00:04:40.880 --> 00:04:42.520
y digamos que tenemos

00:04:42.520 --> 00:04:47.100
este pequeño pedazo de
Controlador ConnectivityChanged.

00:04:47.100 --> 00:04:49.655
Presentamos una pequeña pérdida de memoria.

00:04:49.655 --> 00:04:54.290
Es pequeño porque nuestra visión es
bastante simple y ligero,

00:04:54.290 --> 00:04:55.400
pero es una pérdida de memoria.

00:04:55.400 --> 00:04:57.685
>> Así que es una pérdida de memoria, ¿por qué?

00:04:57.685 --> 00:05:00.860
>> Debido a que esta conectividad y

00:05:00.860 --> 00:05:03.830
Evento ConnectivityChanged
es una referencia estática

00:05:03.830 --> 00:05:05.270
para nuestro recolector de basura.

00:05:05.270 --> 00:05:06.980
Una vez que nuestra basura
coleccionista está tratando de

00:05:06.980 --> 00:05:08.810
identificar si es una basura o no,

00:05:08.810 --> 00:05:11.015
no es porque

00:05:11.015 --> 00:05:14.540
El evento ConnectivityChanged tiene
una referencia a este manejador,

00:05:14.540 --> 00:05:17.375
y este manejador en realidad maneja

00:05:17.375 --> 00:05:21.080
la referencia a nuestra
DetailsViewController.

00:05:21.080 --> 00:05:24.680
>> Ya veo. Entiendo. Así que hemos
creó este evento dentro de

00:05:24.680 --> 00:05:29.600
este ViewController y yo hemos
suscrito pero nunca se canceló la suscripción.

00:05:29.600 --> 00:05:31.970
Así que siempre tiene esto
referencia de inmediato.

00:05:31.970 --> 00:05:34.940
Así que los recolectores de basura dicen,
"Oye, ¿qué hay disponible?"

00:05:34.940 --> 00:05:37.030
"No puedes tener eso".

00:05:37.030 --> 00:05:38.205
>> Eso es correcto.

00:05:38.205 --> 00:05:40.580
>> Quiero asegurarme de que
eso es correcto porque

00:05:40.580 --> 00:05:42.185
creo que así es como
funciona en mi mente.

00:05:42.185 --> 00:05:43.150
Quiero asegurarme de que tengo razón.

00:05:43.150 --> 00:05:47.225
>> El recolector de elementos no utilizados de una sola tarea
hacer es desasignar la memoria,

00:05:47.225 --> 00:05:48.605
y hacerlo correctamente,

00:05:48.605 --> 00:05:50.540
recolector de basura debe saber cómo

00:05:50.540 --> 00:05:52.730
identificar adecuadamente si
es basura o no.

00:05:52.730 --> 00:05:53.180
>> Lo tengo.

00:05:53.180 --> 00:05:55.790
>> Así que para construir un árbol de accesibilidad,

00:05:55.790 --> 00:05:59.270
un recolector de basura
utiliza rutas estáticas o

00:05:59.270 --> 00:06:01.430
sólo rutas y eventos estáticos

00:06:01.430 --> 00:06:03.500
o cualquier propiedad estática
como una de las rutas.

00:06:03.500 --> 00:06:06.460
También variables locales,
un montón de otras cosas.

00:06:06.460 --> 00:06:07.020
>> Lo tengo.

00:06:07.020 --> 00:06:11.820
>> Así que permítanme ejecutarlo
y mostrar cómo funciona.

00:06:11.820 --> 00:06:14.745
¿Crees que vamos a
ver alguna diferencia?

00:06:14.745 --> 00:06:17.540
>> No lo sé. Quiero decir
esperemos que no porque

00:06:17.540 --> 00:06:20.090
es tan simple es lo que estoy pensando.

00:06:20.090 --> 00:06:22.160
Ahora, mi miedo sin embargo es que

00:06:22.160 --> 00:06:24.200
ya que nos estamos registrando más de
y una y otra vez,

00:06:24.200 --> 00:06:26.750
si cambiamos los eventos,

00:06:26.750 --> 00:06:28.850
probablemente estamos recibiendo
en muchos eventos.

00:06:28.850 --> 00:06:30.635
>> Sí. Vamos a verificarlo.

00:06:30.635 --> 00:06:33.560
Así que me he movido a la página Detalles.

00:06:33.560 --> 00:06:36.185
Voy a desconectar mi Wi-Fi ahora.

00:06:36.185 --> 00:06:38.510
>> Aquí, estamos usando
el simulador de iOS.

00:06:38.510 --> 00:06:41.975
Así que en realidad está usando
Internet de la máquina.

00:06:41.975 --> 00:06:46.460
>> Sí. Acabamos de llegar a un evento aquí
que son ConnectivityChanged.

00:06:46.460 --> 00:06:51.910
Volvamos un par de veces
y unas cuantas veces más,

00:06:51.910 --> 00:06:54.630
y estoy de vuelta en la página principal.

00:06:54.630 --> 00:06:58.215
No soy delicado en
cualquier cosa en este momento,

00:06:58.215 --> 00:07:01.280
y asumo que mis datos
página ya no están allí, ¿verdad?

00:07:01.280 --> 00:07:01.430
>> Sí.

00:07:01.430 --> 00:07:02.810
>> Mi controlador de suscripciones

00:07:02.810 --> 00:07:04.805
no debería funcionar porque
No hice nada.

00:07:04.805 --> 00:07:07.015
Encendemos el Wi-Fi.

00:07:07.015 --> 00:07:09.510
>> Está bien. Así que en realidad creamos

00:07:09.510 --> 00:07:11.910
este ConnectivityChanged
en la segunda página.

00:07:11.910 --> 00:07:12.420
>> Segunda página.

00:07:12.420 --> 00:07:13.665
>> Bueno, estoy en la primera página.

00:07:13.665 --> 00:07:17.440
>> Sí. Así que no esperamos
nuestro manejador para trabajar,

00:07:17.440 --> 00:07:18.645
pero mira lo que tenemos.

00:07:18.645 --> 00:07:21.090
Acabamos de conseguir cuatro manejadores
ejecutando nuestro código,

00:07:21.090 --> 00:07:23.600
y podría ser cualquier
base de datos de actualización de código,

00:07:23.600 --> 00:07:25.505
guardar la configuración, lo que sea.

00:07:25.505 --> 00:07:28.070
El tema aquí no sólo
con la gestión de la memoria

00:07:28.070 --> 00:07:30.635
porque se necesita algo de memoria.

00:07:30.635 --> 00:07:34.970
También es un problema porque tenemos
algún código que se ejecutará también.

00:07:34.970 --> 00:07:37.445
>> Entonces significa eso
que la página Detalles,

00:07:37.445 --> 00:07:39.350
ahora nunca puede ser
basura recogida?

00:07:39.350 --> 00:07:42.455
Así que ahora sólo tengo esto
Página de detalles siempre en la memoria.

00:07:42.455 --> 00:07:43.400
>> Desafortunadamente, sí.

00:07:43.400 --> 00:07:44.660
>> Oh Dios mío, eso es malo.

00:07:44.660 --> 00:07:47.385
>> Eso es malo. Como desarrollador,

00:07:47.385 --> 00:07:49.560
no siempre vemos eso.

00:07:49.560 --> 00:07:54.280
Como usuario, veo que mi aplicación se bloquea
como una vez a la semana, lo que sea.

00:07:54.280 --> 00:07:56.675
Voy a reiniciarlo
y seguir utilizándolo.

00:07:56.675 --> 00:07:58.220
Por eso no se informa,

00:07:58.220 --> 00:08:00.350
no se toma muy en serio,

00:08:00.350 --> 00:08:03.950
pero es un problema especialmente si

00:08:03.950 --> 00:08:08.330
obtener una imagen enorme allí
que afecta a su memoria.

00:08:08.330 --> 00:08:10.910
Así que voy a descomentar
esta línea de código,

00:08:10.910 --> 00:08:14.680
que en realidad añade algo de carga de memoria

00:08:14.680 --> 00:08:19.740
aquí y está cargando un
imagen de Internet.

00:08:19.740 --> 00:08:22.265
Sólo estamos tomando una imagen al azar.

00:08:22.265 --> 00:08:24.815
Permítanme mostrarles que es realmente aleatorio.

00:08:24.815 --> 00:08:27.035
Veamos qué tenemos aquí.

00:08:27.035 --> 00:08:29.510
Siempre me preocupa.

00:08:29.510 --> 00:08:32.210
Bien. Así que tenemos esta imagen aleatoria,

00:08:32.210 --> 00:08:34.370
y eso es lo que somos
va a cargar en

00:08:34.370 --> 00:08:37.190
nuestra aplicación cada vez que
ir a la página De detalles.

00:08:37.190 --> 00:08:37.610
>> Está bien.

00:08:37.610 --> 00:08:40.395
>> Permítanme mostrarlo aquí.

00:08:40.395 --> 00:08:42.970
>> Esto es totalmente algo
que lo que siempre pasa, ¿verdad?

00:08:42.970 --> 00:08:45.220
Porque vaya a una página De detalles,

00:08:45.220 --> 00:08:46.740
probablemente carguen algo de información,

00:08:46.740 --> 00:08:48.080
podría estar tirando de algunos
información de

00:08:48.080 --> 00:08:51.095
una base de datos en esa pantalla,
y eso podría ser malo.

00:08:51.095 --> 00:08:53.930
>> Imagínate a ti mismo que estás
usando la aplicación Instagram.

00:08:53.930 --> 00:08:55.330
Tienes una página de Detalles allí.

00:08:55.330 --> 00:08:56.710
Tocas y sigues,

00:08:56.710 --> 00:08:58.435
entrar en detalles, volver.

00:08:58.435 --> 00:09:00.720
Ve a revisar otra carpeta,
entrar en detalles,

00:09:00.720 --> 00:09:03.920
volvió, y en una semana su aplicación
accidentes y nadie sabe por qué.

00:09:03.920 --> 00:09:06.680
Ahí es cuando la memoria tiene problemas
podría entrar en juego.

00:09:06.680 --> 00:09:09.180
>> Te tengo.

00:09:09.180 --> 00:09:11.855
>> No te mostraré que
fuga de memoria todavía está allí

00:09:11.855 --> 00:09:14.650
porque quiero mostrar
usted el generador de perfiles,

00:09:14.650 --> 00:09:16.375
cómo puede identificar estos problemas.

00:09:16.375 --> 00:09:17.800
Para identificar estos problemas,

00:09:17.800 --> 00:09:19.990
tienes algunas herramientas.

00:09:19.990 --> 00:09:23.350
En primer lugar, son herramientas nativas,
iOs proporciona instrumentos,

00:09:23.350 --> 00:09:25.520
y la segunda es la herramienta de gestión,

00:09:25.520 --> 00:09:27.005
que es Xamarin Profiler.

00:09:27.005 --> 00:09:27.990
>> Te tengo.

00:09:27.990 --> 00:09:29.520
>> ¿Por qué crees que necesitamos ambas cosas?

00:09:29.520 --> 00:09:32.985
>> Bueno, hacen cosas diferentes.

00:09:32.985 --> 00:09:36.090
>> Sí. Realmente
debido a esta imagen.

00:09:36.090 --> 00:09:38.025
Recordar. Estaba hablando de eso.

00:09:38.025 --> 00:09:41.565
En realidad pueden saber
sobre su propia parte.

00:09:41.565 --> 00:09:44.190
Así que Xamarin Profiler no sabe nada

00:09:44.190 --> 00:09:47.100
sobre la memoria nativa
objetos creados allí,

00:09:47.100 --> 00:09:50.010
y los instrumentos nativos no
saber acerca de la memoria administrada.

00:09:50.010 --> 00:09:52.685
Sólo dice que hay algunos
fragmento de objeto creado.

00:09:52.685 --> 00:09:54.710
Cuando Mono crea un objeto,

00:09:54.710 --> 00:09:57.275
todavía lo une de alguna manera
a objetos nativos.

00:09:57.275 --> 00:09:59.210
Así que aquellos que podrás ver,

00:09:59.210 --> 00:10:00.500
pero todo lo demás no lo será.

00:10:00.500 --> 00:10:01.220
>> Está bien. Fresco.

00:10:01.220 --> 00:10:02.945
>> Así que vamos a ver el generador de perfiles de Xamarin.

00:10:02.945 --> 00:10:06.550
Es más fácil de comprender
al principio,

00:10:06.550 --> 00:10:10.955
y también te muestra agradable
espacio de nombres y como nombrar.

00:10:10.955 --> 00:10:12.815
Para que pueda identificar su objeto.

00:10:12.815 --> 00:10:16.715
Hay un pequeño botón "Ejecutar"
y "Iniciar perfil" aquí.

00:10:16.715 --> 00:10:20.050
Necesitas una empresa
licencia para hacer eso.

00:10:20.050 --> 00:10:23.870
Pero es muy conveniente y
Te animo a que hagas eso.

00:10:23.870 --> 00:10:25.190
Así que una vez que hagas eso,

00:10:25.190 --> 00:10:26.825
en realidad construye la aplicación con

00:10:26.825 --> 00:10:31.130
algunos metadatos adicionales y
código incrustado en la aplicación.

00:10:31.130 --> 00:10:33.580
Así pudimos ver y
rastrear los objetos.

00:10:33.580 --> 00:10:36.140
>> Ahora una cosa mientras que este
está construyendo e implementando es,

00:10:36.140 --> 00:10:38.030
estamos corriendo en un
simulador que significa que

00:10:38.030 --> 00:10:40.520
tiene toda la potencia de esto.

00:10:40.520 --> 00:10:45.320
¿Está bien que lo esté haciendo
y perfilándolo en mi dispositivo,

00:10:45.320 --> 00:10:49.150
o es mejor hacerlo en un
iPhone físico, por ejemplo?

00:10:49.150 --> 00:10:50.570
>> Esa es una buena pregunta porque

00:10:50.570 --> 00:10:52.340
puede hacer diferentes tipos de generación de perfiles.

00:10:52.340 --> 00:10:52.940
>> Interesante.

00:10:52.940 --> 00:10:54.230
>> Si está generando perfiles de CPU,

00:10:54.230 --> 00:10:56.480
no es una buena idea
para hacerlo en el simulador

00:10:56.480 --> 00:10:58.820
porque usted no tiene el
potencia total del dispositivo.

00:10:58.820 --> 00:11:01.340
Pero si estás haciendo un recuerdo
profiler y asignación,

00:11:01.340 --> 00:11:04.355
obtendrá los mismos problemas
en el simulador y en el dispositivo.

00:11:04.355 --> 00:11:04.730
>> Perfecto.

00:11:04.730 --> 00:11:10.300
>> Me gusta hacerlo en el portátil
porque empieza más rápido.

00:11:10.300 --> 00:11:13.010
No traduce el código

00:11:13.010 --> 00:11:16.085
en instrucciones nativas y sólo
simula y se ejecuta al instante.

00:11:16.085 --> 00:11:18.470
Así que cada vez que haces perfiles de memoria,

00:11:18.470 --> 00:11:20.180
si ejecutas aplicaciones tantas veces,

00:11:20.180 --> 00:11:23.045
así que te va a gustar.

00:11:23.045 --> 00:11:25.085
Déjame hacer la misma prueba.

00:11:25.085 --> 00:11:27.980
Así que he abierto la página Detalles una vez,

00:11:27.980 --> 00:11:29.840
y ves este pequeño pico aquí.

00:11:29.840 --> 00:11:33.590
Significa que aumentamos nuestra
uso de la memoria significativamente.

00:11:33.590 --> 00:11:35.915
Pero no ves esto
aumento de la memoria aquí.

00:11:35.915 --> 00:11:38.510
Sigue siendo como el objeto más grande es

00:11:38.510 --> 00:11:40.730
árbol de sistemas y en algún lugar de aquí.

00:11:40.730 --> 00:11:43.155
Déjame hacerlo unas cuantas veces más.

00:11:43.155 --> 00:11:45.815
Lo aumentaré de nuevo.

00:11:45.815 --> 00:11:47.610
Verás el pico aquí,

00:11:47.610 --> 00:11:49.735
pero no ves ningún pico aquí.

00:11:49.735 --> 00:11:53.330
Lo que significa que cuando asignamos
en algo en la memoria nativa,

00:11:53.330 --> 00:11:56.220
no refleja
en el mundo administrado,

00:11:56.220 --> 00:11:59.419
pero vemos que la memoria total es
creciendo y sin desasignar,

00:11:59.419 --> 00:12:00.720
que es lo más importante.

00:12:00.720 --> 00:12:01.455
>> Ya veo.

00:12:01.455 --> 00:12:04.015
>> Volvemos con esta instantánea.

00:12:04.015 --> 00:12:05.710
La instantánea de memoria realmente se ejecuta

00:12:05.710 --> 00:12:07.875
la recolección de basura
en el sitio administrado.

00:12:07.875 --> 00:12:10.195
Así que hacemos esta instantánea.
Haré otro.

00:12:10.195 --> 00:12:11.755
Te lo explicaré más tarde,

00:12:11.755 --> 00:12:14.500
para hacer frente a la señal de finalización.

00:12:14.500 --> 00:12:17.475
Pero básicamente, ahora es memoria limpia.

00:12:17.475 --> 00:12:19.605
Nos aseguraremos de que
nuestro recolector de basura

00:12:19.605 --> 00:12:22.270
ya corrió y desasignado
todo el objeto adquirido.

00:12:22.270 --> 00:12:23.920
Todavía vemos los recuerdos allí.

00:12:23.920 --> 00:12:25.845
Así que todavía se hundió.

00:12:25.845 --> 00:12:28.755
Para saber lo que está pasando aquí,

00:12:28.755 --> 00:12:32.005
sólo vamos aquí y
utilice el botón de filtro.

00:12:32.005 --> 00:12:35.265
Estamos tratando de identificar
sólo objetos R,

00:12:35.265 --> 00:12:38.110
y también quiero ver en
los objetos vivos aquí.

00:12:38.110 --> 00:12:40.980
Así que golpeé este "Aplicar"
botón, y voila,

00:12:40.980 --> 00:12:43.575
vemos dos detalles controlador
colgando de la memoria,

00:12:43.575 --> 00:12:47.160
a pesar de que no
tienen detalles en su lugar.

00:12:47.160 --> 00:12:48.570
>> Súper muestra, así que dijiste,

00:12:48.570 --> 00:12:50.289
encontrar todo en mi espacio-nombre,

00:12:50.289 --> 00:12:51.610
filtrar hacia abajo en eso.

00:12:51.610 --> 00:12:54.820
Literalmente lo que vemos aquí
es Controlador de vista de detalle 2.

00:12:54.820 --> 00:12:55.225
>> Sí.

00:12:55.225 --> 00:12:56.650
>> Pero debe desaparecer.

00:12:56.650 --> 00:13:00.015
>> Voy a empezar con el más grande
objetos que tiene en estas páginas.

00:13:00.015 --> 00:13:00.280
>> Sí.

00:13:00.280 --> 00:13:02.865
>> Es cierto para Android también.

00:13:02.865 --> 00:13:04.030
Sólo buscas actividades,

00:13:04.030 --> 00:13:05.395
ver modelos, o lo que sea,

00:13:05.395 --> 00:13:07.875
porque una vez que tienes una vista
modelo colgando allí,

00:13:07.875 --> 00:13:11.320
empieza a vincular todo
los otros objetos.

00:13:11.320 --> 00:13:13.380
Todos los servicios, todas las fijaciones,

00:13:13.380 --> 00:13:16.605
todas las uSU, y usted
obtener mucha memoria.

00:13:16.605 --> 00:13:17.500
>> Lo tengo.

00:13:17.500 --> 00:13:19.465
>> Permítanme mostrar que es verdad.

00:13:19.465 --> 00:13:23.260
Lo abriré uno más
tiempo, pulse la "Instantánea".

00:13:23.260 --> 00:13:25.455
Vemos tres casos aquí.

00:13:25.455 --> 00:13:28.569
Voy a volver, pulsando "Instantánea",

00:13:28.569 --> 00:13:30.030
y permanece en la memoria.

00:13:30.030 --> 00:13:30.660
>> Te tengo.

00:13:30.660 --> 00:13:32.500
>> Así que vamos a solucionar este problema de memoria.

00:13:32.500 --> 00:13:33.700
>> Estoy listo.

00:13:33.700 --> 00:13:36.470
>> ¿Cómo arreglarías eso?

00:13:41.220 --> 00:13:43.525
Esta es una página de detalles,

00:13:43.525 --> 00:13:45.460
por lo que tenemos que darse de baja
en algún evento.

00:13:45.460 --> 00:13:49.325
>> Te tengo. Así que el verdadero problema aquí
es que me he suscrito a un evento.

00:13:49.325 --> 00:13:49.970
>> Sí.

00:13:49.970 --> 00:13:52.135
>> Entonces debemos cancelar la suscripción, ¿verdad?

00:13:52.135 --> 00:13:54.550
>> Eso es correcto. éste
es una buena práctica.

00:13:54.550 --> 00:13:56.370
Cada vez que veas esto más igual,

00:13:56.370 --> 00:13:59.490
sólo tienes que buscar si
hay un menos igual,

00:13:59.490 --> 00:14:01.980
si no lo es,
debe introducir eso.

00:14:01.980 --> 00:14:02.595
>> Lo tengo.

00:14:02.595 --> 00:14:05.020
>> Esta es la primera indicación
que tienes una pérdida de memoria.

00:14:05.020 --> 00:14:05.340
>> Lo tengo.

00:14:05.340 --> 00:14:10.460
>> La única excepción es cuando
te suscribes en la página principal,

00:14:10.460 --> 00:14:12.285
como nuestra página principal aquí,

00:14:12.285 --> 00:14:14.725
y usted está seguro de que esta página

00:14:14.725 --> 00:14:18.010
no será capaz de ir
lejos en cualquier momento pronto.

00:14:18.010 --> 00:14:20.115
>> Tal vez lo tienes en
los niveles de delegado de la aplicación.

00:14:20.115 --> 00:14:21.530
Eres como, yo en realidad
quiero que esto sea

00:14:21.530 --> 00:14:23.290
un evento global para todos los tiempos.

00:14:23.290 --> 00:14:25.845
Pero también tal vez cuando la aplicación
entra en segundo plano,

00:14:25.845 --> 00:14:27.295
también debe darse de baja.

00:14:27.295 --> 00:14:28.345
>> Eso es cierto.

00:14:28.345 --> 00:14:28.675
>> Sí.

00:14:28.675 --> 00:14:29.700
>> No ejecutar.

00:14:29.700 --> 00:14:31.750
>> Así que ahora estás diciendo
cuando aparece,

00:14:31.750 --> 00:14:33.855
se suscribirá, y desaparecerá,

00:14:33.855 --> 00:14:35.935
darse de baja, y luego
quitar el de arriba.

00:14:35.935 --> 00:14:37.990
>> Sí, me quité de la nube,

00:14:37.990 --> 00:14:39.710
porque queremos
ejecutarlo cada vez que

00:14:39.710 --> 00:14:42.040
aparecen y cada vez que desaparecemos.

00:14:42.040 --> 00:14:43.850
Además de igual para suscribirse,

00:14:43.850 --> 00:14:45.640
menos igual a cancelar la suscripción.

00:14:45.640 --> 00:14:48.735
Nada complicado, sólo quiero

00:14:48.735 --> 00:14:52.045
asegúrese de que no necesitamos ninguna
instrumentos una vez que vaya a través de él.

00:14:52.045 --> 00:14:52.720
>> Genial.

00:14:52.720 --> 00:14:55.110
>> Así que estoy haciendo las mismas cosas,

00:14:55.110 --> 00:14:59.490
yendo a los detalles,
demostrando que es verdad.

00:14:59.490 --> 00:15:02.980
Tomando instantáneas,
filtrar en mis eventos.

00:15:02.980 --> 00:15:05.300
Lo siento. Simplemente ha clic.

00:15:08.700 --> 00:15:12.170
Veamos los objetos vivos.

00:15:12.420 --> 00:15:15.345
Deberíamos ver los detalles
porque actualmente estamos en

00:15:15.345 --> 00:15:17.475
detalles. Vamos a volver.

00:15:17.475 --> 00:15:18.990
Golpeamos una "Instantánea"

00:15:18.990 --> 00:15:20.880
y qué esperamos aquí?

00:15:20.880 --> 00:15:23.715
En primer lugar, la recolección de basura en realidad

00:15:23.715 --> 00:15:26.065
poner estos objetos en
final,

00:15:26.065 --> 00:15:27.625
pero segundo debe indicar 1,

00:15:27.625 --> 00:15:30.340
o probablemente sigue siendo el mismo.

00:15:30.340 --> 00:15:31.570
>> Ahora se ha ido.

00:15:31.570 --> 00:15:33.910
>> Sí. Así que permítanme hablar de

00:15:33.910 --> 00:15:36.940
finalización en un
segundo, pero por ahora,

00:15:36.940 --> 00:15:40.395
la idea es que hemos
perdimos nuestra visión de los detalles,

00:15:40.395 --> 00:15:43.135
y nuestro uso de memoria bajando.

00:15:43.135 --> 00:15:43.770
>> Hermoso.

00:15:43.770 --> 00:15:46.150
>> Así es como arreglamos las fugas de memoria.

00:15:46.150 --> 00:15:49.420
>> Sí. Usted suscribió su
Eventos. Cancela tu suscripción a los eventos.

00:15:49.420 --> 00:15:51.630
>> Regla general básica.

00:15:51.630 --> 00:15:54.915
>> Eso también es muy gracioso
porque uno, causa dos problemas.

00:15:54.915 --> 00:15:56.800
Vimos que lo mantenías vivo.

00:15:56.800 --> 00:15:58.750
porque estos eventos siguen adelante.

00:15:58.750 --> 00:16:00.715
Así que ahora estás disparando
varias veces,

00:16:00.715 --> 00:16:04.290
pero también, cualquier cosa en esa página
se va a quedar en la memoria.

00:16:04.290 --> 00:16:06.685
>> Así es. Es por eso que
añadimos una imagen pesada,

00:16:06.685 --> 00:16:08.205
y todavía está en la memoria.

00:16:08.205 --> 00:16:08.830
>> Lo tengo.

00:16:08.830 --> 00:16:10.570
>> Déjame mostrarte Instrumentos.

00:16:10.570 --> 00:16:13.390
Así que voy a presentar
volver a nuestra fuga de memoria.

00:16:13.390 --> 00:16:13.800
>> Claro.

00:16:13.800 --> 00:16:15.985
>> Simplemente se quita el evento de no suscripción.

00:16:15.985 --> 00:16:18.435
Voy a desplegarme en mi simulador,

00:16:18.435 --> 00:16:21.330
e instrumentos funciona bastante fácil.

00:16:21.330 --> 00:16:23.355
Sólo tienes que elegir el objetivo de

00:16:23.355 --> 00:16:25.930
el simulador y el
aplicación, y eso es todo.

00:16:25.930 --> 00:16:28.435
Eso es todo lo que necesitas para empezar
el generador de perfiles de instrumentos.

00:16:28.435 --> 00:16:30.175
Aunque se trata de Xamarin App,

00:16:30.175 --> 00:16:32.150
se puede empezar bien
de los Instrumentos,

00:16:32.150 --> 00:16:33.615
que no sabe nada acerca de Xamarin.

00:16:33.615 --> 00:16:35.310
>> ¿De dónde provienen los instrumentos?

00:16:35.310 --> 00:16:38.709
>> Manzana. Es una manzana
herramienta, viene con Xcode,

00:16:38.709 --> 00:16:41.950
y tiene un montón de
herramientas dentro de ella.

00:16:41.950 --> 00:16:43.450
>> Así que está construido en
porque ya tienes

00:16:43.450 --> 00:16:45.415
¿Xcode instalado? así que
todo el mundo tiene esto?

00:16:45.415 --> 00:16:46.015
>> Es gratis.

00:16:46.015 --> 00:16:48.925
>> Es gratis. Fresco. Así que cualquiera
puede usar esto ahora mismo?

00:16:48.925 --> 00:16:53.880
>> Sí. En realidad se puede
ver estas actividades,

00:16:53.880 --> 00:16:57.920
a pesar de que los creados por
mundo como la actividad de detalles,

00:16:57.920 --> 00:17:00.525
todavía está representado
por un objeto nativo.

00:17:00.525 --> 00:17:00.930
>> Lo tengo.

00:17:00.930 --> 00:17:02.855
>> Así que vamos a buscar ese objeto.

00:17:02.855 --> 00:17:07.240
Lo llamamos Controlador de vista de detalles.

00:17:07.240 --> 00:17:09.595
Permítanme crear algunos de ellos.

00:17:09.595 --> 00:17:11.030
>> Esto es en realidad
realmente genial porque

00:17:11.030 --> 00:17:12.240
Nunca he usado Instrumentos,

00:17:12.240 --> 00:17:15.295
no se lo digas a nadie, en años.

00:17:15.295 --> 00:17:18.440
No creo que todo el mundo esté dando
me un detalle. ¿Así que existe?

00:17:18.440 --> 00:17:20.070
>> Sí, existe.

00:17:20.070 --> 00:17:22.335
>> Eso tiene sentido
porque Xamarin es nativo,

00:17:22.335 --> 00:17:23.770
por lo que crea un objeto nativo.

00:17:23.770 --> 00:17:26.380
>> Sí. No es necesario que lo hagas

00:17:26.380 --> 00:17:27.885
una instantánea de memoria aquí

00:17:27.885 --> 00:17:29.975
porque no tenemos
recolección de basura aquí.

00:17:29.975 --> 00:17:33.780
El IOS utiliza la jerarquía, que es
contador de referencia automático.

00:17:33.780 --> 00:17:35.605
Básicamente, siempre que
creas un objeto,

00:17:35.605 --> 00:17:37.065
incrementa el contador,

00:17:37.065 --> 00:17:39.550
cada vez que no lo usas o

00:17:39.550 --> 00:17:42.505
se aleja del alcance de
uso, disminuye el contador.

00:17:42.505 --> 00:17:43.845
Una vez que el contador es cero,

00:17:43.845 --> 00:17:46.495
el objeto es basura, y
podría ser recogido.

00:17:46.495 --> 00:17:48.075
Así que es bastante fácil empezar

00:17:48.075 --> 00:17:51.735
los instrumentos con la aplicación
simplemente haciendo clic en este botón.

00:17:51.735 --> 00:17:53.505
Se inicia la aplicación,

00:17:53.505 --> 00:17:55.860
le muestra el uso de memoria aquí.

00:17:55.860 --> 00:17:57.690
Abramos la página Detalles.

00:17:57.690 --> 00:18:00.425
>> Te tengo. Instrumentos
viene de Apple?

00:18:00.425 --> 00:18:02.040
>> Los instrumentos provienen de Apple.

00:18:02.040 --> 00:18:03.350
Es una herramienta gratuita de Apple.

00:18:03.350 --> 00:18:04.490
Puedes usar esto ahora mismo.

00:18:04.490 --> 00:18:05.390
>> Genial.

00:18:05.390 --> 00:18:06.970
>> Ves que también tenemos

00:18:06.970 --> 00:18:10.140
esta huella de memoria derecho
aquí una vez que abramos la página de Detalles.

00:18:10.140 --> 00:18:12.120
Vamos a abrirlo una vez más.

00:18:12.120 --> 00:18:15.140
>> Así que esto es muy similar
al generador de perfiles de Xamarin,

00:18:15.140 --> 00:18:16.870
pero esto nos va a mostrar

00:18:16.870 --> 00:18:19.240
la pila nativa para todos
intenciones y propósitos.

00:18:19.240 --> 00:18:21.500
>> Así es. Desafortunadamente,

00:18:21.500 --> 00:18:24.090
no sabe nada acerca de
Xamarin y mundo administrado,

00:18:24.090 --> 00:18:27.025
por lo que no será capaz de ver
el objeto administrado que creó.

00:18:27.025 --> 00:18:28.990
Así que ves el pico,

00:18:28.990 --> 00:18:30.850
y ves que no desaparece.

00:18:30.850 --> 00:18:33.350
Así que permítanme hacerlo una tercera vez,

00:18:33.350 --> 00:18:35.145
y mostrar los objetos.

00:18:35.145 --> 00:18:38.455
Así que vamos a ver. Hay
un pequeño botón de filtro.

00:18:38.455 --> 00:18:43.170
Vamos a todas las asignaciones aquí,

00:18:43.170 --> 00:18:45.165
y golpear los "Detalles".

00:18:45.165 --> 00:18:45.820
>> Está bien.

00:18:45.820 --> 00:18:47.555
>> Estas son tres páginas aquí,

00:18:47.555 --> 00:18:48.660
todos están en la memoria,

00:18:48.660 --> 00:18:50.650
y se asignan en la memoria.

00:18:50.650 --> 00:18:54.070
No voy a mostrar cómo desasignar
porque es la misma solución,

00:18:54.070 --> 00:18:57.020
simplemente nos damos de baja,
gestión mundial cancelaciones de suscripción

00:18:57.020 --> 00:19:00.120
desde el objeto. Objeto
considerada basura.

00:19:00.120 --> 00:19:04.660
Entonces nuestro recolector de basura
recopila esa información,

00:19:04.660 --> 00:19:06.460
entonces nativo puede recoger
porque nada

00:19:06.460 --> 00:19:08.490
de gestionar el mundo
ya se aferran a eso.

00:19:08.490 --> 00:19:10.780
>> Tiene sentido. Así que muy
la misma solución,

00:19:10.780 --> 00:19:12.255
pero otra forma de detectarlo.

00:19:12.255 --> 00:19:15.045
>> Así es. Así que esto es

00:19:15.045 --> 00:19:19.345
sobre las diferencias entre
mundo administrado y nativo.

00:19:19.345 --> 00:19:22.120
Mis próximos ejemplos
ser sobre todo sobre administrado

00:19:22.120 --> 00:19:25.320
mundo porque se puede
introducir un problema en cualquier,

00:19:25.320 --> 00:19:26.905
y no está relacionado con Xamarin.

00:19:26.905 --> 00:19:29.570
Como dijiste, podría ser
suscribirse a un evento estático,

00:19:29.570 --> 00:19:32.745
podría introducir
problema incluso en cualquier lugar.

00:19:32.745 --> 00:19:35.410
Así que lo siguiente es

00:19:35.410 --> 00:19:38.210
acerca de la suscripción, y
sin suscripciones.

00:19:38.210 --> 00:19:39.315
Pero en este caso,

00:19:39.315 --> 00:19:42.820
en realidad estamos
suscribirse implícitamente,

00:19:42.820 --> 00:19:44.480
no usamos más iguales.

00:19:44.480 --> 00:19:46.015
Así que es más difícil de encontrar.

00:19:46.015 --> 00:19:48.710
En este caso, ejecutamos este
centro de notificación tratando de

00:19:48.710 --> 00:19:51.795
identificar cada vez que se rota nuestra aplicación.

00:19:51.795 --> 00:19:53.695
Añadimos a este observador.

00:19:53.695 --> 00:19:57.525
Este es un centro predeterminado singleton.

00:19:57.525 --> 00:19:59.700
Estamos diciendo que, quiero conseguir

00:19:59.700 --> 00:20:02.595
cualquier información siempre que
orientación cambiada,

00:20:02.595 --> 00:20:04.140
y aquí está mi manejador para eso.

00:20:04.140 --> 00:20:04.650
>> Lo tengo.

00:20:04.650 --> 00:20:06.690
>> El propio manejador,
es bastante fácil.

00:20:06.690 --> 00:20:08.125
No haremos nada allí,

00:20:08.125 --> 00:20:11.665
lo imprimiremos para depurar.

00:20:11.665 --> 00:20:12.465
>> Lo tengo.

00:20:12.465 --> 00:20:15.525
>> Permítanme quitar el
cosas de conectividad porque

00:20:15.525 --> 00:20:18.630
queremos introducir diferentes
tipos de problemas de memoria.

00:20:18.630 --> 00:20:21.525
También comento
imagen porque no necesitamos

00:20:21.525 --> 00:20:24.430
para mostrar la memoria
huella, está ahí.

00:20:24.430 --> 00:20:28.390
Experimentaremos sólo con
Vistas y controladores de vista de interfaz de usuario.

00:20:28.390 --> 00:20:30.650
>> Muy guay. Así que este
es muy similar,

00:20:30.650 --> 00:20:32.870
pero este patrón, que
podría estar suscribiéndose,

00:20:32.870 --> 00:20:34.605
tal vez incluso pasando en una acción.

00:20:34.605 --> 00:20:38.340
O en este caso, lo que hace
aquí dice que tu devolución de llamada.

00:20:38.340 --> 00:20:40.010
Los delegados son muy similares,

00:20:40.010 --> 00:20:41.115
Creo que a estos patrones.

00:20:41.115 --> 00:20:42.480
Así que es sólo algo
Yo también estoy acostumbrada.

00:20:42.480 --> 00:20:45.590
>> Así es. Eso fue

00:20:45.590 --> 00:20:47.864
su idea principal porque
cuando te suscribes,

00:20:47.864 --> 00:20:51.405
usted está pasando la referencia a
el controlador de vista de interfaz de usuario también.

00:20:51.405 --> 00:20:53.425
Esto es sólo un diferente
manera de pasar la referencia.

00:20:53.425 --> 00:20:55.260
A veces no es tan obvio.

00:20:55.260 --> 00:20:57.955
Así que tenemos nuestra suscripción,
está corriendo aquí.

00:20:57.955 --> 00:20:59.305
Está funcionando sólo una vez.

00:20:59.305 --> 00:21:01.780
Cerremos y abramos de nuevo.

00:21:01.780 --> 00:21:03.525
Ahora, tenemos un doble clic.

00:21:03.525 --> 00:21:05.230
Deja que te enseñe esto.

00:21:05.230 --> 00:21:07.240
Girando una vez, consiguiendo dos,

00:21:07.240 --> 00:21:11.655
lo que significa que tenemos alguna vista de interfaz de usuario
Controlador colgado en la memoria,

00:21:11.655 --> 00:21:13.535
mientras se sigue procesando el primero.

00:21:13.535 --> 00:21:13.980
>> Lo tengo.

00:21:13.980 --> 00:21:15.430
>> Podría ser un problema si usted tiene

00:21:15.430 --> 00:21:19.660
alguna lógica de actualización de la base de datos
o horas extras de solicitud HTTP.

00:21:19.660 --> 00:21:21.340
Como en un día de uso,

00:21:21.340 --> 00:21:24.810
tu aplicación no se mata,
desactivar, reactivar.

00:21:24.810 --> 00:21:26.740
Tendrá todo esto
Ver todavía en la memoria,

00:21:26.740 --> 00:21:28.265
y en una semana, podría estrellarse.

00:21:28.265 --> 00:21:28.785
>> Sí.

00:21:28.785 --> 00:21:30.105
>> Entonces, ¿cómo arreglar eso?

00:21:30.105 --> 00:21:31.550
Es muy fácil.

00:21:31.550 --> 00:21:34.145
>> ¿Asumo que cancelas tu suscripción?

00:21:34.145 --> 00:21:35.835
>> Así es. Eso es más difícil de

00:21:35.835 --> 00:21:38.685
darse de baja porque
no tienen más igual.

00:21:38.685 --> 00:21:42.010
Permítanme mostrarles también lo que
en realidad enviar aquí.

00:21:42.010 --> 00:21:43.365
Así que cuando te suscribes,

00:21:43.365 --> 00:21:46.395
estás pasando el nombre del método.

00:21:46.395 --> 00:21:48.215
En realidad estás pasando una acción,

00:21:48.215 --> 00:21:51.745
y el compilador está haciendo un
gran trabajo de ocultar eso,

00:21:51.745 --> 00:21:54.150
y haciendo nuestras vidas más fáciles.

00:21:54.150 --> 00:21:55.945
>> El compilador es muy agradable.

00:21:55.945 --> 00:21:57.255
>> Muy amable con nosotros.

00:21:57.255 --> 00:22:00.415
Por eso nos gusta ser desarrolladores.

00:22:00.415 --> 00:22:04.360
Así que en realidad pide
acción con NSNotification.

00:22:04.360 --> 00:22:07.840
Así que estoy firmando NSNotification aquí,

00:22:07.840 --> 00:22:13.365
y luego usando esta notación,
pegando este objeto.

00:22:13.365 --> 00:22:16.560
Así que en lugar del nombre del método,

00:22:16.560 --> 00:22:19.225
en realidad estamos pasando
una acción y un objeto,

00:22:19.225 --> 00:22:20.960
que contiene la referencia a

00:22:20.960 --> 00:22:23.610
estos metadatos sobre cómo
para llamar al método.

00:22:23.610 --> 00:22:26.555
Así que no pasamos el método,
es sólo una referencia.

00:22:26.555 --> 00:22:30.060
En nuestro caso, el más importante
parte al pasar esta referencia,

00:22:30.060 --> 00:22:32.155
que es el controlador UIV,

00:22:32.155 --> 00:22:34.170
y es por eso que se mantiene en la memoria.

00:22:34.170 --> 00:22:35.260
>> Lo tengo.

00:22:35.260 --> 00:22:35.865
>> Está bien.

00:22:35.865 --> 00:22:36.670
>> Tiene sentido. Sí.

00:22:36.670 --> 00:22:38.595
>> No voy a mostrar los detalles

00:22:38.595 --> 00:22:40.390
porque la memoria
fuga sigue ahí

00:22:40.390 --> 00:22:43.975
porque vimos estos
cosa para ahorrar algo de tiempo.

00:22:43.975 --> 00:22:45.500
Quiero centrarme en

00:22:45.500 --> 00:22:48.830
el peor escenario que
usted debe ser consciente de.

00:22:48.830 --> 00:22:54.250
Cuando el mundo nativo no coloca
muy bien con el mundo administrado.

00:22:54.250 --> 00:22:56.280
>> Te tengo. Cuando el
dos mundos chocan.

00:22:56.280 --> 00:23:00.265
>> Eso es correcto porque siempre que
hemos creado objetos,

00:23:00.265 --> 00:23:02.155
y hay un objeto nativo creado,

00:23:02.155 --> 00:23:05.690
y tratando de
desasignar objetos nativos,

00:23:05.690 --> 00:23:07.495
nuestro mundo administrado piensa,

00:23:07.495 --> 00:23:09.330
Todavía no he terminado con este objeto.

00:23:09.330 --> 00:23:11.270
Por favor, espera, no

00:23:11.270 --> 00:23:13.765
recoger el objeto porque
Todavía estoy trabajando con eso.

00:23:13.765 --> 00:23:14.525
>> Te tengo.

00:23:14.525 --> 00:23:15.805
>> Podría ser opuesto,

00:23:15.805 --> 00:23:19.130
cuando un mundo nativo
podría crear un objeto,

00:23:19.130 --> 00:23:20.265
y ahora un mundo administrado piensa,

00:23:20.265 --> 00:23:22.450
no está hecho, todavía
allí, así que esperemos.

00:23:22.450 --> 00:23:25.015
Incluso si no tienes otros
referencias a este objeto,

00:23:25.015 --> 00:23:29.015
podía sostenerlo, podría
mantenerlo no como una basura.

00:23:29.015 --> 00:23:29.820
>> Te tengo.

00:23:29.820 --> 00:23:31.460
>> Podría explicarlo con

00:23:31.460 --> 00:23:34.640
estas pequeñas imágenes
de objetos inmortales.

00:23:34.640 --> 00:23:37.230
Así que no crees inmortal
Objetos. Esos son malos.

00:23:37.230 --> 00:23:38.435
>> Suena genial.

00:23:38.435 --> 00:23:39.963
>> Sí.

00:23:39.963 --> 00:23:43.355
Sucede cuando
tienen estos dos mundos.

00:23:43.355 --> 00:23:46.925
Nativo, ves a la derecha el
Controlador de vista nativo y vistas,

00:23:46.925 --> 00:23:49.640
y desde la izquierda tienes

00:23:49.640 --> 00:23:52.580
mundo administrado C Sharp que es
Ver controladores y vistas.

00:23:52.580 --> 00:23:55.640
Siempre que no sabes lo que es
pasando en el mundo nativo,

00:23:55.640 --> 00:23:58.070
no se puede recoger
de este mundo.

00:23:58.070 --> 00:24:00.905
Te mostraré un ejemplo
cómo puedes hacer eso.

00:24:00.905 --> 00:24:03.275
Así que en mi ejemplo,

00:24:03.275 --> 00:24:07.235
Quiero añadir aquí un pequeño
botón "Guardar",

00:24:07.235 --> 00:24:11.375
y sólo quieren cerrar el
Ver una vez que el usuario llega a eso.

00:24:11.375 --> 00:24:13.925
Supongamos que el
El botón "Guardar" también servirá

00:24:13.925 --> 00:24:17.330
alguna base de datos lógica de ahorro
o HTTP llama a lo que sea,

00:24:17.330 --> 00:24:19.055
simplemente no volver

00:24:19.055 --> 00:24:22.145
y en realidad ejecuta
alguna acción adicional.

00:24:22.145 --> 00:24:22.775
>> Está bien.

00:24:22.775 --> 00:24:24.980
>> Como detalles de estos botones,

00:24:24.980 --> 00:24:26.300
enviamos al manejador.

00:24:26.300 --> 00:24:31.205
Este manejador está diciendo que
por favor cierre nasea estos controladores.

00:24:31.205 --> 00:24:33.395
>> Parece perfectamente legítimo para mí.

00:24:33.395 --> 00:24:35.255
>> Sí. Vamos a presentar
una fuga de memoria.

00:24:35.255 --> 00:24:36.230
>> Está bien.

00:24:36.230 --> 00:24:42.515
>> Eres malo. Desgraciadamente
y es un patrón común.

00:24:42.515 --> 00:24:45.005
No tenemos ninguna
evento estático como aquí.

00:24:45.005 --> 00:24:47.195
No tenemos ninguna
tono único como aquí.

00:24:47.195 --> 00:24:49.025
Sólo mantenemos este botón aquí,

00:24:49.025 --> 00:24:51.650
esto es sólo un artículo local.

00:24:51.650 --> 00:24:54.260
Bien James, ahora
creó un botón y

00:24:54.260 --> 00:24:56.735
queremos añadirlo a
nuestra vista de navegación.

00:24:56.735 --> 00:25:00.440
Así que dijimos en ella a través de la
elemento de navegación también no utilizan

00:25:00.440 --> 00:25:05.225
cualquier referencia estática nada
así y sólo eso.

00:25:05.225 --> 00:25:08.015
Ahora tenemos el botón sub
y empecemos el generador de perfiles.

00:25:08.015 --> 00:25:09.890
>> Sí y otra vez,
patrón súper similar.

00:25:09.890 --> 00:25:11.285
Yo creo un botón,

00:25:11.285 --> 00:25:15.800
añadir un botón, y luego hago estallar el
View Controller parece normal.

00:25:15.800 --> 00:25:18.185
>> Tener un delegado que no use

00:25:18.185 --> 00:25:20.540
cualquier referencia externa o estática

00:25:20.540 --> 00:25:23.225
y no pasa ninguna referencia
de nuestro controlador.

00:25:23.225 --> 00:25:23.750
>> Te tengo.

00:25:23.750 --> 00:25:27.090
>> Debería funcionar bien,
¿Correcto? Veamos.

00:25:27.280 --> 00:25:32.780
Así que el generador de perfiles mostrará los objetos

00:25:32.780 --> 00:25:34.760
creado desde el principio y estoy

00:25:34.760 --> 00:25:37.790
va a empezar el seguimiento
ellos al principio.

00:25:37.790 --> 00:25:39.530
Así que he ocultado instantáneas a la derecha

00:25:39.530 --> 00:25:42.455
ahora y filtrando a mis objetos solamente.

00:25:42.455 --> 00:25:45.380
Una vez más es muy común
patrón para solucionar problemas

00:25:45.380 --> 00:25:48.800
problemas de memoria sólo para
ver sólo mis objetos.

00:25:48.800 --> 00:25:52.235
Entonces me iré una vez allí.
Este es mi botón.

00:25:52.235 --> 00:25:55.565
Verás, este es un nuevo control
muy bien nuestra aplicación.

00:25:55.565 --> 00:25:56.870
Tenemos esto en la memoria,

00:25:56.870 --> 00:25:58.745
lo cual es cierto, esperamos eso.

00:25:58.745 --> 00:26:03.410
Volviendo, vamos a golpear a uno
más tiempo y una vez más.

00:26:03.410 --> 00:26:04.430
>> Una vez más porque lo sé.

00:26:04.430 --> 00:26:05.195
>> Una vez más.

00:26:05.195 --> 00:26:06.380
>> Bien, y aún ahí.

00:26:06.380 --> 00:26:08.270
>> Una vez más, sigue ahí.

00:26:08.270 --> 00:26:11.030
Así que vamos a abrirlo y mucho más veces.

00:26:11.030 --> 00:26:14.090
Vamos a cerrarlo también
diferente manera de volver,

00:26:14.090 --> 00:26:17.390
va a ahorrar, en realidad
básicamente haciendo lo mismo.

00:26:17.390 --> 00:26:20.090
Vamos a tocar la "Memoria
instantánea" una más

00:26:20.090 --> 00:26:22.610
tiempo y oh wow que
tienen cinco casos de

00:26:22.610 --> 00:26:24.920
páginas que cuelgan allí en
memoria y si usted tiene

00:26:24.920 --> 00:26:28.130
una imagen enorme allí que
tendrá mucha memoria

00:26:28.130 --> 00:26:28.550
>> Lo tengo.

00:26:28.550 --> 00:26:32.615
>> Así que ese es un patrón muy común

00:26:32.615 --> 00:26:36.800
porque no es obvio que
tienes una fuga de memoria aquí.

00:26:36.800 --> 00:26:39.830
El problema aquí es
que UIBarButtonItem

00:26:39.830 --> 00:26:43.910
en realidad se aferra a
algún recurso nativo,

00:26:43.910 --> 00:26:45.485
está destinado a recursos nativos.

00:26:45.485 --> 00:26:49.100
Si no decimos claramente que
Ya no necesito este botón,

00:26:49.100 --> 00:26:51.020
introducirá
este objeto inmortal.

00:26:51.020 --> 00:26:53.135
>> Te tengo. Entonces, ¿cómo
¿Yo soluciono esta cosa?

00:26:53.135 --> 00:26:56.240
>> Para resolver eso, vamos a usar

00:26:56.240 --> 00:26:59.900
nuestro evento ViewDisappear y
hacer algo con nuestro botón.

00:26:59.900 --> 00:27:00.150
>> Está bien.

00:27:00.150 --> 00:27:01.220
>> Así que tenemos dos opciones,

00:27:01.220 --> 00:27:02.735
podríamos usar

00:27:02.735 --> 00:27:05.299
Evento cliceado y
suscribirse y darse de baja,

00:27:05.299 --> 00:27:07.160
pero volveremos a

00:27:07.160 --> 00:27:10.400
nuestro primer artículo cuando nos suscribemos
sin darse de baja.

00:27:10.400 --> 00:27:12.560
Hagamos algo más interesante.

00:27:12.560 --> 00:27:14.030
Sólo disponeremos el botón.

00:27:14.030 --> 00:27:15.680
>> Me gusta eso. Estoy
hecho con él, ¿verdad?

00:27:15.680 --> 00:27:18.320
>> Sí, decimos
mundo administrado que,

00:27:18.320 --> 00:27:20.495
"Ya terminé con el botón
por favor, deshágase.

00:27:20.495 --> 00:27:24.365
No es obvio porque
un montón de vistas y envoltorios

00:27:24.365 --> 00:27:26.540
en Xamarin iOS han
este método de eliminación y

00:27:26.540 --> 00:27:29.015
realmente no sabes cuando
deberías llamar a eso.

00:27:29.015 --> 00:27:30.815
Así que es un caso interesante.

00:27:30.815 --> 00:27:32.975
Pero hagámoslo y corremos.

00:27:32.975 --> 00:27:34.700
Esa es la única acción que he añadido

00:27:34.700 --> 00:27:37.500
desde la ejecución de la aplicación anterior.

00:27:38.290 --> 00:27:42.530
Estoy empezando el generador de perfiles
y haciendo el mismo caso de uso.

00:27:42.530 --> 00:27:44.000
Vamos a rastrear los objetos desde

00:27:44.000 --> 00:27:46.310
el principio y hacer
asegurarse de que están dispuestos.

00:27:46.310 --> 00:27:48.050
>> Muy guay. Esto es lindo.

00:27:48.050 --> 00:27:49.670
Así que podrías haber, como dijiste,

00:27:49.670 --> 00:27:53.270
en lugar de pasar
toda esa acción en,

00:27:53.270 --> 00:27:55.130
usted puede simplemente similar a cómo

00:27:55.130 --> 00:27:57.605
hacer Conectividad,
suscribirse, darse de baja,

00:27:57.605 --> 00:28:00.590
Me lo habría imaginado
fuera, pero en este caso,

00:28:00.590 --> 00:28:03.125
ya lo has hecho así
simplemente te des haces de él.

00:28:03.125 --> 00:28:04.010
>> Así es.

00:28:04.010 --> 00:28:04.875
>> Genial.

00:28:04.875 --> 00:28:08.455
>> Sí, porque no
esperar que se cancele la suscripción.

00:28:08.455 --> 00:28:10.840
No es una especie de suscripción,

00:28:10.840 --> 00:28:14.230
sólo pasamos y delegamos
dentro del objeto local.

00:28:14.230 --> 00:28:16.045
En el caso de NotificationCenter,

00:28:16.045 --> 00:28:18.790
es una especie de suscripción porque
pasamos en el objeto local

00:28:18.790 --> 00:28:21.760
en algunos estáticos
instancia o singleton.

00:28:21.760 --> 00:28:24.760
En este caso, acabamos de usar
en nuestros recursos locales,

00:28:24.760 --> 00:28:26.395
no esperamos una pérdida de memoria.

00:28:26.395 --> 00:28:26.680
>> Te tengo.

00:28:26.680 --> 00:28:28.630
>> Pero por desgracia puedo ver

00:28:28.630 --> 00:28:32.660
esta barrera mucho y la gente
en estas situaciones.

00:28:32.680 --> 00:28:37.530
Así que hagamos el mismo truco.

00:28:37.750 --> 00:28:41.760
Desearía que pudiera guardar estos datos.

00:28:41.950 --> 00:28:46.310
Así que sólo tenemos una vista
Controlador y delegado.

00:28:46.310 --> 00:28:48.290
Vamos a pulsar "Guardar".

00:28:48.290 --> 00:28:51.215
Volvamos.

00:28:51.215 --> 00:28:54.005
En realidad, vamos a permanecer en la página de detalles.

00:28:54.005 --> 00:28:56.975
Pulse "Instantánea de memoria" y vemos una.

00:28:56.975 --> 00:28:59.315
Permítanme hacer clic en él un par de veces más.

00:28:59.315 --> 00:29:02.735
Hablaremos de eso. Así que
tienen sólo un caso aquí.

00:29:02.735 --> 00:29:10.805
Hago clic en "Guardar", hago clic en "Instantánea"
y desaparece el escaneo.

00:29:10.805 --> 00:29:12.380
¿Bien? Se ha corregido la fuga de memoria.

00:29:12.380 --> 00:29:13.250
>> Muy guay. Muy bien.

00:29:13.250 --> 00:29:14.900
>> El objeto inmortal fue asesinado.

00:29:14.900 --> 00:29:16.445
>> Asesinado. Muy guay.

00:29:16.445 --> 00:29:17.810
De lo contrario, esto es impresionante.

00:29:17.810 --> 00:29:20.600
Así que muy simple, miren sus eventos,

00:29:20.600 --> 00:29:22.850
pero también mira cómo estás pasando

00:29:22.850 --> 00:29:24.890
estas acciones alrededor e incluso yo

00:29:24.890 --> 00:29:26.870
ni siquiera pensaría en eso
botón para ser honesto con usted

00:29:26.870 --> 00:29:29.315
porque el constructor
está pasando esta cosa.

00:29:29.315 --> 00:29:29.600
>> Sí.

00:29:29.600 --> 00:29:30.725
>> Muy guay.

00:29:30.725 --> 00:29:33.350
>> También recomendaría

00:29:33.350 --> 00:29:36.425
nuestros desarrolladores para usarlo más
a menudo para gustar una vez a la semana,

00:29:36.425 --> 00:29:39.545
cada sprint y luego a
ver el uso de memoria,

00:29:39.545 --> 00:29:41.585
puede verlo como una ejecución de prueba de interfaz de usuario.

00:29:41.585 --> 00:29:45.590
Muestra este pequeño
juego de trabajo de memoria.

00:29:45.590 --> 00:29:48.050
Así que sólo ves más
meses si crece o

00:29:48.050 --> 00:29:51.530
no y si crece que
probablemente tengan una pérdida de memoria.

00:29:51.530 --> 00:29:53.360
>> Usted mostró iOS.

00:29:53.360 --> 00:29:54.560
Ahora, ¿qué pasa con Android?

00:29:54.560 --> 00:29:57.500
¿Hay algún otro otro
herramientas allí que se pueden utilizar?

00:29:57.500 --> 00:29:59.465
>> Es una gran pregunta
porque, Android,

00:29:59.465 --> 00:30:02.000
todo lo que hablamos
iOS aplica para Android.

00:30:02.000 --> 00:30:02.150
>> Te tengo.

00:30:02.150 --> 00:30:03.440
>> Sólo tiene diferentes herramientas para

00:30:03.440 --> 00:30:07.145
Generador de perfiles nativo de Android
llamado Android Profiler.

00:30:07.145 --> 00:30:08.390
Es genial.

00:30:08.390 --> 00:30:09.740
Te muestra un montón de

00:30:09.740 --> 00:30:12.380
información, pero todavía tiene
tener que usarlo que es

00:30:12.380 --> 00:30:14.330
el generador de perfiles de Xamarin en conjunto

00:30:14.330 --> 00:30:16.790
debido a la gestión
mundo mundial y nativo.

00:30:16.790 --> 00:30:17.930
>> Te tengo. Simplemente

00:30:17.930 --> 00:30:19.340
suena que era genial que
hay grandes herramientas

00:30:19.340 --> 00:30:22.400
disponible sin importar dónde
estás en, iOS, Android.

00:30:22.400 --> 00:30:23.240
>> Eso es correcto.

00:30:23.240 --> 00:30:24.005
>> Puedo seguir adelante y hacer eso.

00:30:24.005 --> 00:30:25.820
Honestamente, sólo mirando
en algunos de estos,

00:30:25.820 --> 00:30:28.160
Estoy bastante seguro de que mi código,
hay un montón de cosas malas.

00:30:28.160 --> 00:30:29.480
Así que cuando transmito a continuación,

00:30:29.480 --> 00:30:31.790
va a ser todo
arreglar mis fugas de memoria.

00:30:31.790 --> 00:30:32.180
>> Está bien.

00:30:32.180 --> 00:30:34.280
>> Muy guay. Cualquier otra cosa Alexi
que quieres hablar?

00:30:34.280 --> 00:30:35.315
>> Eso es todo por hoy.

00:30:35.315 --> 00:30:37.865
>> Impresionante. Bueno, gracias.
todo el mundo para sintonizar.

00:30:37.865 --> 00:30:40.010
Alexi, muchas gracias por
mostrando todas estas cosas.

00:30:40.010 --> 00:30:42.305
>> Gracias chicos. Gracias
por dejarme.

00:30:42.305 --> 00:30:43.970
>> Absolutamente, y asegúrese de

00:30:43.970 --> 00:30:45.920
que echa un vistazo a todo
las notas de muestra a continuación,

00:30:45.920 --> 00:30:47.420
abrir toda la fuente
código, todos los enlaces

00:30:47.420 --> 00:30:48.980
para toda la documentación allí abajo.

00:30:48.980 --> 00:30:51.740
También puede ir a aka.ms/Xamarin

00:30:51.740 --> 00:30:54.485
mejores prácticas para toda la serie.

00:30:54.485 --> 00:30:55.790
Así que asegúrate de suscribirte

00:30:55.790 --> 00:30:57.695
hoy dondequiera que estés
mirando en este momento.

00:30:57.695 --> 00:30:59.090
Soy James Montemagno.

00:30:59.090 --> 00:31:01.790
Este ha sido El Xamarin
Espectáculo y gracias por mirar.

00:31:01.790 --> 00:31:02.480
>> Gracias chicos.

00:31:02.480 --> 00:31:09.230
[MUSICA]

00:31:09.230 --> 00:31:11.120
>> Hola, James.
Sólo quería registrarme

00:31:11.120 --> 00:31:13.175
y gracias por
viendo este video.

00:31:13.175 --> 00:31:16.265
Ahora haz todas las cosas que
sabe que quieres hacer como,

00:31:16.265 --> 00:31:18.710
suscribirse, y ding
que la campana de notificación,

00:31:18.710 --> 00:31:20.825
formar parte de la
escuadrón de notificaciones.

00:31:20.825 --> 00:31:22.190
Mientras estés aquí, echa un vistazo

00:31:22.190 --> 00:31:25.400
todos estos videos impresionantes
que ya he codificado.

00:31:25.400 --> 00:31:29.040
Haz clic en esa cosa. Haga clic
lo, míralo, hazlo.