Ciclo de vida del widget de la serie Flutter

PD: Tu plan es perfecto, pero el mundo está cambiando demasiado rápido.

En el último artículo, aprendí sobre la carga de imágenes y el análisis de código fuente en Flutter. Los amigos que han realizado desarrollo móvil conocen el ciclo de vida de los componentes. Lo mismo ocurre en Flutter. Es muy importante comprender y aprender el ciclo de vida de los componentes. en Flutter. La misma serie de artículos de la siguiente manera:

Este artículo presentará principalmente el ciclo de vida del widget en Flutter, de la siguiente manera:

  1. StatelessWidget
  2. StatefulWidget
  3. Estado del ciclo de vida del estado
  4. Método del ciclo de vida del estado

StatelessWidget

El componente derivado de StatelessWidget es un componente sin estado. El componente sin estado solo se representa una vez durante la construcción y no admite cambios dinámicos, es decir, el componente no se puede volver a dibujar mediante otras operaciones del usuario y solo se puede construir al recibir los parámetros entrantes, como sigue:

/// StatelessWidget
/// 表示无状态Widget
class StatelessSamplePage extends StatelessWidget {
    
    

  // 外部传入数据
  final String data;
  StatelessSamplePage(this.data);

  @override
  Widget build(BuildContext context) {
    
    
    return Container(
      color: Colors.lightBlue,
      child: Text(data),
    );
  }
}

Los parámetros pasados ​​arriba solo se pueden modificar con final, de lo contrario aparecerá la siguiente advertencia:

This class (or a class which this class inherits from) is marked as '@immutable', but one or more of its instance fields are not final: StatelessSamplePage.data

Indique que el widget está decorado con una anotación @immutable, de la siguiente manera:

@immutable
abstract class Widget extends DiagnosticableTree {
    
    

En este momento, solo final se puede usar para modificar variables, y las variables modificadas por final en Dart solo se pueden inicializar una vez, lo que también se ajusta a las características sin estado de StatelessWidget.

StatefulWidget

Los componentes derivados de StatefulWidget son componentes con estado, y los componentes con estado admiten la construcción múltiple de Widgets a medida que los datos cambian para completar la representación de interfaces dinámicas. Si desea implementar una interfaz que muestre la hora actual en tiempo real, Obviamente StatelessWidget no se puede completar. Utilice StatefulWidget con estado para lograr, de la siguiente manera:

/// StatefulWidget
/// 表示有状态的 Widget
class StatefulSamplePage extends StatefulWidget {
    
    
  @override
  _StatefulSamplePageState createState() => _StatefulSamplePageState();
}

class _StatefulSamplePageState extends State<StatefulSamplePage> {
    
    
  DateFormat _dateFormat;
  String _currentTime;
  Timer _timer;

  @override
  void initState() {
    
    
    super.initState();
    _dateFormat = new DateFormat("yyyy-MM-dd HH:mm:ss");
    // 初始化当前时间
    _currentTime = _dateFormat.format(DateTime.now());
    // 更新时间
    _startTime();
  }

  @override
  Widget build(BuildContext context) {
    
    
    return Center(
      child: Scaffold(
        appBar: AppBar(
          title: Text("Stateful Widget sample"),
          centerTitle: true,
        ),
        body: Align(
          alignment: Alignment.topCenter,
          child: Text("当前时间:$_currentTime"),
        ),
      ),
    );
  }

  @override
  void dispose() {
    
    
    super.dispose();
    if(_timer!=null){
    
    
      _timer.cancel();
    }
  }

  _startTime() {
    
    
    const Duration duration = Duration(seconds: 1);
    _timer = Timer.periodic(
        duration,
        (Timer timer) => {
    
    
              // 刷新界面状态
              setState(() {
    
    
                _currentTime = _dateFormat.format(DateTime.now());
              })
            });
  }
}

El efecto es el siguiente:

De hecho, si solo la interfaz estática StatelessWidget y StatefulWidget son completamente indistinguibles, ambos son alcanzables. La única diferencia es que StatefulWidget puede activar la reconstrucción del Widget a través del método setState. La clase State es el puente de Stateless -> Stateful .

Estado del ciclo de vida del estado

El ciclo de vida de Flutter es en realidad el ciclo de vida de cada componente:

  • StatelessWidget: el ciclo de vida de un componente sin estado es solo el proceso de compilación;
  • StatefulWidget: el ciclo de vida de un componente sin estado se refiere al ciclo de vida de State.

El ciclo de vida de Flutter es en realidad el ciclo de vida de los componentes sin estado, es decir, el ciclo de vida de State, como se muestra en la siguiente figura:

Estado del ciclo de vida del estado

Como se indicó anteriormente, los estados del ciclo de vida de cada estado son principalmente tres:

  • creado: se refiere al estado de creación del Estado, está en el estado creado cuando se llama al método createState;
  • Sucio: se refiere al estado en el que se llama a los datos del método, como setState, pero el widget no se ha reconstruido;
  • limpio: se refiere al estado después de que se construye el widget;
  • Defunct: se refiere al estado después de que se llama a State.dispose. En este momento, el widget correspondiente se ha destruido y no se puede reconstruir.

Método del ciclo de vida del estado

El ciclo de vida de un componente con estado es el ciclo de vida de State. El proceso de llamada específico y el tiempo de activación de la compilación se muestran en la siguiente figura:

Método del ciclo de vida del estado

El significado específico de su método de ciclo de vida es el siguiente:

  • createState: se utiliza para crear State en StatefulWidget;
  • initState: operaciones de inicialización de estado, como inicialización de variables, etc .;
  • didChangeDependencies: se llama después de llamar a initState, o si se usa el componente InheritedWidgets, InheritedWidgets se puede usar para la administración del estado de Flutter;
  • build: utilizado para la construcción de Widget;
  • deactivate: se llama después de que se elimina el widget que contiene este objeto de estado. Si el widget no se agrega a la estructura de árbol de otros widgets después de ser eliminado, el método dispose continuará llamándose;
  • dispose: libera los recursos ocupados por el widget después de llamar al método;
  • reensamblar: utilizado en la fase de desarrollo, se llamará durante la recarga en caliente y se reconstruirá más tarde;
  • didUpdateWidget: El método didUpdateWidget del widget secundario se llamará cuando se construya el widget principal.

Agregue un registro al método de ciclo de vida del widget correspondiente para verificar la ejecución del método de ciclo de vida anterior. El código fuente del widget principal es el siguiente:

const String TAG = "Flutter";
/// Widget生命周期
class WidgetLifecycleSamplePage extends StatefulWidget {
    
    
  @override
  _WidgetLifecycleSamplePageState createState() {
    
    
    Log.info(TAG, "parent createState");
    return _WidgetLifecycleSamplePageState();
  }
}

class _WidgetLifecycleSamplePageState extends State<WidgetLifecycleSamplePage> {
    
    

  num _count = 0;

  @override
  void initState() {
    
    
    super.initState();
    Log.info(TAG, "parent initState");
  }

  @override
  Widget build(BuildContext context) {
    
    
    Log.info(TAG, "parent build");
    return Scaffold(
      appBar: AppBar(
        title: Text("Widget Lifecycle Sample"),
        centerTitle: true,
      ),
      body: Column(
        children: <Widget>[
          Center(
            child: RaisedButton(
                textColor:Colors.white,
                color: Colors.lightBlue,
                child: Text("parent->setState:$_count",style: TextStyle(color: Colors.white),),
                onPressed: (){
    
    
                  setState(() {
    
    
                    Log.info(TAG, "parent setState");
                    _count++;
                  });
                }),
          ),
          SubWidgetLifecycleSamplePage(),
        ],
      )
    );
  }

  @override
  void didUpdateWidget(WidgetLifecycleSamplePage oldWidget) {
    
    
    super.didUpdateWidget(oldWidget);
    Log.info(TAG, "parent didUpdateWidget");
  }

  @override
  void didChangeDependencies() {
    
    
    super.didChangeDependencies();
    Log.info(TAG, "parent didChangeDependencies");
  }

  @override
  void deactivate() {
    
    
    super.deactivate();
    Log.info(TAG, "parent deactivate");
  }

  @override
  void reassemble() {
    
    
    super.reassemble();
    Log.info(TAG, "parent reassemble");
  }

  @override
  void dispose() {
    
    
    super.dispose();
    Log.info(TAG, "parent dispose");
  }
}

/// 子Widget
class SubWidgetLifecycleSamplePage extends StatefulWidget {
    
    
  @override
  _SubWidgetLifecycleSamplePageState createState() {
    
    
    Log.info(TAG, "sub createState");
    return _SubWidgetLifecycleSamplePageState();
  }
}

La implementación del widget secundario es similar a la implementación del widget principal y no se publicará. Puede responder a la palabra clave [Lifecycle] en el fondo de la cuenta oficial para obtener el código fuente completo.

Las llamadas de método correspondientes del ciclo de vida son las siguientes:

analizar de la siguiente manera:

  1. El proceso de inicialización del widget se refiere al proceso del ciclo de vida de ingresar a la página donde se encuentra el widget, primero el widget principal y luego el widget secundario, y luego llamar a los métodos createState, initState, didChangeDepandencies y build;
  2. Cuando el Widget principal seteState actualiza los datos, se activa la construcción del Widget principal, por lo que el Widget secundario llama al método didUpdateWidget;
  3. Otros procesos, como la recarga en caliente y la destrucción de widgets, son los mismos que los del diagrama de flujo del método del ciclo de vida del estado anterior, por lo que no los repetiré aquí.

Puede responder a la palabra clave [Lifecycle] en el fondo de la cuenta oficial para obtener el código fuente completo. Para obtener más información, consulte la cuenta oficial de WeChat .

Inserte la descripción de la imagen aquí

Supongo que te gusta

Origin blog.csdn.net/jzman/article/details/112454883
Recomendado
Clasificación