A partir de 27 de março de 2025, recomendamos usar android-latest-release em vez de aosp-main para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Leia as informações a seguir para testar implementações gráficas.
Para a comparação de mercado, use o seguinte fluxo por fase:
Especificação. Ao especificar o dispositivo inicialmente, como
ao usar drivers imaturos, use relógios e cargas de trabalho predefinidos (fixos) para
medir os frames por segundo (fps) renderizados. Isso oferece uma visão clara dos recursos
de hardware.
Desenvolvimento. À medida que os drivers amadurecem, use um conjunto fixo de ações do usuário
para medir o número de gagueiras visíveis (janks) nas animações.
Produção. Quando um dispositivo estiver pronto para comparação com
concorrentes, aumente a carga de trabalho até que os travamentos aumentem. Determine se as
configurações atuais do relógio podem acompanhar a carga. Isso pode ajudar a identificar
onde diminuir a velocidade dos relógios e reduzir o uso de energia.
Para ajudar a extrair os recursos do dispositivo durante a fase de especificação, use a
ferramenta Flatland em platform/frameworks/native/cmds/flatland/.
O Flatland usa relógios fixos e mostra a taxa de transferência alcançável com
cargas de trabalho baseadas em composição. Ele usa buffers gralloc para simular vários cenários
de janela, preenchendo a janela com GL e medindo a composição.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-27 UTC."],[],[],null,["# Implementation testing\n\nReview the following information to test graphics implementations.\n\nFor benchmarking, use the following flow by phase:\n\n- *Specification.* When initially specifying the device (such as when using immature drivers), use predefined (fixed) clocks and workloads to measure frames per second (fps) rendered. This gives a clear view of hardware capabilities.\n- *Development.* As drivers mature, use a fixed set of user actions to measure the number of visible stutters (janks) in animations.\n- *Production.* When a device is ready for comparison against competitors, increase the workload until stutters increase. Determine if the current clock settings can keep up with the load. This can help you identify where to slow the clocks and reduce power use.\n\nFor help deriving device capabilities during the specification phase, use the\nFlatland tool at `platform/frameworks/native/cmds/flatland/`.\nFlatland relies on fixed clocks and shows the throughput achievable with\ncomposition-based workloads. It uses gralloc buffers to simulate multiple window\nscenarios, filling in the window with GL then measuring the compositing.\n| **Note:** Flatland uses the synchronization framework to measure time, so your implementation must support the synchronization framework."]]
