🔧 Optymalizacje systemowe – część 1
Pracując nad kolejną wersją mojego systemu HA Tablet – autorskiego buildu AOSP przeznaczonego dla tabletów ściennych zasilanych przez PoE, bez baterii i z nastawieniem na maksymalną responsywność – skupiłem się na dwóch obszarach:
- eliminacji opóźnień przy ponownym uruchamianiu interfejsu Home Assistant,
- oraz 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 HA była całkowicie przeładowywana. Oznaczało to, że użytkownik po odblokowaniu musiał kilka sekund czekać na ponowne załadowanie interfejsu:
Aby zrozumieć, co dzieje się „pod maską”, skorzystałem z Chromium DevTools oraz Wiresharka.
Pozwoliło mi to dokładnie prześledzić działanie WebSocketów i potwierdzić, że:
- po wyłączeniu ekranu WebView spowalniało działanie timerów JavaScript (m.in. tych wykorzystywanych do mechanizmu ping/pong w WebSocketach),
- a po około 5 minutach bezczynności Chromium zamykało połączenie WebSocket.
To zachowanie wynikało z wewnętrznych mechanizmów Chromium – tzw. background throttling – które mają sens na urządzeniach mobilnych, ale w przypadku panelu ściennego z zasilaniem PoE są zupełnie niepożądane. Korzystałem 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 wykorzystując najnowsze źródła 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,
- oraz dodałem możliwość testowania dodatkowych flag i opcji Chromium pod kątem integracji z Home Assistantem.
Efekt?
Po wybudzeniu ekranu panel zachowuje aktywne połączenie z HA, a interfejs użytkownika jest natychmiast dostępny – 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,
- oraz 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=false
Ostatni parametr (ro.surface_flinger.protected_contents=false) okazał się konieczny, ponieważ w systemie pojawiała się informacja że:
„protectedMemoryFeatures”: {
„protectedMemory”: 0.0
}
To oznacza, że sterownik nie obsługuje rozszerzenia VK_KHR_protected_memory, czyli tzw. protected content / protected memory.
W praktyce oznaczało to, że SurfaceFlinger próbował uruchamiać renderowanie w trybie zabezpieczonym, którego sterownik Mali / Rockchip nie implementuje – stąd konieczność ręcznego wyłączenia tej funkcji.
🧠 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 (VkPhysicalDeviceFeatures2, VkPhysicalDeviceProtectedMemoryFeatures, VkExtensionProperties, itp.).
Dzięki temu możliwa jest pełna diagnostyka możliwości sterownika i jego rozszerzeń.
🧩 Podsumowanie
Nowe zmiany znacząco przyspieszają działanie interfejsu HA po wybudzeniu ekranu i otwierają drogę do dalszych eksperymentów z Vulkanem na urządzeniach z Rockchip/Mali, co widać na poniższym wideo:
W kolejnych krokach planuję:
- dalszą optymalizację silnika webview i usług systemowych AOSP,
- testy Vulkan/Skia w kontekście interfejsu HA,
- 🆕 testy modelu 8 calowego z nowym, 8-rdzeniowym procesorem, który powinien zaspokoić potrzeby bardziej wymagających użytkowników.