Performance Test no desenvolvimento móvel: o que é, métricas e como é realizado

O que é Performance Test?

Performance Test é um tipo de teste não funcional que determina a rapidez e eficiência com que uma aplicação realiza as suas tarefas. Ao contrário dos testes unitários ou testes de UI, o Performance Test mede características quantitativas: tempo de resposta, carga de CPU, consumo de RAM e uso de bateria. De acordo com o relatório da Sauce Labs (2025), 68% das equipas de desenvolvimento móvel incluem o Performance Test no seu ciclo de testes regular, e 41% automatizam-no em CI.

O principal objetivo do Performance Test é garantir que a aplicação cumpre os requisitos de desempenho especificados na documentação. Se o tempo de arranque do ecrã exceder 500 milissegundos ou a aplicação consumir mais de 200 MB de RAM num dispositivo médio, isto é um sinal para otimização. O baseline de desempenho é estabelecido na primeira versão estável e revisto com cada atualização importante.

O Performance Test é realizado em dispositivos reais, não em simuladores, uma vez que a emulação não fornece uma imagem precisa do uso de CPU, GPU e recursos de rede. De acordo com a Apple WWDC (2024), os testes em simulador mostram resultados inflacionados em comparação com um dispositivo real em 15–30%. Um dispositivo real continua a ser a única fonte fiável de dados de desempenho.

A frequência de execução do Performance Test depende do ciclo de desenvolvimento. De acordo com as recomendações do Google Android Performance (2024), as medições de base devem ser executadas em cada pull request, e um conjunto completo antes de cada lançamento. A automatização destas medições permite detetar regressões de desempenho em fases iniciais.

Métricas chave de desempenho

No desenvolvimento móvel, são identificadas cinco métricas principais que cobrem 90% dos cenários de Performance Test. O tempo de arranque (cold start e warm start) é a primeira métrica verificada em cada lançamento. A Google Play Console (2024) regista o tempo de arranque por limiar: o cold start não deve exceder 5 segundos, o warm start — 1,5 segundos. Exceder estes limiares afeta diretamente a classificação na loja de aplicações.

Tempo de arranque (Cold Start)

O cold start é medido desde o momento em que se toca no ícone até ao aparecimento do primeiro frame da aplicação. iOS utiliza `dispatch_async` para inicialização diferida, o que reduz o tempo de arranque visível. O cold start no Android inclui a criação do processo, a inicialização da Application e o arranque da Activity. De acordo com o Google Performance (2024), cada 100 ms de atraso no cold start reduz a taxa de conversão em 1,2% em aplicações de comércio eletrónico.

Taxa de frames (FPS)

FPS (Frames Per Second) é a taxa de frames durante animações e deslocamento de listas. Uma interface fluida requer 60 FPS estáveis. O Android Studio Profiler e o Xcode GPU Report mostram quedas de FPS durante operações pesadas — carregamento de imagens, parsing de JSON ou renderização de layouts complexos. Uma queda abaixo de 30 FPS é percebida pelo utilizador como lentidão e leva a uma diminuição da taxa de retenção de 22% de acordo com a Adjust (2025).

Consumo de RAM

O consumo de RAM é a terceira métrica crítica. As fugas de memória são a principal causa de degradação do desempenho em sessões longas. O Instruments Allocations e o Android Memory Profiler ajudam a detetar referências circulares em Swift e Activities não libertadas em Android. O consumo de bateria é uma métrica frequentemente negligenciada durante os testes. De acordo com a Apple Developer (2024), as aplicações com alto consumo de energia são restringidas em segundo plano no iOS. Energy Log no Xcode regista o perfil de wattage da aplicação por sessão.

Tipos de testes de desempenho

Teste de carga (Load Test) verifica o comportamento da aplicação sob o número esperado de utilizadores simultâneos. Para um backend móvel, isto significa simular 1000–10000 pedidos API simultâneos. O servidor deve suportar a carga máxima sem aumentar o tempo de resposta em mais de 20% do valor base. De acordo com os benchmarks k6 (2024), uma configuração típica de Load Test inclui uma rampa de 0 a 1000 VUs (utilizadores virtuais) em 5 minutos.

Teste de estresse (Stress Test) determina o ponto de falha da aplicação — o momento em que o sistema deixa de responder aos pedidos ou degrada-se de forma inaceitável. Ao contrário do Load Test, o Stress Test sobrecarrega o sistema além dos limites normais. O ponto de falha é registado com base num dos critérios: o tempo de resposta excede 10 segundos, a percentagem de erros 5XX excede 5%, ou o consumo de RAM atinge 90% da memória disponível.

Teste de volume (Volume Test) avalia o comportamento da aplicação ao trabalhar com grandes volumes de dados. No contexto móvel, isto envolve testar com milhares de registos numa base de dados local, dezenas de gigabytes de cache, ou milhões de notificações push. SQLite no Android e Core Data no iOS mostram desempenhos diferentes quando se ultrapassam os 100 000 registos.

Ferramentas para Performance Test

Xcode Instruments

Xcode Instruments é a ferramenta principal para perfilar aplicações iOS. O Time Profiler mostra quais os métodos que consomem mais CPU, enquanto o Allocations monitoriza a alocação e libertação de memória. O Instruments suporta gravação em sessões longas (até 30 minutos) e exportação de traces para comparação entre compilações. Activity Monitor dentro do Instruments mostra a carga geral do sistema em tempo real.

Android Studio Profiler

Android Studio Profiler é o profiler integrado para Android. Ele combina os profilers de CPU, Memória, Rede e Energia numa única interface. Uma característica do Android Profiler é o suporte para sessões interativas: os programadores podem executar ações na aplicação e ver a resposta instantânea das métricas. De acordo com o Google I/O (2024), Profiler suporta gravação no formato .perf, que pode ser comparado com um baseline em CI.

Charles Proxy

Charles Proxy e Proxyman são ferramentas para analisar tráfego de rede. Mostram o tempo de cada pedido HTTP, tamanho da resposta e cabeçalhos. Para Performance Test, é importante capturar os pedidos que demoram mais de 500 ms — estes são candidatos a cache ou otimização. Charles suporta o modo throttle que simula redes lentas: 3G, Edge e LTE. Proxyman é uma alternativa mais leve para macOS com arquitetura Swift nativa.

import XCTest

class PerformanceTests: XCTestCase {

    func testLaunchPerformance() {
        measure(metrics: [XCTClockMetric(),
                         XCTMemoryMetric()]) {
            XCUIApplication().launch()
        }
    }

    func testScrollPerformance() {
        let app = XCUIApplication()
        app.launch()
        let tableView = app.tables["list"]
        measure {
            tableView.swipeUp()
            tableView.swipeDown()
        }
    }
}

Performance Test no pipeline CI/CD

Integrar Performance Test em CI/CD é o padrão da indústria para 2025–2026. O pipeline de desempenho inclui três etapas: pre-commit (medições rápidas em pull request), nightly (conjunto completo de testes) e pre-release (comparação com baseline em dispositivos de referência). Bitrise e GitHub Actions suportam a execução de Xcode Instruments CLI e Gradle Profiler.

O GitHub Actions (2024) publicou um template oficial para Performance Test em iOS usando `xcodebuild test-without-building`. O template executa testes numa das máquinas do GitHub e publica o relatório como artifact. O baseline é armazenado num ficheiro JSON no repositório: se o limiar for excedido em 10%, o pipeline falha com um erro. Esta abordagem evita a degradação do desempenho sem revisão manual de cada compilação.

O problema do Performance Test móvel em CI é a instabilidade dos resultados em diferentes máquinas. Apple Silicon (M1–M4) e Intel Xeon dão tempos de execução diferentes. A solução é usar uma relação percentual ao baseline em vez de valores absolutos. Se um teste demorar 15% mais que o baseline, a compilação é marcada como necessitando de revisão.

Escrever Performance Tests em iOS e Android

XCTest Performance em iOS usa o método `measure(metrics:)`, que executa um bloco de código 10 vezes e devolve estatísticas: média, mediana, desvio padrão. Para testes de desempenho de base de dados, o XCTest usa convenientemente o XCTMemoryMetric, que captura o consumo máximo de RAM. O limiar é definido através de `XCTPerformanceReport` após a conclusão do teste.

Android Macrobenchmark é uma biblioteca da Google para medir o desempenho ao nível da aplicação. O Macrobenchmark executa cenários de utilizador (início de Activity, deslocamento de RecyclerView, abertura de WebView) e mede o tempo de execução. Baseline Profile é um conjunto de classes e métodos que o compilador Android pré-otimiza. O Google Play utiliza o Baseline Profile para acelerar o primeiro arranque em 30%.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {
    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun startup() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 5
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}

Ambas as abordagens — XCTest Performance e Android Macrobenchmark — usam o mesmo conceito: medição repetida com obtenção de média e comparação com um limiar. O desempenho não pode ser reduzido a um único número. Cada lançamento deve ser acompanhado por um relatório de desempenho contendo as tendências das métricas nas últimas 5 compilações. Esse relatório permite que a equipa veja a degradação antes de os utilizadores a notarem.