Android System WebView – co to jest i jak działa?

Android System WebView to systemowy komponent oparty na silniku Chromium, który pozwala zainstalowanym aplikacjom na wyświetlanie treści internetowych bezpośrednio w ich własnym interfejsie bez otwierania zewnętrznej przeglądarki. Działa on jako wbudowany mechanizm renderujący, tłumaczący kod HTML, CSS i JavaScript na gotowy widok zintegrowany z oprogramowaniem telefonu.

Piszę ten tekst zaraz po nocnej zmianie. Znowu sypnęła nam się produkcja we wtorek nad ranem, bo jedna z wtyczek w naszej firmowej aplikacji przestała dogadywać się z nową wersją tego komponentu. Prawda jest zresztą absolutnie taka, że większość użytkowników smartfonów dowiaduje się o istnieniu tego modułu dopiero wtedy, gdy coś nagle przestaje działać. Awarie potrafią położyć połowę usług na urządzeniu. Telefon wariuje. Aplikacje bankowe wyłączają się sekunda po uruchomieniu. Komunikatory wyrzucają do ekranu głównego. Użytkownik widzi czarny ekran i panikuje.

Zmieniliśmy te zasady na robocie lata temu. Kiedyś WebView było zaszyte głęboko w kodzie samego systemu Android. Aktualizacja wymagała wydania nowej wersji całego oprogramowania przez producenta telefonu. To był koszmar dla bezpieczeństwa. Google w końcu poszło po rozum do głowy i wydzieliło ten element jako osobną aplikację dostępną w sklepie Play. Zyskaliśmy możliwość łatania dziur na bieżąco. Straciliśmy nerwy, bo każda wadliwa paczka wypuszczona przez deweloperów z Mountain View potrafi teraz zepsuć telefony milionom ludzi w jeden wieczór.

Dlaczego mój telefon ciągle aktualizuje Android System WebView?

Widzę to pytanie na forach technicznych bez przerwy. Ludzie wchodzą w sklep Play, patrzą na listę pobierania i widzą ten sam proces instalacji kilka razy w miesiącu. Zastanawiacie się zresztą, dlaczego to pobiera się tak często i zżera wam transfer danych? Sam się nad tym borykałem dzisiaj u siebie we wtorek, analizując logi z serwera.

Powód jest bardzo prozaiczny. Moduł ten opiera się w całości na kodzie źródłowym przeglądarki Chrome. Silnik Chromium ma ogromną powierzchnię ataku. Każdego dnia badacze cyberbezpieczeństwa znajdują nowe luki w przetwarzaniu skryptów JavaScript. Google musi wypuszczać łatki. Wrzucają poprawkę do Chrome, a chwilę później ta sama poprawka trafia do WebView. Zdecydowana większość tych aktualizacji to proste łatanie dziur, o których nikt głośno nie mówi przed publikacją poprawki, by nie ułatwiać pracy hakerom. Brak aktualizacji oznacza dziurawy telefon.

Dobrym pomysłem jest pozostawienie automatycznych aktualizacji dla tej konkretnej paczki. Ręczne blokowanie pobierania to proszenie się o kłopoty. Wycieki danych z sesji logowania zdarzają się regularnie. Złośliwy kod na stronie internetowej załadowanej wewnątrz czytnika RSS może wykraść ciasteczka sesyjne. Zaktualizowany silnik blokuje takie próby. Stara wersja przepuszcza je bez mrugnięcia okiem.

Zwróćcie uwagę na dwa konkretne powody tej częstotliwości:

• Eliminacja błędów renderowania układu stron (CSS flexbox i grid często się psują na mobilkach).
• Wdrażanie nowych standardów WebGL dla gier przeglądarkowych ładowanych wewnątrz apek.

I tyle. Żadnej magii. Po prostu brutalna, codzienna walka z błędami w kodzie.

Jakie dokładnie aplikacje korzystają z tego komponentu?

Prawie wszystkie. A na pewno te, w których spędzasz najwięcej czasu. Architektura oprogramowania mobilnego mocno się zmieniła. Mało komu chce się pisać natywne widoki dla każdego ekranu.

Weźmy pod lupę lokalne aplikacje. Program do kupowania biletów komunikacji miejskiej w Warszawie czy Krakowie. Myślisz, że regulamin przewoźnika, polityka prywatności albo widok mapy z rozkładem jazdy to natywny kod Javy lub Kotlina? Skądże. To po prostu zwykła strona internetowa wygenerowana na serwerze i wstrzyknięta w ramkę wewnątrz aplikacji. Ta ramka to właśnie WebView. Deweloperzy oszczędzają czas. Zamiast budować widok od zera, ładują URL.

Zajrzyjmy do innych sektorów:

• Aplikacje bankowe ładują w ten sposób formularze kontaktowe i tabele opłat.
• Czytniki wiadomości (Feedly, Flipboard) używają tego do formatowania artykułów pobranych z sieci.
• Komunikatory internetowe wyświetlają tak podgląd linków przesyłanych w wiadomościach.
• Aplikacje sklepów odzieżowych to często w 90% zwykłe strony mobilne ubrane w ikonkę na pulpicie.

Zrobiliśmy na wdrożeniu eksperyment w zeszłym roku. Próbowaliśmy przepisać małą aplikację e-commerce całkowicie na kod natywny, pozbywając się widoków webowych. Czas pracy zespołu wzrósł o bez mała prawie pięćdziesiąt procent na plusie uderzając do przodu u wyników kosztowych. Zrezygnowaliśmy. Przeglądarka osadzona w systemie jest po prostu tańsza w utrzymaniu dla biznesu.

Czy można bezpiecznie odinstalować lub wyłączyć Android System WebView?

Nie. Nawet o tym nie myśl.

Użytkownicy często szukają sposobów na odzyskanie pamięci w starych smartfonach. Wchodzą w ustawienia, widzą aplikację zajmującą kilkaset megabajtów i klikają “Wyłącz”. To najszybsza droga do uszkodzenia systemu. Telefon nie wybuchnie, ale korzystanie z niego stanie się koszmarem.

Wyłączenie tego modułu powoduje natychmiastowe odcięcie zewnętrznych aplikacji od silnika renderującego. Co to w praktyce oznacza? Otwierasz aplikację pogodową, a zamiast mapy radarowej dostajesz szary kwadrat i komunikat o błędzie. Próbujesz zalogować się do usługi kurierskiej za pomocą konta Google. Okno logowania (które jest stroną webową) w ogóle się nie pojawia. Aplikacja czeka w nieskończoność na odpowiedź z systemu i w końcu system operacyjny ubija proces z powodu braku odpowiedzi (ANR – Application Not Responding).

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj dla wszystkich modeli z Androidem 14, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku, starsze telefony radziły sobie z tym jeszcze gorzej. W Androidzie 7, 8 i 9 wyłączenie WebView często prowadziło do pętli restartów interfejsu systemowego. Teraz system po prostu ignoruje żądania aplikacji, co kończy się ich zawieszeniem.

Zresztą, spróbujcie sami napisać apkę bez tego. Zderzycie się ze ścianą płaczu. DZIWNE rzeczy dzieją się w logach, kiedy system traci swój główny renderer. Użytkownik końcowy dostaje po prostu frustrację na tacy.

Co zrobić, gdy WebView powoduje awarie i zamykanie aplikacji?

Zdarzają się sytuacje kryzysowe. Marzec 2021 roku przeszedł do historii deweloperów mobilnych. Google wypuściło wadliwą aktualizację. Zepsuła ona ładowanie stron w aplikacjach na całym świecie. Gmail padał. Aplikacje giełdowe padały. Setki tysięcy ludzi myślało, że zepsuli im telefony. My u nas w biurze odbieraliśmy telefony od wściekłych klientów od 6 rano. Nikt nie wiedział, co się dzieje.

Jeśli aplikacje masowo się zamykają bez powodu, to prawie zawsze wina tego komponentu. Rozwiązanie jest brutalnie proste i wymaga kilku kliknięć.

• Wejdź w Ustawienia systemu, a potem w zakładkę Aplikacje.
• Znajdź na liście “Android System WebView”.
• Kliknij trzy kropki w prawym górnym rogu i wybierz “Odinstaluj aktualizacje”.
• Zrestartuj telefon.

To cofa moduł do wersji fabrycznej wgranej przez producenta sprzętu. Błędy znikają. Pamiętaj tylko, żeby za kilka dni wejść do sklepu Play i zaktualizować go ponownie, gdy Google wypuści poprawioną paczkę. Siedzenie na fabrycznej wersji miesiącami wystawia cię na ataki z sieci. Zmieniliśmy te zasady na robocie u klientów firmowych, wdrażając systemy MDM (Mobile Device Management), które same opóźniają instalację łatek o 48 godzin. Czekamy, aż inni przetestują błędy na sobie.

Jakie są techniczne różnice między WebView a zwykłą przeglądarką Chrome?

Na pierwszy rzut oka to to samo. Pod maską siedzi ten sam silnik V8 do mielenia JavaScriptu i ten sam Blink do rysowania pikseli na ekranie. Architektura obu rozwiązań różni się jednak drastycznie, bo mają do wykonania zupełnie inną pracę w środowisku operacyjnym.

Chrome to samodzielny kombajn. Ma własny interfejs, zarządzanie kartami, synchronizację zakładek, menedżer haseł i obsługę rozszerzeń. Działa we własnym, odizolowanym procesie (a właściwie w wielu procesach piaskownicy). Zarządza własną pamięcią cache i historią przeglądania.

WebView to z kolei naga biblioteka. Surowy silnik pozbawiony paska adresu i przycisków nawigacyjnych. Jest wstrzykiwany bezpośrednio w proces aplikacji hostującej. Jeśli aplikacja bankowa ładuje widok webowy, to ten widok dzieli limity pamięci RAM z resztą tej aplikacji bankowej. Jeśli strona internetowa załaduje skrypt ważący 50 MB, to pamięć zostanie odjęta od puli aplikacji. To generuje potężne problemy optymalizacyjne dla twórców oprogramowania.

Z technicznego punktu widzenia, gdy inicjalizujemy ten moduł w kodzie, musimy ręcznie skonfigurować mnóstwo rzeczy, które Chrome robi domyślnie. Musimy włączyć obsługę JavaScriptu (domyślnie jest wyłączona ze względów bezpieczeństwa). Musimy zdecydować, czy pozwalamy na dostęp do lokalnej pamięci telefonu. Musimy napisać własne mosty komunikacyjne między kodem JS na stronie a natywnym kodem Java w telefonie. To wymaga czasu i precyzji.

W jaki sposób programiści implementują ten moduł w kodzie?

Praca z tym narzędziem przypomina czasem rzeźbienie w mydle. Od strony kodu to zaledwie kilka linijek, ale konfiguracja zachowań pożera godziny pracy. Wrzucasz komponent do pliku XML z układem ekranu, a potem w klasie aktywności podpinasz do niego adres URL.

Problem polega na komunikacji. Strona webowa żyje w swoim świecie dokumentu DOM, a telefon żyje w świecie sprzętowym. Co jeśli przycisk na stronie internetowej ma włączyć wibracje w telefonie? Przeglądarka sama z siebie nie ma takich uprawnień.

Musimy wstrzykiwać interfejsy Javascript. Tworzymy specjalną klasę w Javie, oznaczamy jej metody adnotacją `@JavascriptInterface` i rejestrujemy ją w ustawieniach widoku. Wtedy kod JS na stronie może wywołać funkcję `Android.zrobWibracje()`. Brzmi super, prawda? Ale to potężna dziura w zabezpieczeniach. Jeśli załadujesz obcą, złośliwą stronę do tak skonfigurowanego modułu, haker może wywołać dowolny kod natywny na twoim telefonie. Dlatego w środowiskach produkcyjnych stosujemy białe listy domen i rygorystyczne sprawdzanie certyfikatów SSL.

Sam proces debugowania to też osobna historia. Trzeba podłączyć telefon kablem do komputera, odpalić desktopowego Chrome’a, wpisać `chrome://inspect` i łapać logi konsoli z telefonu. O ile deweloper aplikacji w ogóle włączył flagę `setWebContentsDebuggingEnabled`. Jeśli nie włączył, jesteś ślepy. Zgadujesz, dlaczego formularz nie chce się wysłać na produkcję we wtorek po południu.

Dlaczego WebView zużywa tak dużo baterii i pamięci RAM?

Zarządzanie zasobami to pięta achillesowa tego rozwiązania. Wszyscy narzekają na drenaż baterii.

Telefony mają określoną pulę pamięci operacyjnej. Aplikacje natywne są kompilowane z myślą o oszczędzaniu tej pamięci. Strony internetowe są pisane dla desktopów z 16 GB RAM. Kiedy ładujesz nowoczesną, ciężką stronę naszpikowaną frameworkami takimi jak React czy Angular wewnątrz mobilnej ramki, procesor telefonu dostaje zadyszki.

Silnik renderujący musi pobrać pliki. Musi zbudować drzewo DOM. Musi przeliczyć style CSS dla każdego elementu na ekranie. Następnie silnik JavaScript kompiluje skrypty w czasie rzeczywistym (JIT – Just In Time compilation). To wszystko wymaga ciągłej pracy procesora na wysokich taktowaniach. Wysokie taktowanie oznacza pobór prądu. Pobór prądu oznacza gorący telefon i spadające procenty baterii.

Kolejna sprawa to wycieki pamięci. (Programiści webowi rzadko przejmują się czyszczeniem pamięci po zamknięciu komponentu). W zwykłej przeglądarce zamykasz kartę i proces zostaje ubity. Pamięć wraca do systemu. W aplikacji mobilnej często ukrywasz widok webowy pod innym ekranem, ale on nadal działa w tle. Skrypty śledzące użytkownika, animacje, pętle zdarzeń – to wszystko mieli dane, zużywając RAM. Jeśli deweloper aplikacji nie wywoła metody `destroy()` na komponencie webowym w odpowiednim momencie cyklu życia aplikacji, ten potwór będzie pożerał zasoby aż do momentu, gdy system sam zabije całą aplikację.

Zmieniliśmy te zasady na robocie, wprowadzając twarde limity ładowania. Zrzucamy procesy webowe z pamięci, gdy tylko użytkownik przejdzie do innej zakładki. Interfejs ładuje się ułamek sekundy dłużej przy powrocie, ale telefony przestają parzyć w dłonie.

Ten cały mechanizm to kompromis. Oddajemy płynność i czas pracy na baterii w zamian za szybkość tworzenia oprogramowania i łatwość aktualizacji treści. Prawda jest zresztą absolutnie taka, że bez tego komponentu połowa współczesnych startupów w ogóle by nie powstała, bo nie stać by ich było na utrzymanie dwóch osobnych zespołów programistów do pisania natywnego kodu na iOS i Androida z osobna. Klepią jeden kod w technologiach webowych, pakują go w ramkę i wysyłają do sklepów. Działa. Zarabia pieniądze.

Gdy następnym razem zobaczysz pasek postępu pobierania z napisem “Android System WebView” na swoim ekranie, nie anuluj go. Ten mały, frustrujący i pożerający RAM kawałek kodu to klej, który trzyma twój cyfrowy ekosystem w jednym kawałku. Sprawdź swoje logi w telefonie, zaktualizuj system i przestań walczyć z wiatrakami. Wejdź w ustawienia już teraz i upewnij się, że masz najnowszą łatkę. Twój telefon podziękuje ci stabilnością, a ty unikniesz oglądania czarnych ekranów przy próbie opłacenia rachunków.

FAQ – Najczęściej zadawane pytania

• Czym dokładnie jest Android System WebView?
  To systemowy komponent oparty na Chrome, który pozwala aplikacjom na wyświetlanie stron internetowych wewnątrz ich własnego interfejsu bez konieczności otwierania zewnętrznej przeglądarki.
• Dlaczego ta aplikacja cały czas się aktualizuje?
  Aktualizacje są wymuszone poprawkami bezpieczeństwa silnika Chromium. Każda nowa luka znaleziona w przeglądarce Chrome wymaga załatania również w module WebView, aby chronić dane użytkownika.
• Czy mogę odinstalować Android System WebView?
  Nie. Odinstalowanie lub wyłączenie tego komponentu spowoduje awarie i natychmiastowe zamykanie się większości aplikacji na telefonie, które polegają na nim do renderowania treści.
• Co zrobić, gdy aplikacje na Androidzie same się wyłączają?
  Najlepszym rozwiązaniem jest wejście w Ustawienia > Aplikacje > Android System WebView i wybranie opcji “Odinstaluj aktualizacje”. Następnie należy uruchomić ponownie telefon i pobrać nową, stabilną wersję ze sklepu Play.
• Czy WebView zużywa dużo baterii?
  Tak, renderowanie ciężkich stron internetowych i wykonywanie kodu JavaScript wewnątrz aplikacji wymaga dużej mocy procesora, co bezpośrednio przekłada się na wyższe zużycie pamięci RAM i szybsze rozładowywanie baterii.
• Czym WebView różni się od Chrome?
  Chrome to pełnoprawna przeglądarka z interfejsem, kartami i izolowanymi procesami. WebView to nagi silnik renderujący wstrzykiwany w proces innej aplikacji, pozbawiony własnego interfejsu graficznego.

Bibliografia

1. Android Developers – https://developer.android.com
2. Chromium Projects – https://www.chromium.org
3. Google Play Help – https://support.google.com/googleplay
4. Android Open Source Project – https://source.android.com