PoC-02 — próg awarii przy kompresji

Mierzymy, przy jakim rozmiarze zdjęcia ginie karta — bo zużycia pamięci na iOS nie da się zmierzyć żadną drogą.

Dlaczego próg, a nie pamięć. Safari nie ma ani performance.memory, ani measureUserAgentSpecificMemory() (BCD: oba safari: false), a bez Maca nie ma debuggera. Próg awarii to jednak nie namiastka: zużycie pamięci służyło wyłącznie do wyznaczenia limitu twardego, a próg daje tę wartość bezpośrednio i dokładniej, bo obejmuje realny narzut silnika. Szczegóły w ADR-0017.

To urządzenie

wykrywanie…

Tryb 1 — czasy etapów (realne zdjęcia)

Użyj natywnych zdjęć z telefonu, najlepiej ciemnych i zaszumionych z wnętrza — szum kompresuje się najgorzej i to on wyznacza realny rozmiar wyjściowy. Obrazy generowane nie nadają się do tego pomiaru.

Tryb 2 — próg awarii (wyszukiwanie binarne)

Korzysta z obrazów wygenerowanych przez tools/genimages. Karta będzie ginąć — to jest zamierzone. Po każdej awarii wróć na tę stronę i kliknij „Kontynuuj": algorytm wie, gdzie skończył, bo stan przeżył w IndexedDB.

stan wyszukiwania: wczytywanie…

Porównaj progi wariantu A i B — ich różnica odpowiada na pytanie, czy resizeWidth realnie oszczędza pamięć (Q-03).

Tryb 3 — seria 20 zdjęć

Sprawdza, czy zasoby są zwalniane. Bez pomiaru pamięci wykrywamy to spadkiem wydajności lub awarią w trakcie serii — jeśli dwudzieste zdjęcie ginie przy rozmiarze, który wcześniej przechodził, zwalnianie nie działa.

Wyniki

Log