Android studio – czego nie robić, aby nie tracić pamięci

AS (Android Studio) nie jest kojarzony w opinii publicznej jako najszybsze narzędzie do pracy. Jest ciężkie i dodatkowo zabiera więcej pamięci niż znany z tego o wiele bardziej Chrome.

Dlatego istotnym jest aby nie dobijać swojego AS jeszcze bardziej, dodając mu więcej zadań, którymi musi się zajmować.

W dwóch z naszych największych projektów mieliśmy pomysł, żeby dodać plik zwany logic.dart. Miał się on zajmować wszystkimi naszymi importami tak, abyśmy my nie musieli o nich myśleć. Wrzucaliśmy do niego wszystkie pliki `import` oraz `part` które odnosiły się do naszych zasobów zarówno zewnętrznych jak i wewnętrznych.

W teorii działało to dobrze – nie musieliśmy się martwić importowaniem, wszystko mieliśmy dostępne z miejsca na ekranie importowaliśmy po prostu jeden plik – logic.dart, pliki były mniejsze i bez zbędnych linijek.

Okazało się jednak, że otwarcie każdego pliku zawierającego logikę aplikacji wymagało kilku sekundowego oczekiwania. Często trzeba było też resetować całe Android Studio za pomocą popularnego przycisku `invalidate caches / restart`, a samo AS zaczęło pobierać makabryczne ilości pamięci systemowej osiągając nawet 9 GB.

Zdawało się wręcz ciągle chcieć więcej pamięci do momentu, aż oczekiwanie na podpowiedź okazywało się trwać dłużej, niż napisanie całego kodu bez wsparcia programu.

Oświecenie dotarło do nas dopiero przy wytworzeniu nowej architektury, której używamy do teraz. Wymagała ona większego podziału logiki z naszej strony. Nie mogliśmy więc pozwolić sobie na przechowywanie wszystkiego w jednym miejscu. Nasze nowe projekty stały się nieporównywalnie lżejsze, a po całym dniu widoczna była różnica w wygodzie pracy.

Nie był to dla nas oczywisty powód tak zasobożernego działania aplikacji. Dopiero po ukończeniu kilku projektów w nowej architekturze doszliśmy do wniosku, że musiał to być nasz nieszczęsny plik `logic.dart`. Wygląda na to, że jeżeli AS posiada zbyt dużą ilość oznaczeń segmentacji kodu (czy raczej, ilość linijek do jakiej dany plik ma dostęp), to zaczyna działać zdecydowanie wolniej. Prawdopodobnie Android Studio próbowało wszystkie te pliki przechowywać w pamięci. Dodatkowo, sprawy nie ułatwia fakt, że `dart analyzer` zdaje się także działać tym wolniej, im więcej błędów występuje w plikach które są posegmentowane!

W celu naprawienia tego błędu należy próbować ograniczać ilość segmentacji plików. Nie powinno być problemu z posiadaniem jednego pliku `bloc`, `state` oraz `event`, jako elementów segmentowanych. A już napewno nie warto jest wrzucać w ten sposób rzeczy które wcale tego nie wymagają!

Jesteśmy też świadomi, że nie jest to coś, co warto utrzymywać. Kod powinno się segmentować tylko jeżeli jest ku temu dobry powód. Ale po tej zmianie, ilość używanych zasobów w naszym Task managerze spadła o ponad 6 GB RAM’u!

Pozwoliło nam to trafić na inny problem. Wielu developerom znana jest pewnie paczka o nazwie `moor`. Tym który jej nie znają – jest to biblioteka, która służy do zarządzania bazą danych oraz jej ORM. Problem, na jaki natrafiliśmy w jednym z naszych projektów, wymagał zapewnienia możliwości używania aplikacji w trybie offline oraz synchronizacji z serwerem.

Pliki, które służą jako tabele dla naszej bazy danych (jest ich 20), muszą być zdefiniowane w tym samym pliku, w którym jest zdefiniowana nasza baza danych. Wymaga to od nas importowania całego wygenerowanego kodu i definicji tabel wraz z każdym obiektem.

Powoduje to jednak wygenerowanie olbrzymiego, liczącego 13,500 linijek kodu-potwora (nie licząc samych plików z bazą danych oraz jej tablicami!), który zjada naszą pamięć.

Nie pomaga dodanie wygenerowanego pliku, jako zignorowanego do analysis_options.yaml, ponieważ kod i tak musi interpretować załączone pliki. Jedynym tego obejściem jest segmentacja plików tak, że logicznie są one tym samym.

Aktualnie, w momencie pisania tego artykułu trwają prace, które mają zaradzić temu problemowi. Mogą one zająć jednak sporo czasu. Warto mieć to na uwadze, kiedy zastanawiamy się nad wyborem biblioteki do bazy danych. Nie jest to może wada, która całkowicie skreśla `moor`, jako wspaniałą paczkę (on sam poprawił już to co mnie osobiście najbardziej raziło – generowanie serializacji json’a), ale dobrze wiedzieć co przyczynia się do takiego działania naszego AS. Bibliotek takich, jak ta może być więcej.

This site is registered on wpml.org as a development site.