Cómo acelerar el inicio de una aplicación iOS 2 veces usando Network Instrument / Sudo Null IT News

Una aplicación es una conexión de datos de la red a una interfaz gráfica. Hay muchos artículos sobre la interfaz de usuario, pero casi nadie recuerda la red, y es esto lo que afecta el tiempo de espera del usuario para recibir una respuesta. Al mismo tiempo, desde el lado del desarrollador a menudo se ve así: “bueno, creé una sesión, ejecuté una solicitud, procesé un error, ¿qué más podría haber allí?”

Si observa todas las solicitudes desde el exterior, surgirán muchas preguntas: ¿es necesario reutilizar URLSession.shared, por qué las primeras solicitudes, incluso las más simples, tardan más que otras, cómo acelerar el inicio de la aplicación cuando hay muchas solicitudes, cómo acelerar la carga de imágenes, cómo monitorear la calidad de las redes de trabajo, etc.

Al analizar a través de Network Instrument, encontramos una docena de problemas diferentes en nuestras aplicaciones. Estoy seguro de que uno de ellos también está en su solicitud.

como lanzar

No dudes en saltarte esta parte si ya has trabajado con otras herramientas.

Compile la aplicación de creación de perfiles en su teléfono: seleccione su teléfono y haga clic en ⌘ I. Por lo general, para la creación de perfiles, la aplicación está integrada en la configuración de versión y esto puede impedir que se instale en el teléfono.

Si la aplicación ya ha sido compilada y no desea reiniciar la compilación, seleccione en la barra de estado Xcode → Open Developer Tool → Instruments :

Entre todas las herramientas, seleccione Red:

La red le mostrará dónde se realizan las solicitudes, pero si desea analizar qué sucede en los huecos entre ellas, deberá agregar Time Profiler. Haz clic en + Instrumento y añade el que necesites, filtrando los instrumentos por nombre:

Para comenzar, presione el botón redondo rojo o ⌘ R . Después de eso, en la aplicación, realice las acciones que desea perfilar (por ejemplo, espere hasta que se muestre el menú) y presione el cuadrado negro “detener”. Normalmente después de esto hay que esperar un minuto más hasta que se procesen los datos.

Para escalar correctamente el gráfico, debe mantener presionado Option y seleccione el área deseada; se extenderá por todo el ancho de la pantalla.

Habrá muchos sectores de datos y lo más probable es que los superiores no le resulten útiles. Pero si expandes el nombre de la aplicación, encontrarás muchas cosas interesantes allí: qué datos fueron procesados ​​por qué URLSession, en qué hilo, etc. Si desea centrarse solo en una pareja, haga clic en el signo más a la izquierda de la línea de datos; se moverá a la sección inferior, que se puede estirar para llenar toda la pantalla.

Sólo puedes probar tus aplicaciones. El depurador no podrá conectarse con el resto.

Como resultado, podrá eliminar un perfil completo de diferentes solicitudes. Los analizaremos en detalle.

¿En qué consiste una solicitud?

En la documentación de URLSessionTaskTransactionMetrics Hay un buen esquema de consulta. Veámoslo con más detalle.

1. Se crea una tarea para la solicitud de red;

2. la búsqueda de dominio a través de DNS convierte la cadena del host en la IP a la que necesita conectarse;

3. Se establece una conexión TCP y luego se configura una conexión TLS segura;

4. Al final, solicitamos datos del servidor, esperamos una respuesta y recibimos una respuesta.

Por supuesto, todos estos detalles son difíciles de ver en el código o en los registros, por lo que necesitamos un instrumento de red que dibuje un gráfico de todas las solicitudes a la vez. Para varias solicitudes el esquema cambia mucho: IP del servidor URLSession aprende de la primera solicitud, para solicitudes posteriores no es necesario establecer una conexión: solo ejecutan la última parte del circuito. A continuación se muestra una instantánea del lanzamiento de la aplicación “Kebster!” de 10 solicitudes:

Lo que se puede ver en el diagrama:

• El morado indica el período en el que la solicitud es bloqueada por la conexión al host y en realidad no se ejecuta. La conexión al servidor se reutiliza para todas las solicitudes dentro de una URLSession si está utilizando HTTP/2. A continuación veremos ejemplos de cómo se descompone esto;

• el azul indica tareas de conexión que bloquearon las otras dos solicitudes. Este no es el caso en solicitudes posteriores, porque todas las solicitudes reutilizan esta Conexión y no es necesaria una reconexión. Hay tres etapas dentro de la conexión:

  • DNS: convierte el nombre de nuestro endpoint en un número de IP;

  • Conexión TCP al servidor: envíe una solicitud de conexión, obtenga permiso, envíe otra solicitud de confirmación y establezca una conexión al final. En general, no es muy importante qué sucede exactamente aquí; lo importante es que bloquea la ejecución de la solicitud;

  • TLS: configura el cifrado para la conexión.

• Después de una conexión exitosa, ambas solicitudes bloqueadas continúan. La zona gris está esperando una respuesta. Hice solicitudes desde Argentina a Rusia, por lo que ocuparon una parte importante de todas las solicitudes;

• Después de la franja gris hay un breve inserto verde: se trata de recibir datos. Su ancho depende de la cantidad de datos en la respuesta. Para la primera solicitud de configuración de la aplicación, la respuesta es muy pequeña, pero la respuesta del menú es mucho más amplia, porque allí se cargan 500 kb;

• algunas solicitudes se ejecutan en paralelo (y esto es bueno), mientras que otras son secuenciales, razón por la cual la aplicación tarda más en iniciarse y los usuarios esperan más para que se abra;

• el verde son las solicitudes exitosas y el naranja las que fallaron. Como resultado del procesamiento de este último, se mostraron los errores 400 y 401.

En el panel inferior puede seleccionar la solicitud deseada, ver los encabezados de la solicitud, los encabezados de la respuesta y la respuesta misma.

Por desgracia, no está escrito qué tamaño exacto de la respuesta se recibió, pero en los encabezados está claro que Content-Encoding vino br (Qué significa brotli) y el archivo en sí se descomprimió a nivel de red en JSON. Los números exactos se pueden obtener a través de URLSessionTaskTransactionMetrics. En esta solicitud, por ejemplo, la respuesta pesa 500kb, pero solo se comprimen y descargan 45kb.

Conexión

Una de las etapas más inesperadas e interesantes fue la conexión al servidor. Había muchas opciones y problemas, veamos todo por separado.

Reutilizar URLSession

Cuando lanzamos el Kebster! análisis, vimos una imagen completamente diferente: muchos individuosURLSessioncada uno contiene solo una conexión y cada solicitud tarda 500 ms. Permítanme recordarles: todas las solicitudes provienen de Argentina a Rusia.

Si ampliamos las líneas y cambiamos el modo de visualización de Task en HTTP Transactions by Connectionpodemos ver una representación más precisa:

¡Resulta que cada solicitud establece una conexión y dedica el 80% del tiempo a hacerlo! Estos bloqueos están resaltados en azul y morado:

La razón es simple: como resultado de un error, se crea una cuenta por separado. URLSession. Las solicitudes no compartían la conexión entre sí, por lo que la conexión se produjo una y otra vez.

Por lo tanto, al reutilizar una sesión, es posible corregir el error (por ejemplo, URLSession.shared). Ahora la imagen se ha vuelto normal: las dos primeras solicitudes tardan 500 ms. como antes, pero los siguientes son más rápidos: ¡130 ms cada uno!

Lo mismo sucedió con las imágenes: para cada solicitud se creó su propia sesión, por lo que la conexión tomó la mayor parte del tiempo y las imágenes no se cargaron tan rápido como podrían. Creamos una sesión separada para las imágenes para que pudiera reutilizarse entre solicitudes.

Como resultado, cuando reutilizamos la sesión, obtuvimos dos pistas claras: para solicitudes a la API y para imágenes. Se conectan a diferentes hosts, por lo que tienen diferentes conexiones.

Al mismo tiempo, es normal separar sesiones para conectarse a diferentes hosts. Por ejemplo, los análisis, los registros, la API y el acceso a CDN para imágenes pueden vivir en diferentes sesiones con diferentes configuraciones. Si las pasa todas a través de una URLSession, aún creará su propio Connect para cada host, por lo que no habrá ningún beneficio, pero si crea diferentes URLSessions, podrá darles diferentes nombres y configurar diferentes configuraciones. Útil si descarga archivos grandes en segundo plano.

Al reutilizar URLSession, aceleramos a la mitad tanto el inicio de la aplicación como la carga de todas las imágenes. Buen resultado para cambiar tres líneas de código.

HTTP repentino 1.1

Recientemente cambiamos el servicio anti-bot y el lanzamiento de la aplicación Dodo Pizza se ha ralentizado. Después de ejecutar el inicio a través de Network Instrument, vimos que solo había una URLSession, pero las conexiones aún se creaban por separado. Debido a esto, la conexión para solicitudes simultáneas se produce de nuevo cada vez. Las solicitudes posteriores reutilizan conexiones, pero su número es igual al número de solicitudes simultáneas.

El truco está en el ① ubicado en la esquina superior izquierda de la solicitud: significa que la conexión se estableció a través de HTTP 1. La primera versión del protocolo crea conexiones separadas para solicitudes paralelas y luego las reutiliza debido al encabezado Keep-Alive.

La versión del protocolo HTTP también se puede ver en el panel inferior:

La versión del protocolo HTTP preferida se especifica desde el backend. Si iOS lo admite, la conexión se establecerá utilizando exactamente esta versión del protocolo. Al mismo tiempo, iOS ya admite versiones modernas del protocolo y el problema debe corregirse desde el backend. Para devolver HTTP/2, tuvimos que cambiar el proveedor anti-bot.

Sería aún mejor HTTP/3 Y OMS – su tarea es acortar la etapa de conexión para que lleve mucho menos tiempo.

Verifique la conexión de un extremo a otro, diferentes proxies pueden romper la versión del protocolo

Preconexión

Normalmente, una aplicación va a varios hosts diferentes: uno para la API, un segundo para las imágenes, un tercero para el pago, etc. Incluso si usamos HTTP/2, la primera solicitud tardará mucho más. ¡Pero este tiempo se puede reducir si realizas la conexión con antelación!

Literalmente: llame a una solicitud vacía a la raíz de su host para que se establezca la conexión antes de comenzar a realizar las primeras solicitudes. Los anfitriones se pueden registrar en la aplicación con anticipación; no sucederá nada terrible, incluso si quedan obsoletos y usted realiza una solicitud adicional. En este caso, la conexión se puede llamar literalmente desde la primera línea de la aplicación: mientras configura las primeras dependencias, lee los datos de la base de datos y dibuja la primera interfaz, esto puede tardar fácilmente entre 100 y 300 ms, durante los cuales la conexión ocurrirá y las primeras solicitudes “reales” serán más rápidas.

public func preheatConnections(endpoints: (URL)) {
  for endpoint in endpoints {
    Task(priority: .userInitiated) {
      try? await preheatConnection(to: endpoint)
    }
  }
}

private func preheatConnection(to endpoint: URL) async throws
  var request = URLRequest(url: endpoint)
  request.httpMethod = "HEAD"

  let session = URLSession.shared
  _ = try await session.data(for: request)

  // Обрабатывать результат даже не нужно, 
  // достаточно внутреннего состояния коннекта в URLSession
}

En la captura de pantalla, la solicitud de conexión comenzó 400 ms antes, lo que permitió que todas las solicitudes posteriores omitieran la etapa de conexión. A veces, la conexión puede tardar un poco más y ocupar parte de la solicitud; esto es normal.

Muy extraño, pero la conexión exitosa no siempre se muestra en las herramientas.

Sin embargo, en el panel inferior puede ver cuánto tiempo tardó la solicitud y cuándo comenzó seleccionando el tipo de visualización Tareas de sesión URL.

De esta forma puedes acelerar las primeras solicitudes en la aplicación, cargando la primera imagen o vídeo, o cualquier otro servicio que pase a su backend. Por ejemplo, puede acelerar la primera solicitud de pago si un anfitrión independiente es responsable de los pagos.

La conexión a todos los hosts se puede realizar desde la primera línea de su aplicación; mientras se inicia, puede conectarse al host. De esta forma las primeras solicitudes se procesarán más rápido.

IP estática

La conexión consta de tres etapas: DNS, TCP y TLS. Puede guardar en DNS si no escribe el nombre de dominio del host, sino su IP. No es un hecho que esta solución le convenga en 2024, pero puede intentar reutilizar la IP de la última sesión para las primeras solicitudes para ganar otros 50-100 ms. Es muy fácil romperlo todo, por eso este es un consejo para los más valientes. Por ejemplo, no hicimos eso.

Por supuesto, puedes probar scripts con una IP estática de la última sesión. Pero luego asegúrese de tener una opción de respaldo en caso de que la conexión no funcione; por ejemplo, el balanceador transferirá su cliente a otra IP.

Analizando el lanzamiento de la aplicación Dodo Pizza

Hemos analizado detalladamente en qué consiste una solicitud y qué problemas hay. Ahora veamos cómo se inicia la aplicación Dodo Pizza y qué más podemos ver en Network Instrumentcuando analizamos la imagen completa del lanzamiento de la aplicación.

El gráfico muestra varios lugares interesantes:

1. Las solicitudes no comienzan desde el principio, hay una especie de pausa: se inicia la aplicación, se crean dependencias y se dibuja la primera interfaz. En este momento, puede realizar una conexión preliminar, evitando el resto del lanzamiento.

2. Después de la pausa hay 3 solicitudes paralelas. Están bloqueados por la conexión, pero ya sabemos que podemos intentar conectarnos incluso antes.

3. En el medio hay una solicitud de pizzerías: tiene una gran zona verde, por lo que allí llega mucha información. Esto es bastante de esperar: pedí un menú en Moscú y hay muchas pizzerías allí. Pero hay dos conclusiones más:

   • por alguna razón, esta solicitud bloquea las demás, por lo que la solicitud del carrito y del menú ocurre mucho más tarde; esto retrasa el inicio de la aplicación;

   • ¡Después de esta solicitud hay un agujero notable, durante el cual no hay ni una sola solicitud! Time Profiler le ayudará a encontrar este problema más adelante.

4. El tercer bloque de solicitudes es para obtener información sobre el carrito. El carrito de menú en sí no es necesario, pero sí indica el tipo de pedido; es necesario para la siguiente solicitud de menú, porque es diferente para restaurante y entrega a domicilio. Si guarda el tipo de pedido en su teléfono desde la última sesión, entonces esta etapa puede ser paralela al menú principal. ¡Junto con corregir la solicitud de pizzería, esto acelerará el inicio en un 30%!

5. La última gran petición es conseguir un menú. Consta de tres etapas:

   • El área azul es una redirección: solicité un menú en inglés, pero el backend me dijo que para ello necesito ir a otro punto final. Parece lógico, pero lleva tiempo.

   • La segunda área gris: al redirigir, la solicitud vuelve a estrechar la mano con el host. Lamentablemente, las redirecciones también llevan tiempo.

   • Área verde: recibimos datos. El menú es grande y los datos vienen en varios paquetes; debemos asegurarnos de recibirlos en formato comprimido. Desafortunadamente, Network Instrument No muestra esto, pero puedes comprobarlo a través de URLSessionTaskTransactionMetrics.

Un par de aplicaciones se inician después Network Instrument mostró una docena de problemas al inicio de la aplicación.

Agujero entre solicitudes debido a un análisis prolongado

La solicitud de pizzerías se bloqueó por accidente: se olvidaron de asignarla a una tarea separada. Pero el hoyo posterior resultó ser más interesante y constaba de dos partes:

1. Analizando pizzerías. Dado que hay muchos datos sobre pizzerías, lleva mucho tiempo analizarlos. Agregamos Time Profiler para analizar este lugar y sugirió un problema: al analizar cada pizzería, calculamos su tiempo de funcionamiento, y para ello tomamos los horarios de apertura y cierre de los 7 días de la semana para las 300 pizzerías y creamos DateFormatter justo en el bucle. Inicialización DateFormatter fue muy largo, por lo que eliminamos su creación y comenzó a funcionar notablemente más rápido. Como resultado, la solicitud bloqueó la ejecución del programa y el análisis de estos datos retrasó la carga del menú.

2. Creación de interfaz en el hilo principal, unos 60 ms. En este momento ya se pudo lanzar la solicitud del carrito y menú. Para mejorar, dejamos de esperar a que la pantalla se dibujara y solicitamos datos de inmediato; todo lo que la pantalla tenía que hacer era suscribirse a las actualizaciones del menú.

Solicite datos antes de cargar la interfaz; puede ahorrar entre 50 y 100 ms. antes de la primera solicitud.

Descargas simultáneas

Quizás ya te hayas hecho la pregunta: ¿cuántas solicitudes puedes hacer al mismo tiempo? Por mucho que quieras, estás limitado únicamente por el protocolo:

• HTTP 1 admite entre 6 y 8 conexiones;

• HTTP/2 no tiene límite y normalmente puede contener unas 100 conexiones, dependiendo de la configuración del servidor. La mayoría de las veces, URLSession simplemente espera una respuesta de la infraestructura de red, por lo que estos son todos los beneficios del paralelismo.

Por otro lado, es posible que tengas el mismo problema de recibir grandes cantidades de datos al mismo tiempo. En las capturas de pantalla se muestran como grandes zonas verdes. En este caso, estás limitado por la velocidad del usuario o del servidor, pero la dependencia es más compleja, porque los datos llegan en varios paquetes.

Aquí solo puedo compartir un ejemplo: una vez, para migrar de un contrato de menú a otro, comenzamos a cargar dos menús a la vez; el cronograma de carga del menú anterior aumentó inmediatamente en un 50%.

A veces, el segundo menú se recibía sólo después de recibir el primero. En general, este tipo de maniobras no son gratuitas. Si descarga varios archivos grandes al mismo tiempo (por ejemplo, imágenes, videos o modelos 3D), entonces vale la pena experimentar con la cantidad de descargas paralelas; quizás una cantidad menor proporcione una mayor velocidad.

Las descargas paralelas grandes pueden retrasarse entre sí, pero las áreas grises de espera no ralentizan el proceso de apertura de ninguna manera: simplemente están esperando una respuesta.

Una redirección que no estaba incluida en la conexión.

Veamos un caso muy raro, sólo veamos “cómo sucede”. Ya hemos comentado que la redirección del menú no es gratuita: los datos para una solicitud repetida no llegan inmediatamente y hay una doble espera:

Es incluso peor si HTTP/2 no funciona. Por ejemplo, al principio solo se nos solicitan 3 solicitudes en paralelo, y al abrir el menú se pueden llamar de 4 a 5 solicitudes simultáneamente. En este caso, la primera solicitud del menú puede crear una conexión adicional y recibir una redirección, pero después de la redirección terminará en la conexión anterior. ¡Resulta que estábamos esperando una nueva conexión solo para ser redirigidos a la anterior!

En HTTP 1, los problemas con las conexiones pueden surgir en distintos momentos y solo los verás en el generador de perfiles 🙂

Análisis de consultas a través de Firebase Performance

Medir la red únicamente en su teléfono no es suficiente: las experiencias reales de las personas pueden variar mucho. Por ejemplo, la primera cafetería Drinkit abrió en un centro de negocios con muy mala conexión a Internet. Esto ya se reflejó en la experiencia de los invitados, pero en la aplicación Drinkit, ¡los vídeos también se reproducen directamente en el menú!

Creamos una forma de monitorear a través de Firebase Performance como esta:

• todas las solicitudes de red ya se analizan a través de Firebase;

• Además, marcamos un escenario de cliente grande, por ejemplo:

  • primer lanzamiento de la aplicación antes de que se muestre el mapa;

  • reiniciando la aplicación hasta que se muestre el menú;

  • Es hora de crear un pedido y comenzar el pago.

• Refinamos gradualmente el rastreo para que todos los lugares queden claros: lo dividimos en grandes etapas, aclaramos qué tipo de procesos ocupan el tiempo entre solicitudes;

• Si algo sale mal, podemos ir a una sesión específica y ver qué pasó allí.

El detalle está oculto detrás del botón. View all sessions bien:

¿Qué podemos aprender de aquí sobre cargar dos menús? Cuántas veces se descargaron de la red, cuántos modelos diferentes se convirtieron, dónde hay expectativas incomprensibles, por ejemplo, algún tipo de agujero incomprensible hacia el final. Como resultado, veremos el resultado de la métrica general del usuario a las tareas individuales en el código.

Desafortunadamente, para el artículo, el gráfico tuvo que simplificarse, porque Firebase agrega todos los seguimientos de la aplicación en un gráfico; no es tan fácil mirar solo la imagen de “cómo se carga el menú”. Pero es posible.

Comience a recopilar métricas de usuario y luego profundice en áreas que no están claras.

Cómo analizar en Android

En Android, también puedes recopilar gráficos similares a través de la utilidad proxy mitmproxy; simplemente inicia la aplicación de grabación y; exportar en formato har. Puedes abrir el archivo. en el visualizador de PerfCascade. El gráfico muestra diferentes etapas de las solicitudes, pero lamentablemente no las agrupa por conexiones.

Nos enfrentamos al hecho de que las velocidades de inicio no se pueden comparar fácilmente entre plataformas: incluso en el percentil 50, una aplicación de Android se inicia 2 o 3 veces más lento, aunque el patrón de solicitud es el mismo. Esto sucede debido al hecho de que los teléfonos Android, en promedio, son mucho más débiles que los iPhone tanto en términos de potencia del procesador y velocidad de la memoria como en el funcionamiento de los módulos de red del teléfono.

Vale la pena comparar el rendimiento de teléfonos de la misma potencia. Por ejemplo, compare el iPhone 13, iPhone 14 y iPhone 15, y los modelos de teléfono Samsung Galaxy y Google Pixel lanzados en los últimos años.

En este contexto, el tiempo de lanzamiento coincidió, pero en iPhone fue el percentil 50, y en Android apenas llegó al 10-15.

En pocas palabras

Utilizando Network Instrument, hemos diagnosticado y resuelto muchos problemas:

1. Ahora usamos una URLSession por host para reutilizar las conexiones.

2. Agregamos calentar la conexión como la primera línea de la aplicación.

3. Descubrimos un HTTP/2 roto a tiempo y lo arreglamos a nivel de infraestructura. Al reemplazar el antibot, redujimos el tiempo de inicio de la aplicación en 0,5 segundos.

4. La mayor parte del trabajo implicó cambiar el orden de las consultas:

   • hizo que cargar el menú fuera casi la primera solicitud, anteriormente solo solicitaban alternar;

   • Comenzamos a almacenar en caché la función de alternancia entre lanzamientos y a actualizarlos de forma asincrónica. El menú ahora se solicita incluso antes al reiniciar.

   • se eliminaron las redirecciones en la capa de red porque solo ralentizaron la respuesta;

   • Separamos las consultas que se pueden llamar después de renderizar la primera interfaz; así es como paralelizamos la larga actualización de la pizzería. Ahora no afecta en absoluto la representación de la interfaz;

   • Verificamos que todos los JSON grandes estén comprimidos y para el nuevo menú utilizamos Referencia JSON. Esto hizo posible transferir menos datos y tampoco duplicar objetos en la RAM;

   • Dividimos los scripts de inicio en los primeros y los repetidos para recopilar estadísticas sobre ellos por separado en Firebase.

Comenzamos con esta imagen con una docena de problemas, pero al final aceleramos la aplicación a la mitad y llegamos a un esquema en el que el usuario espera solo una solicitud para que el menú la vea. De hecho, la interfaz se muestra en el medio del gráfico inferior y la gran área verde ahorra tiempo.

¿Qué más se puede mejorar?

1. Eliminaremos la carga de dos versiones del menú para que no obstruyan el canal, lo haremos antes de finales de 2024. También ahorraremos tiempo de análisis.

2. Guarde en caché el menú: se actualiza con más frecuencia de la que las personas ingresan a nuestra aplicación, pero la primera pantalla no cambia tanto, por lo que podemos mostrar datos del caché y actualizar el menú en segundo plano; en el peor de los casos, parpadeará. un poco, pero lo mostraremos mucho antes, y las métricas sobre “parpadeos” se pueden recopilar y controlar por separado.

3. Solicita la segunda parte de solicitudes antes, sin esperar a que se muestre el menú. De hecho, estas consultas actualizan diferentes datos de fondo, por lo que no son visibles para el usuario y no tendrán un efecto visible.

4. Agregue un marcador de cambio para consultas grandes, p. eTag y procesar el código HTTP 304, por ejemplo, para actualizaciones de la lista de pizzerías. Podemos evitar descargarlo si no hay actualizaciones en él, porque el horario de la pizzería rara vez se actualiza.

En este artículo intenté hablar de los problemas al iniciar la aplicación, pero aún queda toda una capa de trabajo para optimizar la carga de imágenes tanto en la lista del catálogo como entre pantallas. Dale me gusta al artículo si el tema es interesante y suscríbete. en el canal Dodo Mobile Telegrampara no perderte el siguiente.