Hot Start em aplicativos móveis: o que é, fatores e como acelerar

O que é Hot Start em aplicativos móveis

Hot Start é um cenário de inicialização onde o processo do aplicativo já existe na RAM do dispositivo. O usuário minimiza o aplicativo, depois retorna — e o sistema não cria um novo processo, mas retoma o existente. Neste cenário, não é necessário carregamento do SO, inicialização da classe Application ou criação de processo, o que reduz drasticamente o tempo até a UI aparecer na tela. De acordo com a Documentação do Android (2025), o Hot Start leva apenas 200–500 ms, enquanto o Cold Start pode chegar a 5 segundos ou mais. A diferença de velocidade é especialmente perceptível em dispositivos com memória limitada, onde o sistema descarrega aplicativos em segundo plano com mais frequência.

A principal característica do Hot Start é o conjunto mínimo de métodos do ciclo de vida chamados. No Android, são Activity.onCreate e Activity.onStart; no iOS, é applicationDidBecomeActive. Ao contrário do Cold Start, onde Application.onCreate, ContentProvider.onCreate, Activity.onCreate e muitas inicializações de bibliotecas são chamados sequencialmente, o Hot Start pula todas essas etapas. O desenvolvedor deve entender qual código é executado especificamente durante uma inicialização a quente — muitas vezes, inicializações pesadas de SDK, análises e contêineres DI são repetidos tanto no Cold quanto no Hot Start, embora não sejam mais necessários durante uma inicialização a quente.

Cold Start, Warm Start e Hot Start: comparação

Os três cenários de inicialização do aplicativo diferem na profundidade da inicialização. Cold Start ocorre quando o aplicativo é iniciado pela primeira vez após a instalação, reinicialização do dispositivo ou remoção da memória. O sistema cria um novo processo Linux, carrega as classes Application, cria instâncias ContentProvider, realiza a inicialização de bibliotecas e só então renderiza a Activity. Todo o processo leva de 2 a 10 segundos, dependendo da complexidade do aplicativo e das características do dispositivo.

Warm Start é um cenário intermediário. O processo do aplicativo está vivo na memória, mas a Activity foi destruída e deve ser recriada. Isso acontece, por exemplo, na rotação da tela ou ao retornar de outro aplicativo onde a Activity foi removida por falta de memória, mas o processo permaneceu. Warm Start inclui chamar Activity.onCreate e Activity.onStart, mas não inclui Application.onCreate ou inicialização de ContentProvider. O tempo de Warm Start é de 500 ms a 2 segundos. Hot Start é o mais rápido dos três: a Activity já existe na pilha de retorno, o processo está vivo e o sistema simplesmente chama Activity.onRestart, onStart e onResume. O tempo de Hot Start é de 200–500 ms. A diferença do Warm Start é que a Activity não é criada novamente — ela é restaurada a partir da instância existente.

Ciclo de vida do Android durante Hot Start

No Android, Hot Start é acionado quando o usuário retorna ao aplicativo pela tela de Recentes ou tocando no ícone do aplicativo enquanto minimizado. O sistema verifica se o processo está vivo e, se sim, chama sequencialmente Activity.onRestart, onStart e onResume. O método onCreate não é chamado durante o Hot Start porque a instância da Activity já existe na memória. Esta é uma diferença importante do Warm Start, onde onCreate ainda é chamado devido à destruição da Activity. De acordo com o Google I/O 2019, o tempo típico de Hot Start no Android é de 200–400 ms, e qualquer lentidão neste estágio aumenta diretamente o tempo de inicialização percebido.

Os desenvolvedores muitas vezes ignoram que o código de inicialização da UI, assinaturas LiveData ou configuração do RecyclerView são realizados não apenas no onCreate, mas também no onStart ou onResume. Durante o Hot Start, esses blocos de código executam novamente, embora a UI já estivesse configurada. Recomenda-se separar a inicialização única (no onCreate com verificação de savedInstanceState) e a lógica retomável (onStart/onResume). Por exemplo, operações pesadas — configuração de adaptadores, carregamento de listas — devem ser movidas para um bloco que não execute durante onRestart, ou verificar savedInstanceState.

Exemplo de rastreamento do tipo de inicialização

O seguinte código em Kotlin demonstra uma maneira simples de detectar o cenário de inicialização e medir o tempo. A variável launchTimeStamp captura o momento do início da inicialização, e isColdStart permite separar a lógica para inicialização a frio e a quente.

class MainActivity : AppCompatActivity() {

    private var launchTimeStamp = 0L
    private var isColdStart = true

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            isColdStart = true
            launchTimeStamp = System.currentTimeMillis()
            // inicialização única
        } else {
            isColdStart = false
            // Hot Start — Activity é restaurada
        }
    }

    override fun onResume() {
        super.onResume()
        if (isColdStart) {
            val launchTime =
                System.currentTimeMillis() - launchTimeStamp
            Log.d("LaunchTime", "Cold Start: $launchTime ms")
        }
    }
}

Ciclo de vida do iOS durante inicialização a quente

No iOS, Hot Start corresponde ao retorno do aplicativo do segundo plano via sceneDidBecomeActive (UIKit) ou onAppear (SwiftUI). O sistema operacional não recria o processo se o aplicativo estava no estado Suspenso ou em Segundo Plano. Durante uma inicialização a quente, applicationDidBecomeActive é chamado no AppDelegate, mas applicationDidFinishLaunching não é chamado — isso é análogo ao Android onde Application.onCreate é pulado. O iOS descarrega aplicativos da memória de forma mais agressiva: se o dispositivo não tiver RAM suficiente, o sistema pode descarregar um aplicativo em segundo plano, e a próxima inicialização será um Cold Start. De acordo com a Documentação do Apple Developer, o tempo médio de Hot Start no iOS é de 300–600 ms.

Uma diferença chave no iOS é a falta de um análogo direto do Warm Start no sentido do Android. No iOS, quando um aplicativo é minimizado, sceneDidEnterBackground é chamado, e ao retornar, sceneWillEnterForeground e sceneDidBecomeActive são chamados. Se o sistema descarrega a cena mas mantém o processo vivo, a próxima inicialização será Cold da perspectiva da cena, mas Hot da perspectiva do processo. O desenvolvedor deve considerar isso ao colocar o código de inicialização: assinaturas no NotificationCenter, atualizações de UI e redefinições de estado devem estar em sceneDidBecomeActive, não apenas em viewDidLoad.

Exemplo de manipulação de Hot Start no iOS

Este código Swift mostra como rastrear o número de inicializações a quente e separar a lógica. O contador foregroundCount incrementa a cada retorno do segundo plano.

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var foregroundCount = 0

    func sceneDidBecomeActive(
        _ scene: UIScene
    ) {
        foregroundCount += 1

        if foregroundCount == 1 {
            // Cold Start — inicialização completa
            setupSDKs()
        } else {
            // Hot Start — apenas atualização de UI
            refreshUI()
        }
    }

    private func refreshUI() {
        // atualização de dados na tela
    }
}

Fatores que afetam a velocidade do Hot Start

Várias categorias de fatores afetam a velocidade do Hot Start. A primeira é a quantidade de trabalho nos métodos do ciclo de vida onStart e onResume. Se o desenvolvedor colocou carregamento de dados de rede, análise JSON, inicialização de adaptadores ou cálculos pesados nesses métodos, cada bloco adiciona dezenas ou centenas de milissegundos ao tempo de inicialização. De acordo com Android Vitals, aplicativos com duração de Hot Start superior a 800 ms perdem até 20% dos usuários ao retornar.

A segunda categoria são fragmentos e Views restaurados de savedInstanceState. Se os fragmentos contêm ViewPager2 pesado, WebView ou hierarquias complexas profundamente aninhadas, sua restauração consome recursos de CPU. De acordo com o Google I/O 2023, cada ViewGroup aninhado adiciona em média 2–5 ms ao tempo de renderização durante o Hot Start. A terceira categoria são SDKs de terceiros: bibliotecas de análise, relatórios de falhas, testes A/B e carregadores DEX podem realizar inicialização a cada retorno do segundo plano. Recomenda-se verificar quais SDKs executam código especificamente em onStart/onResume e adiar tarefas não críticas para uma thread em segundo plano.

Métodos de otimização da inicialização a quente

A otimização do Hot Start se resume a minimizar o trabalho nos métodos do ciclo de vida de retomada. O primeiro método é a inicialização preguiçosa: qualquer código não necessário para o primeiro quadro da UI deve ser executado após onResume com um atraso via Handler.postDelayed ou Coroutine.launch(Dispatchers.IO). O segundo método é o cache de estado da View: quando o aplicativo é minimizado, salve os dados em um cache em memória para que durante o Hot Start você não precise recarregá-los do banco de dados ou rede. O terceiro método é usar SavedStateHandle no Android e StateRestorationPolicy no iOS para minimizar a quantidade de dados restaurados.

Carregamento preguiçoso após Hot Start

Neste exemplo, Handler.postDelayed adia a inicialização da análise por 500 ms após a renderização do primeiro quadro. Isso não afeta o tempo de inicialização percebido porque o usuário já vê a interface.

class AnalyticsDeferrer {

    fun lazyInitAfterHotStart() {
        val handler = Handler(Looper.getMainLooper())
        handler.postDelayed({
            // inicialização após o primeiro quadro
            Analytics.init(Application.getInstance())
            CrashReporter.start()
        }, 500)
    }
}

Usando a biblioteca App Startup

AndroidX App Startup permite controlar a ordem de inicialização dos componentes na inicialização. Todos os ContentProviders são inicializados automaticamente durante o Cold Start, mas você pode desativar a inicialização automática para componentes não necessários durante o Hot Start.

@Initializer(Application::class)
class SdkInitializer : Initializer<Unit> {

    override fun create(context: Context) {
        SdkOne.init(context)
        SdkTwo.init(context)
    }

    override fun dependencies() = emptyList<Class<*>>()
}

Ferramentas de monitoramento do tempo de inicialização

Para medir o tempo de Hot Start, existem ferramentas integradas das plataformas e soluções de terceiros. No Android, a ferramenta chave é Android Vitals no Google Play Console — coleta automaticamente métricas de tempo de inicialização para todos os cenários (Cold, Warm, Hot) divididas por modelo de dispositivo e versão do SO. Adicionalmente, você pode usar Macrobenchmark do AndroidX — uma biblioteca para testes automatizados de desempenho de inicialização. No iOS, o equivalente é MetricKit, que coleta dados sobre tempo de inicialização, taxa de quadros e uso de memória.

Para criação de perfil detalhada de inicialização a quente, Firebase Performance Monitoring (rastreia traces personalizados) e New Relic com painéis de tempo de inicialização são adequados. No lado do desenvolvedor para medição manual, reportFullyDrawn no Android é usado — uma API que informa ao sistema o momento exato em que a UI é renderizada e pronta para interação. No iOS, o equivalente é endActivity no MetricKit. Combinando essas ferramentas, você pode identificar qual SDK ou bloco de código retarda o Hot Start em dispositivos específicos.

Exemplo de Macrobenchmark para Hot Start

Código Kotlin usando a biblioteca Macrobenchmark para medir Cold e Hot Start. O teste inicia a Activity e mede o tempo até o estado completo.

@RunWith(AndroidJUnit4::class)
class StartupBenchmark {

    @get:Rule
    val benchmarkRule = MacrobenchmarkRule()

    @Test
    fun hotStart() {
        benchmarkRule.measureRepeated(
            packageName = "com.example.app",
            metrics = listOf(StartupTimingMetric()),
            iterations = 10,
            startupMode = StartupMode.HOT
        ) {
            pressHome()
            startActivityAndWait()
        }
    }
}