Renderização lenta

Renderização da IU é o ato de gerar um frame do seu app e exibi-lo na tela. Para garantir que a interação do usuário com o app seja suave, ele precisa renderizar frames em menos de 16 ms para atingir 60 quadros por segundo (confira o vídeo por que 60 fps?). Se o app realizar uma renderização lenta da IU, o sistema será forçado a ignorar frames e o usuário perceberá oscilações no app. Chamamos isso de instabilidade.

Para ajudar você a melhorar a qualidade do app, o Android faz um monitoramento automático em busca de instabilidades e exibe as informações no painel do Android vitals. Para informações sobre como os dados são coletados, consulte os documentos do Play Console.

Caso seu app esteja enfrentando instabilidade, esta página fornece orientações sobre como diagnosticar e corrigir o problema.

Observação: o painel do Android vitals e o sistema Android acompanham estatísticas de tempo de renderização para apps que usam o UI Toolkit (a parte visível do app para o usuário é desenhada na hierarquia Canvas ou View). Se o app não usar o UI Toolkit, como é o caso de apps criados com Vulkan, Unity, Unreal ou OpenGL, as estatísticas de tempo de renderização não ficarão disponíveis no painel do Android vitals. Para determinar se o dispositivo está registrando as métricas de tempo de renderização do seu app, execute adb shell dumpsys gfxinfo <package name>.

Identificar instabilidade

Identificar qual parte do código do app está causando instabilidade pode ser difícil. Esta seção descreve três métodos para identificar a instabilidade:

• Inspeção visual
• Systrace
• Monitoramento de desempenho personalizado

A inspeção visual permite que você execute rapidamente todos os casos de uso no app em alguns minutos, mas não fornece tantos detalhes quanto o Systrace. O Systrace fornece mais detalhes, mas se você o executasse para todos os casos de uso no app, receberia um número tão grande de dados que seria difícil analisá-los. Tanto a inspeção visual quanto o Systrace detectam instabilidade no dispositivo local. Se a instabilidade não puder ser reproduzida em dispositivos locais, é possível criar um monitoramento de desempenho personalizado para avaliar partes específicas do app em dispositivos executados em campo.

Com inspeção visual

A inspeção visual ajuda a identificar os casos de uso que estão produzindo instabilidade. Para realizar uma inspeção visual, abra o app, percorra manualmente as diferentes partes dele e procure instabilidade na IU. Veja algumas dicas ao realizar inspeções visuais:

• Execute uma versão de lançamento do app ou pelo menos uma versão não depurável. O tempo de execução de ART desativa várias otimizações importantes para que haja suporte a recursos de depuração. Por isso, verifique se você está analisando algo semelhante ao que o usuário verá.
• Ative a Criação do perfil de renderização de GPU. A Criação do perfil de renderização de GPU exibe barras na tela que fornecem uma representação visual rápida do tempo necessário para renderizar os frames de uma janela da IU em relação ao comparativo de 16 ms por frame. Cada barra tem componentes coloridos que mapeiam uma etapa do pipeline de renderização para que você possa ver qual parte está demorando mais tempo. Por exemplo, se o frame gasta muito tempo com a entrada, analise o código do app referente à entrada do usuário.
• Há certos componentes, como o RecyclerView, que são uma fonte comum de instabilidade. Caso seu app use esses componentes, é recomendável percorrer essas partes dele.
• Às vezes, a instabilidade pode ser reproduzida somente com uma inicialização a frio do app.
• Tente executar o app em um dispositivo mais lento para que o problema fique mais fácil de identificar.

Depois de encontrar casos de uso que produzem instabilidade, você poderá ter uma boa ideia do que está causando esse problema no app. Mas, se precisar de mais informações, use o Systrace para ter mais detalhes.

Com o Systrace

Embora o Systrace seja uma ferramenta que mostra o que todo o dispositivo está fazendo, ele pode ser útil para identificar instabilidade no seu app. O Systrace tem uma sobrecarga mínima do sistema, por isso haverá uma instabilidade realista durante a instrumentação.

Registre um trace com o Systrace enquanto executa o caso de uso de instabilidade no dispositivo. Veja no Tutorial do Systrace instruções de como usá-lo. O Systrace é dividido em processos e linhas de execução. Procure o processo do seu app no Systrace, que será parecido com a figura 1.

Figura 1: Systrace

O Systrace da figura 1 contém as seguintes informações para identificar instabilidade:

1. O Systrace mostra quando cada frame é desenhado e codifica cada frame por cor para destacar os tempos de renderização lenta. Isso ajuda a encontrar frames individuais instáveis com mais precisão do que a fornecida pela inspeção visual. Para ver mais informações, consulte inspecionar frames e alertas da IU.
2. O Systrace detecta problemas no app e exibe alertas em frames individuais e no painel de alertas. Seguir as instruções do alerta é a melhor opção.
3. Partes do framework e das bibliotecas do Android, como RecyclerView, contêm marcadores de rastreamento. Portanto, a linha do tempo do Systrace mostra quando esses métodos são executados na linha de execução de IU e em quanto tempo.

Depois de analisar a saída do Systrace, poderá haver métodos no app que você suspeita que estão causando instabilidade. Por exemplo, se a linha do tempo mostrar que um frame lento é causado pela demora do RecyclerView, você poderá adicionar marcadores de rastros ao código relevante e executar novamente o Systrace para receber mais informações. No novo Systrace, a linha do tempo exibe quando os métodos do app foram chamados e quanto tempo levaram para ser executados.

Se o Systrace não mostrar detalhes do motivo pelo qual o trabalho da linha de execução de IU está demorando, será necessário usar o Android CPU Profiler para gravar um rastreamento de método amostrado ou instrumentado. Geralmente, os rastreamentos de método não são bons para identificar instabilidade, porque geram falsos positivos devido a sobrecarga pesada e não podem perceber quando linhas de execução estão sendo executadas ou estão bloqueadas. No entanto, os rastreamentos de método podem ajudar a identificar os métodos do seu app que estão demorando mais. Depois de identificar esses métodos, adicione marcadores de rastro e execute novamente o Systrace para ver se esses métodos estão causando instabilidade.

Observação: ao gravar um Systrace, cada marcador de rastros (um par de início e fim que é executado) adiciona aproximadamente 10 µs de sobrecarga. Para evitar instabilidades falso-positivas, não adicione marcadores de rastros a métodos que são chamados dezenas de vezes em um frame ou que são mais curtos do que aproximadamente 200 us.

Para mais informações, consulte Noções básicas sobre o Systrace.

Com o monitoramento de desempenho personalizado

Se não for possível reproduzir instabilidade em um dispositivo local, você poderá criar um monitoramento de desempenho personalizado no seu app para ajudar a identificar a origem da instabilidade nos dispositivos em campo.

Para fazer isso, colete os tempos de renderização do frame de partes específicas do app com o FrameMetricsAggregator e grave e analise os dados usando o Monitoramento de desempenho do Firebase.

Para saber mais, consulte Usar o Monitoramento de desempenho do Firebase com o Android vitals.

Corrigir a instabilidade

Para corrigir a instabilidade, inspecione quais frames não estão concluindo em 16,7 ms e verifique o que deu errado. O recurso Record View#draw está demorando demais em alguns frames, ou talvez o Layout? Consulte esses e outros problemas na seção Fontes comuns de instabilidade abaixo.

Para evitar a instabilidade, as tarefas de longa execução precisam ser executadas de forma assíncrona fora da linha de execução de IU. Esteja sempre ciente de qual linha de execução seu código está executando e tenha cuidado ao postar tarefas não triviais na linha de execução principal.

Se você tem uma IU principal complexa e importante para o app (como a lista de rolagem central), grave testes de instrumentação que possam detectar automaticamente tempos de renderização lenta e execute esses testes com frequência para evitar regressões. Para ver mais informações, consulte o Codelab de testes de desempenho automatizado.

Fontes comuns de instabilidade

As seções a seguir explicam as fontes comuns de instabilidade em apps e as práticas recomendadas para resolvê-las.

Listas roláveis

Os componentes ListView e, especialmente, RecyclerView são usados frequentemente para listas de rolagem complexas, mais suscetíveis à instabilidade. Ambos contêm marcadores do Systrace, então você pode usar a ferramenta para descobrir se eles estão contribuindo para a instabilidade no app. Certifique-se de passar o argumento de linha de comando -a <your-package-name> para que as seções de rastreamento do RecyclerView sejam exibidas, assim como todos os marcadores de rastros adicionados. Se disponível, siga a orientação dos alertas gerados na saída do Systrace. Dentro do Systrace, você pode clicar nas seções rastreadas pelo RecyclerView para ver uma explicação do trabalho que ele está fazendo.

RecyclerView: notifyDataSetChanged

Caso você perceba todos os itens do RecyclerView sendo recuperados em um frame (e, portanto, sendo organizados e desenhados novamente), certifique-se de não chamar notifyDataSetChanged(), setAdapter(Adapter) ou swapAdapter(Adapter, boolean) para pequenas atualizações. Esses métodos indicam que todo o conteúdo da lista mudou e aparecerá no Systrace como RV FullInvalidate. Em vez disso, use SortedList ou DiffUtil para gerar atualizações mínimas quando um conteúdo for mudado ou adicionado.

Por exemplo, considere um app que recebe uma nova versão de uma lista de notícias do servidor. Quando você posta essa informação no Adapter, é possível chamar notifyDataSetChanged() como mostrado abaixo:

Kotlin

fun onNewDataArrived(news: List<News>) {
    myAdapter.news = news
    myAdapter.notifyDataSetChanged()
}

Java

void onNewDataArrived(List<News> news) {
    myAdapter.setNews(news);
    myAdapter.notifyDataSetChanged();
}

Mas isso tem uma grande desvantagem: se for uma mudança trivial (talvez um único item adicionado ao topo), o RecyclerView não tomará conhecimento. Isso porque a instrução é descartar todo o estado dos itens em cache e, portanto, recuperar tudo.

É muito melhor usar o DiffUtil, que calculará e enviará atualizações mínimas para você.

Kotlin

fun onNewDataArrived(news: List<News>) {
    val oldNews = myAdapter.items
    val result = DiffUtil.calculateDiff(MyCallback(oldNews, news))
    myAdapter.news = news
    result.dispatchUpdatesTo(myAdapter)
}

Java

void onNewDataArrived(List<News> news) {
    List<News> oldNews = myAdapter.getItems();
    DiffResult result = DiffUtil.calculateDiff(new MyCallback(oldNews, news));
    myAdapter.setNews(news);
    result.dispatchUpdatesTo(myAdapter);
}

Basta definir MyCallback como uma implementação de DiffUtil.Callback para informar a DiffUtil como inspecionar suas listas.

RecyclerView: RecyclerViews aninhados

É comum aninhar RecyclerViews, especialmente com uma lista vertical contendo listas de rolagem horizontal, como grades de apps na página principal da Play Store. Isso pode funcionar muito bem, mas também há muitas visualizações em movimento. Caso haja uma grande quantidade de itens internos inflados ao rolar a página para baixo pela primeira vez, verifique se você está compartilhando os RecyclerView.RecycledViewPools entre RecyclerViews internos (horizontais). Por padrão, cada RecyclerView tem seu próprio pool de itens. No entanto, com uma dúzia de itemViews na tela ao mesmo tempo, é problemático quando os itemViews não podem ser compartilhados pelas listas horizontais, se todas as linhas estiverem exibindo tipos semelhantes de visualizações.

Kotlin

class OuterAdapter : RecyclerView.Adapter<OuterAdapter.ViewHolder>() {

    ...

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ViewHolder {
        // inflate inner item, find innerRecyclerView by ID…
        val innerLLM = LinearLayoutManager(parent.context, LinearLayoutManager.HORIZONTAL, false)
        innerRv.apply {
            layoutManager = innerLLM
            recycledViewPool = sharedPool
        }
        return OuterAdapter.ViewHolder(innerRv)
    }
    ...

Java

class OuterAdapter extends RecyclerView.Adapter<OuterAdapter.ViewHolder> {
    RecyclerView.RecycledViewPool sharedPool = new RecyclerView.RecycledViewPool();

    ...

    @Override
    public void onCreateViewHolder(ViewGroup parent, int viewType) {
        // inflate inner item, find innerRecyclerView by ID…
        LinearLayoutManager innerLLM = new LinearLayoutManager(parent.getContext(),
                LinearLayoutManager.HORIZONTAL);
        innerRv.setLayoutManager(innerLLM);
        innerRv.setRecycledViewPool(sharedPool);
        return new OuterAdapter.ViewHolder(innerRv);

    }
    ...

Se você quiser otimizar ainda mais, também pode chamar setInitialPrefetchItemCount(int) no LinearLayoutManager interno do RecyclerView. Se, por exemplo, sempre houver 3,5 itens visíveis em uma linha, chame innerLLM.setInitialItemPrefetchCount(4);. Isso sinalizará ao RecyclerView que, quando uma linha horizontal estiver prestes a aparecer na tela, ele precisará tentar pré-buscar os itens dentro dela, se houver tempo livre na linha de execução de IU.

RecyclerView: excesso de inflação/criação demorando muito

O recurso de pré-busca do RecyclerView deve ajudar a solucionar o custo da inflação, na maioria dos casos, fazendo o trabalho com antecedência, enquanto a linha de execução de IU está ociosa. Caso você observe inflação durante um frame (e não em uma seção chamada RV Prefetch), certifique-se de que está fazendo o teste em um dispositivo recente e usando uma versão recente da Biblioteca de Suporte. A pré-busca atualmente só é compatível com o Android 5.0, API de nível 21 e mais recentes.

Se você observa frequentemente que a inflação está causando instabilidade quando novos itens aparecem na tela, verifique se não há mais tipos de visualização do que o necessário. Quanto menos tipos de visualizações houver em um conteúdo do RecyclerView, menos inflação precisará ser feita quando novos tipos de itens aparecerem na tela. Se possível, mescle tipos de visualização quando for razoável. Se apenas um ícone, cor ou texto for diferente entre os tipos, você poderá fazer essa alteração no tempo de vinculação e evitar inflação, reduzindo o consumo de memória do app ao mesmo tempo.

Caso não haja problemas com os tipos de visualização, tente reduzir o custo da sua inflação. Reduzir visualizações de contêiner e estruturais desnecessárias pode ajudar. Crie itemViews com ConstraintLayout, o que pode facilitar a redução de visualizações estruturais. Se você quer realmente otimizar o desempenho, se as suas hierarquias de itens são simples e você não precisa de recursos complexos de temas e estilo, chame os construtores. No entanto, muitas vezes não vale a pena fazer isso, porque você perderá a simplicidade e os recursos de XML.

RecyclerView: vinculação muito demorada

É preciso que a vinculação (ou seja, onBindViewHolder(VH, int)) seja muito simples e leve muito menos de um milissegundo para todos os itens, exceto os mais complexos. Ela precisa simplesmente pegar os itens POJO dos dados de itens internos do adaptador e chamar setters em visualizações do ViewHolder. Se o RV OnBindView está demorando muito, verifique se você está fazendo um trabalho mínimo no seu código de vinculação.

Caso você esteja usando objetos POJO simples para reter dados no adaptador, evite completamente gravar o código de vinculação em onBindViewHolder usando a biblioteca Data Binding.

RecyclerView ou ListView: layout/desenho demorando muito

Para problemas com desenho e layout, consulte as seções sobre Layout e Desempenho da renderização.

ListView: inflação

É fácil desativar acidentalmente a reciclagem no ListView se não tomar cuidado. Caso você observe inflação toda vez que um item aparece na tela, verifique se a implementação de Adapter.getView() está usando, vinculando novamente e retornando o parâmetro convertView. Se a implementação do getView() sempre inflar, o app não terá os benefícios da reciclagem no ListView. A estrutura da getView() precisa ser quase sempre semelhante à implementação abaixo:

Kotlin

fun getView(position: Int, convertView: View?, parent: ViewGroup): View {
    return (convertView ?: layoutInflater.inflate(R.layout.my_layout, parent, false)).apply {
        // … bind content from position to convertView …
    }
}

Java

View getView(int position, View convertView, ViewGroup parent) {

    if (convertView == null) {
        // only inflate if no convertView passed
        convertView = layoutInflater.inflate(R.layout.my_layout, parent, false)
    }
    // … bind content from position to convertView …
    return convertView;
}

Desempenho do layout

Se o Systrace mostra que o segmento Layout do Choreographer#doFrame está trabalhando muito ou com muita frequência, isso significa que você está enfrentando problemas de desempenho do layout. O desempenho do layout do app depende de qual parte da hierarquia de visualização tem parâmetros ou entradas de layout que mudam.

Desempenho do layout: custo

Se os segmentos forem mais longos que alguns milésimos de segundo, é possível que você esteja tendo o pior desempenho de aninhamento para RelativeLayouts ou LinearLayouts ponderados. Cada um desses layouts pode acionar várias passagens de medida/layout dos filhos, portanto, aninhá-los pode levar ao comportamento O(n^2) na profundidade do aninhamento. Tente evitar RelativeLayout ou o recurso de ponderação de LinearLayout em todos os nós folha da hierarquia, exceto nos menores. Há algumas maneiras de fazer isso:

• Você pode reorganizar as visualizações estruturais.
• Você pode definir uma lógica de layout personalizada. Acesse Otimizar hierarquias de layout para consultar um exemplo específico. Você pode tentar converter para o ConstraintLayout, que fornece recursos parecidos e sem as desvantagens para o desempenho.

Desempenho do layout: frequência

Espera-se que o layout aconteça quando conteúdo novo aparece na tela, por exemplo, quando um novo item rola para a visualização no RecyclerView. Se um layout significativo está acontecendo em cada frame, é possível que você esteja animando o layout, o que provavelmente causa frames perdidos. Geralmente, as animações precisam ser executadas nas propriedades de desenho de View (por exemplo, setTranslationX/Y/Z(), setRotation(), setAlpha() etc.). Todas elas podem ser alteradas de maneira muito mais econômica do que as propriedades de layout, como padding ou margens. Também é muito mais barato mudar as propriedades de desenho de uma visualização, geralmente chamando um setter, que aciona um invalidate(), seguido por um draw(Canvas) no frame seguinte. Isso regravará as operações de desenho para a visualização que é invalidada e também é geralmente muito mais econômico que o layout.

Desempenho de renderização

A IU do Android funciona em duas fases: Record View#draw, na linha de execução de IU, e DrawFrame, no RenderThread. A primeira é executada no draw(Canvas) em cada View invalidada e pode invocar chamadas para visualizações personalizadas ou para seu código. A segunda é executada no RenderThread nativo, mas funciona com base no trabalho gerado pela fase de Record View#draw.

Desempenho da renderização: linha de execução de IU

Se a fase Record View#draw estiver demorando muito, normalmente é porque um bitmap está sendo pintado na linha de execução de IU. A pintura em um bitmap usa a renderização da CPU, então você precisa evitar isso quando possível. Você pode usar o rastreamento de método com o Android CPU Profiler para conferir se esse é o problema.

A pintura em um bitmap geralmente é feita quando um app quer decorar um bitmap antes de exibi-lo. Às vezes, é feita uma decoração como a adição de cantos arredondados:

Kotlin

val paint = Paint().apply {
    isAntiAlias = true
}
Canvas(roundedOutputBitmap).apply {
    // draw a round rect to define shape:
    drawRoundRect(
            0f,
            0f,
            roundedOutputBitmap.width.toFloat(),
            roundedOutputBitmap.height.toFloat(),
            20f,
            20f,
            paint
    )
    paint.xfermode = PorterDuffXfermode(PorterDuff.Mode.MULTIPLY)
    // multiply content on top, to make it rounded
    drawBitmap(sourceBitmap, 0f, 0f, paint)
    setBitmap(null)
    // now roundedOutputBitmap has sourceBitmap inside, but as a circle
}

Java

Canvas bitmapCanvas = new Canvas(roundedOutputBitmap);
Paint paint = new Paint();
paint.setAntiAlias(true);
// draw a round rect to define shape:
bitmapCanvas.drawRoundRect(0, 0,
        roundedOutputBitmap.getWidth(), roundedOutputBitmap.getHeight(), 20, 20, paint);
paint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.MULTIPLY));
// multiply content on top, to make it rounded
bitmapCanvas.drawBitmap(sourceBitmap, 0, 0, paint);
bitmapCanvas.setBitmap(null);
// now roundedOutputBitmap has sourceBitmap inside, but as a circle

Se esse for o tipo de trabalho que você faz na linha de execução de IU, poderá fazê-lo na linha de execução de decodificação em segundo plano. Em alguns casos como esse, você poderá até mesmo fazer o trabalho no momento do desenho. Então, se seu código de Drawable ou View for parecido com este:

Kotlin

fun setBitmap(bitmap: Bitmap) {
    mBitmap = bitmap
    invalidate()
}

override fun onDraw(canvas: Canvas) {
    canvas.drawBitmap(mBitmap, null, paint)
}

Java

void setBitmap(Bitmap bitmap) {
    mBitmap = bitmap;
    invalidate();
}

void onDraw(Canvas canvas) {
    canvas.drawBitmap(mBitmap, null, paint);
}

Você poderá substituí-lo por este:

Kotlin

fun setBitmap(bitmap: Bitmap) {
    shaderPaint.shader = BitmapShader(bitmap, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP)
    invalidate()
}

override fun onDraw(canvas: Canvas) {
    canvas.drawRoundRect(0f, 0f, width, height, 20f, 20f, shaderPaint)
}

Java

void setBitmap(Bitmap bitmap) {
    shaderPaint.setShader(
            new BitmapShader(bitmap, TileMode.CLAMP, TileMode.CLAMP));
    invalidate();
}

void onDraw(Canvas canvas) {
    canvas.drawRoundRect(0, 0, width, height, 20, 20, shaderPaint);
}

Observe que isso também pode ser feito para proteção em segundo plano (desenhando um gradiente na parte superior do bitmap) e filtragem de imagem (com ColorMatrixColorFilter), duas outras operações comuns feitas para modificar bitmaps.

Caso esteja desenhando em um bitmap por outro motivo, possivelmente usando-o como cache, desenhe diretamente para o Canvas com aceleração de hardware passado para a View ou Drawable. Se necessário, chame também setLayerType() com LAYER_TYPE_HARDWARE para armazenar em cache a renderização complexa e aproveitar a renderização da GPU.

Desempenho de renderização: RenderThread

Algumas operações de Canvas são baratas para gravar, mas acionam cálculos dispendiosos no RenderThread. O Systrace geralmente as destaca com alertas.

Canvas.saveLayer()

Evite Canvas.saveLayer(): ele pode acionar renderizações caras, sem cache e fora da tela de cada frame. Embora o desempenho tenha sido aprimorado no Android 6.0, com otimizações para evitar a renderização de chave de destino na GPU, ainda é recomendável evitar essa API cara, se possível, ou no mínimo passar o Canvas.CLIP_TO_LAYER_SAVE_FLAG ou chamar uma variante que não aceite sinalizações.

Animar caminhos grandes

Quando Canvas.drawPath() é chamado no Canvas com aceleração de hardware passado para Views, o Android desenha esses caminhos primeiro na CPU e os envia para a GPU. Se você tem caminhos grandes, evite editá-los frame a frame para que eles possam ser armazenados em cache e desenhados de forma eficiente. drawPoints(), drawLines() e drawRect/Circle/Oval/RoundRect() são mais eficientes. Então, é melhor usá-los, mesmo que, para isso, você use mais chamadas de desenho.

Canvas.clipPath

clipPath(Path) aciona um comportamento de recorte caro e geralmente precisa ser evitado. Quando possível, opte por desenhar formas, em vez de recortar e gerar não retângulos. Isso funciona melhor e é compatível com antialias. Por exemplo, a seguinte chamada de clipPath:

Kotlin

canvas.apply {
    save()
    clipPath(circlePath)
    drawBitmap(bitmap, 0f, 0f, paint)
    restore()
}

Java

canvas.save();
canvas.clipPath(circlePath);
canvas.drawBitmap(bitmap, 0f, 0f, paint);
canvas.restore();

Pode ser expressa como:

Kotlin

paint.shader = BitmapShader(bitmap, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP)
// at draw time:
canvas.drawPath(circlePath, mPaint)

Java

// one time init:
paint.setShader(new BitmapShader(bitmap, TileMode.CLAMP, TileMode.CLAMP));
// at draw time:
canvas.drawPath(circlePath, mPaint);

Uploads de bitmap

O Android exibe bitmaps como texturas OpenGL, e, na primeira vez que um bitmap é exibido em um frame, ele é enviado para a GPU. Você pode ver isso no Systrace como Texture upload(id) width x height. Isso pode levar vários milissegundos (veja a Figura 2), mas é necessário para exibir a imagem com a GPU.

Se levar muito tempo, primeiro verifique os números de largura e altura no rastreamento. Certifique-se de que o bitmap exibido não seja significativamente maior do que a área em que ele é mostrado na tela. Se for, haverá desperdício de tempo de upload e memória. Geralmente, as bibliotecas de carregamento de bitmap fornecem meios fáceis de solicitar um bitmap de tamanho adequado.

No Android 7.0, o código de carregamento de bitmap (geralmente feito por bibliotecas) pode chamar prepareToDraw() para acionar um upload antecipado, antes que seja necessário. Dessa forma, o upload acontece cedo, enquanto o RenderThread está ocioso. Isso pode ser feito após a decodificação ou ao vincular um bitmap a um View, contanto que você conheça o bitmap. Idealmente, sua biblioteca de carregamento de bitmaps fará isso, mas se você estiver gerenciando sua própria biblioteca ou quiser garantir que não atinja uploads em dispositivos mais recentes, chame prepareToDraw() no seu código.

Figura 2: um app gasta muito tempo em um frame fazendo upload de um bitmap grande. Reduza o tamanho dele ou acione-o com antecedência quando decodificado com prepareToDraw().

Atrasos na programação de linhas de execução

O programador de linhas de execução é a parte do sistema operacional Android responsável por decidir quais linhas de execução do sistema devem ser executadas, quando e por quanto tempo. Às vezes, ocorre instabilidade porque a linha de execução de IU do app está bloqueada ou não está em execução. O Systrace usa cores diferentes (confira a figura 3) para indicar quando uma linha de execução está em Em suspensão (cinza), Executável (azul: pode ser executada, mas o programador ainda não a executou), Em execução (verde) ou Em suspensão ininterrupta (vermelho ou laranja). Isso é extremamente útil para depurar problemas de instabilidade causados por atrasos de programação de linha de execução.

Observação: em versões mais antigas do Android, ocorrem com mais frequência problemas de programação que não foram causados pelo app. Melhorias contínuas são feitas nessa área. Por isso, considere a depuração de problemas de programação de linhas de execução nas versões mais recentes do sistema operacional, em que é mais provável que linhas de execução desprogramadas sejam causadas por falha no app.

Figura 3: destaca um período em que a linha de execução de IU está em suspensão.

Observação: há partes de um frame onde não se espera que a linha de execução de IU ou o RenderThread sejam executados. Por exemplo, a linha de execução de IU é bloqueada enquanto o syncFrameState do RenderThread está em execução e os bitmaps são enviados. Isso permite que o RenderThread copie com segurança os dados usados pela linha de execução de IU. Outro exemplo: o RenderThread pode ser bloqueado quando usar comunicação entre processos (IPC, na sigla em inglês) para adquirir um buffer no início de um frame, consultar informações dele ou passar o buffer de volta para o compositor com eglSwapBuffers.

Muitas vezes, pausas longas na execução do app são causadas por chamadas do binder, o mecanismo de comunicação entre processos (IPC) do Android. Em versões recentes do Android, esse é um dos motivos mais comuns para a linha de execução de IU parar de ser executada. Geralmente, a correção visa evitar chamadas de funções que fazem chamadas de binder. Se for inevitável, coloque o valor em cache ou mova o trabalho para linhas de execução em segundo plano. À medida que as bases de código ficam maiores, é fácil adicionar acidentalmente uma chamada de binder invocando algum método de nível inferior se você não tiver cuidado, mas é igualmente fácil encontrá-las e corrigi-las por meio de rastreamento.

Se você tiver transações de binder, poderá capturar as pilhas de chamadas com os seguintes comandos adb:

$ adb shell am trace-ipc start
… use the app - scroll/animate ...
$ adb shell am trace-ipc stop --dump-file /data/local/tmp/ipc-trace.txt
$ adb pull /data/local/tmp/ipc-trace.txt

Às vezes, chamadas aparentemente inofensivas como getRefreshRate() podem acionar transações de binder e causar grandes problemas quando são chamadas com frequência. O rastreamento periódico pode ajudar você a encontrar e corrigir esses problemas rapidamente à medida que surgirem.

Figura 4: mostra a linha de execução de IU inativa devido a transações de binder em um movimento de RV. Mantenha sua lógica de vinculação simples e use trace-ipc para rastrear e remover chamadas de binder.

Se você não observar atividade de binder, mas ainda não observar a linha de execução de IU, certifique-se de que não está aguardando algum bloqueio ou outra operação de outra linha de execução. Normalmente, a linha de execução de IU não precisa esperar por resultados de outras linhas de execução. Elas é que precisam postar informações.

Alocação de objetos e coleta de lixo

A alocação de objetos e a coleta de lixo (GC, na sigla em inglês) tornaram-se um problema menos significativo desde que o ART foi lançado como o ambiente de execução padrão do Android 5.0, mas ainda é possível sobrecarregar as linhas de execução com esse trabalho extra. Não há problemas em alocar em resposta a um evento raro que não acontece muitas vezes por segundo, como um usuário clicando em um botão, mas lembre-se de que cada alocação tem um custo. Se a alocação estiver em uma repetição que é chamada com frequência, considere evitá-la para aliviar a carga de GC.

O Systrace mostrará se a coleta de lixo está sendo executada com frequência e o Android Memory Profiler poderá mostrar a origem das alocações. Se você evitar alocações quando puder, especialmente em repetições apertadas, provavelmente não terá problemas.

Figura 5: mostra uma coleta de lixo de 94 ms na linha de execução HeapTaskDaemon.

Em versões recentes do Android, a coleta de lixo geralmente é executada em uma linha de execução em segundo plano chamada HeapTaskDaemon. Observe que quantidades significativas de alocação podem significar mais recursos de CPU gastos em GC, como mostrado na figura 5.