Processadores mobile já são tão rápidos quanto a maioria dos chips de PC
Os processadores voltados para dispositivos móveis, como smartphones e tablets, já são tão ou mais rápidos do que os chips feitos para PCs. Bom, para Chris Hoffman, em um interessante artigo para o site Howtogeek, esse dia chegou. E com força.
A Apple diz que seus novos iPad Pros são mais rápidos do que 92% de todos os laptops, tablets e PCs conversíveis comercializados no ano passado. E sim, isso inclui PCs com processadores Intel Core i7! As CPUs móveis, ou processadores para dispositivos móveis, como queira, estão se tornando tão rápidas quanto as CPUs dos PCs de mesa, independentemente de qual seja o processador.
Claro, um iPhone ou iPad não vai substituir seu PC de mesa tão cedo, mas isso é apenas por causa do software. O hardware já está pronto. Basta pensar no que poderíamos fazer com um sistema operacional móvel mais adequado ao PC, ou mesmo o Windows 10 sendo executado em um dispositivo com um desses novos chips.
publicidade
Esqueça o iPad. Mesmo o iPhone é já é mais rápido
Nem precisa pensar em um dispositivo maior, como um tablet, para ter uma CPU de desempenho. O iPhone já é mais rápido. Podemos ter a impressão de que isso não é verdade porque smartphones são pequenos, leves, não tem mouse, teclado… mas não estamos falando de conectividade e, sim, poder de processamento.
Os novos iPhones – ou seja, o iPhone XS, o iPhone XS Max e até o mais barato iPhone XR – incluem o novo chip A12 Bionic da Apple. Aquela pequena CPU do iPhone é um cavalo de batalha. Veja os testes que o site especialista em hardware, o Anandtech, escreveu depois de rodar alguns benchmarks nesses iPhones:
O que surpreende é o quão próximos estão as CPUS Bionic A11 e A12 da Apple em relação às atuais CPUs de desktop quando se fala de desempenho. Não tivemos a oportunidade de rodas aplicações semelhantes para fazer uma comparação prática, mas … vemos que o A12 supera uma CPU Skylake (6ª geração de CPUs Intel) com velocidade moderada (frequência de funcionamento) no desempenho single-threaded (quando uma única tarefa é executada por vez). É claro que há considerações de compiladores dos sistemas e detalhes de faixa de frequência que cada arquitetura usa a serem levadas em consideração, mas falta muito pouco para um celular que contém todos os seus componentes em um único chip (SoC, ou system-on-a-chips) da Apple superar as CPUs de desktop mais rápidas em termos de desempenho, ao menos quando se fala em execução de uma tarefa por vez (chamado de single-thread em termo computacional).
A partir disso, podemos afirmar que a Apple está melhorando seus chips muito mais rápido do que a Intel. E logo pode alcança-la no poder computacional.
Mais provas estão em outro software de benchmark (softwares de testes de desempenho), chamado GeekBench, largamente utilizado para medir desempenho absoluto de uma CPU. O desempenho absoluto é relativo à velocidade que uma CPU alcança para executar cálculos aritméticos.
Confira os resultados do Geekbench para iPhones e iPads e compare-os com os resultados para PCs desktop. Um iPhone atual modelo XS ou XR oferece uma pontuação bem próxima a alguns processadores de desktop de baixo custo da Intel Kaby Lake (7ª geração) lançados em 2017.
Os chips da Apple são tão rápidos quanto um moderno console de videogame também
Em plataformas móveis, a CPU (processador aritmético) e a GPU (processador gráfico) estão encapsuladas em um único chip, o chamdo system on a chip (SoC), como já citamos. E as GPUs também estão impressionando no desempenho.
A Apple também diz que seus novos iPads com o chip A12 X Bionic têm gráficos comparáveis ao Xbox One S-class. E o iPad é apenas tablet leve, portátil e com um tempo de vida útil longo.
O Xbox One original, convenhamos, é uma caixa pesada que precisa de um monte de fios e deve ser conectada à parede com um adaptador AC pesado e grande. Esse Xbox One é mais lento que um Xbox One S, o que significa que é mais lento que um iPad!
Ok, ok, o Xbox One foi lançado em 2013. Mas ainda é um console de jogos da atual geração. Imagine o que os engenheiros da Apple poderiam fazer se colocassem esse chip em uma caixa do tamanho de um Xbox com mais energia e refrigeração.
Não é coisa de fanboy: isso serve para outros smartphones também
Mas vamos falar sobre outros fabricantes. Os modernos telefones Android, como o Pixel 3 do Google, o Galaxy S9 da Samsung e o OnePlus 6T usam os chips Snapdragon 845 da Qualcomm.
Os telefones Android ainda ficam um pouco atrás da Apple quando vemos as pontuações do Geekbench. Os dispositivos Android com o Snapdragon 845 oferecem uma pontuação única de cerca de 2400, embora as variantes do Samsung Galaxy com o chip Exynos 9810 da Samsung estejam mais próximas de 3300.
Esses dispositivos Android têm desempenho semelhantes a um iPhone 6s Plus ou iPhone 7 quando se mede o desempenho por single-thread. Portanto, talvez eles estejam alguns anos atrasados para o desempenho single-thread, mas estão chegando lá também. Os fabricantes de chips para Android também estão caminhando mais rápido do que a Intel está melhorando suas CPUs para desktops.
O que isso significa para o futuro da computação?
Esses chips de baixa potência que você tem em seu telefone e tablet estão a caminho de superar os chips de maior potência do seu laptop e desktop. Isso significa um desempenho bem alto para um telefone ou tablet.
O sonho da “convergência” não está longe. Veja o Galaxy Note 9, da samsung. Um simples cabo USB-C / HDMI o conecta a um monitor de vídeo, que pode ter resolução 4K e mais um teclado e mouse podem ser pareados. “Voiála” e você tem um PC de mesa do tamanho de um celular. Como dissemos, ainda não há software ideal para que esse ecossistema seja igualado ao de um PC. Mas o hardware já tem desempenho suficiente para tal. É uma pena que o Ubuntu Phone e o Windows 10 Mobile tenham saído de cena muito cedo.
E essas CPUs potentes de celulares não precisam ficar só nos telefones. Elas podem ser usadas em laptops para maior duração da bateria, por exemplo. O projeto para rodar o Windows 10 em um processador de arquitetura ARM (a base dos processadores móveis) é um reconhecimento de que mesmo o Windows irá rodar em chips ARM.
Esses dispositivos são bastante lentos hoje porque a arquitetura ARM ainda não tem chips velozes o suficiente para suportar o Windows 10. Mas, uma vez que eles superarem essa barreira, esses aparelhos terão um ótimo desempenho, combinado com uma excelente duração da bateria. Você também poderá comprar Chromebooks que usam processadores ARM.
Para a Apple – a empresa que produz os chips móveis mais rápidos até o momento – esta é uma grande oportunidade. Ela poderia substituir os chips da Intel em Macs por seus próprios chips ARM da série A. Isso há muito tem sido um rumor, mas faz sentido. Esses processadores são realmente rápidos o suficiente para isso. E eles provavelmente poderiam ser mais rápidos, com mais potência unindo a eles um sistema com melhor resfriamento, como já usam os notebooks e desktops há tempos. Um relatório da Bloomberg disse que a Apple planeja usar seus chips ARM em Macs a partir de 2020, e não ficaríamos surpresos em ver isso acontecer.
Outra coisa que pode acontecer é o iPad ganhar um software mais poderoso até que se torne superior ao desempenho de um PC também. O software do iPad tem um longo caminho a percorrer, mas já tem o hardware para fazer muito trabalho sério hoje. O software só precisa acompanhar.
* Com informações de René Ribeiro
Elevada da CPU utilização e desempenho problemas que ocorre quando a enumeração baseada no acesso está activada no Windows 8.1 ou o Windows 7
Informações sobre correção
Uma correção suportada está disponível a partir do Suporte da Microsoft. No entanto, esta correção destina-se apenas a corrigir o problema descrito neste artigo. Aplique esta correção apenas em sistemas que tenham o problema descrito neste artigo. Esta correcção poderá ser submetida a testes adicionais. Por conseguinte, se não estiver a ser gravemente afetado por este problema, recomendamos que aguarde pela próxima atualização de software que contenha esta correção.
Se a correcção estiver disponível para transferência, existirá uma secção de "Transferência de correcção disponível" na parte superior deste artigo da Base de dados de conhecimento. Se esta secção não for apresentada, contacte o Suporte ao Cliente da Microsoft para obter a correção.
Nota Caso ocorram problemas adicionais ou se for necessária a resolução de problemas, poderá ter de criar um pedido de assistência separado. Os custos de normais do suporte serão aplicados a questões de suporte adicional e problemas incluídos nesta correção específica. Para uma lista completa dos números de telefone de suporte e serviço de cliente da Microsoft ou para criar um pedido de assistência separado, vá para o seguinte Web site da Microsoft:
O formulário "Transferência de correcção disponível" apresenta os idiomas nos quais a correcção está disponível. Se não visualizar o seu idioma, é porque uma correcção não está disponível para esse idioma.
Pré-requisitos Para aplicar esta correcção, instale a actualização 2919355 no ponto 8.1 do Windows ou Windows Server R2 de 2012. Ou, instale o Service Pack 1 no Windows 7 ou Windows Server 2008 R2.
Requisito de reinício Tem de reiniciar o computador depois de aplicar esta correcção.
Melhorar o desempenho do jogo
Jogadores preferem jogos com tempos de carregamento menores, frame rates consistentes e capacidade de resposta confiável.
Se você já tem experiência com desenvolvimento de jogos para computadores ou consoles, poderá se surpreender com as diferenças entre esses dispositivos e os dispositivos móveis com relação ao tamanho e o desempenho da memória flash da GPU. Essa divergência entre as estruturas de sistema pode dificultar a previsão do desempenho do seu jogo no Android.
Este guia ajudará você a otimizar seu jogo, para que o desempenho seja o mais confiável possível em todos os tipos de dispositivos Android compatíveis. Especificamente, será explicado como configurar o rastreamento do sistema de um jogo para Android. O guia também descreve como usar o relatório de saída de um rastro do sistema para analisar aspectos específicos do desempenho do jogo.
Configurar um rastro de sistema baseado em jogo
A ferramenta Systrace, disponível como um programa da linha de comando e como um serviço no dispositivo, captura um perfil da CPU e da linha de execução do app durante um breve período. Você pode usar os resultados de um relatório do Systrace para entender melhor o desempenho do seu jogo no Android e para identificar como aprimorar a eficiência e a capacidade de resposta do jogo.
O Systrace é uma ferramenta de nível muito baixo, o que traz os seguintes benefícios:
Fornece informações precisas . O Systrace captura saídas diretamente do kernel. Assim, as métricas capturadas são praticamente idênticas às que seriam relatadas por diversas chamadas do sistema.
. O Systrace captura saídas diretamente do kernel. Assim, as métricas capturadas são praticamente idênticas às que seriam relatadas por diversas chamadas do sistema. Consome menos recursos. O Systrace introduz uma sobrecarga muito baixa no dispositivo. Geralmente, essa sobrecarga é inferior a 1%, porque a ferramenta transfere dados para um buffer na memória.
Configurações ideais
Independentemente de como você capturar o rastro do sistema, é importante que a ferramenta tenha um conjunto razoável de argumentos:
Categorias : o melhor conjunto de categorias para ativar em um rastro de sistema com base em um jogo é: { sched , freq , idle , am , wm , gfx , view , sync , binder_driver , hal , dalvik }.
: o melhor conjunto de categorias para ativar em um rastro de sistema com base em um jogo é: { , , , , , , , , , , }. Tamanho do buffer : como regra geral, o tamanho do buffer de 10 MB por núcleo da CPU permite um rastro de cerca de 20 segundos. Por exemplo, se um dispositivo tem duas CPUs quad-core (oito núcleos no total), o valor apropriado a ser transmitido para o programa systrace é 80.000 KB (80 MB). No entanto, se o jogo realizar muitas trocas de contexto, aumente o buffer para 15 MB por núcleo da CPU. Observação : para solicitar um tamanho de buffer maior, o dispositivo precisa ter memória suficiente disponível para todos os núcleos. Além disso, cada parte da memória por núcleo precisa ser contígua. Por exemplo, se você tentar capturar um rastro do sistema em um dispositivo com oito núcleos com um tamanho de buffer de 80 MB, o dispositivo precisará ter 640 MB disponíveis, e cada parte de 80 MB da memória precisará estar disponível como um bloco contíguo.
Eventos personalizados: se você definir eventos personalizados para realizar capturas no jogo, ative a sinalização -a , que permite que o Systrace inclua esses eventos personalizados no relatório de saída.
Se você estiver utilizando o programa de linha de comando systrace , use o seguinte comando para capturar um rastro do sistema que segue as práticas recomendadas do conjunto de categorias, do tamanho do buffer e de eventos personalizados:
python systrace.py -a -b 80000 -o my_systrace_report.html sched freq idle am wm gfx view sync binder_driver hal dalvik
Se você estiver usando o app do sistema Systrace em um dispositivo, realize as etapas a seguir para capturar um rastro do sistema que segue as práticas recomendadas do conjunto de categorias, do tamanho do buffer e de eventos personalizados:
Ative a opção Rastrear aplicativos depuráveis. Em Tamanho do buffer, selecione 65536 (cerca de 64 MB). Para usar essa configuração, o dispositivo precisa ter 256 ou 512 MB disponíveis, dependendo da CPU ter quatro ou oito núcleos, respectivamente. Além disso, cada parte de 64 MB da memória precisa estar disponível como um bloco contíguo. Selecione Categorias e ative as categorias da seguinte lista: am : gerenciador de atividades
: gerenciador de atividades binder_driver : driver do binder do kernel
: driver do binder do kernel dalvik : VM Dalvik
: VM Dalvik freq : frequência da CPU
: frequência da CPU gfx : gráficos
: gráficos hal : módulos de hardware
: módulos de hardware idle : CPU inativa
: CPU inativa sched : programação da CPU
: programação da CPU sync : sincronização
: sincronização view : sistema de visualização
: sistema de visualização wm : gerenciador de janelas Ative a opção Registrar rastros. Carregue o jogo. Realize as interações no jogo que correspondam à jogabilidade dos dispositivos em que você quer medir o desempenho. Depois de encontrar comportamentos indesejados no jogo, desative o rastreamento do sistema. Você terá capturado as estatísticas de desempenho necessárias para analisar melhor o problema.
Para economizar espaço em disco, os rastros do sistema no dispositivo salvam os arquivos em um formato de rastro compactado ( ). Para descompactar o arquivo ao gerar um relatório, use o programa da linha de comando e inclua a opção --from-file :
python systrace.py -o my_systrace_report.html
Aprimorar áreas de desempenho específicas
Esta seção destaca várias questões de desempenho comuns de jogos para dispositivos móveis e descreve como identificar e melhorar esses aspectos do jogo.
Velocidade de carregamento
Os usuários querem começar a jogar o mais rápido possível. Por isso, é importante melhorar ao máximo os tempos de carregamento do jogo. As medidas a seguir geralmente diminuem os tempos de carregamento:
Execute o carregamento lento . Se você usa os mesmos recursos em cenas ou fases consecutivas do jogo, carregue-os apenas uma vez.
. Se você usa os mesmos recursos em cenas ou fases consecutivas do jogo, carregue-os apenas uma vez. Reduza o tamanho dos recursos. Assim, é possível agrupar versões não compactadas desses recursos com o APK do jogo.
Assim, é possível agrupar versões não compactadas desses recursos com o APK do jogo. Use um método de compactação eficiente em disco. Um exemplo desse tipo de método é zlib (link em inglês).
Um exemplo desse tipo de método é zlib (link em inglês). Use o IL2CPP (link em inglês) em vez do modo mono . Essa opção só é válida se você está usando o Unity. O IL2CPP apresenta um desempenho de execução melhor para scripts C#.
. Essa opção só é válida se você está usando o Unity. O IL2CPP apresenta um desempenho de execução melhor para scripts C#. Use várias linhas de execução no jogo. Para ver mais detalhes, consulte a seção consistência de frame rate.
Consistência de frame rate
Um dos elementos mais importantes da experiência de jogabilidade é um frame rate consistente. Siga as técnicas de otimização discutidas nesta seção para alcançar essa meta com mais facilidade.
Usar várias linhas de execução
Ao desenvolver para várias plataformas, é natural colocar toda a atividade do seu jogo em uma única linha de execução. Embora seja fácil implementar esse método de execução em vários mecanismos de jogo, ele não é o mais ideal para dispositivos Android. Consequentemente, jogos com uma única linha de execução costumam apresentar carregamento lento e falta de consistência do frame rate.
O Systrace mostrado na Figura 1 exibe o comportamento típico de um jogo executado em uma única CPU por vez:
Figura 1. Relatório do Systrace para um jogo com uma única linha de execução.
Para melhorar o desempenho do jogo, use várias linhas de execução. Normalmente, o melhor modelo é usar duas linhas de execução:
Uma linha de execução do jogo, que contém os módulos principais do jogo e envia comandos de renderização.
Uma linha de comando de renderização, que recebe comandos de renderização e os traduz em comandos gráficos, usados pela GPU do dispositivo para exibir um cenário.
A API do Vulkan expande esse modelo, devido à capacidade de enviar dois buffers comuns em paralelo. Usando esse recurso, você pode distribuir diversas linhas de execução de renderização em várias CPUs, melhorando ainda mais o tempo de renderização de um cenário.
Você também pode fazer algumas mudanças específicas do mecanismo para melhorar o desempenho do jogo em diversas linhas de execução.
Se você está desenvolvendo seu jogo usando o mecanismo do Unity, ative as opções Multithreaded Rendering e GPU Skinning .
e . Se você estiver usando um mecanismo de renderização personalizado, verifique se os pipelines de comandos de renderização e de comandos gráficos estão alinhados corretamente. Caso contrário, você corre o risco de introduzir atrasos na exibição dos cenários do jogo.
Depois da implementação dessas mudanças, o jogo ocupará pelo menos duas CPUs simultaneamente, conforme mostrado na Figura 2:
Figura 2. Relatório do Systrace para um jogo com várias linhas de execução.
Carregamento de elementos da IU
Figura 3. Relatório do Systrace para um jogo que está renderizando dezenas de elementos da IU ao mesmo tempo.
Ao criar um jogo com muitos recursos, é tentador exibir várias opções e ações diferentes para o jogador ao mesmo tempo. No entanto, para manter um frame rate consistente, é importante considerar o tamanho relativamente pequeno das telas de dispositivos móveis e usar a IU mais simples possível.
O relatório do Systrace mostrado na Figura 3 é um exemplo de frame da IU que tenta renderizar elementos demais para a capacidade de um dispositivo móvel.
Tenha como meta reduzir o tempo de atualização da IU para 2 a 3 milésimos de segundo. Para atualizar nessa velocidade, implemente otimizações como as seguintes:
Atualize apenas os elementos que se moveram na tela.
Limite o número de texturas e camadas de IU. Você pode combinar chamadas gráficas que usam o mesmo material, como sombreadores e texturas.
Adie operações de animação de elementos para a GPU.
Use algoritmos de visibilidade "frustum culling" e "occlusion culling" mais agressivos.
Se possível, realize operações de desenho usando a API do Vulkan. A sobrecarga de chamadas de desenho é menor no Vulkan.
Consumo de energia
Mesmo depois de realizar as otimizações discutidas na seção anterior, você pode perceber que o frame rate do jogo diminui nos primeiros 45 a 50 minutos de jogo. Além disso, o dispositivo pode começar a aquecer e consumir mais bateria com o tempo.
Em muitos casos, essa combinação indesejada de temperatura e consumo de bateria está relacionada à forma como a carga de trabalho do jogo é distribuída entre as CPUs do dispositivo. Para aumentar a eficiência de consumo da bateria do jogo, aplique as práticas recomendadas mostradas nas seções a seguir.
Manter as linhas de execução com uso intenso de memória em uma só CPU
Em muitos dispositivos móveis, os caches L1 ficam em CPUs específicas, e os caches L2 ficam em um conjunto de CPUs que compartilham um clock. Em geral, para aumentar a ocorrência em cache L1, é melhor manter a linha de execução principal do jogo, junto de outras linhas de execução com uso intenso de memória, em uma única CPU.
Adiar trabalhos de curta duração para CPUs com menor consumo de energia
A maior parte dos mecanismos de jogo, inclusive o Unity, adia operações de linha de execução worker para outra CPU que não a da linha de execução principal do jogo. No entanto, o mecanismo não reconhece a arquitetura específica do dispositivo e não pode prever a carga de trabalho do jogo tão bem quanto você.
A maior parte dos dispositivos system on a chip tem pelo menos dois clocks compartilhados: um para as CPUs rápidas e outro para as CPUs lentas do dispositivo. Uma das consequências dessa arquitetura é que, se uma CPU precisa operar em velocidade máxima, todas as outras CPUs rápidas também operarão na mesma velocidade.
O relatório de exemplo da Figura 4 mostra um jogo que usa CPUs rápidas. No entanto, esse alto nível de atividade apresenta um alto consumo de bateria e o aumento rápido da temperatura.
Figura 4. Relatório do Systrace mostrando uma atribuição não ideal de linhas de execução para as CPUs do dispositivo.
Observação: em um relatório do Systrace, se você selecionar uma linha de execução em uma das linhas da CPU, a ferramenta exibirá o estado da CPU que ocorreu durante a execução da linha. Um estado "3" representa a velocidade máxima da CPU.
Para reduzir o consumo geral da bateria, é recomendado sugerir ao programador que trabalhos de duração mais curta, como o carregamento de áudio, a execução de linhas de execução de worker e a execução do coreógrafo, sejam adiados para o conjunto de CPUs lentas do dispositivo. Transfira o máximo possível desse tipo de trabalho para as CPUs lentas para manter um frame rate adequado.
A maioria dos dispositivos lista as CPUs lentas antes das CPUs rápidas, mas não presuma que o SoC do dispositivo esteja usando essa ordem. Para verificar, execute comandos como os mostrados neste código de descoberta de topologia da CPU (em inglês) no GitHub.
Quando você souber quais são as CPUs lentas no dispositivo, poderá declarar afinidades para as linhas de execução de curta duração, que serão seguidas pelo programador do dispositivo. Para fazer isso, adicione o seguinte código em cada linha de execução:
#include
Observação: em casos avançados em que você tem uma carga de trabalho com carregamento intenso em paralelo, é recomendável gerenciar essas linhas de execução de forma que as CPUs lentas continuem ativas com a maior frequência possível. Esse alto nível de granularidade para a programação da CPU ajuda ainda mais a manter o frame rate do jogo.
Estresse térmico
Quando os dispositivos ficam muito quentes, eles podem limitar a CPU e/ou a GPU, e isso pode afetar os jogos de maneiras inesperadas. Os jogos que incorporam gráficos complexos, computação intensa ou atividade de rede sustentada têm maior probabilidade de apresentar problemas.
Use a API Thermal para monitorar as mudanças de temperatura no dispositivo e tomar medidas para reduzir o uso de energia e manter a temperatura mais baixa no dispositivo. Quando o dispositivo relatar estresse térmico, desative as atividades contínuas para reduzir o consumo de energia. Por exemplo, reduza o frame rate ou a tesselação de polígonos.
Primeiro, declare o objeto PowerManager e inicialize-o no método onCreate() . Adicione um listener de status térmico ao objeto.
Kotlin class MainActivity : AppCompatActivity() { lateinit var powerManager: PowerManager override fun onCreate(savedInstanceState: Bundle?) { powerManager = getSystemService(Context.POWER_SERVICE) as PowerManager powerManager.addThermalStatusListener(thermalListener) } } Java public class MainActivity extends AppCompatActivity { PowerManager powerManager; @Override protected void onCreate(Bundle savedInstanceState) { ... powerManager = (PowerManager) getSystemService(Context.POWER_SERVICE); powerManager.addThermalStatusListener(thermalListener); } }
Defina as ações que serão realizadas quando o listener detectar uma mudança de status. Se o jogo usar C/C++, adicione o código aos níveis de status térmico em onThermalStatusChanged() para chamar o código nativo do jogo usando o JNI ou use a API Thermal nativa.
Kotlin val thermalListener = object : PowerManager.OnThermalStatusChangedListener() { override fun onThermalStatusChanged(status: Int) { when (status) { PowerManager.THERMAL_STATUS_NONE -> { // No thermal status, so no action necessary } PowerManager.THERMAL_STATUS_LIGHT -> { // Add code to handle light thermal increase } PowerManager.THERMAL_STATUS_MODERATE -> { // Add code to handle moderate thermal increase } PowerManager.THERMAL_STATUS_SEVERE -> { // Add code to handle severe thermal increase } PowerManager.THERMAL_STATUS_CRITICAL -> { // Add code to handle critical thermal increase } PowerManager.THERMAL_STATUS_EMERGENCY -> { // Add code to handle emergency thermal increase } PowerManager.THERMAL_STATUS_SHUTDOWN -> { // Add code to handle immediate shutdown } } } } Java PowerManager.OnThermalStatusChangedListener thermalListener = new PowerManager.OnThermalStatusChangedListener () { @Override public void onThermalStatusChanged(int status) { switch (status) { case PowerManager.THERMAL_STATUS_NONE: // No thermal status, so no action necessary break; case PowerManager.THERMAL_STATUS_LIGHT: // Add code to handle light thermal increase break; case PowerManager.THERMAL_STATUS_MODERATE: // Add code to handle moderate thermal increase break; case PowerManager.THERMAL_STATUS_SEVERE: // Add code to handle severe thermal increase break; case PowerManager.THERMAL_STATUS_CRITICAL: // Add code to handle critical thermal increase break; case PowerManager.THERMAL_STATUS_EMERGENCY: // Add code to handle emergency thermal increase break; case PowerManager.THERMAL_STATUS_SHUTDOWN: // Add code to handle immediate shutdown break; } } };
Latência entre o toque e a exibição
Jogos que renderizam frames com a maior velocidade possível criam um cenário limitado pela GPU em que o buffer do frame fica sobrecarregado. A CPU precisa aguardar a GPU, o que causa um atraso perceptível entre a entrada do jogador e o efeito que ela causa na tela.
Para saber se você pode melhorar o ritmo dos frames do jogo, siga estas etapas:
Gere um relatório do Systrace que inclua as categorias gfx e input . Essas categorias abrangem medidas especialmente úteis para determinar a latência entre o toque e a exibição. Verifique a seção SurfaceView do relatório do Systrace. Um buffer sobrecarregado faz com que os números de desenhos pendentes no buffer oscilem entre 1 e 2, conforme mostrado na Figura 5: Figura 5. Relatório do Systrace mostrando um buffer sobrecarregado que, periodicamente, fica cheio demais para aceitar comandos de desenho.
Para diminuir essa inconsistência no ritmo de frames, realize as ações descritas nas seções a seguir:
Integrar a API Android Frame Pacing ao jogo
A API Android Frame Pacing ajuda a realizar trocas de frame e definir um intervalo de troca para que o jogo mantenha um frame rate mais consistente.
Reduzir a resolução dos recursos do seu jogo que não são de IU
As telas dos dispositivos móveis modernos possuem muito mais pixels do que o jogador consegue enxergar. Portanto, não há problema em reduzir a resolução de modo que um conjunto de 5 até 10 pixels contenha apenas uma cor. Considerando a estrutura da maioria dos caches de telas, é recomendável reduzir a resolução em apenas uma dimensão.
No entanto, não reduza a resolução dos elementos de IU do jogo. É importante preservar a espessura da linha nesses elementos para manter uma área de toque suficientemente grande para todos os jogadores.
Observação: como a GPU precisa de certo tempo para redimensionar os recursos, é melhor realizar qualquer operação de redução de resolução na etapa de pós-processamento do jogo, caso ela exista.
Estabilidade de renderização
Quando o SurfaceFlinger é fixado em um buffer de exibição para mostrar uma cena no jogo, a atividade da CPU aumenta temporariamente. Se esses picos de atividade da CPU ocorrerem de forma irregular, será possível notar a renderização lenta do jogo. O diagrama na Figura 6 representa a causa desse problema:
Figura 6. Relatório do Systrace mostrando como um frame pode perder uma janela de Vsync.
Se um frame começar a ser desenhado tarde demais, ainda que apenas por alguns milésimos de segundo, ele poderá perder a próxima janela de exibição. Nesse caso, o frame precisa esperar pela próxima janela de Vsync para ser exibido (33 milésimos de segundo para um jogo a 30 QPS), o que causa um atraso perceptível para o jogador.
Para solucionar esse problema, use a API Android Frame Pacing, que sempre exibe um novo frame em um wavefront de VSync.
Estado da memória
Quando o jogo é executado por um longo período, o dispositivo pode apresentar erros de falta de memória.
Nesse caso, verifique a atividade da CPU em um relatório do Systrace e observe com que frequência o sistema está chamando o daemon kswapd . Se houver muitas chamadas durante a execução do jogo, analise mais detalhadamente o gerenciamento e a limpeza da memória.
Para saber mais, consulte Gerenciar a memória em jogos.
Estado da linha de execução
Ao navegar pelos elementos típicos de um relatório do Systrace, você poderá ver quanto tempo determinada linha de execução passou em cada estado possível selecionando a linha de execução no relatório, conforme mostrado na Figura 7:
Figura 7. Relatório do Systrace mostrando como um resumo do estado da linha de execução é exibido quando ela é selecionada.
Como mostrado na Figura 7, você pode descobrir se as linhas de execução do jogo não estão no estado "running" ou "runnable" com a frequência esperada. A lista a seguir mostra diversos motivos comuns que podem fazer com que uma linha de execução passe para um estado incomum periodicamente:
Caso uma linha de execução esteja suspensa por um longo período, ela pode estar sofrendo contenção de bloqueio ou aguardando uma atividade da GPU.
Se uma linha de execução é bloqueada constantemente na E/S, isso significa que você está lendo muitos dados do disco de uma vez só ou que seu jogo está com uma sobrecarga.
Observação: os dispositivos mais sofisticados costumam ser limitados pela CPU com muito mais frequência do que pela E/S. No entanto, caso o jogo seja executado em dispositivos básicos, é recomendável implementar algumas otimizações secundárias à capacidade de E/S.
Outros recursos
Para saber mais sobre como melhorar o desempenho do jogo, consulte as fontes a seguir:
Vídeos