Plazer szyfruje prywatne rozmowy i grupy rdzeniem w Ruście, tym samym co w aplikacjach natywnych, a do przeglądarki rdzeń trafia jako WebAssembly. Szyfrowanie, głos, wideo z efektami tła i ustawienia serwera to dużo kodu, więc przeglądarka pobiera każdą część dopiero wtedy, gdy jest potrzebna. Liczby poniżej pochodzą z pomiaru wersji webowej: zimny start w Chromium bez pamięci podręcznej, każdy plik skompresowany osobno przez gzip -9.
Co i kiedy pobiera przeglądarka
| Część | Po kompresji | Kiedy |
|---|---|---|
| Ekran logowania po polsku, z fontem | 110 kB w 25 plikach | przy pierwszym wejściu |
| Rdzeń szyfrowania, część startowa | 536 kB | przy każdym starcie po zalogowaniu |
| Rdzeń szyfrowania, reszta | 239 kB | przy logowaniu hasłem, rejestracji, parowaniu urządzenia, prywatnych grupach i wysyłce w szyfrowanych rozmowach |
| Rozmyte albo podmienione tło kamery | 3,76 MB: silnik MediaPipe w WebAssembly, model i kod efektu | gdy ktoś pierwszy raz włączy efekt tła |
Sam efekt tła waży 34 razy więcej niż ekran logowania, a kto nie włączy efektu tła, nie pobierze z niego ani bajtu.
Podział według linkera
O tym, co trafia do reszty rdzenia, nie decydują nazwy funkcji. Skrypt podziału czyta relokacje, które linker rust-lld zostawia z flagą --emit-relocs: wywołania, indeksy funkcji w tablicach i adresy danych. Funkcja przechodzi do reszty tylko wtedy, gdy nie prowadzi do niej żadna ścieżka startowa, więc start nigdy nie trafi na brakujący kod. Potem wasm-split z pakietu Binaryen przenosi te funkcje, a wasm-opt optymalizuje każdą część osobno. Pole wiadomości w szyfrowanej rozmowie zaczyna pobierać resztę przy pierwszym wpisanym słowie, więc wysyłka rzadko na nią czeka, a test end-to-end pilnuje, żeby sam start reszty nie pobierał.
Jak powstawał Plazer, opisuje case study, a aplikacje webowe na zamówienie strona aplikacji webowych i PWA.
Czy ten wpis był przydatny?
