42声明式UI 的编程思维.pdfVIP

声明式UI 的编程思维 如果你之前是 Android 或 iOS 开发，你最熟悉的应该是命令式的 UI 开发，但是 Flutter 的 UI 开发是声明式的，所以需要你的编程思维 从命令式 声明式转变。 从 命令式UI 到 声明式UI 假设要实现⼀个界⾯。 在 命令式UI ⾥，你需要⼿动创建所有 UI 的实例，如果界⾯有变化 的话，就需要调⽤ UI实例的⽅法，例如 get、set 等⽅法。换句话 说，当 UI 从⼀个状态转变到另⼀个状态，都需要对 UI 的实例操作 ⼀番，估计⼤家对这个过程也痛苦不已，尤其是 UI 有频繁、⼤规模 的变动时。 当 UI 状态切换时，命令式UI 就需要写代码来实现，为了减轻开发者 在不同 UI 状态之间切换写代码的负担，Flutter 采⽤了 声明式UI： 开发者只需描述当前的 UI 状态，Framework 会⾃动将 UI 从上⼀个 状态切换到下⼀个状态，⽽不需要额外的编码。 ⽽且在 命令式UI ⾥，你想都不敢想的⼀些⽅法，在 声明式UI ⾥完 全没问题，例如，Flutter 更改 UI ，不是通过 set ⽅法，改变 Widget 的值，⽽是重新 build ⼀个全新的 Widget，⽽且可以做到 每帧都创建新的 Widget 也没问题，因为创建新的 Widget 在 Flutter ⾥的消耗⾜够⼩；⽽每帧都创建新的 UI ，这个在 命令式UI ⾥，是没法想象的。 声明式的 Flutter Flutter 是 声明式的，就意味着 Flutter 的 UI 反应的是当前的状 态，就像下⾯的函数： 这个函数的输⼊是 状态 （state），函数 f 会重建 Widget，然后 输出 UI，状态指的就是 APP ⽣命周期内变化的数据，⽽Flutter 的 UI 就是状态的可视化展示。 例如，假设设置菜单中有⼀个开关，这个开关的功能是将 Flutter APP 的主题⾊由红⾊变为蓝⾊，⽤户打开这个开关，因为值变了， 所以当前 Flutter APP 的状态也发⽣了变化，会触发 UI 从头到尾的 重建，在重建的时候，会读取当前状态的值，例如，当前的主题⾊是 蓝⾊，从⽽让 UI 的显示发⽣变化。 在前⾯实现城市选择⻚⾯时，就是更改了变量 curCity 的值，来实现 UI 内容的刷新： setState(() { curCity = selectCity; }); 声明式UI 在更改 UI 时，不需要对 UI 进⾏操作，使⽤的还是原来 UI 的代码，只需要更改值，使状态发⽣变化，就能触发 UI 刷新。 声明式UI 有很多好处： 1. 不管 UI 有多少种状态，写 UI 的代码只有⼀份。 2. 你想要 UI 显示成什么样⼦，只要描述当前的状态就⾏ . 相对 UI 进⾏更改，也只需要描述更改后的 UI 状态就⾏，不需 要像命令式⼀样进⾏很多操作，因为 Framework 会⾃动处理 当然除了好处之外，也是会有坏处的，主要坏处就是： 1. 当 UI 的整个结构发⽣变化时，就不能复⽤原来的 UI 代码，需 要重新实现。请看下⾯的详细对⽐说明。 命令式UI 和 声明式UI 实现 UI 更改的对⽐ 声明式UI 的编程⻛格不像 命令式UI 的编程⻛格那么直观，现在通过 如下的⼀个例⼦来说明。 假设要实现⼀个如下的功能： 先实现左边的⻚⾯，然后将 ViewB b ⾥的⼦ View 替换为 ViewC c ，且将 ViewB b 的背景由⻩⾊变为红⾊。 使⽤命令式实现 如果⽤命令式的代码来实现，那么代码就会是这样⼦的 （）： ⾸先实现左边的⻚⾯： // 实现左边的⻚⾯ ViewA a = new ViewA(...) ViewB b = new ViewB(...) ViewC c1 = new ViewC(...) ViewC c = New ViewC(...) a.add(b) b.add(c1) b.add(c ) 对左边的⻚⾯进⾏修改，实现右边的⻚⾯： //实现右边的⻚⾯ b.setColor(red) b.clearChildren() ViewC c3 = new ViewC(...) b.add(c3) 你⾸先要通过 View 的构造函数创建 View 的实例，然后在组织 View 的层级修改，如果要对已有的⻚⾯进⾏修改，则⾸先要获取 View 的实例，然后对 View 的实例进⾏操作，更改 View 的配置， 这样⼀步⼀步操作 View ，就叫做 代码命令式。 使⽤声明式实现 如果