Gestione del framebuffer del client

A partire da Android 13, i nuovi framebuffer, utilizzati durante la composizione del client , vengono allocati ogni volta che cambia la risoluzione dello schermo. Questa allocazione viene eseguita da SurfaceFlinger al successivo ciclo di invalidazione dopo una modifica della risoluzione.

Gestione del framebuffer durante i cambi di risoluzione

Le modifiche alla risoluzione si verificano a causa di uno dei due scenari seguenti:

  • Un evento hotplug , avviato da Hardware Composer (HWC), che si verifica quando si passa da un display esterno a un display esterno diverso con una risoluzione predefinita diversa.

    Durante un evento hotplug, gli handle dei vecchi framebuffer vengono rilasciati quando i vecchi dati di visualizzazione vengono deallocati.

  • Un cambio di modalità di visualizzazione avviato da SurfaceFlinger, che si verifica quando l'utente modifica la risoluzione con user settings o un'app modifica la risoluzione con preferredDisplayModeId .

    Durante un cambio di modalità di visualizzazione, gli handle dei framebuffer del client esistente vengono rilasciati da SurfaceFlinger prima di chiamare setActiveConfig o setActiveConfigWithConstraints .

Per evitare problemi catastrofici, come la frammentazione della memoria, sui dispositivi che non riservano memoria sufficiente per i framebuffer vecchi e nuovi, è fondamentale che HWC smetta di utilizzare i vecchi framebuffer e rilasci eventuali handle a questi framebuffer, come mostrato nei seguenti casi:

Il rilascio degli handle consente la completa deallocazione della memoria del framebuffer prima dell'allocazione di nuovi framebuffer che SurfaceFlinger esegue durante il successivo ciclo di invalidazione .

Raccomandazioni per la gestione del framebuffer

Se HWC non rilascia in tempo gli handle dei vecchi framebuffer, la nuova allocazione del framebuffer avviene prima della vecchia deallocazione del framebuffer. Ciò può causare problemi catastrofici quando la nuova allocazione fallisce a causa della frammentazione o di altri problemi. Ancora peggio, se HWC non rilascia affatto questi handle, può verificarsi una perdita di memoria.

Per evitare errori catastrofici nell'allocazione, seguire questi consigli:

  • Se HWC deve continuare a utilizzare i vecchi framebuffer client finché non vengono forniti i nuovi framebuffer client, è fondamentale riservare memoria sufficiente sia per i framebuffer vecchi che per quelli nuovi ed eventualmente eseguire algoritmi di deframmentazione sullo spazio di memoria del framebuffer.

  • Allocare un pool di memoria dedicato per i framebuffer separato dal resto della memoria del buffer grafico. Questo è importante perché tra la deallocazione e la riallocazione dei framebuffer, un processo di terze parti può tentare di allocare memoria grafica. Se lo stesso pool di memoria grafica viene utilizzato dal framebuffer e se la memoria grafica è piena, il processo di terze parti può occupare la memoria grafica precedentemente allocata da un framebuffer, lasciando così memoria insufficiente per la riallocazione del framebuffer o, eventualmente, frammentando lo spazio di memoria .

Testare la gestione del framebuffer

Si consiglia agli OEM di verificare la corretta gestione della memoria del framebuffer del client attraverso gli switch di risoluzione per il proprio dispositivo, descritti di seguito:

  • Per gli eventi hotplug, è sufficiente scollegare e ricollegare due diversi display con risoluzioni diverse.

  • Per i cambi di modalità, utilizzare il test ModeSwitchingTestActivity CTS Verifier per avviare un cambio di modalità per testare il comportamento della memoria del framebuffer. Questo test può identificare visivamente i problemi difficili da rilevare a livello di codice.