This page is not yet available in Spanish. We are working on its translation.
If you have any questions or feedback about our current translation project,
feel free to reach out to us!Real User Monitoring ofrece Mobile Vitals, que incluye un conjunto de puntos de datos inspirados en marcos como Android Vitals y MetricKit de Apple, que pueden ayudar a calcular información sobre la capacidad de respuesta, la estabilidad y el uso de recursos de tu aplicación móvil. Las calificaciones de Mobile Vitals pueden ser deficiente, moderado y bueno.
Puedes ver Mobile Vitals para tu aplicación al navegar a Digital Experience > Performance Summary (Experiencia digital > Resumen de rendimiento) y seleccionar tu aplicación.
Para acceder al dashboard de rendimiento de la aplicación móvil de RUM, ve a la pestaña Performance (Rendimiento) y, a continuación, haz clic en el enlace View Dashboard (Ver dashboard).
Comprende el estado general y el rendimiento de tu aplicación con los gráficos de líneas que muestran puntos de datos de varias versiones de la aplicación. Para filtrar por versión de la aplicación o ver sesiones y vistas específicas, haz clic en un gráfico.
También puedes seleccionar una vista en el RUM Explorer y observar los rangos de referencia recomendados que se correlacionan directamente con la experiencia de usuario de tu aplicación en la sesión. Haz clic en una métrica como Refresh Rate Average (Frecuencia de actualización media) y haz clic en Search Views With Poor Performance (Buscar vistas con bajo rendimiento) para aplicar un filtro en tu consulta de búsqueda y examinar vistas adicionales.
Telemetría
La siguiente telemetría proporciona información sobre el rendimiento de tu aplicación móvil.
| Medición | Descripción |
|---|
| Frecuencia de actualización | Para asegurar una experiencia de usuario fluida y sin fallos, tu aplicación debe renderizar los fotogramas a menos de 60Hz.
RUM rastrea la tasa de actualización de la vista del subproceso principal de la aplicación usando los atributos de vista @view.refresh_rate_average y @view.refresh_rate_min.
Nota: Las tasas de actualización están normalizadas en un rango de cero a 60fps. Por ejemplo, si tu aplicación se ejecuta a 100fps en un dispositivo capaz de renderizar 120fps, Datadog informa de 50fps en Mobile Vitals. |
| Renderizados lentos | Para asegurar una experiencia de usuario fluida y sin fallos, tu aplicación debe renderizar los fotogramas a menos de 60Hz.
RUM rastrea la tasa de actualización de la vista del subproceso principal de la aplicación usando los atributos de vista @view.refresh_rate_average y @view.refresh_rate_min.
Con el renderizado lento, puedes monitorizar qué vistas tardan más de 16ms o 60Hz en renderizar.
Nota: Las tasas de actualización están normalizadas en un rango de cero a 60fps. Por ejemplo, si tu aplicación se ejecuta a 100fps en un dispositivo capaz de renderizar 120fps, Datadog informa de 50fps en Mobile Vitals. |
| Fotogramas congelados | Los fotogramas que tardan más de 700ms en renderizarse aparecen como atascados y sin respuesta en tu aplicación. Se clasifican como fotogramas congelados.
RUM rastrea eventos long task con la duración de cualquier tarea que tarde más de 100ms en completarse.
Con los fotogramas congelados, puedes monitorizar qué vistas aparecen congeladas (tardan más de 700ms en renderizarse) para tus usuarios finales y eliminar los fallos en tu aplicación. |
| La aplicación no responde | Cuando el subproceso de interfaz de usuario de una aplicación se bloquea durante más de 5 segundos, se produce un error Application Not Responding (ANR). Si la aplicación está en primer plano, el sistema muestra un modal de diálogo al usuario, permitiéndole forzar la salida de la aplicación.
RUM rastrea las ocurrencias de ANR y captura todo el stack trace que bloquea el subproceso principal cuando encuentra un ANR. |
| Sesiones sin fallos por versión | Un fallo de aplicación se produce debido a una salida inesperada de la aplicación, normalmente causada por una excepción o señal no controlada. Las sesiones de usuario sin caídas en la aplicación se corresponden directamente con la experiencia y la satisfacción general del usuario final.
RUM realiza un rastreo completo de los informes de fallos y presenta tendencias a lo largo del tiempo con el Rastreo de errores.
Con las sesiones sin fallos, puedes mantenerte al día en los puntos de referencia de la industria y asegurarte de que tu aplicación ocupa un lugar destacado en Google Play Store. |
| Tics por segundo de la CPU | Un uso elevado de la CPU afecta a la duración de la batería de los dispositivos de tus usuarios.
RUM realiza rastreo de tics de CPU por segundo para cada vista y la utilización de la CPU en el transcurso de una sesión. El rango recomendado es <40 para bueno y <60 para moderado.
Puedes ver las principales vistas con el mayor número de tics de CPU de media durante un periodo seleccionado en Mobile Vitals en la página Información general de tu aplicación. |
| Utilización de la memoria | Un uso elevado de memoria puede provocar OutOfMemoryError, lo que hace que la aplicación se bloquee y crea una mala experiencia para el usuario.
RUM rastrea la cantidad de memoria física utilizada por tu aplicación en bytes para cada vista, en el transcurso de una sesión. El rango recomendado es <200MB para bueno y <400MB para moderado.
Puedes ver las principales vistas con mayor consumo de memoria de media durante un periodo seleccionado en Mobile Vitals en la página Información general de tu aplicación. |
| Medición | Descripción |
|---|
| Frecuencia de actualización | Para asegurar una experiencia de usuario fluida y sin fallos, tu aplicación debe renderizar los fotogramas a menos de 60Hz.
RUM rastrea la tasa de actualización de la vista del subproceso principal de la aplicación usando los atributos de vista @view.refresh_rate_average y @view.refresh_rate_min.
Nota: Las tasas de actualización están normalizadas en un rango de cero a 60fps. Por ejemplo, si tu aplicación se ejecuta a 100fps en un dispositivo capaz de renderizar 120fps, Datadog informa de 50fps en Mobile Vitals. |
| Renderizados lentos | Para asegurar una experiencia de usuario fluida y sin fallos, tu aplicación debe renderizar los fotogramas a menos de 60Hz.
RUM rastrea la tasa de actualización de la vista del subproceso principal de la aplicación usando los atributos de vista @view.refresh_rate_average y @view.refresh_rate_min.
Con el renderizado lento, puedes monitorizar qué vistas tardan más de 16ms o 60Hz en renderizar.
Nota: Las tasas de actualización están normalizadas en un rango de cero a 60fps. Por ejemplo, si tu aplicación se ejecuta a 100fps en un dispositivo capaz de renderizar 120fps, Datadog informa de 50fps en Mobile Vitals. |
| Fotogramas congelados | Los fotogramas que tardan más de 700ms en renderizarse aparecen como atascados y sin respuesta en tu aplicación. Se clasifican como fotogramas congelados.
RUM rastrea eventos long task con la duración de cualquier tarea que tarde más de 100ms en completarse.
Con los fotogramas congelados, puedes monitorizar qué vistas aparecen congeladas (tardan más de 700ms en renderizarse) para tus usuarios finales y eliminar los fallos en tu aplicación. |
| Sesiones sin fallos por versión | Un fallo de aplicación se produce debido a una salida inesperada de la aplicación, normalmente causada por una excepción o señal no controlada. Las sesiones de usuario sin caídas en la aplicación se corresponden directamente con la experiencia y la satisfacción general del usuario final.
RUM realiza un rastreo completo de los informes de fallos y presenta tendencias a lo largo del tiempo con el Rastreo de errores.
Con las sesiones sin fallos, puedes mantenerte al día en los puntos de referencia de la industria y asegurarte de que tu aplicación ocupa un lugar destacado en Google Play Store. |
| Tasa de cuelgues | Según la definición de Apple, la tasa de cuelgues de una aplicación corresponde al “número de segundos por hora que la aplicación no responde, contando únicamente los periodos de no respuesta superiores a 250 ms”. Para calcular la tasa de cuelgues de tu aplicación en Datadog, activa el informe de cuelgues de la aplicación y sigue la sección dedicada. |
| Tics por segundo de la CPU | Un uso elevado de la CPU afecta a la duración de la batería de los dispositivos de tus usuarios.
RUM realiza rastreo de tics de CPU por segundo para cada vista y la utilización de la CPU en el transcurso de una sesión. El rango recomendado es <40 para bueno y <60 para moderado.
Puedes ver las principales vistas con el mayor número de tics de CPU de media durante un periodo seleccionado en Mobile Vitals en la página Información general de tu aplicación. |
| Utilización de la memoria | Un uso elevado de memoria puede provocar terminaciones de WatchDog, lo que crea una mala experiencia para el usuario.
RUM rastrea la cantidad de memoria física utilizada por tu aplicación en bytes para cada vista, en el transcurso de una sesión. El rango recomendado es <200MB para bueno y <400MB para moderado.
Puedes ver las principales vistas con mayor consumo de memoria de media durante un periodo seleccionado en Mobile Vitals en la página Información general de tu aplicación. |
| Medición | Descripción |
|---|
| Frecuencia de actualización | Para asegurar una experiencia de usuario fluida y sin fallos, tu aplicación debe renderizar los fotogramas a menos de 60Hz.
RUM rastrea la tasa de actualización de la vista del subproceso principal de la aplicación usando los atributos de vista @view.refresh_rate_average y @view.refresh_rate_min.
Nota: Las tasas de actualización están normalizadas en un rango de cero a 60fps. Por ejemplo, si tu aplicación se ejecuta a 100fps en un dispositivo capaz de renderizar 120fps, Datadog informa de 50fps en Mobile Vitals. |
| Renderizados lentos | Para asegurar una experiencia de usuario fluida y sin fallos, tu aplicación debe renderizar los fotogramas a menos de 60Hz.
RUM rastrea la tasa de actualización de la vista del subproceso principal de la aplicación usando los atributos de vista @view.refresh_rate_average y @view.refresh_rate_min.
Con el renderizado lento, puedes monitorizar qué vistas tardan más de 16ms o 60Hz en renderizar.
Nota: Las tasas de actualización están normalizadas en un rango de cero a 60fps. Por ejemplo, si tu aplicación se ejecuta a 100fps en un dispositivo capaz de renderizar 120fps, Datadog informa de 50fps en Mobile Vitals. |
| Fotogramas congelados | Los fotogramas que tardan más de 700ms en renderizarse aparecen como atascados y sin respuesta en tu aplicación. Se clasifican como fotogramas congelados.
RUM rastrea eventos long task con la duración de cualquier tarea que tarde más de 100ms en completarse.
Con los fotogramas congelados, puedes monitorizar qué vistas aparecen congeladas (tardan más de 700ms en renderizarse) para tus usuarios finales y eliminar los fallos en tu aplicación. |
| La aplicación no responde | En Android, cuando el subproceso de interfaz de usuario de una aplicación se bloquea durante más de 5 segundos, se produce un error Application Not Responding (ANR). Si la aplicación está en primer plano, el sistema muestra un modal de diálogo al usuario, permitiéndole forzar la salida de la aplicación.
RUM rastrea las ocurrencias de ANR y captura todo el stack trace que bloquea el subproceso principal cuando encuentra un ANR. |
| Sesiones sin fallos por versión | Un fallo de aplicación se produce debido a una salida inesperada de la aplicación, normalmente causada por una excepción o señal no controlada. Las sesiones de usuario sin caídas en la aplicación se corresponden directamente con la experiencia y la satisfacción general del usuario final.
RUM realiza un rastreo completo de los informes de fallos y presenta tendencias a lo largo del tiempo con el Rastreo de errores.
Con las sesiones sin fallos, puedes mantenerte al día en los puntos de referencia de la industria y asegurarte de que tu aplicación ocupa un lugar destacado en Google Play Store. |
| Tics por segundo de la CPU | Un uso elevado de la CPU afecta a la duración de la batería de los dispositivos de tus usuarios.
RUM realiza rastreo de tics de CPU por segundo para cada vista y la utilización de la CPU en el transcurso de una sesión. El rango recomendado es <40 para bueno y <60 para moderado.
Puedes ver las principales vistas con el mayor número de tics de CPU de media durante un periodo seleccionado en Mobile Vitals en la página Información general de tu aplicación. |
| Utilización de la memoria | Un uso elevado de memoria puede provocar fallos de falta de memoria, lo que crea una mala experiencia para el usuario.
RUM rastrea la cantidad de memoria física utilizada por tu aplicación en bytes para cada vista, en el transcurso de una sesión. El rango recomendado es <200MB para bueno y <400MB para moderado.
Puedes ver las principales vistas con mayor consumo de memoria de media durante un periodo seleccionado en Mobile Vitals en la página Información general de tu aplicación. |
| Tiempo de compilación del widget | Es el tiempo que tarda en compilarse el fotograma en el subproceso de la interfaz de usuario. Para asegurar animaciones sin errores, esto no debería exceder 16ms para 60 FPS, y 8ms para 120 FPS.
Valores altos significan que necesitas optimizar tus métodos de compilación para esta vista. Consulta Control del costo de compilación en la documentación de Flutter. |
| Tiempo de ráster | Es el tiempo que se tarda en hacer ráster del fotograma en el subproceso de ráster. Para asegurar animaciones sin errores, esto no debería exceder 16ms para 60 FPS, y 8ms para 120 FPS.
Valores altos aquí pueden significar que tu vista es compleja de renderizar. Consulta [Identificación de problemas en el gráfico de la GPU][12] en la documentación de Flutter. |
| Medición | Descripción |
|---|
| Frecuencia de actualización | Para asegurar una experiencia de usuario fluida y sin fallos, tu aplicación debe renderizar los fotogramas a menos de 60Hz.
RUM rastrea la tasa de actualización de la vista del subproceso principal de la aplicación usando los atributos de vista @view.refresh_rate_average y @view.refresh_rate_min.
Nota: Las tasas de actualización están normalizadas en un rango de cero a 60fps. Por ejemplo, si tu aplicación se ejecuta a 100fps en un dispositivo capaz de renderizar 120fps, Datadog informa de 50fps en Mobile Vitals. |
| Frecuencia de actualización de JS | Para asegurar una experiencia de usuario fluida y sin fallos, tu aplicación debe renderizar los fotogramas a menos de 60Hz.
RUM rastrea la tasa de actualización de la vista del subproceso de JavaScript de la aplicación usando los atributos de vista @view.js_refresh_rate.average, @view.js_refresh_rate.min y @view.js_refresh_rate.max.
Nota: Las tasas de actualización están normalizadas en un rango de cero a 60fps. Por ejemplo, si tu aplicación se ejecuta a 100fps en un dispositivo capaz de renderizar 120fps, Datadog informa de 50fps en Mobile Vitals. |
| Renderizados lentos | Para asegurar una experiencia de usuario fluida y sin fallos, tu aplicación debe renderizar los fotogramas a menos de 60Hz.
Con el renderizado lento, puedes monitorizar qué vistas tienen una tasa de fotograma media de menos de 55fps.
Nota: Las tasas de actualización están normalizadas en un rango de cero a 60fps. Por ejemplo, si tu aplicación se ejecuta a 100fps en un dispositivo capaz de renderizar 120fps, Datadog informa de 50fps en Mobile Vitals. |
| Fotogramas congelados | Los fotogramas que tardan más de 700ms en renderizarse aparecen como atascados y sin respuesta en tu aplicación. Se clasifican como fotogramas congelados.
RUM rastrea eventos long task con la duración de cualquier tarea que tarde más de 100ms en completarse.
Con los fotogramas congelados, puedes monitorizar qué vistas aparecen congeladas (tardan más de 700ms en renderizarse) para tus usuarios finales y eliminar los fallos en tu aplicación. |
| La aplicación no responde | Cuando el subproceso de interfaz de usuario de una aplicación se bloquea durante más de 5 segundos, se produce un error Application Not Responding (ANR). Si la aplicación está en primer plano, el sistema muestra un modal de diálogo al usuario, permitiéndole forzar la salida de la aplicación.
RUM rastrea las ocurrencias de ANR y captura todo el stack trace que bloquea el subproceso principal cuando encuentra un ANR. |
| Sesiones sin fallos por versión | Un fallo de aplicación se produce debido a una salida inesperada de la aplicación, normalmente causada por una excepción o señal no controlada. Las sesiones de usuario sin caídas en la aplicación se corresponden directamente con la experiencia y la satisfacción general del usuario final.
RUM realiza un rastreo completo de los informes de fallos y presenta tendencias a lo largo del tiempo con el Rastreo de errores.
Con las sesiones sin fallos, puedes mantenerte al día en los puntos de referencia de la industria y asegurarte de que tu aplicación ocupa un lugar destacado en Google Play Store. |
| Tics por segundo de la CPU | Un uso elevado de la CPU afecta a la duración de la batería de los dispositivos de tus usuarios.
RUM realiza rastreo de tics de CPU por segundo para cada vista y la utilización de la CPU en el transcurso de una sesión. El rango recomendado es <40 para bueno y <60 para moderado.
Puedes ver las principales vistas con el mayor número de tics de CPU de media durante un periodo seleccionado en Mobile Vitals en la página Información general de tu aplicación. |
| Utilización de la memoria | Un uso elevado de memoria puede provocar fallos de falta de memoria, lo que crea una mala experiencia para el usuario.
RUM rastrea la cantidad de memoria física utilizada por tu aplicación en bytes para cada vista, en el transcurso de una sesión. El rango recomendado es <200MB para bueno y <400MB para moderado.
Puedes ver las principales vistas con mayor consumo de memoria de media durante un periodo seleccionado en Mobile Vitals en la página Información general de tu aplicación. |
Referencias adicionales
Más enlaces, artículos y documentación útiles:
