Gerenciamento de framebuffer do cliente

No Android 13 e versões mais recentes, os novos framebuffers, usados durante a composição do cliente, são alocados sempre que a resolução da tela muda. Essa alocação é realizada pelo SurfaceFlinger no próximo ciclo de invalidação após uma mudança de resolução.

Gerenciamento de framebuffer durante mudanças de resolução

As mudanças de resolução ocorrem devido a um dos seguintes cenários:

  • Um evento hotplug, iniciado pelo compositor de hardware (HWC, na sigla em inglês), que ocorre ao trocar de uma tela externa para outra que tem 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 mudança de modo de exibição iniciada pelo SurfaceFlinger, que ocorre quando o usuário muda a resolução com as configurações do usuário, ou um app muda a resolução com preferredDisplayModeId.

    Durante uma mudança de modo de exibição, os identificadores dos framebuffers de clientes são liberados pelo SurfaceFlinger antes de chamar setActiveConfig ou setActiveConfigWithConstraints.

Para evitar problemas catastróficos, como a fragmentação de memória, em dispositivos que não reservam memória suficiente para os framebuffers antigos e novos, é fundamental que o HWC deixe de usar os framebuffers antigos e libere todos os identificadores para esses framebuffers, conforme mostrado nos seguintes casos:

A liberação dos identificadores 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 o gerenciamento de framebuffer

Se o HWC não liberar os identificadores para framebuffers antigos a tempo, a nova alocação de framebuffer vai ocorrer antes da dealocação do framebuffer antigo. Isso pode causar problemas catastróficos quando a nova alocação falhar devido à fragmentação ou outros problemas. Pior ainda, se o HWC não liberar esses identificadores, um vazamento de memória poderá ocorrer.

Para evitar falhas catastróficas de alocação, siga estas recomendações:

  • Se o HWC precisar continuar usando os framebuffers de cliente antigos até que os novos 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 que são separados do resto da memória do buffer gráfico. Isso é importante porque, entre a dealocação e a realocação dos framebuffers, um processo de terceiros pode tentar alocar 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 poderá ocupar a memória gráfica alocada anteriormente por um framebuffer, deixando memória insuficiente para a realocação do framebuffer ou, possivelmente, fragmentando o espaço de memória.

Testar o gerenciamento de framebuffer

Os OEMs são aconselhados a testar o gerenciamento adequado da memória de framebuffer do cliente em interruptores de resolução para o dispositivo, conforme descrito abaixo:

  • Para eventos de hotplug, basta desconectar e reconectar duas telas diferentes com resoluções diferentes.

  • Para alternar entre modos, use o teste do verificador CTS ModeSwitchingTestActivity para iniciar uma troca de modo para testar o comportamento da memória do framebuffer. Esse teste pode identificar visualmente problemas difíceis de detectar programaticamente.