Perfilando código Kotlin: encontrando gargalos na prática

Perfilando código Kotlin: encontrando gargalos na prática

O desempenho da aplicação é um dos principais fatores de sucesso. Mesmo o código Kotlin mais bonito e conciso pode ser lento se houver gargalos. Neste artigo, vamos explorar métodos práticos de perfilamento de código Kotlin, aprender a encontrar trechos problemáticos e corrigi-los com ferramentas reais.

Por que perfilar código Kotlin?

O perfilamento ajuda a responder três perguntas principais:

\n
• O que está travando? — quais funções ou blocos de código consomem mais tempo de CPU.
\n
• Onde está o vazamento? — quais objetos não são liberados e sobrecarregam a memória.
\n
• Como corrigir? — quais mudanças trarão o maior ganho de desempenho.
\n

Sem perfilamento, os desenvolvedores frequentemente otimizam "no olho", perdendo tempo em trechos insignificantes e ignorando os problemas reais. Vamos analisar as principais ferramentas e abordagens.

Ferramentas para perfilamento Kotlin

Dependendo da plataforma (JVM, Android, Native) e dos objetivos, diferentes ferramentas são usadas. Vamos considerar três principais:

1. JProfiler (JVM)

Poderoso profiler comercial para aplicações Java/Kotlin na JVM. Permite analisar CPU, memória, threads e consultas SQL. Adequado para projetos server-side com Spring Boot, Ktor e outros frameworks.

2. Android Studio Profiler (Android)

Ferramenta integrada para aplicações Android. Permite monitorar em tempo real CPU, memória, rede e consumo de energia. Ideal para projetos móveis Kotlin.

3. Kotlinx-benchmark (microbenchmarking)

Biblioteca da JetBrains para medição precisa do desempenho de funções individuais. Permite escrever benchmarks diretamente no código e obter resultados estatisticamente confiáveis.

Exemplo prático: encontrando um gargalo com JProfiler

Imagine que temos uma aplicação server-side em Kotlin que processa pedidos. Os usuários reclamam da lentidão do método processOrders(). Iniciamos o JProfiler e obtemos uma amostragem de CPU.

Exemplo de código problemático:

data class Order(val id: Int, val items: List<String>, val price: Double)\n\nfun processOrders(orders: List<Order>): List<String> {\n    return orders\n        .filter { it.price > 100.0 }\n        .map { it.items }\n        .flatten()\n        .distinct()\n        .sorted()\n}\n

O JProfiler mostra que 70% do tempo é gasto em flatten() e distinct() em listas grandes. Esse é o gargalo. Otimização:

fun processOrdersOptimized(orders: List<Order>): List<String> {\n    val result = mutableSetOf<String>()\n    for (order in orders) {\n        if (order.price > 100.0) {\n            result.addAll(order.items)\n        }\n    }\n    return result.sorted()\n}\n

Usar mutableSetOf em vez de flatten().distinct() reduziu o tempo de execução em 3 vezes. Sem o perfilamento, não saberíamos que a cadeia de coleções estava causando a sobrecarga.

Perfilamento de memória: encontrando vazamentos

Vazamentos de memória são um problema comum em Kotlin, especialmente ao usar corrotinas e closures. Vamos considerar um exemplo com o Android Studio Profiler.

Código problemático (Activity com corrotina):

class MainActivity : AppCompatActivity() {\n    override fun onCreate(savedInstanceState: Bundle?) {\n        super.onCreate(savedInstanceState)\n        // Inicia uma corrotina que mantém uma referência à Activity\n        CoroutineScope(Dispatchers.IO).launch {\n            while (true) {\n                delay(1000)\n                // Usa this@MainActivity (vazamento!)\n                runOnUiThread {\n                    findViewById<TextView>(R.id.textView).text = "Working..."\n                }