Wprowadzenie
ShareChat to wiodąca platforma mediów społecznościowych w Indiach, która umożliwia użytkownikom dzielenie się opiniami, dokumentowanie swojego życia i nawiązywanie nowych znajomości w ich języku ojczystym. Inne funkcje to pokoje czatów i wiadomości prywatne, które umożliwiają użytkownikom udostępnianie filmów, żartów, piosenek i innych treści społecznościowych opartych na języku. ShareChat ma na celu zapoczątkowanie rewolucji internetowej w Indiach i zmienia sposób, w jaki kolejny miliard użytkowników będzie korzystać z internetu.
Aplikacja w liczbach
- Ponad 100 mln pobrań
- Ponad 180 milionów aktywnych użytkowników miesięcznie
- Ponad 32 miliony twórców treści
- 15 różnych języków indyjskich,
- ~1,5 mln postów tworzonych dziennie
Wyzwanie
Gdy ShareChat zyskał popularność wśród tysięcy użytkowników dziennie, aplikacja napotkała problem z konsekwentnym dostarczaniem nowych klatek, co prowadziło do długiego czasu reakcji i pogorszenia komfortu użytkowania.
W efekcie w aplikacji wzrosła liczba pominiętych lub opóźnionych klatek (tzw. „zacięć”). Wyeliminowanie tych problemów przez poprawę wolnych i zamrożonych klatek było kluczowe dla zapewnienia wszystkim użytkownikom płynnego działania aplikacji. To również odegra ważną rolę w wydłużeniu czasu spędzanego przez użytkowników w aplikacji, zwiększeniu zaangażowania, a w konsekwencji poprawie oceny ShareChat w sklepie Google Play na Androida.
Jak to zrobili
Zespół ShareChat współpracował z zespołem Google ds. relacji z programistami, aby zmniejszyć liczbę klatek zacinających się i zamrożonych (Jank) w aplikacji, co przyniosło pozytywne efekty biznesowe. W szczególności skupiono się na rozwiązaniu tych problemów:
Wspólna pula widoków RecyclerView – na podstawie profilowania zaobserwowano, że tworzenie różnych obiektów Viewholder trwa dłużej. Aby to zminimalizować, utworzono wspólną pulę widoków RecyclerView. Pomogło to również w usunięciu kosztów tworzenia elementów widoku w przypadku podobnych kart.
Nadmierna liczba przejść układu – dzięki profilowaniu zaobserwowano też, że niektóre obiekty widoku wysyłały dodatkowe żądania requestLayout. Aby zoptymalizować kod, zaktualizowaliśmy go tak, aby pobierał wartość w momencie tworzenia, a nie przy każdym powiązaniu. Dzięki temu uniknęliśmy dodatkowych kosztów związanych z wywołaniem requestLayout.
OverDraw – uproszczono układy, aby zmniejszyć liczbę warstw i usunąć kolory, które były ustawiane osobno dla każdej warstwy.
Spłaszczenie hierarchii – długotrwałą inflację zaobserwowano podczas profilowania i ręcznego sprawdzania wielu ekranów. Aby rozwiązać ten problem, hierarchia została spłaszczona za pomocą ConstraintLayout.
Nadmierne zwiększenie liczby wyświetleń – podczas profilowania wykryto długi czas zwiększania liczby wyświetleń w przypadku niektórych widoków. Te wyświetlenia zostały przekonwertowane na wyświetlenia zastępcze.
Usunięcie z wątku interfejsu zadań o dużym obciążeniu – profiler pozwolił nam zidentyfikować kilka miejsc, w których w wątku głównym wykonywane były zadania o dużym obciążeniu, takie jak tworzenie obiektu SpannableStringBuilder z tagowaniem i stylem każdego powiązania recyclerView, dekodowanie BlurHash itp. Usunęliśmy te zadania z wątku interfejsu i przenieśliśmy je do wątku w tle.
Migracja z Rx na Coroutine – zużycie pamięci również prowadziło do częstych wywołań GC, a liczba wątków była bardzo wysoka (ponad 100 wątków RX). Wiele przypadków użycia zostało przeniesionych do Coroutine, aby rozwiązać te problemy.
Wprowadzenie Coil do wczytywania obrazów – Glide powodował problemy podczas wczytywania obrazów, zwłaszcza w komponentach utworzonych za pomocą Jetpack Compose. Stwierdziliśmy też, że podczas wczytywania obrazów w LazyColumn próg renderowania był wysoki. Te sytuacje doprowadziły do wdrożenia biblioteki Coil do wczytywania obrazów.
Czyszczenie i refaktoryzacja starego kodu – usunięcie starego kodu i eksperymentów pomogło usunąć z interfejsu niepotrzebne ukryte widoki i przepisać niektóre ekrany w lepszy sposób.
Wyniki
Analizując obszary wymagające ulepszeń i identyfikując strategie optymalizacji, ShareChat mogła poprawić ogólne wrażenia użytkowników, zwiększyć współczynnik zaangażowania i oceny w Sklepie Play. Poniżej znajdziesz ilościowe podsumowanie wyników osiągniętych przez ShareChat:
- Około 45% mniej klatek „Powolne renderowanie” w Sklepie Play
- spadek o ok. 30% liczby „zamrożonych” klatek w Sklepie Play;
- Odsetek niestabilnych klatek na każde 10 tys.wyrenderowanych klatek zmniejszył się z 10,72% do 3,98%.
- Przewijanie kanału wzrosło o 60%
- Ogólne oceny w sklepie wzrosły z ok.4,0 do 4,3.
- Wzrost liczby wyświetleń postów o 10%
„W ShareChat naszym celem jest bycie najlepszą aplikacją społecznościową, która zachwyca użytkowników.Oznacza to również, że musimy być najlepsi pod względem wydajności aplikacji. Współpraca z zespołem Google ds. relacji z deweloperami pomogła nam zidentyfikować obszary, w których możemy wprowadzić ulepszenia na najczęściej używanych urządzeniach z niższej półki. Poznaliśmy sprawdzone metody i narzędzia do identyfikowania i naprawiania zamrożonych klatek, zacięć, nadmiernego rysowania i błędów ANR”.
– Vihaan Verma, menedżer ds. inżynierii w zespole Androida w ShareChat