带你重新“玩转”Flutter( 三 ) _Flutter

•状态不拆，拆分逻辑：这种做法的特点全局共用一个状态结构体对象，所有状态全部放在这个对象中，叫做“统一状态管理” 。只有一个数据对象，就消除了各个处理逻辑之间信息共享问题，逻辑内部没有状态，变得非常的纯粹（比如纯函数来实现），再将逻辑以合适的方式组合成一个整体，实现上界限清晰，简单优雅，代表的方案就是Redux 。
如果采用这种设计方案，推荐使用函数式风格来实现，这倒不是因为函数式“更高效”，“更优雅”之类的，而是它与函数式的思路十分的契合，在实现上更容易把握住思路。用面向对象来实现也并没有问题，最后的效果取决于你所面临的工程环境和用户。
这种状态管理好处显而易见：一处状态发生改变，不需要到处发事件同步。但是如果用在复杂大业务上面(比如一个有数十个页面流程的业务产品），状态必定是复杂的，状态结构体必然是庞大的。Redux的方式很好的管理了逻辑，如果要管理一个统一庞大的状态数据，也许内存级别的SQL是个不错的主意，GraphQL-Client给了我们启发，我们也正在尝试实践。

文章插图
•逻辑不拆，拆分状态：我把这种叫做“步进状态管理”，实际上这类似于状态机模式。但如果要真正使用，状态必须是有限的，而且不能经常变动。这与互联网持续多变的业务需求实际是不符合的，所以采用这种方式的设计几乎没有。但在一些很严肃的业务场景中，比如交易流程，一旦定下来就不容易变动。这时，步进状态管理就很合适了。

文章插图
•同时拆分逻辑和状态：这是容易想到方案，在更细的粒度上，将状态和它对应的处理逻辑拆分打包，变成更小的域（scope），然后统一协调这些子域（subModel），我把这种叫做“组合状态管理” 。进一步的方案可以统一定义subModel的基础行为，然后引入调度器来协调管理它们，subModel之间还可以共享上下文来共享信息等等。
这种思路形式自由，可以采用的实现方式很多，经典的面向对象当然不在话下，scoped_model采用的就是这种思路，scoped_model实现的简单易懂，同时能力也比较有限。当然也可以采用函数式的方式，高阶函数+闭包也能很好的实现，但是圈内没有看到有相关的设计实现。还有一点，Dart提供了Mixin特性，通过这个特性，可以得到更简洁的实现方案。比如，可以沉淀很多特定的Model，然后通过with选择组合到业务Model中来(参考Flutter Framework中WidgetsBinding的实现) 。目前flutter-hook在做这方面的探索，flutter-hook看起来有些迷惑，其核心就是利用了Dart的Mixin特性来组合状态。

文章插图

界面管理Flutter使用了响应式UI，目的就是让业务开发减少界面的管理工作，只要提供好页面“描述”就行了。虽然Flutter内建了类似Virtual Dom的Diff机制，但是，做这个Diff也是要费性能的，如果我们在框架设计上能内建的把Diff工作提前到数据层，是不是可以提升性能呢？

文章插图
我们尝试了几种方法，受制于在Flutter中Dart不能反射，效果不理想，也许后续生态完善之后会有好的解法。
在UI开发中，Flutter一直有一个隐隐的声音就是动态化，官方好像是“忽略”的，这里也不谈了。

生命周期Flutter通过StatefulWidget给业务开发提供了基础的生命周期管理。组件生命周期的设计是随着业务场景的不同而不同的，我自己的理解，设计生命周期要从两点出发：一是组件从诞生到消亡的时间线，二是组件在场景中所拥有的权益和所承担的责任。生命周期的扩展原点是StatefulWidget,因业务场景不同而扩展不同，很难展开讲。
举个例子，如果使用原生Flutter开发(或者叫纯Flutter开发)，StatefulWidget所提供的生命周期是足够的。但是如果要做混合开发，引入混合栈后，显然就不够用了。这时候就需要提供新的组件来扩展生命周期，更好的满足混合场景的开发。当时我在做混合栈的时候并没有能理解到这一点。

结语本篇从分析前端开发需要面对的几个基础核心问题入手，结合Flutter带来的技术工具，尝试结构化的分析Flutter在业务开发中可能的技术选择和探索方向。当然，技术同学既要仰望星空，还需要脚下看路，对于Flutter开发中的热点技术问题，欢迎关注闲鱼技术公众号的其他文章，或者加入我们，和闲鱼一起做一点不一样的技术！