О памятных утечках и оптимизации в Flutter & Dart, возможно, это не так сложно, как кажется

root -> A -> B -> C
root -> A -> B -/- C (Указывает сборщику мусора на освобождение памяти C)

class Child {}

class Parent {
  Child? child;
}

Parent parent1 = Parent();

void myFunction() {

  Child? child = Child();

  // Объект `child` был выделен в памяти.
  // Он теперь удерживается от сборки мусора одним путём удержания (root ... -> myFunction -> child).

  Parent? parent2 = Parent()..child = child;
  parent1.child = child;

  // В этот момент объект `child` имеет три пути удержания:
  // root ... -> myFunction -> child
  // root ... -> myFunction -> parent2 -> child
  // root -> parent1 -> child

  child = null;
  parent1.child = null;
  parent2 = null;

  // В этот момент экземпляр `child` становится недостижимым
  // и будет в конечном итоге собран мусором.

  ...
}
```Когда мы говорим о памятных утечках, обычно имеется в виду ситуация, когда **неиспользуемые объекты остаются занятыми программой и не могут быть освобождены**, что может привести к утечкам памяти. Сборщик мусора Dart не может предотвратить все возможные утечки памяти, поскольку он может освободить только те объекты, которые больше не имеют ссылок.

> Обычно, когда объекты создаются с помощью конструкторов, связанная с ними память выделяется в куче Dart VM (виртуальной машиной). Dart VM отвечает за выделение памяти для объектов при их создании и её освобождение при прекращении использования этих объектов.

В Dart, если объекты, которые больше не нужны, всё ещё существуют благодаря некоторым ссылкам, таким как глобальные или статические переменные, сборщик мусора не сможет их распознать, что приведёт к утечкам памяти. Часто встречающиеся ситуации включают:

- Удерживание глобальными/статическими переменными
- Удерживание в замыканиях
- Неправильное использование метода dispose
- ...**Что касается этих сценариев, большинство утечек связано с `BuildContext`**. Почему `BuildContext` легко утекает? Это происходит потому что многие операции связаны с `BuildContext`, такие как: `Theme.of(context)`, `Provider.of(context)`, `context.read()`, `context.pop()` и так далее.**Когда `BuildContext` утекает, это обычно означает, что весь компонент или страница становится недоступной для сборки мусора**. Поскольку `BuildContext` является абстракцией от `Element`, а `Element` служит "мостом" между `Widget` и `RenderObject`.Поскольку в `Element` содержится сильная ссылка на `Widget` и `RenderObject`, сборка мусора этих двух объектов зависит от того, был ли вызван метод `unmount` у `Element`. Даже удаление состояния `StatefulWidget` также зависит от его `Element.unmount`:

![](http://img.cdn.guoshuyu.cn/2bkj9/image1.png)

> Так как `Element` равен `BuildContext`, утечка `BuildContext` эквивалентна тому, что все остальные объекты становятся недоступными для сборки мусора.

Таким образом, мы понимаем, что для того чтобы объекты могли быть собраны сборщиком мусора, они должны быть освобождены от других объектов, то есть **проще говоря, присвоить null тем объектам, которые должны быть собраны мусором**. В действительности во многих действиях `dispose` в Flutter/Dart соответствующие слушатели устанавливаются в null:

![](http://img.cdn.guoshuyu.cn/2bkj9/image2.png)

Но почему я сказал ранее, что утечки в Flutter на уровне Dart не являются "полностью" утечками? **Потому что возможность утечки не равна определенной утечке, а временная утечка не равна полной утечке**.

Пример: это часто встречающийся пример утечки памяти в Flutter, где замыкание внутри `Timer` удерживает контекст, поэтому в течение жизни этого замыкания соответствующий компонент или страница не может быть собрана мусором, что приводит к утечке:

```dart
Timer(Duration(seconds: 5), () {
  print(context.size); // Удерживает ссылку на контекст
});
```Однако это не является «смертельной утечкой», поскольку для данного замыкания его жизненный цикл составляет всего 5 секунд, после чего это замыкание больше не будет иметь внешних ссылок, и сборщик мусора сможет успешно очистить его.

Аналогичный пример: в следующем коде `Future.delayed` удерживает `context`, поэтому сразу после выполнения `Navigator.pop` страница, содержащая этот контекст, не может быть собрана мусором. Однако, как показано на рисунке, если ждать 5 секунд и затем запустить сборку мусора вручную, количество экземпляров в DevTools уменьшится, и конечная страница всё же будет успешно собрана мусором:

```dart
ElevatedButton(
    onPressed: () {
      Future.delayed(Duration(seconds: 5), () {
        print(this.context.widget);
      });
      Navigator.pop(context);
    },
    child: Text("назад")),

@override
Widget build(BuildContext context) {
  final handler = () => print(Theme.of(context));

  return ElevatedButton(
    onPressed: handler,
    child: Text('Применить тему'),
  );
}

![](http://img.cdn.guoshuyu.cn/20241221_DL/image4.gif)

Однако, если вы измените код таким образом, чтобы `callback` таймера захватывал `context`:

```dart
int _counter = 0;
Timer? _timer;
@override
void initState() {
  _timer = Timer.periodic(Duration(seconds: 1), (timer) {
    print(context.size);
  });
  super.initState();
}

int _counter = 0;
late AnimationController animationController;

@override
void initState() {
  animationController =
      AnimationController(vsync: this, duration: const Duration(seconds: 60));
  animationController.addListener(() {
    print(this._counter);
  });
  animationController.repeat();
  super.initState();
}

final List<Function> closures = [];

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  @override
  void initState() {
    var test = () {
      _counter++;
      print(context.widget);
    };

    closures.add(test);

    super.initState();
  }
}