Wallpanel OS
OptymalizacjeOptymalizacje systemowe - część 1
Optymalizacja WebView, utrzymanie połączenia WebSocket z Home Assistant i pierwsze prace nad renderowaniem Vulkan w AOSP.
Pracując nad kolejną wersją systemu HA Tablet, autorskiego buildu AOSP przeznaczonego dla tabletów ściennych zasilanych przez PoE, skupiłem się na dwóch obszarach:
- eliminacji opóźnień przy ponownym uruchamianiu interfejsu Home Assistant,
- testach i aktywacji wsparcia dla Vulkan w module renderowania Androida.
Problem z ponownym ładowaniem strony Home Assistant
Jednym z najbardziej irytujących efektów w działaniu panelu ściennego było to, że po wygaszeniu i ponownym włączeniu ekranu strona Home Assistant była całkowicie przeładowywana. Po odblokowaniu użytkownik musiał czekać kilka sekund na ponowne załadowanie interfejsu.
Aby zrozumieć, co dzieje się pod maską, skorzystałem z Chromium DevTools oraz Wiresharka. Pozwoliło mi to prześledzić działanie WebSocketów i potwierdzić, że:
- po wyłączeniu ekranu WebView spowalniało działanie timerów JavaScript, między innymi tych wykorzystywanych do mechanizmu ping/pong w WebSocketach,
- po około 5 minutach bezczynności Chromium zamykało połączenie WebSocket.
To zachowanie wynikało z wewnętrznych mechanizmów Chromium, czyli background throttlingu. Ma to sens na urządzeniach mobilnych, ale w przypadku panelu ściennego z zasilaniem PoE jest niepożądane. Korzystałem wtedy z domyślnego silnika Chromium WebView w wersji 139.0.7258.143.
Własna wersja WebView
Aby wyeliminować problem, stworzyłem własną wersję silnika WebView na bazie nowszych źródeł w wersji 142.0.7424.0, w której:
- wyłączyłem throttling timerów dla wybranych kontekstów,
- usunąłem ograniczenia zamykające WebSockety w tle,
- dodałem możliwość testowania dodatkowych flag i opcji Chromium pod kątem integracji z Home Assistant.
Efekt jest prosty: po wybudzeniu ekranu panel zachowuje aktywne połączenie z Home Assistant, a interfejs użytkownika jest dostępny od razu, bez ponownego ładowania strony i oczekiwania na reconnect WebSocketów.
Włączenie Vulkan
Drugim obszarem prac było uruchomienie renderowania przez Vulkan zamiast klasycznego OpenGL ES. Przejście na Vulkan przynosi kilka zauważalnych korzyści:
- lepsze zarządzanie pamięcią GPU,
- niższe narzuty CPU przy renderowaniu interfejsu,
- wyższą stabilność i wydajność biblioteki Skia wykorzystywanej przez Androida.
Aby aktywować Vulkan, dodałem do build.prop następujące wpisy:
ro.hwui.use_vulkan=true
debug.renderengine.backend=skiavk
ro.surface_flinger.protected_contents=falseOstatni parametr, ro.surface_flinger.protected_contents=false, okazał się konieczny, ponieważ w systemie pojawiała się informacja:
{
"protectedMemoryFeatures": {
"protectedMemory": 0.0
}
}Oznacza to, że sterownik nie obsługuje rozszerzenia VK_KHR_protected_memory, czyli tak zwanego protected content / protected memory. W praktyce SurfaceFlinger próbował uruchamiać renderowanie w trybie zabezpieczonym, którego sterownik Mali / Rockchip nie implementuje.
Dostosowanie kodu źródłowego
Podczas uruchamiania Vulkan napotkałem dodatkowy problem: sterownik Rockchip/Mali DDK błędnie deklaruje obsługę vkGetDeviceQueue2, mimo że faktycznie jej nie wspiera. System raportuje Vulkan 1.1, ale funkcja działa poprawnie tylko przy klasycznym vkGetDeviceQueue().
Aby to obejść, zmodyfikowałem źródło SkiaVkRenderEngine.cpp, dodając fallback do starszego wywołania i rozbudowane logowanie struktur kontekstu Vulkan, takich jak VkPhysicalDeviceFeatures2, VkPhysicalDeviceProtectedMemoryFeatures i VkExtensionProperties.
Podsumowanie
Nowe zmiany znacząco przyspieszają działanie interfejsu Home Assistant po wybudzeniu ekranu i otwierają drogę do dalszych eksperymentów z Vulkanem na urządzeniach z Rockchip/Mali.
W kolejnych krokach planowałem dalszą optymalizację silnika WebView i usług systemowych AOSP, testy Vulkan/Skia w kontekście interfejsu Home Assistant oraz testy modelu 8-calowego z nowszym, 8-rdzeniowym procesorem.
