Por que a UXCam tem o melhor SDK do mercado de aplicativos?

O desempenho do SDK da UXCam num relance

Veja aqui o que o SDK custa em um dispositivo Android de entrada, antes de entrarmos em como cada número foi medido.

• O tamanho do app cresce cerca de 0,6 MB, mais ou menos 1% de um app típico.

• A inicialização a frio adiciona cerca de 90 ms. As inicializações a morno e a quente variam menos de 10 ms

• A gravação usa cerca de 6 MB de heap

• A captura de tela ocorre mais ou menos uma vez a cada dois segundos, fora da thread principal

• No uso real, uma sessão gravada envia cerca de 0,4 MB por minuto de vídeo de replay no Android, comprimido e criptografado, e a qualidade de gravação é configurável.

SDK Android da UXCam 3.10.7, Galaxy M11 (pior caso, dispositivo de entrada). iOS medido no iPhone 16 Pro, iOS 26 — veja a seção de iOS abaixo.

Para quem prefere tudo em um só lugar, aqui está a especificação completa no dispositivo de entrada usado no teste.

O que é um SDK e por que seu desempenho importa

Um SDK, ou software development kit (kit de desenvolvimento de software), é um conjunto de ferramentas que os desenvolvedores baixam para criar aplicações em plataformas específicas. Na essência, um SDK é um trecho de código que outra pessoa escreveu para que você possa executar uma função no seu app. A vantagem de um kit assim é que o desenvolvedor não precisa construir todas as funções de um app do zero. O kit pode incluir bibliotecas, documentação, exemplos de código, processos e guias que os desenvolvedores usam para integrar aos próprios apps.

Neste caso, em vez de escrever gravação de sessão, captura de tela e envio seguro do zero, você instala o SDK da UXCam e recebe tudo isso pronto.

Por que um SDK de baixo risco e alto desempenho importa

O desempenho importa porque todo SDK roda dentro do seu processo, nas suas threads, dentro do seu orçamento de frame.

Um SDK de alto risco e desempenho ruim pode resultar em:

• Inicializações mais lentas

• Bugs no app (quedas de frame durante a rolagem...)

• Maior uso de memória

• Mais falhas

• Pior duração de bateria

• Funcionalidades reduzidas

E o pior é que os seus usuários interpretam tudo isso como o seu app sendo lento, não o do fornecedor. Um SDK que se comporta mal também pode colocar em risco a sua listagem na loja, causar ANRs ou inchar o seu APK, e qualquer um desses problemas recai sobre a sua equipe, não sobre o fornecedor.

Por isso, a pergunta certa a fazer a qualquer fornecedor de análise é simples: quanto custa adicionar o seu SDK, e você consegue me mostrar?

Por que o SDK da UXCam foi construído para desempenho mobile

Os números da UXCam são bons porque o SDK foi projetado para as restrições em que ele roda.

Alguns pontos o diferenciam:

• Ele é nativo de mobile. A UXCam constrói para mobile desde 2014, então o pipeline de captura, a oclusão e a fila de envio foram projetados para celulares, não portados de um gravador feito para web.

• Uma equipe dedicada de SDK cuida dele em tempo integral, em frameworks nativos e multiplataforma.

• Ele cobre as stacks que as equipes realmente usam em produção, incluindo iOS, Android, React Native, Flutter, NativeScript, Cordova/Ionic e .NET MAUI.

• Ele é rápido de integrar, o que mantém baixo o risco de uma instalação problemática.

Nada disso é, por si só, uma promessa de desempenho. É o motivo pelo qual as medições abaixo têm os resultados que têm.

A UXCam foi destacada como um dos 80 principais SDKs no Google SDK Index, um diretório que ajuda os desenvolvedores a escolher os melhores apps para a sua plataforma. Os SDKs presentes nessa lista são confiáveis e reconhecidos pela comunidade de desenvolvedores de apps móveis.

Como medimos o impacto do SDK da UXCam

Medimos o SDK em profundidade em um dispositivo Android de entrada, próximo do pior caso — se o custo é aceitável ali, ele é menor no hardware que a maioria dos usuários carrega — e depois confirmamos que isso se mantém em um iPhone atual, na seção de iOS abaixo.

Montamos um ambiente de benchmark que inicializa o app a frio, executa uma rolagem fixa sobre uma lista de 60 linhas e grava a mesma execução duas vezes: uma sem o SDK e outra com ele instalado e gravando. Os tempos de frame vêm das métricas de frame da plataforma (frameDurationCpuMs), a inicialização vem do tempo até a exibição inicial, e o comportamento de threads e de coleta de lixo (garbage collection) vem de 76 traces do Perfetto.

Reportamos medianas, não médias. A inicialização a frio em uma CPU sem frequência travada é ruidosa. Em 10 execuções, uma inicialização a frio chegou a 1.729 ms, enquanto as demais ficaram entre cerca de 1.050 e 1.250 ms, de modo que uma média distorceria a inicialização típica.

Nomeamos o dispositivo de propósito. O mesmo SDK se comporta de forma diferente em um Pixel 9 e em um Galaxy M11, então um benchmark sem um dispositivo declarado não é um benchmark. Escolhemos o M11, um celular de entrada de 2020, porque ele está perto de um pior caso: um overhead aceitável aqui é menor no hardware intermediário e topo de linha que a maioria dos usuários carrega.

Também rodamos o mesmo benchmark em um topo de linha atual, um iPhone 16 Pro com iOS 26, para mostrar o outro extremo da faixa; esses resultados estão na seção de iOS abaixo.

Tamanho do app: a UXCam adiciona cerca de 0,6 MB

A UXCam adiciona cerca de 0,6 MB a uma build de produção. Veja o detalhamento do benchmark:

• App de teste sem a UXCam: 2,2 MB

• App de teste com a UXCam: 2,8 MB

• Adicionado pelo SDK: 0,6 MB

Tamanho de app medido no SDK Android 3.8.12; a pegada do SDK é estável nas versões recentes. No iOS, o SDK adiciona cerca de 1,3 MB (estimativa comprimida); veja a seção de iOS.

A porcentagem depende de onde você o coloca. No app de teste de 2,2 MB, 0,6 MB representa um salto de 27%, e é por isso que esse número, sozinho, engana. Em um app de 40 a 60 MB, o que é típico no Android, os mesmos 0,6 MB representam cerca de 1%. É por isso que destacamos o número absoluto.

A inicialização do app continua rápida

A inicialização a frio é onde a inicialização do SDK aparece. Com a UXCam gravando, ela passou de cerca de 969 ms para 1.058 ms, mais ou menos 90 ms. A inicialização a morno foi de 168 ms para 176 ms, e a a quente de 110 ms para 113 ms — praticamente inalteradas.

A inicialização roda nas threads do próprio SDK, então ela não bloqueia a thread principal enquanto o seu app termina de abrir. Os 90 ms são trabalho concorrente, não uma espera que o usuário percebe. O valor de inicialização a frio com a UXCam também se manteve estável nas versões 3.9.0, 3.10.0 e 3.10.7, ou seja, não vem subindo de release em release.

A CPU se mantém dentro do orçamento de frame

Durante o benchmark, não vimos a UXCam empurrar o trabalho normal de UI para além do orçamento de 16,7 ms por frame. A captura de tela é a exceção. Ela faz trabalho de verdade, mas esse trabalho roda fora da thread principal e dispara mais ou menos uma vez a cada dois segundos na taxa de captura padrão.

Uma captura custa cerca de 80 ms de trabalho em thread de segundo plano para capturar, ocultar e transformar a tela, mais cerca de 18 ms para codificá-la. A thread principal só faz um breve desvio para repassar o frame. O Perfetto mostrou o SDK usando um pequeno pool fixo de worker threads para isso e reaproveitando-as, sem crescimento descontrolado de threads nem pausas de GC ao longo de uma sessão.

Force mais do que a produção jamais forçaria — rolagem contínua no M11 com a captura muito acima da taxa padrão — e os frames que coincidem com uma captura ficam longos. Essa é uma configuração de estresse, não de produção. Na taxa padrão, e em hardware intermediário ou topo de linha, isso não apareceu. Os percentis completos por frame estão nos dados do benchmark, caso a sua equipe queira vê-los.

Memória: uma pegada leve e fixa

Durante a gravação, o pico de heap passou de cerca de 7,6 MB para 13,5 MB e a memória residente (RSS) de cerca de 25 MB para 38 MB, ou seja, a gravação custa aproximadamente 6 MB de heap neste dispositivo.

SDK Android 3.10.7, pico por sessão, mediana. Mais importante: o heap não continuou subindo ao longo da sessão. Nas nossas execuções, ele subiu até o overhead acima e então se estabilizou, que é o comportamento que se espera de um gravador: um conjunto de trabalho limitado, em vez de um vazamento lento. Os mesmos picos se mantiveram nas versões 3.9.0, 3.10.0 e 3.10.7.

Quantos dados móveis uma sessão consome

A gravação de sessão registra vídeo, então o seu envio é medido em megabytes, não em kilobytes. No uso real, a UXCam se mantém leve: em milhões de sessões reais de apps em produção e de alto tráfego, a gravação envia, em média, cerca de 0,4 MB por minuto no Android, de modo que uma sessão típica de 10 minutos envia por volta de 4 MB — mais ou menos o tamanho de uma única foto de celular — comprimido e criptografado. Um teste controlado à parte, em um dispositivo de entrada, confirma esse valor. No iOS, em uma medição controlada em um iPhone 11 na qualidade de gravação padrão, uma sessão de 10 minutos tem cerca de 5,7 MB.

Dados enviados por sessão, qualidade de gravação padrão. As duas plataformas comprimidas e criptografadas.

Quase tudo isso é o vídeo de replay comprimido; os dados de eventos em si somam apenas cerca de 2 KB por sessão. O envio acontece quando o app vai para segundo plano, e não em streaming enquanto alguém está usando o app; e as sessões ficam em fila localmente quando não há conexão, sendo enviadas assim que uma conexão volta.

A largura de banda também é configurável. A qualidade de gravação tem cinco níveis, de um modo economia de dados até muito alta, uma faixa de aproximadamente quatro vezes, então uma equipe sensível a consumo de dados pode reduzi-la. Você também pode restringir os envios apenas ao Wi-Fi nas configurações de gravação, o que mantém o replay totalmente fora da conta do plano de dados.

Os números de Android são a média de produção no mundo real em milhões de sessões de apps de alto tráfego em produção, respaldados por um teste controlado em um dispositivo de entrada (Galaxy M31, qualidade padrão). Os números de iOS são uma medição controlada em um iPhone 11 na qualidade padrão. As duas plataformas são medidas de formas diferentes, então leia cada uma isoladamente, e não como um ranking. Ambas são comprimidas e criptografadas, e o tamanho real varia conforme a atividade na tela — uma tela majoritariamente estática envia menos, e rolagem constante envia mais.

iOS: o mesmo resultado em um iPhone atual

Os números de Android acima são um pior caso de propósito: um celular de entrada de 2020. Para ver o outro extremo da faixa, rodamos o mesmo benchmark em um topo de linha atual, um iPhone 16 Pro com iOS 26, em todas as dez telas de carga de trabalho, com três iterações cada. Nesse hardware, a UXCam é quase imperceptível.

A CPU média nas dez telas passou de 1,44% para 1,51%, uma variação pequena o bastante para caber no ruído normal entre execuções. O pico de memória subiu cerca de 1,3 MB durante a gravação, e a taxa de frames ficou inalterada tela a tela. O overhead do iOS parece mais leve que os números de Android acima, mas a maior parte dessa diferença é o dispositivo: um topo de linha de 2024 tem muito mais folga que um celular de entrada de 2020, então a leitura justa é que essas duas execuções delimitam a faixa, e não que uma plataforma seja mais barata que a outra.

No tamanho do app, a linha de base de 0,32 MB é um app de demonstração vazio, então ler o aumento como proporção o exagera; o que se aplica a um app real é o aumento absoluto de cerca de 1,3 MB, e é por isso que destacamos esse número. O valor é uma estimativa de pacote comprimido no dispositivo, e não um relatório de app thinning da App Store, então o tamanho final de download que o usuário vê depende do app thinning da Apple.

Projetado para falhar com segurança

A gravação foi projetada para nunca derrubar o app hospedeiro junto com ela.

O trabalho de captura, codificação e envio da UXCam fica isolado em suas próprias threads e encapsulado de modo que, se algo der errado dentro do SDK, ele para de gravar em vez de travar o seu app. O SDK não fica no caminho crítico da sua UI, então um problema na captura aparece como uma sessão faltante, não como um crash que os seus usuários veem.

É esse isolamento que permite à UXCam rodar em apps regulados de finanças, varejo e telecomunicações, que submetem toda dependência a revisão de crash e estabilidade antes de entrar em produção.

Como a UXCam mantém o SDK leve

Os números acima são resultado de algumas escolhas deliberadas de engenharia. As que mais importam:

• A captura de tela usa PixelCopy quando disponível e executa o trabalho pesado em uma thread de segundo plano, então a thread principal só faz um breve desvio.

• A captura é limitada a cerca de um frame a cada dois segundos por padrão, o que torna o custo de CPU raro.

• A oclusão acontece no momento da captura, no dispositivo, então mascarar conteúdo sensível faz parte do trabalho de captura, e não de uma etapa extra.

• Os envios são agrupados em lote e funcionam offline, ficando em fila localmente e sendo enviados quando o app vai para segundo plano ou quando a conexão volta.

Como a UXCam se compara a outros SDKs de análise mobile

A maioria das ferramentas de análise e de experiência foi construída primeiro para a web, ou trata a gravação de sessão mobile como um complemento. A UXCam é nativa de mobile, grava a sessão completa sobre views nativas reais e publica quanto isso custa. Quando você coloca lado a lado os números que os fornecedores divulgam na própria documentação pública, a UXCam tem a menor pegada publicada de tamanho de app entre todos os SDKs de gravação de sessão mobile.

Os números dos concorrentes vêm da documentação pública de cada fornecedor, com a data informada sempre que o próprio fornecedor a informa. Nem todo fornecedor publica o tamanho do seu SDK mobile. Incluímos apenas fornecedores com números oficiais e disponíveis publicamente, então nem toda empresa aparece na tabela.

Duas ressalvas acompanham essa tabela. Os números de tamanho de app não são medidos de forma idêntica entre os fornecedores, então leia-os como o valor próprio de cada fornecedor, e não como um único teste controlado. E várias ferramentas aqui foram feitas para análise web ou análise de produto, não para gravação de sessão mobile, que é um trabalho diferente. Pelos números que cada fornecedor publica, a UXCam tem a menor pegada de tamanho de app entre as ferramentas de gravação de sessão listadas, e publica mais sobre o seu impacto em tempo de execução do que a maioria delas.

Como a UXCam protege os dados dos seus usuários

A privacidade é tratada no dispositivo, no momento da captura. Qualquer conteúdo sensível — seja campos de texto individuais, uma parte de uma tela ou uma tela inteira, como uma página de pagamento — é ocultado antes de o frame virar vídeo. Os pixels sensíveis nunca são renderizados na gravação e nunca saem do dispositivo.

Você controla o que é mascarado:

• Ocultar textos específicos, para campos que contêm dados pessoais

• Ocultar uma view, para uma parte de uma tela

• Ocultar uma tela inteira, para páginas como checkout ou configurações de conta

A UXCam está em conformidade com o GDPR e, como a oclusão acontece antes do envio, a garantia não depende de apagar nada no servidor. O conteúdo sensível simplesmente nunca chega até nós.

Plataformas e frameworks que a UXCam suporta

A UXCam cobre stacks nativas e multiplataforma a partir de um único SDK central, incluindo iOS, Android, React Native, Flutter, NativeScript, Cordova/Ionic e .NET MAUI. O Jetpack Compose no Android é suportado pelo SDK principal, e o SwiftUI no iOS é suportado por meio de um SDK dedicado de SwiftUI.

A integração é rápida. Uma instalação básica — importar o SDK, criar o objeto de configuração e iniciá-lo — leva alguns minutos, e uma configuração completa com eventos personalizados e oclusão costuma levar cerca de 30 minutos.

Perguntas frequentes sobre o SDK da UXCam

Coloque em produção com confiança

A UXCam grava a sessão mobile completa por cerca de 0,6 MB de tamanho de app, mais ou menos 90 ms de trabalho concorrente na inicialização a frio e cerca de 6 MB de memória, sobre uma stack construída para mobile desde 2014. Os números estão acima, e os dados completos do benchmark estão disponíveis, caso a sua equipe queira se aprofundar.

Se você quer ver isso no seu próprio app, comece de graça ou solicite uma demonstração.