A partir do Android 13, novos framebuffers, usados durante a composição do cliente , são alocados sempre que a resolução da tela muda. Essa alocação é executada pelo SurfaceFlinger no próximo ciclo de invalidação após uma alteração de resolução.
Gerenciamento de framebuffer durante trocas de resolução
As alterações de resolução ocorrem devido a um dos dois cenários a seguir:
Um evento de hotplug , iniciado pelo Hardware Composer (HWC), que ocorre ao trocar de um monitor externo para outro monitor externo com uma resolução padrão diferente.
Durante um evento de hotplug, os identificadores dos framebuffers antigos são liberados quando os dados de exibição antigos são desalocados.
Uma troca de modo de exibição iniciada por SurfaceFlinger, que ocorre quando o usuário altera a resolução com configurações do usuário ou um aplicativo altera a resolução com
preferredDisplayModeId.Durante uma troca de modo de exibição, os identificadores para framebuffers de cliente existentes são liberados por SurfaceFlinger antes de chamar
setActiveConfigousetActiveConfigWithConstraints.
Para evitar problemas catastróficos, como fragmentação de memória, em dispositivos que não reservam memória suficiente para os framebuffers antigos e novos, é fundamental que o HWC pare de usar os framebuffers antigos e libere quaisquer handles para esses framebuffers conforme mostrado nos seguintes casos:
Para eventos hotplug, imediatamente antes de chamar
onHotplug.Para opções de modo, imediatamente após a chamada para
setActiveConfigousetActiveConfigWithConstraints.
A liberação dos manipuladores permite que a memória do framebuffer seja totalmente desalocada antes da alocação de novos framebuffers que o SurfaceFlinger executa durante o próximo ciclo de invalidação .
Recomendações para gerenciamento de framebuffer
Se o HWC não liberar manipulações para framebuffers antigos a tempo, a nova alocação de framebuffer ocorre antes da antiga desalocação de framebuffer. Isso pode causar problemas catastróficos quando a nova alocação falha devido à fragmentação ou outros problemas. Pior ainda, se o HWC não liberar esses identificadores, pode ocorrer um vazamento de memória.
Para evitar falhas de alocação catastróficas, siga estas recomendações:
Se o HWC precisar continuar usando os antigos framebuffers do cliente até que os novos framebuffers do cliente sejam fornecidos, é fundamental reservar memória suficiente para os framebuffers antigos e novos e, possivelmente, executar algoritmos de desfragmentação no espaço de memória do framebuffer.
Aloque um pool de memória dedicado para os framebuffers separados do restante da memória do buffer gráfico. Isso é importante porque, entre a desalocação e a realocação dos framebuffers, um processo de terceiros pode tentar alocar a memória gráfica. Se o mesmo pool de memória gráfica for usado pelo framebuffer e se a memória gráfica estiver cheia, o processo de terceiros pode ocupar a memória gráfica previamente alocada por um framebuffer, deixando memória insuficiente para a realocação do framebuffer ou possivelmente fragmentando o espaço de memória .
Testar gerenciamento de framebuffer
Os OEMs são aconselhados a testar o gerenciamento adequado de memória do framebuffer do cliente em switches de resolução para seus dispositivos, descritos a seguir:
Para eventos hotplug, basta desconectar e reconectar dois monitores diferentes com resoluções diferentes.
Para comutadores de modo, use o teste
ModeSwitchingTestActivityCTS Verifier para iniciar um comutador de modo para testar o comportamento da memória do framebuffer. Esse teste pode identificar visualmente problemas que são difíceis de detectar programaticamente.