preview/testing/performance.jd

page.title=Teste de desempenho de exibio
page.image=images/cards/card-test-performance_2x.png
page.keywords=performance, fps, tools

@jd:body


<div id="qv-wrapper">
  <div id="qv">
    <h2>Neste documento</h2>
      <ol>
        <li><a href="#measure">Medir desempenho da IU</a>
          <ul>
            <li><a href="#aggregate">Agregar estatsticas de quadro</a></li>
            <li><a href="#timing-info">Informaes de preciso de quadro</a></li>
            <li><a href="#timing-dump">Despejo de preciso de quadro simples</a></li>
            <li><a href="#collection-window">Controlar janela de coleta de estatsticas</a></li>
            <li><a href="#diagnose">Diagnosticar regresses de desempenho</a></li>
            <li><a href="#resources">Recursos adicionais</a></li>
          </ul>
        </li>
        <li><a href="#automate">Automatizar teste de desempenho da IU</a>
          <ul>
            <li><a href="#ui-tests">Configurar testes da IU</a></li>
            <li><a href="#automated-tests">Configurar testes automatizados da IU</a></li>
            <li><a href="#triage">Triagem e resoluo de problemas observados</a></li>
          </ul>
        </li>
      </ol>
  </div>
</div>


<p>
  O teste de desempenho da interface do usurio (IU) garante que o aplicativo
 no s esteja de acordo com os requisitos funcionais, como tambm que as interaes de usurios
 sejam muito mais suaves, executando a 60 quadros por segundo de forma consistente (<a href="https://www.youtube.com/watch?v=CaMTIgxCSqU&index=25&list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE">por que
 60 qps?</a>), sem nenhum quadro atrasado ou descartado ou, como gostamos de chamar, <em>"jank"</em>. Este documento explica as ferramentas disponveis
 para medir o desempenho da IU e dispe uma abordagem para integrar
 as medidas de desempenho de IU nas prticas de teste.
</p>


<h2 id="measure">Medir desempenho da IU</h2>

<p>
  Para aprimorar o desempenho, deve-se primeiro ter a habilidade de medir o desempenho
 do sistema e, em seguida, diagnosticar e identificar problemas que podem ocorrer
 em vrias partes do processo.
</p>

<p>
  <em><a href="https://source.android.com/devices/tech/debug/dumpsys.html">dumpsys</a></em>  uma ferramenta
 do Android que  executada no dispositivo e despeja informaes interessantes sobre o estado
 dos servios do sistema. Passar o comando <em>gfxinfo</em> para dumpsys fornece uma sada no logcat
 com informaes de desempenho relacionada aos quadros de animao que ocorrem
 durante a fase de registro.
</p>

<pre>
&gt; adb shell dumpsys gfxinfo &lt;PACKAGE_NAME&gt;
</pre>

<p>
  Este comando pode produzir diversas variveis de dados de preciso de quadro.
</p>

<h3 id="aggregate">Agregar estatsticas de quadro</h3>

<p>
  Com o M Preview, o comando emite uma anlise agregada dos dados de quadro para logcat,
 coletados em todo o ciclo de vida do processo. Por exemplo:
</p>

<pre class="noprettyprint">
Stats since: 752958278148ns
Total frames rendered: 82189
Janky frames: 35335 (42.99%)
90th percentile: 34ms
95th percentile: 42ms
99th percentile: 69ms
Number Missed Vsync: 4706
Number High input latency: 142
Number Slow UI thread: 17270
Number Slow bitmap uploads: 1542
Number Slow draw: 23342
</pre>

<p>
  Estas estatsticas de alto nvel carregam um alto nvel de desempenho de renderizao do aplicativo,
 bem como a estabilidade em vrios quadros.
</p>


<h3 id="timing-info">Informaes de preciso de quadro</h3>

<p>
  Com o M Preview, h um novo comando para gfxinfo, o <em>framestats</em>, que fornece
 informaes de preciso de quadros extremamente detalhadas dos quadros recentes para que voc possa rastrear
 e depurar os problemas de forma mais precisa.
</p>

<pre>
&gt;adb shell dumpsys gfxinfo &lt;PACKAGE_NAME&gt; framestats
</pre>

<p>
  Este comando emite informaes de preciso de quadros, com marcaes de data e hora, dos ltimos 120
 quadros produzidos pelo aplicativo. Abaixo, h um exemplo de sada bruta das estatsticas
 de quadro de adb dumpsys gfxinfo &lt;PACKAGE_NAME&gt;:
</p>

<pre class="noprettyprint">
0,49762224585003,49762241251670,9223372036854775807,0,49762257627204,49762257646058,49762257969704,49762258002100,49762265541631,49762273951162,49762300914808,49762303675954,
0,49762445152142,49762445152142,9223372036854775807,0,49762446678818,49762446705589,49762447268818,49762447388037,49762453551527,49762457134131,49762474889027,49762476150120,
0,49762462118845,49762462118845,9223372036854775807,0,49762462595381,49762462619287,49762462919964,49762462968454,49762476194547,49762476483454,49762480214964,49762480911527,
0,49762479085548,49762479085548,9223372036854775807,0,49762480066370,49762480099339,49762481013089,49762481085850,49762482232152,49762482478350,49762485657620,49762486116683,
</pre>

<p>
  Cada linha desta sada representa um quadro produzido pelo aplicativo. Cada linha tem um nmero fixo
 de colunas que descrevem o tempo gasto em cada estgio do pipeline que produz quadros. A prxima seo descreve
 este formato com detalhes, incluindo o que cada coluna representa.
</p>


<h4 id="fs-data-format">Formato de dados de estatsticas de quadro</h4>

<p>
  Como o bloco de dados  a sada no formato CSV, basta col-lo na ferramenta
 de planilha de sua escolha ou colet-lo e analis-lo com o script. A tabela a seguir explica o formato
 das colunas de dados de sada. Todas as marcaes de data e hora esto em nanossegundos.
</p>

<ul>
  <li>SINALIZADORES
    <ul>
      <li>Linhas com 0 para a coluna FLAGS podem ter o tempo total de quadros calculado
 subtraindo a coluna INTENDED_VSYNC da coluna FRAME_COMPLETED.
      </li>

      <li>Se for um nmero diferente de zero, a linha dever ser ignorada, pois o quadro ser determinado
 como exceo em comparao ao desempenho normal, onde espera-se que o layout e o desenho
 demorem mais do que 16 ms. Eis alguns motivos para que isto ocorra:
        <ul>
          <li>Layout da janela alterado (como o primeiro quadro do aplicativo
 ou aps uma rotao)
          </li>

          <li>Tambm  possvel que o quadro seja ignorado, quando alguns valores
 ainda tero marcaes de data e hora de lixo. Um quadro pode ser ignorado se, por exemplo,
 estiver executando a 60 quadros por segundo ou se nada na tela estiver incorreto, o que no necessariamente
  um sinal de problema no aplicativo.
          </li>
        </ul>
      </li>
    </ul>
  </li>

  <li>INTENDED_VSYNC
    <ul>
      <li>O ponto inicial planejado para o quadro. Se este valor for diferente de VSYNC,
 significa que h um trabalho ocorrendo no encadeamento da IU que no permitiu que ele respondesse
 ao sinal de vsync de forma precisa.
      </li>
    </ul>
  </li>

  <li>VSYNC
    <ul>
      <li>O valor de tempo foi usado em todos os escutadores vsync e no desenho para o quadro
 (retorno de chamada do quadro Choreographer, animaes, View.getDrawingTime(), etc.)
      </li>

      <li>Para entender mais sobre VSYNC e como ele influencia o aplicativo, assista ao vdeo
 <a href="https://www.youtube.com/watch?v=1iaHxmfZGGc&list=PLOU2XLYxmsIKEOXh5TwZEv89aofHzNCiu&index=23">
Entendimento do VSYNC</a>.
      </li>
    </ul>
  </li>

  <li>OLDEST_INPUT_EVENT
    <ul>
      <li>A marcao de data e hora do evento de entrada mais antigo na fila de entrada, ou Long.MAX_VALUE
 se no houver eventos de entrada para o quadro.
      </li>

      <li>Este valor  principalmente planejado para o trabalho da plataforma e tem utilidade limitada
 para desenvolvedores de aplicativos.
      </li>
    </ul>
  </li>

  <li>NEWEST_INPUT_EVENT
    <ul>
      <li>A marcao de data e hora do evento de entrada mais recente na fila de entrada
 ou 0 se no houver eventos de entrada para o quadro.
      </li>

      <li>Este valor  principalmente planejado para o trabalho da plataforma e tem utilidade limitada
 para desenvolvedores de aplicativos.
      </li>

      <li>No entanto,  possvel ter uma breve ideia da quantidade de latncia que o aplicativo
 est adicionado verificando (FRAME_COMPLETED - NEWEST_INPUT_EVENT).
      </li>
    </ul>
  </li>

  <li>HANDLE_INPUT_START
    <ul>
      <li>A marcao de data e hora em que os eventos de entrada foram despachados para o aplicativo.
      </li>

      <li>Ao olhar o horrio entre isto e ANIMATION_START,  possvel medir o tempo que o aplicativo
 gastou para lidar com os eventos de entrada.
      </li>

      <li>Se este nmero for alto (&gt; 2 ms), indica que o aplicativo est gastando
 tempo demais processando os eventos de entrada, como View.onTouchEvent(), o que pode indicar
 que este trabalho precisa ser otimizado ou descarregado para um encadeamento diferente. Observe que h algumas situaes,
 como eventos de clique que iniciam novas atividades,
 em que  esperado e aceitvel que este nmero seja grande.
      </li>
    </ul>
  </li>

  <li>ANIMATION_START
    <ul>
      <li>A marcao de data e hora em que as animaes registradas com Choreographer foram executadas.
      </li>

      <li>Ao olhar para o tempo entre isto e PERFORM_TRANVERSALS_START,
  possvel determinar o tempo levado para avaliar todos os animadores
 (ObjectAnimator, ViewPropertyAnimator e Transitions sendo as mais comuns) que esto sendo executados.
      </li>

      <li>Se este nmero for alto (&gt; 2 ms), verifique se o aplicativo gravou qualquer animador
 personalizado ou quais campos de ObjectAnimators esto animando
 e certifique-se de que eles sejam adequados para uma animao.
      </li>

      <li>Para saber mais sobre Choreographer, assista ao vdeo
 <a href="https://developers.google.com/events/io/sessions/325418001">Para melhor ou pior</a>.
      </li>
    </ul>
  </li>

  <li>PERFORM_TRAVERSALS_START
    <ul>
      <li>Se voc subtrair o DRAW_START deste valor, ser possvel extrair o tempo que as fases de medida e layout
 levaram para serem concludas (observao: durante uma rolagem ou animao,
 espera-se que este valor seja prximo a zero).
      </li>

      <li>Para saber mais sobre as fases de medida e layout do pipeline de renderizao,
 assista ao vdeo <a href="https://www.youtube.com/watch?v=we6poP0kw6E&list=PLOU2XLYxmsIKEOXh5TwZEv89aofHzNCiu&index=27">
Invalidaes, layouts e desempenho</a>
      </li>
    </ul>
  </li>

  <li>DRAW_START
    <ul>
      <li>O horrio em que a fase de desenho de performTraversals foi iniciada. Este  o ponto inicial
 do registro de listas de exibio de vistas que foram invalidadas.
      </li>

      <li>O tempo entre isto e SYNC_START  o tempo levado para chamar View.draw()
 em todas as vistas invalidadas na rvore.
      </li>

      <li>Para obter mais informaes sobre o modelo de desenho, assista aos vdeos <a href="{@docRoot}guide/topics/graphics/hardware-accel.html#hardware-model">Acelerao de hardware</a>
 ou <a href="https://www.youtube.com/watch?v=we6poP0kw6E&list=PLOU2XLYxmsIKEOXh5TwZEv89aofHzNCiu&index=27">
 Invalidaes, layouts e desempenho</a>
      </li>
    </ul>
  </li>

  <li>SYNC_START
    <ul>
      <li>O horrio em que a fase de sincronizao do desenho foi iniciada.
      </li>

      <li>Se o tempo entre isto e ISSUE_DRAW_COMMANDS_START for substancial (aproximadamente &gt; 0,4ms),
 geralmente indicar que vrios Bitmaps novos que foram desenhados devero
 ser enviados para o GPU.
      </li>

      <li>Para entender mais sobre a fase de sincronizao, assista ao vdeo <a href="https://www.youtube.com/watch?v=VzYkVL1n4M8&index=24&list=PLOU2XLYxmsIKEOXh5TwZEv89aofHzNCiu">
Renderizao de GPU de perfil</a>
      </li>
    </ul>
  </li>

  <li>ISSUE_DRAW_COMMANDS_START
    <ul>
      <li>O horrio em que o renderizador de hardware comeou a emitir comandos de desenho para a GPU.
      </li>

      <li>O tempo entre isto e FRAME_COMPLETED fornece uma breve ideia da quantidade de trabalho de GPU
 que o aplicativo est produzindo. Problemas com excesso ou efeitos de renderizao
 ineficientes so exibidos aqui.
      </li>
    </ul>
  </li>

  <li>SWAP_BUFFERS
    <ul>
      <li>O horrio em que o eglSwapBuffers foi chamado, relativamente desinteressante
 fora do trabalho da plataforma.
      </li>
    </ul>
  </li>

  <li>FRAME_COMPLETED
    <ul>
      <li>Tudo feito! O tempo total gasto trabalhando neste quadro pode ser calculando
 realizando FRAME_COMPLETED - INTENDED_VSYNC.
      </li>
    </ul>
  </li>

</ul>

<p>
   possvel usar estes dados de vrias formas. Uma visualizao simples mas til  o histograma
 exibindo a distribuio dos tempos dos quadros (FRAME_COMPLETED - INTENDED_VSYNC)
 em diferentes espaos de latncia. Consulte a figura abaixo. Este grfico mostra brevemente que a maioria
 dos quadros estavam bons  bem abaixo do limite de 16 ms (representado em vermelho) ,
 mas que alguns quadros estavam bem acima do limite. Podemos verificar as alteraes neste histograma
 com o tempo para encontrar as mudanas indiscriminadas ou novas excees sendo criadas. Tambm  possvel colocar em grfico a latncia de entrada,
 o tempo gasto no layout ou outras medidas interessantes com base
 nas vrias marcaes de data e hora nos dados.
</p>

<img src="{@docRoot}preview/images/perf-test-framestats.png">


<h3 id="timing-dump">Despejo de preciso de quadro simples</h3>

<p>
  Se a <strong>renderizao de GPU de perfil</strong> for definida para <strong>em adb shell dumpsys gfxinfo</strong>
 nas opes de desenvolvedor, o comando <code>adb shell dumpsys gfxinfo</code> emitir informaes
 de preciso para os 120 quadros mais recentes, divididas em algumas categorias
 com valores separados por guias. Estes dados podem ser teis para indicar quais partes do pipeline
 de desenho podem estar lentas em um nvel alto.
</p>

<p>
  Semelhante s <a href="#fs-data-format">estatsticas de quadro</a> acima,
 basta col-los na ferramenta de planilha de sua escolha ou colet-los e analis-los
 com um script. O grfico a seguir exibe um detalhamento de onde os vrios quadros produzidos
 pelo aplicativo gastaram o tempo.
</p>

<img src="{@docRoot}preview/images/perf-test-frame-latency.png">

<p>
  O resultado de executar gfxinfo, copiar a sada, col-lo no aplicativo de planilha
 e gerar um grfico dos dados como barras empilhadas.
</p>

<p>
  Cada barra vertical representa um quadro da animao; sua altura representa a quantidade
 de milissegundos para calcular este quadro de animao. Cada segmento colorido da barra
 representa um estgio diferente do pipeline de renderizao para que voc possa ver que partes do aplicativo
 podem estar criando um afunilamento. Para obter mais informaes sobre o entendimento do pipeline
 de renderizao e como otimiz-lo, assista ao vdeo <a href="https://www.youtube.com/watch?v=we6poP0kw6E&index=27&list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE">
Invalidaes, layouts e desempenho</a>.
</p>


<h3 id="collection-window">Controlar janela de coleta de estatsticas</h3>

<p>
  As precises de quadro simples e estatsticas de quadro coletam dados
 em um perodo muito curto  cerca de dois segundos de renderizao. Para controlar este perodo de forma precisa  por exemplo,
 restringir os dados para uma animao em particular ,  possvel redefinir
 todos os contadores e agregar as estatsticas coletadas.
</p>

<pre>
&gt;adb shell dumpsys gfxinfo &lt;PACKAGE_NAME&gt; reset
</pre>

<p>
  Isto tambm pode ser usado em conjunto com os prprios comandos de despejo para coletar
 e redefinir em uma cadncia regular, capturando perodos de menos de dois segundos de quadros
 continuamente.
</p>


<h3 id="diagnose">Diagnosticar regresses de desempenho</h3>

<p>
  A identificao de regresses  uma boa primeira etapa para rastrear os problemas
 e manter o bem-estar do aplicativo. No entanto, o dumpsys identifica apenas a existncia
 e a gravidade relativa dos problemas. Ainda  necessrio diagnosticar a causa particular dos problemas
 de desempenho e encontrar maneiras adequadas de resolv-los. Para isso,  altamente recomendado
 o uso da ferramenta <a href="{@docRoot}tools/help/systrace.html">systrace</a>.
</p>


<h3 id="resources">Recursos adicionais</h3>

<p>
  Para obter mais informaes sobre como o pipeline de renderizao do Android funciona,
 problemas comuns que podem ser encontrados e como resolv-los,
 alguns dos seguintes recursos podem ser teis:
</p>

<ul>
  <li>Desempenho de renderizao 101
  </li>
  <li>Por que 60 qps?
  </li>
  <li>GPU e IU do Android
  </li>
  <li>Invalidaes, layouts e desempenho
  </li>
  <li>Anlise do desempenho de IU com Systrace
  </li>
</ul>


<h2 id="automate">Automatizar teste de desempenho da IU</h2>

<p>
  Uma abordagem para o teste de desempenho da IU  fazer com que um testador humano
 realize uma srie de operaes de usurio no aplicativo-alvo e procure visualmente problemas
 ou gaste uma grande quantidade de tempo usando uma abordagem de ferramenta para encontr-los. No entanto, esta abordagem manual
  repleta de riscos: a habilidade humana de notar alteraes na taxa de quadros varia tremendamente,
 alm de consumir tempo, ser tedioso e propenso a erros.
</p>

<p>
  Uma abordagem mais eficiente  registrar e analisar as mtricas de desempenho essenciais
 dos testes de IU automatizados. O Android M Developer Preview inclui novas capacidades de registro que facilitam
 a determinao da quantidade e da gravidade de erros nas animaes do aplicativo
 e que podem ser usadas para compilar um processo rigoroso para determinar o desempenho atual
 e rastrear os futuros objetivos de desempenho.
</p>

<p>
  Este artigo mostra uma abordagem recomendada para usar estes dados para automatizar
 o teste de desempenho.
</p>

<p>
  Ele  geralmente dividido em duas aes principais. Primeiro: identificar o que est testando
 e como ser testado. Segundo: configurao e manuteno
 de um ambiente de teste automatizado.
</p>


<h3 id="ui-tests">Configurar de testes da IU</h3>

<p>
  Antes de iniciar o teste automatizado,  importante determinar algumas decises de alto nvel
 para entender corretamente o espao de teste e as possveis necessidades.
</p>

<h4>
  Identificar principais animaes/fluxos a testar
</h4>

<p>
  Lembre-se que um desempenho ruim  mais visvel aos usurios quando
 interrompe uma animao suave. Portanto, ao identificar que tipos de aes de IU sero testadas,  til se concentrar
 nas animaes principais que os usurios veem
 ou nas mais importantes para a experincia. Por exemplo, eis alguns cenrios comuns que pode ser til identificar:
</p>

<ul>
  <li>Rolagem de um ListView ou RecyclerView principal
  </li>

  <li>Animaes durante ciclos de espera assncrona
  </li>

  <li>Qualquer animao que possa ter manipulao ou carregamento de bitmap
  </li>

  <li>Animaes com mistura alpha
  </li>

  <li>Desenho de vista personalizada com Canvas
  </li>
</ul>

<p>
  Trabalhe com engenheiros, designers, e gerentes de produto em sua equipe para priorizar
 as animaes de produto essenciais para a cobertura de teste.
</p>

<h4>
  Defina os futuros objetivos e faa um rastreamento
</h4>

<p>
  De um alto nvel, talvez seja essencial identificar os objetivos especficos de desempenho
 e concentrar-se em escrever testes e coletar dados. Por exemplo:
</p>

<ul>
  <li>Quer apenas iniciar o rastreamento de desempenho de IU pela primeira vez para aprender mais?
  </li>

  <li>Quer evitar regresses que possam ser introduzidas no futuro?
  </li>

  <li>Est com 90% de quadros suaves hoje e deseja chegar a 98% neste trimestre?
  </li>

  <li>Est com 98% de quadros suaves e no quer regredir?
  </li>

  <li>O seu objetivo  aprimorar o desempenho em dispositivos de baixo nvel?
  </li>
</ul>

<p>
  Em todos esses casos, voc optar pelo rastreamento histrico, que exibe o desempenho
 entre vrias verses do aplicativo.
</p>

<h4>
  Identificar dispositivos para realizar testes
</h4>

<p>
  O desempenho do aplicativo varia dependendo do dispositivo em que est sendo executado. Alguns dispositivos podem
 conter menos memria, GPUs menos eficientes ou chips de CPU mais lentos. Isto significa que as animaes que podem
 ter um bom desempenho em um conjunto de hardwares podem no ter o mesmo desempenho em outras,
 podendo ser o resultado de um afunilamento em uma parte diferente do pipeline. Portanto, para contabilizar
 esta variao em o que o usurio pode ver, escolha uma variao de dispositivos
 para executar os testes: dispositivos e tablets de alto e baixo nvel etc. Procure variaes no desempenho de CPU,
 RAM, densidade da tela, tamanho etc. Testes que passam em dispositivos de alto nvel
 podem falhar em dispositivos de baixo nvel.
</p>

<h4>
  Estruturas bsicas para teste de IU
</h4>

<p>
  Conjuntos de ferramenta, como <a href="{@docRoot}training/testing/ui-testing/uiautomator-testing.html">UI Automator</a> e
 <a href="{@docRoot}training/testing/ui-testing/espresso-testing.html">Espresso</a>,
 so integrados para ajudar na automatizao da ao de um usurio movendo-se pelo aplicativo. So estruturas simples
 que imitam a interao de usurio no dispositivo. Para usar estas estruturas,
 voc cria efetivamente scripts nicos que executam um conjunto
 de aes de usurio e reproduzem-nas no prprio dispositivo.
</p>

<p>
  Ao combinar estes testes automatizados, juntamente com <code>dumpsys gfxinfo</code>,  possvel criar
 rapidamente um sistema reproduzvel que permite a execuo de um teste e a medio das informaes
 de desempenho desta condio em particular.
</p>


<h3 id="automated-tests">Configurar testes automatizados da IU</h3>

<p>
  Com a habilidade de executar um teste de IU e um pipeline para coletar
 os dados de um nico teste, a prxima etapa importante  adotar uma estrutura que pode executar
 esse teste vrias vezes, em vrios dispositivos, e agregar os dados de desempenho resultados
 para futuras anlises da equipe de desenvolvimento.
</p>

<h4>
  Uma estrutura para automatizao de testes
</h4>

<p>
  Vale observar que as estruturas de teste de IU (como o <a href="{@docRoot}training/testing/ui-testing/uiautomator-testing.html">UI Automator</a>)
 so executadas diretamente no emulador/dispositivo alvo. Enquanto as informaes de coleta de desempenho feita
 pelo <em>dumpsys gfxinfo</em> forem direcionadas por uma mquina hospedeira, envie comandos pelo ADB. Para ajudar a transmitir
 a automatizao dessas entidades separadas, a estrutura <a href="{@docRoot}tools/help/monkeyrunner_concepts.html">MonkeyRunner</a>
 foi desenvolvida: um sistema de script que  executado na mquina host que pode
 emitir comandos para um conjunto de dispositivos conectados, bem como receber dados deles.
</p>

<p>
  A compilao de um conjunto de scripts para uma automatizao adequada de teste de desempenho de IU,
 no mnimo, deve ser capaz de utilizar o MonkeyRunner para realizar as seguintes tarefas:
</p>

<ul>
  <li>Carregar e iniciar um APK desejado para um emulador ou dispositivo alvo.
  </li>

  <li>Iniciar um teste de IU do UI Automator e permitir que ele seja executado.
  </li>

  <li>Coletar informaes de desempenho por meio de <em>dumpsys gfxinfo</em><em>.</em>
  </li>

  <li>Agregar informaes e exibi-las de forma til para o desenvolvedor.
  </li>
</ul>


<h3 id="triage">Triagem e resoluo de problemas observados</h3>

<p>
  Quando os padres ou regresses dos problemas forem identificados, a prxima etapa
  identificar e aplicar a resoluo. Se a estrutura de teste automatizado preservar o detalhamento preciso para os quadros,
 ela poder ajudar na inspeo de alteraes de layout/cdigo suspeitos recentes (em caso
 de regresso) ou reduzir a parte do sistema que voc est analisando ao alternar
 para a investigao manual. Para a investigao manual, <a href="{@docRoot}tools/help/systrace.html">systrace</a>  um timo lugar para comear,
 exibindo as informaes de preciso sobre cada estgio do pipeline de renderizao,
 cada encadeamento e ncleo no sistema, bem como quaisquer marcadores de evento personalizados definidos.
</p>

<h4>
  Gerao de perfis adequada de precises temporais
</h4>

<p>
   importante observar as dificuldades em obter e medir as precises
 do desempenho de renderizao. Esses nmeros so, por natureza, no determinsticos e frequentemente
 oscilam dependendo do estado do sistema, da quantidade de memria disponvel,
 da diminuio termal e da ltima vez em que a luz do sol atingiu a sua rea da Terra. Ou seja,  possvel executar
 o mesmo teste duas vezes e receber nmeros levemente diferentes
 que podem ser muito prximos, mas no idnticos.
</p>

<p>
  A coleta e a gerao de perfil de dados nesta maneira significa executar o mesmo teste,
 vrias vezes, e acumular os resultados como uma mdia ou valor mediano (para a simplicidade,
 chamemos de "lote"). Isto fornece uma aproximao do desempenho do teste,
 j que precises exatas no so necessrias.
</p>

<p>
  Os lotes podem ser usados entre alteraes de cdigos para verificar o impacto relativo
 dessas alteraes no desempenho. Se a taxa de quadros mdia para o lote antes da alterao
 for maior do que o lote aps a alterao, ento o resultado de desempenho wrt geral ser um sucesso
 para esta alterao em particular.
</p>

<p>
  Isto significa que qualquer teste de IU automatizado feito deve levar este conceito
 em considerao, bem como quaisquer anomalias que possam ocorrer durante um teste. Por exemplo,
 se o desempenho do aplicativo repentinamente cair devido a algum problema do dispositivo
 (que no tenha sido causado pelo aplicativo), ento talvez seja necessrio executar
 o lote novamente para obter precises menos caticas.
</p>

<p>
  Logo, quantas vezes deve-se realizar um teste antes de as medidas terem algum sentido? 10 vezes deve ser o mnimo,
 com nmeros altos como 50 ou 10 oferecendo resultados mais precisos
 ( claro que se deve levar em considerao o tempo para ter mais preciso).
</p>