Zarządzanie buforem ramki klienta

Od Androida 13 nowe framebuffery używane podczas komponowania przez klienta są przydzielane, gdy tylko zmieni się rozdzielczość wyświetlacza. Ta alokacja jest wykonywana przez SurfaceFlinger w następnym cyklu unieważnienia po zmianie rozdzielczości.

Zarządzanie ramką obrazu podczas przełączania rozdzielczości

Zmiany rozdzielczości mają miejsce z jednego z tych 2 scenariuszy:

  • Zdarzenie hotplug, które jest inicjowane przez sterownik sprzętowy (HWC) i występuje podczas przełączania się z jednego wyświetlacza zewnętrznego na inny wyświetlacz zewnętrzny o innej domyślnej rozdzielczości.

    Podczas zdarzenia „hotplug” uchwyty starych buforów ramek są zwalniane po cofnięciu lokalizacji starych danych wyświetlacza.

  • Przełączanie trybu wyświetlania inicjowane przez SurfaceFlinger, które występuje, gdy użytkownik zmienia rozdzielczość za pomocą ustawień użytkownika lub gdy aplikacja zmienia rozdzielczość za pomocą preferredDisplayModeId.

    Podczas przełączania trybu wyświetlania uchwyty do istniejących framebufferów klienta są uwalniane przez SurfaceFlingera przed wywołaniem funkcji setActiveConfig lub setActiveConfigWithConstraints.

Aby uniknąć katastrofalnych problemów, takich jak fragmentacja pamięci, na urządzeniach, które nie zarezerwowały wystarczającej ilości pamięci dla starych i nowych framebufferów, ważne jest, aby HWC przestało używać starych framebufferów i zwolnić wszystkie uchwyty tych framebufferów w tych przypadkach:

Zwolnienie uchwytów umożliwia pełne zwolnienie pamięci bufora ramki przed przydzieleniem nowych buforów ramki, które SurfaceFlinger wykonuje podczas następnego cyklu unieważniania.

Rekomendacje dotyczące zarządzania framebufferem

Jeśli HWC nie zwolni uchwytów starych framebufferów na czas, przydzielenie nowego framebuffera nastąpi przed zwolnieniem starego. Może to powodować katastrofalne problemy, gdy nowy przydział nie powiedzie się z powodu fragmentacji lub innych problemów. Co gorsza, jeśli HWC w ogóle nie zwolni tych uchwytów, może dojść do wycieku pamięci.

Aby uniknąć katastrofalnych błędów przydzielania, postępuj zgodnie z tymi zaleceniami:

  • Jeśli HWC musi nadal używać starych buforów ramki klienta do czasu udostępnienia nowych buforów ramki klienta, należy zarezerwować wystarczającą ilość pamięci dla starych i nowych buforów ramki oraz ewentualnie uruchomić algorytmy defragmentacji na przestrzeni pamięci bufora ramki.

  • Przydziela osobny pulę pamięci dla framebufferów, która jest oddzielona od reszty pamięci bufora graficznego. To ważne, ponieważ między realizacją a relokacją buforów klatek proces firmy zewnętrznej może próbować przydzielić pamięć graficzną. Jeśli ten sam pulę pamięci graficznej wykorzystuje bufor ramki, a pamięć graficzna jest pełna, proces zewnętrzny może zająć pamięć graficzną przydzieloną wcześniej przez bufor ramki, pozostawiając w ten sposób niewystarczającą ilość pamięci na potrzeby bufora ramki lub powodując fragmentację przestrzeni pamięci.

Testowanie zarządzania framebufferem

Producenci OEM powinni przetestować prawidłowe zarządzanie pamięcią buforową klienta na różnych przełącznikach rozdzielczości dla swojego urządzenia, jak opisano poniżej:

  • W przypadku zdarzeń typu „hotplug” wystarczy odłączyć i ponownie podłączyć 2 różne wyświetlacze o różnych rozdzielczościach.

  • W przypadku przełączania trybów użyj testu ModeSwitchingTestActivity weryfikatora CTS, aby zainicjować przełączenie trybu w celu przetestowania zachowania pamięci framebuffera. Ten test może wizualnie zidentyfikować problemy, które są trudne do wykrycia za pomocą programów.