关于Flutter应用架构的简单探讨(一)

2019年7月19日 604次阅读 来源: 每天多一点

动机

随着Flutter的发布以及谷歌的宣传, 国内已经有团队进行跟进. 其中不乏有很多经验进行分享. 但遗憾的是, 大多数中文的分享集中在”翻译”Flutter的官方文档, 以及记录如何照着文档画UI, 而对于应用结构和工程实践方面的探索甚少. 而很多实践类分享由于一些客观原因, 又比较难以看到. 所以这篇文章的主旨是希望能够通过一些已有代码的大致分析来帮助对Flutter感兴趣的朋友了解Flutter应用可能的组成方式, 希望能够起到抛砖引玉的作用.

参考资源

Youtube上已经存在的关于Flutter的应用实践分享
官方文档
Github上的关于此话题方面的项目
https://stackoverflow.com/questions/49491860/flutter-how-to-correctly-use-an-inherited-widget

概要

Flutter的应用架构可以很多样, 根据目前的分享, 大致可以分成如下几种:

  • 利用Flutter原生的状态机制Vanilla
  • 利用BloC模型进行组织
  • 利用Flux进行组织
    本文将会涉及到前两者, 而Flux来源于React, 这次将不做讨论.

理解Flutter的核心规则

Flutter中, 基本单元是widget, 这些widget以树形的组织进行连接, 构成一个完整应用. Widget可以理解为Flutter中的细胞.

《关于Flutter应用架构的简单探讨(一)》 screenshot.png

而Flutter中提供了两种Widget, Stateful和Stateless. 从组成上看, Stateful比Stateless多了一个State的组成部分, 用来记录交互的结果. 之所以分成两类, 是因为Widget的设计初衷是”不可变”, 这种不可变是为了能够以尽可能少的代价重建(也就是调用build()方法)Widget. Stateless天生就不可变, 而StatefulWidget利用State进行状态管理, 系统可以创建多个StatefulWidget, 而只需要有一个State就可以了.

几个概念

InheritedWidget

InheritedWidget是Flutter中提供的一个简单Widget, 其主要作用是为了能够让数据在Widget间更好的传递. 它只有一个作用, 就是保存数据. 但是它有一个特性:context.inheritedWidgetOfExactType. 凡是调用了这个方法的Widget, 当保存的数据改变时, 将会被刷新.

《关于Flutter应用架构的简单探讨(一)》 image

StreamBuilder

这个widget的主要作用是根据一个流(Stream)的最近一个SnapShot创建一个Widget. 所以它的builder将会随着流被调用多次.

Vanilla结构

假设我们要构建一个购物车, 用户点选商品列表中的商品, 购物车将会同步将商品添加到其中.真个工程结构如下:

《关于Flutter应用架构的简单探讨(一)》 Vanilla.png

  • 应用在初始化时, 创建了Cart对象, Cart对象作为整个应用的数据模型的一部分, 存在于整个应用的根部.
    随后应用又创建了页面和路由,
  • 将Cart的”向下”传递给了页面(MyHomePage).
  • 因为MyHomePage中一个重要的组件是ProductGrid用来展现商品, 所以MyHomePage需要将Cart进一步传递给ProductGrid
  • 用户在ProductGrid上选择商品, 同时需要MyHomePage根据用户的操作来更新购物车. 这就需要MyHomePage将更新操作的方法传递给ProductGrid (updateProduct的值就是_updateCart).

待续…

    原文作者：每天多一点
    原文地址: https://www.jianshu.com/p/d6da59d51652
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞