Я новичок в флаттере и мне действительно интересно, все ли поддерево виджетов перестраивается, когда мы вызываем setState.
Поддерево здесь означает все дерево виджетов ниже этого виджета (включая этот виджет как узел root).
Когда мы вызываем функцию setState
, метод build
вызывается для root node
поддерева, которое запускает методы сборки для его дочернего элемента. Скажем, ветвь (здесь MyWidget1
) поддерева (дочернего элемента этого виджета) не зависит от переменных состояния. Я заметил, что даже независимые ветки перестраиваются на setState
, вызываемом в родительском узле.
class _MyAppState extends State<MyApp> {
int count=0;
@override
Widget build(BuildContext context) {
return Scaffold(
body: Column(children: <Widget>[ MyWidget1(),MyWidget2(count),],),
floatingActionButton: FloatingActionButton(onPressed: ()=>setState((){count++;}),),
);
}
}
class MyWidget1 extends StatelessWidget {
@override
Widget build(BuildContext context) { print("widget builds 1");
return Container(height: 100, color: Colors.orange,);
}
}
class MyWidget2 extends StatelessWidget {
final int count;
MyWidget2(this.count);
@override
Widget build(BuildContext context) { print("widget builds 2");
return Text(count.toString());
}
}
Здесь мы видим, что MyWidget1
не зависит от переменной состояния (здесь count
), поэтому обычно , setState
не должно на него влиять. Мне было интересно, должна ли быть какая-то оптимизация, чтобы избежать этой бесполезной сборки MyWidget1
при вызове функции setState
. Поскольку дерево ниже MyWidget1
может быть слишком большим, оно тоже будет перестроено снова.
Мои вопросы:
Это нормально для этого Независимый виджет (здесь MyWidget1
) для повторной сборки на setState
?
Есть ли лучший способ справиться с этой ситуацией, чтобы избежать его перестройки.
Примечание: я прочитал этот вопрос
В этом вопросе есть способ избежать бесполезной сборки, создав экземпляр независимой ветки вне метода сборки,
Я сомневаюсь:
Это СПОСОБ справиться с этой ситуацией или какой-то другой лучший способ, или эта ситуация совсем не такая уж большая, поскольку дерево строится за O (n) время ( который, я думаю, не должен быть ответом, потому что построение дерева может быть операцией O (n), но оно может включать в себя множество трудоемких операций, которые могут быть не оптимизированы для повторного вызова без толку).