[e.....n]

Protip #css.

Nigdy, ale to nigdy nie używajcie "transition" dla elementów ![]() jeżeli to ma działać w webview.

Gdy img ma zaaplikowane jakieś animacje czy inne rzeczy, silnik renderujący jest ciągle w gotowości i nigdy nie usunie tych obrazków z pamięci przez cały czas gdy obrazek jest w DOM.

Dla porównania, czyste obrazki są dynamicznie wyrzucane z pamięci gdy tylko obrazek znajdzie się daleko od viewportu.

Nie dziękujcie, to tylko 6 godzin szukania dlaczego nasza aplikacja #!$%@? się przy infinite scrollu na liście wyszukiwania itemów w aplikacji sklepowej.

#programowanie #webdev #javascript

[Pietras55]

@esen: Dzięki za info :) Problem dotyczy też elementów z obrazkami w tle?

[e.....n]

@Pietras55: Prawdopodobnie tak, ale tego nie testowaliśmy. Na razie jako hotfix wywaliłem opacity:0 i transition: opacity... z css, żeby nie wywalało aplikacji.

Wygląda to tak, że gdy jakaś funkcja jest zaaplikowana na obrazek, silnik renderujący wydaje się być ciągle w gotowości na animowanie tego elementu. Zakładam, że to jest celowe (nie bug webkita).

Swoją drogą nie wiedziałem, że webkit jest na tyle mądry, że elementy które ma poza viewportem wywala z

[Melcma]

@esen: masz jakies zrodlo?

[e.....n]

@Melcma: Ja jestem źródło. Szukałem przyczyn w internetach wcześniej, ale problem jest na tyle specyficzny, że się w sumie nie dziwię że nic nie ma.

Na początku pousuwałem jakieś callbacki które były nadmiarowe i dalej problem występował. Dopiero jak dotarłem to tego transition to byłem w stanie ustalić powtarzalność (z transition - GC nie działa poprawnie, bez transition - działa).

Testowałem też z obrazkami które sam dodawałem w vanillajs (200 obrazków

[e.....n]

Aha i jeszcze dla tych co nie mają dużego doświadczenia w developingu na osx. Jeśli macie dostęp do xcode to macie też dostęp do fajnych narzędzi jak np. "leaks" albo "memory cośtam" który pięknie listuje na co idzie pamięć i co z nią robi system. Dostęp do tego jest nietypowy, bo albo trzeba otworzyć paczkę z xcode i szukać "instruments", albo prawym klikiem na otwarty xcode i Tools -> instruments.

[kary_koniu]

@esen: Shadow DOM by pewnie rozwiązał sprawę. Mógłbyś jeszcze samemu sprawdzać czy obrazek jest już niewidoczny i kasować go z DOMu trzymając go przy tym w jakiejś zmiennej i wstawiać znowu kiedy trzeba, ale kij wie jak z perf wtedy
Anyway, dzięki za podpowiedź ;)

[e.....n]

@kary_koniu: Shadow chyba by nic nie rozwiązał, bo dalej aplikacja ma ten sam limit pamięci. Chyba, że czegoś nie wiem (a jeśli chodzi o shadow DOM to mało wiem).

[Marmite]

@esen: Występuje w każdej przeglądarce czy tylko w jakiejś specyficznej?

[e.....n]

@Marmite: na pewno na safari z iOS. Innych jeszcze nie testowałem.

[regis3]

@Marmite: @esen:

Nie jestem pewien ale problemem nie jest transition a opacity ( http://www.sitepoint.com/introduction-to-hardware-acceleration-css-animations/ ) gdyż tworzy on 2. warstwę do renderowania sprzętowego.

To jest dość znana przypadłość i pewien feature. Po prostu transform, opacity i filter, powoduje utworzenie nowej warstwy renderowanej hardwarowo i to ona nie jest zwalniana. Często używa się to w odwrotną stronę aby włączyć taki sposób renderowania (transform na 0).

Jest pewna propozycja rozwiązania aby transform

[e.....n]

@regis3: o. Dzięki serdeczne za poprawne wyjaśnienie. ++

[H....._]

Nigdy, ale to nigdy nie używajcie "transition" dla elementów ![]() jeżeli to ma działać w webview.

@esen: Może głupie pytanie, ale czy użycie tego na Div>img rozwiązuje problem?

[e.....n]

@HitmaNeK_: chyba nie.

[Jurigag]

@esen: ty, czy to samo może dziać mi się w operze na androidzie ? tylko że urządzenie dostaje restart ( ͡° ʖ̯ ͡°)

[e.....n]

@Jurigag: restartu nie powinno być, bo aplikacje powinny działać w sandboxie, ale to android więc nigdy nie wiadomo.