Por qué UXCam tiene uno de los SDK con mejor rendimiento

El rendimiento del SDK de UXCam de un vistazo

Esto es lo que cuesta el SDK en un dispositivo Android de gama baja, antes de entrar en cómo se midió cada número.

• El tamaño de la app crece cerca de 0.6 MB, más o menos 1% de una app típica.

• El arranque en frío agrega cerca de 90 ms. Los arranques templado y en caliente varían menos de 10 ms.

• La grabación usa cerca de 6 MB de heap.

• La captura de pantalla ocurre más o menos una vez cada dos segundos, fuera del hilo principal.

• En uso real, una sesión grabada sube cerca de 0.4 MB por minuto de video de replay en Android, comprimido y cifrado, y la calidad de grabación es configurable.

SDK Android de UXCam 3.10.7, Galaxy M11 (peor caso, gama baja). iOS medido en iPhone 16 Pro, iOS 26 — ve la sección de iOS más abajo.

Para quienes lo prefieren todo en un solo lugar, aquí está la especificación completa en el dispositivo de gama baja usado en la prueba.

Qué es un SDK y por qué importa su rendimiento

Un SDK, o software development kit (kit de desarrollo de software), es un conjunto de herramientas descargables que los desarrolladores usan para crear aplicaciones en plataformas específicas. En esencia, un SDK es un fragmento de código que escribió otra persona para que tú puedas ejecutar una función en tu app. La ventaja de un kit así es que el desarrollador no tiene que construir todas las funciones de una app desde cero. El kit puede incluir bibliotecas, documentación, ejemplos de código, procesos y guías que los desarrolladores usan para integrar en sus propias apps.

En este caso, en lugar de escribir grabación de sesión, captura de pantalla y subida segura desde cero, instalas el SDK de UXCam y obtienes todo eso listo.

Por qué importa un SDK de bajo riesgo y alto rendimiento

El rendimiento importa porque todo SDK corre dentro de tu proceso, en tus hilos, contra tu presupuesto de frame.

Un SDK de alto riesgo y mal rendimiento puede provocar:

• Arranques más lentos

• Bugs en la app (caídas de frames al hacer scroll...)

• Mayor uso de memoria

• Más crashes

• Peor duración de batería

• Funcionalidad reducida

Y lo peor es que tus usuarios lo interpretan todo como que tu app es lenta, no la del proveedor. Un SDK que se comporta mal también puede poner en riesgo tu ficha en la tienda, causar ANRs o inflar tu APK, y cualquiera de esos problemas recae sobre tu equipo, no sobre el proveedor.

Así que la pregunta correcta para hacerle a cualquier proveedor de analítica es simple: ¿cuánto cuesta agregar tu SDK y me lo puedes mostrar?

Por qué el SDK de UXCam está hecho para el rendimiento móvil

Los números de UXCam salen bien porque el SDK se diseñó para las restricciones en las que corre.

Algunos puntos lo diferencian:

• Es nativo de mobile. UXCam construye para mobile desde 2014, así que el pipeline de captura, la oclusión y la cola de subida se diseñaron para teléfonos, no se portaron desde un grabador hecho para web.

• Un equipo dedicado de SDK lo mantiene a tiempo completo, en frameworks nativos y multiplataforma.

• Cubre los stacks que los equipos realmente usan en producción, incluidos iOS, Android, React Native, Flutter, NativeScript, Cordova/Ionic y .NET MAUI.

• Es rápido de integrar, lo que mantiene bajo el riesgo de una mala instalación.

Nada de esto es, por sí solo, una promesa de rendimiento. Es la razón por la que las mediciones de abajo dan los resultados que dan.

UXCam fue destacada como uno de los 80 principales SDKs en el Google SDK Index, un directorio que ayuda a los desarrolladores a elegir las mejores apps para su plataforma. Los SDKs presentes en esa lista son confiables y reconocidos por la comunidad de desarrolladores de apps móviles.

Cómo medimos el impacto del SDK de UXCam

Medimos el SDK en profundidad en un dispositivo Android de gama baja, cercano al peor caso — si el costo es aceptable ahí, es menor en el hardware que la mayoría de los usuarios lleva — y luego confirmamos que se sostiene en un iPhone actual, en la sección de iOS más abajo.

Armamos un entorno de benchmark que arranca la app en frío, ejecuta un scroll fijo sobre una lista de 60 filas y graba la misma ejecución dos veces: una sin el SDK y otra con él instalado y grabando. Los tiempos de frame vienen de las métricas de frame de la plataforma (frameDurationCpuMs), el arranque del tiempo hasta la visualización inicial, y el comportamiento de hilos y de recolección de basura (garbage collection) de 76 trazas de Perfetto.

Reportamos medianas, no promedios. El arranque en frío en una CPU sin frecuencia bloqueada es ruidoso. En 10 ejecuciones, un arranque en frío llegó a 1,729 ms mientras el resto se ubicó entre cerca de 1,050 y 1,250 ms, de modo que un promedio distorsionaría el arranque típico.

Nombramos el dispositivo a propósito. El mismo SDK se comporta distinto en un Pixel 9 que en un Galaxy M11, así que un benchmark sin un dispositivo declarado no es un benchmark. Elegimos el M11, un teléfono de gama baja de 2020, porque está cerca de un peor caso: un overhead aceptable aquí es menor en el hardware de gama media y tope de línea que la mayoría de los usuarios lleva.

También corrimos el mismo benchmark en un tope de línea actual, un iPhone 16 Pro con iOS 26, para mostrar el otro extremo del rango; esos resultados están en la sección de iOS más abajo.

Tamaño de la app: UXCam agrega cerca de 0.6 MB

UXCam agrega cerca de 0.6 MB a un build de producción. Este es el desglose del benchmark:

• App de prueba sin UXCam: 2.2 MB

• App de prueba con UXCam: 2.8 MB

• Agregado por el SDK: 0.6 MB

Tamaño de app medido en el SDK Android 3.8.12; la huella del SDK es estable en las versiones recientes. En iOS, el SDK agrega cerca de 1.3 MB (estimación comprimida); ve la sección de iOS.

El porcentaje depende de dónde lo coloques. En la app de prueba de 2.2 MB, 0.6 MB representa un salto de 27%, y por eso ese número, por sí solo, engaña. En una app de 40 a 60 MB, típica en Android, los mismos 0.6 MB representan cerca de 1%. Por eso destacamos el número absoluto.

El arranque de la app sigue siendo rápido

El arranque en frío es donde aparece la inicialización del SDK. Con UXCam grabando, pasó de cerca de 969 ms a 1,058 ms, más o menos 90 ms. El arranque templado fue de 168 ms a 176 ms, y el arranque en caliente de 110 ms a 113 ms — prácticamente sin cambios.

La inicialización corre en los hilos propios del SDK, así que no bloquea el hilo principal mientras tu app termina de abrir. Los 90 ms son trabajo concurrente, no una espera que el usuario percibe. El valor de arranque en frío con UXCam también se mantuvo estable en las versiones 3.9.0, 3.10.0 y 3.10.7, o sea, no viene subiendo de release en release.

La CPU se mantiene dentro del presupuesto de frame

Durante el benchmark no vimos a UXCam empujar el trabajo normal de UI más allá del presupuesto de 16.7 ms por frame. La captura de pantalla es la excepción. Hace trabajo real, pero ese trabajo corre fuera del hilo principal y se dispara más o menos una vez cada dos segundos en la tasa de captura por defecto.

Una captura cuesta cerca de 80 ms de trabajo en hilo de segundo plano para capturar, ocluir y transformar la pantalla, más cerca de 18 ms para codificarla. El hilo principal solo hace un breve salto para entregar el frame. Perfetto mostró al SDK usando un pequeño pool fijo de worker threads para esto y reutilizándolos, sin crecimiento descontrolado de hilos ni pausas de GC a lo largo de una sesión.

Fuérzalo más de lo que la producción lo haría jamás — scroll continuo en el M11 con la captura muy por encima de la tasa por defecto — y los frames que coinciden con una captura se alargan. Esa es una configuración de estrés, no de producción. En la tasa por defecto, y en hardware de gama media o tope de línea, no lo vimos aparecer. Los percentiles completos por frame están en los datos del benchmark, si tu equipo quiere verlos.

Memoria: una huella ligera y fija

Durante la grabación, el pico de heap pasó de cerca de 7.6 MB a 13.5 MB y la memoria residente (RSS) de cerca de 25 MB a 38 MB, o sea, la grabación cuesta aproximadamente 6 MB de heap en este dispositivo.

SDK Android 3.10.7, pico por sesión, mediana.

Más importante aún: el heap no siguió subiendo a lo largo de la sesión. En nuestras ejecuciones subió hasta el overhead de arriba y luego se estabilizó, que es el comportamiento que se espera de un grabador: un conjunto de trabajo acotado, en lugar de una fuga lenta. Los mismos picos se mantuvieron en las versiones 3.9.0, 3.10.0 y 3.10.7.

Cuántos datos móviles consume una sesión

La grabación de sesión registra video, así que su subida se mide en megabytes, no en kilobytes. En uso real, UXCam se mantiene ligera: en millones de sesiones reales de apps en producción y de alto tráfico, la grabación sube, en promedio, cerca de 0.4 MB por minuto en Android, de modo que una sesión típica de 10 minutos sube alrededor de 4 MB — más o menos el tamaño de una sola foto de teléfono — comprimido y cifrado. Una prueba controlada aparte, en un dispositivo de gama baja, lo confirma. En iOS, en una medición controlada en un iPhone 11 con la calidad de grabación por defecto, una sesión de 10 minutos es de cerca de 5.7 MB.

Datos subidos por sesión, calidad de grabación por defecto. Ambas plataformas comprimidas y cifradas.

Casi todo eso es el video de replay comprimido; los datos de eventos en sí suman apenas cerca de 2 KB por sesión. La subida ocurre cuando la app pasa a segundo plano, no en streaming mientras alguien está usando la app; y las sesiones quedan en cola localmente cuando no hay conexión, y se envían apenas una vuelve.

El ancho de banda también es configurable. La calidad de grabación tiene cinco niveles, desde un modo ahorro de datos hasta muy alta, un rango de aproximadamente cuatro veces, así que un equipo sensible al consumo de datos puede bajarla. También puedes restringir las subidas solo a Wi-Fi en la configuración de grabación, lo que mantiene el replay totalmente fuera de la factura de datos móviles.

Las cifras de Android son el promedio de producción en el mundo real sobre millones de sesiones de apps de alto tráfico en producción, respaldadas por una prueba controlada en un dispositivo de gama baja (Galaxy M31, calidad por defecto). Las cifras de iOS son una medición controlada en un iPhone 11 con la calidad por defecto. Las dos plataformas se miden de formas distintas, así que lee cada una por separado, no como un ranking. Ambas están comprimidas y cifradas, y el tamaño real varía según la actividad en pantalla — una pantalla mayormente estática sube menos, y el scroll constante sube más.

iOS: el mismo resultado en un iPhone actual

Las cifras de Android de arriba son un peor caso a propósito: un teléfono de gama baja de 2020. Para ver el otro extremo del rango, corrimos el mismo benchmark en un tope de línea actual, un iPhone 16 Pro con iOS 26, en las diez pantallas de carga de trabajo, con tres iteraciones cada una. En ese hardware, UXCam es casi imperceptible.

La CPU promedio en las diez pantallas pasó de 1.44% a 1.51%, un cambio lo bastante pequeño como para caber dentro del ruido normal entre ejecuciones. El pico de memoria subió cerca de 1.3 MB durante la grabación, y la tasa de frames quedó sin cambios pantalla por pantalla. El overhead de iOS se ve más ligero que las cifras de Android de arriba, pero la mayor parte de esa diferencia es el dispositivo: un tope de línea de 2024 tiene mucho más margen que un teléfono de gama baja de 2020, así que la lectura justa es que estas dos ejecuciones delimitan el rango, no que una plataforma sea más barata que la otra.

En el tamaño de la app, la línea base de 0.32 MB es una app de demostración vacía, así que leer el aumento como proporción lo exagera; lo que se traslada a una app real es el aumento absoluto de cerca de 1.3 MB, y por eso destacamos ese número. La cifra es una estimación de paquete comprimido en el dispositivo, no un reporte de app thinning de la App Store, así que el tamaño final de descarga que ve el usuario depende del app thinning de Apple.

Diseñado para fallar de forma segura

La grabación está diseñada para nunca tumbar la app anfitriona junto con ella. El trabajo de captura, codificación y subida de UXCam está aislado en sus propios hilos y encapsulado de modo que, si algo sale mal dentro del SDK, deja de grabar en lugar de hacer crashear tu app. El SDK no está en la ruta crítica de tu UI, así que un problema en la captura aparece como una sesión faltante, no como un crash que ven tus usuarios.

Ese aislamiento es lo que le permite a UXCam correr en apps reguladas de finanzas, retail y telecomunicaciones, que someten cada dependencia a revisión de crash y estabilidad antes de salir a producción.

Cómo UXCam mantiene el SDK ligero

Los números de arriba son resultado de unas cuantas decisiones deliberadas de ingeniería. Las que más importan:

• La captura de pantalla usa PixelCopy cuando está disponible y ejecuta el trabajo pesado en un hilo de segundo plano, así que el hilo principal solo hace un breve salto.

• La captura está limitada a cerca de un frame cada dos segundos por defecto, lo que hace que el costo de CPU sea raro.

• La oclusión ocurre en el momento de la captura, en el dispositivo, así que enmascarar contenido sensible es parte del trabajo de captura, no un paso extra.

• Las subidas se agrupan en lotes y funcionan offline: quedan en cola localmente y se envían cuando la app pasa a segundo plano o cuando vuelve la conexión.

Cómo se compara UXCam con otros SDKs de analítica móvil

La mayoría de las herramientas de analítica y de experiencia se construyeron primero para la web, o tratan la grabación de sesión móvil como un agregado. UXCam es nativa de mobile, graba la sesión completa sobre vistas nativas reales y publica cuánto cuesta eso. Cuando pones lado a lado los números que los proveedores publican en su propia documentación pública, UXCam tiene la menor huella publicada de tamaño de app entre todos los SDKs de grabación de sesión móvil.

Las cifras de la competencia provienen de la documentación pública de cada proveedor, con la fecha que el propio proveedor indica cuando la indica. No todos los proveedores publican el tamaño de su SDK móvil. Solo incluimos proveedores con cifras oficiales y disponibles públicamente, así que no todas las empresas aparecen en la tabla.

Dos advertencias acompañan esa tabla. Las cifras de tamaño de app no se miden de forma idéntica entre proveedores, así que léelas como la cifra propia de cada proveedor, no como una única prueba controlada. Y varias herramientas aquí están hechas para analítica web o analítica de producto, no para grabación de sesión móvil, que es un trabajo distinto. Por los números que cada proveedor publica, UXCam tiene la menor huella de tamaño de app entre las herramientas de grabación de sesión listadas, y publica más sobre su impacto en tiempo de ejecución que la mayoría de ellas.

Cómo UXCam protege los datos de tus usuarios

La privacidad se maneja en el dispositivo, en el momento de la captura. Cualquier contenido sensible — ya sean campos de texto individuales, una parte de una pantalla o una pantalla entera, como una página de pago — se ocluye antes de que el frame se convierta en video. Los pixeles sensibles nunca se renderizan en la grabación y nunca salen del dispositivo.

Tú controlas qué se enmascara:

• Ocultar textos específicos, para campos que contienen datos personales

• Ocultar una vista, para una parte de una pantalla

• Ocultar una pantalla entera, para páginas como checkout o configuración de la cuenta

UXCam cumple con el GDPR y, como la oclusión ocurre antes de la subida, la garantía no depende de borrar nada en el servidor. El contenido sensible simplemente nunca llega hasta nosotros.

Plataformas y frameworks que UXCam admite

UXCam cubre stacks nativos y multiplataforma desde un único SDK central, incluidos iOS, Android, React Native, Flutter, NativeScript, Cordova/Ionic y .NET MAUI. Jetpack Compose en Android es compatible con el SDK principal, y SwiftUI en iOS es compatible mediante un SDK dedicado de SwiftUI.

La integración es rápida. Una instalación básica — importar el SDK, crear el objeto de configuración e iniciarlo — toma unos minutos, y una configuración completa con eventos personalizados y oclusión suele tomar cerca de 30 minutos.

Ponlo en producción con confianza

UXCam graba la sesión móvil completa por cerca de 0.6 MB de tamaño de app, más o menos 90 ms de trabajo concurrente en el arranque en frío y cerca de 6 MB de memoria, sobre un stack construido para mobile desde 2014. Los números están arriba, y los datos completos del benchmark están disponibles si tu equipo quiere profundizar.

Si quieres verlo en tu propia app, comienza gratis o solicita una demo.