L'optimisation du scintillement du fractionnement des widgets en méthodes affectera les performances de rendu

 

Tout le monde est invité à prêter attention au compte public [ développement multiplateforme ces choses ] et à pousser régulièrement la pratique de la technologie de développement multiplateforme.

Dans la boîte de développement multiplateforme React Native, nous constatons souvent que lorsque le niveau du composant d'interface est profondément imbriqué et que l'interaction du composant implique une logique métier, afin de conciser et d'effacer le niveau de code, le composant sera divisé en méthodes, puis dans la disposition principale Introduit dans, par exemple:

render() {
  return (
      <View style={{ flex: 1, backgroundColor: Color.white }}>
           <NavBar />
         { this. this._renderContent() }
      </View>
  )
}

En raison de la complexité du contenu, nous avons résumé la logique métier et l'affichage de l'interface utilisateur dans la méthode.

Beaucoup d'amis ont une plainte commune après avoir contacté le développement Flutter, c'est-à-dire que cette mise en page est trop difficile à écrire et qu'une mise en page simple doit être imbriquée dans plusieurs couches. Donc, de nombreux développeurs vont le diviser en méthodes, et ont déjà vu certains projets open source utiliser cette méthode auparavant, cette méthode est-elle donc applicable dans Flutter?

Affichage du problème

Par exemple, il existe le morceau de code suivant:

@override
Widget build(BuildContext context) {
  return Scaffold(
	body: Center(
	  child: Column(
	    mainAxisAlignment: MainAxisAlignment.center,
	    children: <Widget>[
	      Text(
	        widget.title,
	      ),
	      Center(
	        child: Text(result,)
	      ),
	      Row(
	        children: [
		      MaterialButton(
		        color: Theme.of(context).primaryColor,
		        child: Text("1", style: TextStyle(color: Colors.white)),
		        onPressed: () => onPressCallback('startActivity'),
		      ),
		      ......
	        ]
	      )
	    ],
	  ),
	),
  );
}

Lorsque j'ai vu le code d'interface utilisateur de Flutter pour la première fois, certains amis pourraient penser que le niveau d'imbrication est un peu fou. Étant donné que les widgets peuvent être un peu basés sur des modèles, la première solution qui vient à l'esprit est de diviser les parties imbriquées en méthodes distinctes. À ce stade, vous aurez le code suivant:

@override
Widget build(BuildContext context) {
  return Scaffold(
	body: Center(
	  child: Column(
	    mainAxisAlignment: MainAxisAlignment.center,
	    children: <Widget>[
	      Text(
	        widget.title,
	      ),
	      Center(
	        child: Text(result,)
	      ),
	      this._buildRowBtnWidget() // 拆分为组件方法
	    ],
	  ),
	),
  );
}

/**
 * 组件方法模块
 */
Widget _buildRowBtnWidget() {
  return Row(
	children: [
	  MaterialButton(
		color: Theme.of(context).primaryColor,
		child: Text("1", style: TextStyle(color: Colors.white)),
		onPressed: () => onPressCallback('startActivity'),
	  ),
	  ......
	]
  )
}

En ce moment, il a l'air très beau, donc y aura-t-il des problèmes avec cette écriture?

La façon de diviser les widgets en méthodes, à première vue, il est logique de diviser les méthodes de construction longues en petites fonctions. En fait, nous ne devrions pas faire cela. En supposant qu'il existe actuellement une valeur d'état num, chaque fois que nous déclenchons la mise à jour des données num via setState (), _buildRowBtnWidget () sera appelé, ce qui entraînera la reconstruction de l'arborescence du widget encore et encore. Les composants de _buildRowBtnWidget () n'ont pas besoin d'être mis à jour et affichés, c'est -à-dire les modules de composants sans état . Lorsque l'application est plus complexe, il y aura un impact significatif sur les performances de rendu (planification CPU).

Plan d'optimisation

Flutter créer des composants en deux façons: stateful (StatefulWidget)  et sans état (StatelessWidget)  composants. Ainsi, au lieu de diviser les méthodes de génération en méthodes plus petites, nous les divisons en widgets sans état, à savoir: StatelessWidgets. Jetons un coup d'oeil au code après refactoring:

@override
Widget build(BuildContext context) {
  return Scaffold(
	body: Center(
	  child: Column(
	    mainAxisAlignment: MainAxisAlignment.center,
	    children: <Widget>[
	      Text(
	        widget.title,
	      ),
	      Center(
	        child: Text(result,)
	      ),
	      const _RowBtnWidget() // 拆分为组件方法
	    ],
	  ),
	),
  );
}

/**
 * 组件
 */
class _RowBtnWidget extends StatelessWidget {

  const _RowBtnWidget();

  @override
  Widget build(BuildContext context) {
	return Row(
	  children: [
		MaterialButton(
		  color: Theme.of(context).primaryColor,
	      child: Text("1", style: TextStyle(color: Colors.white)),
		  onPressed: () => onPressCallback('startActivity'),
		),
		......
	  ]
	)
  }
}

On peut voir que le code ci-dessus est beaucoup plus "gonflé" que divisé en méthodes, mais ce _RowBtnWidget ne sera construit qu'une seule fois, ce qui réduira la surcharge de performances de la reconstruction inutile de composants. 

Conclusion

Lors de la création de composants sans état, nous les divisons en StatelessWidgets. Réduisez la surcharge de performances de la reconstruction des widgets statiques. Pour optimiser les performances de l'application Flutter, il s'agit également d'une méthode d'optimisation très simple.