Утечка памяти во Flutter через историю навигации?

Question

[Руслан]

Здравствуйте.
Поясните, пожалуйста, правильно ли я понимаю ситуацию:
Во Flutter, когда мы переходим от одной страницы к другой при помощи навигации вот так:

onTap: () {
          Navigator.push(context, MaterialPageRoute(builder: (_) {
            return SomePage();
          }));
        }

то мы создаем новый объект, который записывается в историю и храниться там, пока мы эту историю не очистим или пока не вызовем Navigator.pop() до предыдущей страницы.

Если так, то не случиться ли рано или поздно утечка памяти?
Что если пользователь будет ходить только при помощи push между тремя страницами, а каждая страница будет создавать какое-то состояние и это состояние все время будет запоминаться в истории?

Я провел эксперимент: сделал в Stateful виджете-странице метод dispose(), но он не вызывался у меня ни разу, получается, объекты создаются и не удаляются (это, в принципе, правильно, есть же ссылки на объект из истории навигации).

Странно как то: если пользователь будет ходить по интернет-магазину по разным страницам товаров, а каждая страница будет тянуть из интернета данные о товаре и все это будет оставаться в памяти, то как бы ее скоро может не хватить.
Стоит этого опасаться или все же нужно как то иначе организовывать навигацию?

Answer 1

[Andrew Nodermann]

Если не важна история, можно использовать Navigator.pushReplacement для удаления предыдущей страницы, если нужна история переходов, то можно отдельно сохранять ее в список List<String> routeHistory = [] и потом выдергивать оттуда.

Насчет жора памяти, у ios и android работают сборщики мусора, вам просто так не дадут сожрать всю память устройства, GC начнет выгружать старый кэш и соответственно приложение начнет медленно работать, т.к. придется заново все подгружать.

Чтобы как-то ускорить процесс, можно использовать прогрев кэша для картинок, которые скоро будут использоваться:

ImageProvider imageProvider = AssetImage(imagePath);
scheduleMicrotask(() {
  precacheImage(imageProvider, context);
});

Реализация зависит от конкретного приложения и как пользователь его использует, оптимизировать заранее не стоит, иначе закопаетесь в задачах.

Comments

[Руслан]

"Насчет жора памяти, у ios и android работают сборщики мусора, вам просто так не дадут сожрать всю память устройства, GC начнет выгружать старый кэш и соответственно приложение начнет медленно работать, т.к. придется заново все подгружать."

Сборщик мусора очистит только тогда, когда не будет ни одной ссылки на объекты, а в данном случае они будут в стеке навигатора. Логично что либо приложение сдохнет или будет тормозить.

Интересно, как этот момент задумывался самими разработчиками flutter, они наверняка предполагали, что будет возникать такая проблема. я вот в интернетах ничего не нарыл по этому поводу.

Вообще мне кажется, что тот код, который приводиться в примерах самими разработчиками не совсем удачный:

Navigator.push(context, MaterialPageRoute(builder: (_) {
            return SomePage();
          }));

т.е. каждый раз создается новый объект, может быть стоит не создавать каждую страницу заново, а переиспользовать ранее созданные страницы при помощи какого-нибудь сервиса.

В общем хочется понять, как другие программисты в такой ситуации действуют: то-ли не заморачиваются и делают new Page(), то-ли как то по другому. и вообще, есть ли проблема тут, может быть это я ошибочно ищу проблему там, где ее нет.

[Andrew Nodermann]

Руслан, можно сделать шаблон, сами товары хранить в списке, id страницы и список хранить в Provider, не обязательно делать страничную навигацию в данном случае