Flutter 布局控件完结篇
本文对flutter的29种布局控件进行了总结分类，讲解一些布局上的优化策略，以及面对具体的布局时，如何去选择控件。
1. 系列文章
- flutter 布局详解
- flutter 布局（一）- container详解
- flutter 布局（二）- padding、align、center详解
- flutter 布局（三）- fittedbox、aspectratio、constrainedbox详解
- flutter 布局（四）- baseline、fractionallysizedbox、intrinsicheight、intrinsicwidth详解
- flutter 布局（五）- limitedbox、offstage、overflowbox、sizedbox详解
- flutter 布局（六）- sizedoverflowbox、transform、customsinglechildlayout详解
- flutter 布局（七）- row、column详解
- flutter 布局（八）- stack、indexedstack、gridview详解
- flutter 布局（九）- flow、table、wrap详解
- flutter 布局（十）- listbody、listview、custommultichildlayout详解
1.1 乱侃
前前后后也算是拖拖拉拉的写了一些flutter的文章，写的也都比较粗略。最近工作调动，内部换了部门，一顿瞎忙活，也打乱了原本的分享计划。
从我最开始接触flutter到现在，差不多四个多月了。在这段时间里面，flutter也发布了release preview版本。各个技术网站本着先拨头筹的心态，推广了几波，国内的人气跟着也起来了不少。全世界flutter开发人员中，国内从业者占据了很大的比重，这个现象本身并不能说明什么，不过可以反映一点，有商业诉求吧。当然观望的还是占绝大部分，除了一些个人开发者爱折腾外，也就是一些大的业务成熟到不能再成熟的团队，内部消化人员去折腾这个了。
插个题外话，有感于最近的工作变动，这段时间胡思乱想的比较多。一门技术对程序员来说到底意味着什么？如果不需要再为生计奔波，是否还会对目前已上手的技术感兴趣？如果你现在的项目所需要的技术，对你个人而言毫无加成，只会浪费你的时间，让你在已有的技术栈上渐行渐远，你是否还会参与这个项目。只有极少数人会遇上逆天改命的项目，不管参与什么项目，技术人员的立身之本始终是技术（高管或者打算换行的除外），技术的选型，除去时间效率后续维护等普适性的考虑要素外，排在第一位的始终应该是对自身的提高，扯的有些远了哈。
1.2 本质
我数了一下我文章总结过的布局控件，总共有29种。乍看会觉得真鸡毛的多，不乍看，也会觉得鸡毛的真多。为什么其他的移动平台没有这么多布局控件呢？其实不然，其他平台没有这么细分。
以android平台为例，最基础的几种布局例如linearlayout、relativelayout、constraintlayout等等。很多flutter的控件，对于android来说，仅仅是一个属性的设置问题。
再往上看，ios、android、web这些平台的布局，其实最基本就那几种，线性布局、绝对布局、相对布局等等。flutter也逃不出这些，那为什么flutter现在有这么多布局控件呢？
第一点，之前文章介绍过的，flutter的理念是
万物皆为widget。这和flutter的实现机制有关，而不是因为它在布局上有什么特殊性，这也是最主要的一点。第二点，我觉得是因为这是flutter的初期，如果有经历过一个技术的完整发展周期，就会明白，前期只是提供各种零件，只有商业支撑或者人员支撑足够的时候，才会去优化零件。而现在就是这么一种资源不足的状态。各种组件可以合并的有很多，底层的实现机制不会变，只是再加一层即可，这也是可以造*的地方，例如封装一套适用于android、ios或者web人员的控件库等。
第三点，跟初期相关，一套新的技术，各种东西不可能一下子全想明白，路总是走着走着才发现走歪了，就像一些控件，可能一些地方合适，但是一些新的地方又不太合适，所以就再造一个，所以有些控件看起来功能十分相似。
说了这么多，我其实就想说明一点，flutter现在还只是处在社会发展的初级阶段，还处在温饱问题都解决不了的状态，想达到小康还需要很长的一段路要走。
2. 单节点控件
单节点控件，顾名思义就是只有一个节点的布局控件。这种控件有多少个呢，我之前文章总结过的有18种，现阶段还是不排除增加的可能，哈哈。
2.1 分类
在这小节里，我尝试从多个维度去对这些控件进行分类，希望这样可以帮助大家理解。
2.1.1 按照继承划分
上面是这18种控件的父节点层面的继承关系，唯一不同的一个控件就是container。所以按照是否继承自singlechildrenderobjectwidget的分类如下：
- 继承自statelesswidget的控件，有container。
- 继承自singlechildrenderobjectwidget的控件，有padding、align、center、fittedbox、aspectratio、constrainedbox、baseline、fractionallysizedbox、intrinsicheight、intrinsicwidth、limitedbox、offstage、overflowbox、sizedbox、sizedoverflowbox、transform、customsinglechildlayout。
container是一个组合控件，不是一个基础控件，这点从继承关系就可以看出来。
2.1.2 按照功能是否单一划分
分类如下：
- 功能不单一的控件，container、transform、fittedbox、sizedoverflowbox。
- 功能单一的控件，有padding、align、center、aspectratio、constrainedbox、baseline、fractionallysizedbox、intrinsicheight、intrinsicwidth、limitedbox、offstage、overflowbox、sizedbox、customsinglechildlayout。
先在此处小结一下，可以看出container的特殊之处了吧，为什么container这么特殊了。这个特殊要从两个层面去看。
- 对于flutter而言，container是特殊的，因为它不是功能单一的控件，是一个组合的控件，所以它相对于flutter是特殊的。
- 对于移动端开发者而言，它不是特殊的，因为很多ui都是一些基础功能组合的，这样能让开发者更方便的使用。
那能得出什么结论呢？我个人觉得，container这种组合的控件会越来越多，也会有个人开发者去开发这种通用型的组合控件，这是一个大趋势，是flutter走向易用的一小步。
2.1.3 按照功能划分
在此处我按照定位、尺寸、绘制三部分来尝试着去做功能的划分，当然这个划分并不绝对，仁者见仁吧。
- 定位控件：container、align、center、fittedbox、baseline、transform。
- 尺寸控件：container、fittedbox、aspectratio、constrainedbox、fractionallysizedbox、intrinsicheight、intrinsicwidth、limitedbox、sizedbox、sizedoverflowbox。
- 绘制控件：container、padding、offstage、overflowbox、sizedoverflowbox、transform。
有一个控件并没有归到这三类中，customsinglechildlayout可以自定义实现，此处不做分类。baseline可以把它放到绘制里面去，此处我按照调节文字的位置去做分类，这个大家知道就行，并不是说只能这么划分。
对于绘制控件，其实分的有些杂，我把显示相关的都归到这里，例如是否显示、内边距、是否超出显示以及变形等等。
每一种大类，flutter都提供了多种控件。经过这么划分，可以看出很多控件功能的交叉，很多时候一个属性的事情，flutter还是分出了一个控件。
2.2 使用
单节点控件虽然这么多，但是大部分不会挨个去尝试。对于大部分人而言，都是佛系的用法，一个控件能够使用，就一直用到死。
在布局上，大方向还是不停的拆，把一张设计图，拆成一棵树，每个节点根据需要，选择合适的控件，然后从根部开始不停嵌套，布局就完成了。
2.3 控件的选择
控件种类繁多，真正使用的时候该如何去选择呢？有万金油的做法，不管啥都用container，这也是很多初接触的人经常干的方式。这么做的确可以按照设计图把布局给实现了，但是会涉及到一些性能上的问题。
控件的选择，按照控件最小功能的标准去选择。例如需要将子节点居中，可以使用container设置alignment的方式，也可以使用center。但是从功能上，center是最小级别的，因此选择它的话，额外的开销会最小。
将ui实现了，这只是最基本的，当达到这一步了，应该更多的去思考，如何更好的布局，使得性能更高。
3. 多节点控件
多节点控件的种类就少了一些，虽然也有11种，但是功能和场景多了，所以选择上反而会简单一些。
3.1 分类
多节点控件内部实现比单节点控件复杂的多，会从继承以及功能两个方向去做分类。
3.1.1 按照继承划分
从上图可以看出，多节点布局控件基本上可以分为三条线
- 继承自boxscrollview的控件，有gridview以及listview；
- 继承自multichildrenderobjectwidget的控件，有row、column、flow、wrap、stack、indexedstack、listbody、custommultichildlayout八种；
- 继承自renderobjectwidget的控件，有table一种。
之前介绍过，gridview和listview的实现都是非常相似的，基本上就是silvers只包含一个sliver（gridview为silvergrid、listview为sliverlist）的customscrollview。 这也是为啥这两元素都继承自boxscrollview的缘故。
multichildrenderobjectwidget类，官方解读如下
a superclass for renderobjectwidgets that configure renderobject subclasses
that have a single list of children.
它只是一个含有单一list子节点的控件，为什么table不需要继承自multichildrenderobjectwidget呢？
这是因为table的子节点是二维（横竖）的，而multichildrenderobjectwidget提供的是一个一维的子节点管理，所以必须继承自renderobjectwidget。知道了这些过后，对继承关系的理解会有更好的帮助。
3.1.2 按照功能划分
这个对于多节点布局控件来说，还是比较难以划分的，笔者试着做了如下划分：
- 列表：gridview、listview；
- 单列单行或者多列多行：row、column、flow、wrap、listbody、table；
- 显示位置相关：stack、indexedstack、custommultichildlayout。
个人觉得这种分类方式不是特别的稳妥，但还是写下来了，请大家仁者见仁。
gridview和listview分为一类，一个是因为其实现非常的相似，另一个原因是这两个控件内容区域可以无限，不像其他控件的内容区域都是固定的，因此将这两个划分为一类。
关于单列单行多列多行的，也并不是说很严格的，row、column、table、listbody可能会遵守这种划分，flow以及wrap则是近似的多列多行。这种划分绝对不是绝对的，只是个人的一种考量划分方式。
3.2 使用
多节点控件种类较少，而且功能重叠的很少，因此在使用上来说，还是简单一些。比较常用的gridview、listview、row、column、stack，这几个控件基本上涵盖了大部分的布局了。
3.3 控件的选择
多节点控件功能重叠的较少，因此选择上，不会存在太多模凌两可的问题，需要什么使用什么即可。
4. 性能优化
性能优化这块儿，可能仁者见仁，并没有一个统一的说法，毕竟现在flutter各方面都还不完善。但是，大方向还是有的，尽量使用功能集更小的控件，这个对于渲染效率上还是有所帮助的。
4.1 优化
在这里我试着去列举一些，并不一定都正确。
- 对于单节点控件，如果一个布局多个控件都可以完成，则使用功能最小的，可以参照上面控件分类中的功能划分来做取舍；
- 对于多节点控件，如果单节点控件满足需求的话，则去使用单节点控件进行布局；
- 对于listview，标准构造函数适用于条目比较少的情况，如果条目较多的话，尽量使用listview.builder；
- 对于gridview，如果需要展示大量的数据的话，尽量使用gridview.builder；
- flow、wrap、row、column四个控件，单纯论效率的话，flow是最高效的，但是使用起来是最复杂的；
- 如果是单行或者单列的话，row、column比table更高效；
- stack和custommultichildlayout如果同时满足需求的话，custommultichildlayout在某些时候效率会更高一些，但是取决于delegate的实现，且使用起来更加的复杂；
上面所列的比较杂，但是归纳起来，无非这几点：
- 功能越少的控件，效率越高；
- listview以及gridview的builder构造函数效率更高；
- 实现起来比较复杂的控件，效率一般会更高。
4.2 选择
控件的选择，个人觉得把握大方向就够了。如果时间紧急，以实现效率最优先，如果时间充裕的话，可以按照一些优化细则，去做一些选择。单纯控件层面，带来性能上的改进毕竟十分有限。
5. 实战
首先看一下实际的效果图，这个是之前做工程中，比较复杂的一个界面吧，就算放到native上看，也是比较复杂的。
这个页面中有不少自定义控件，例如日期选择、进度等。整体看着复杂，实现起来其实也还好。关于如何布局拆解，之前文章有过介绍，在这里不再阐述，诀窍就是一个字----拆。
5.1 关于自定义控件
自定义控件一般都是继承自statelesswidget、statefulwidget。也有一些特殊的，例如上面的进度控件，直接使用canvas画的。
对于需要更新状态的，一般都是继承自statefulwidget，对于不需要更新状态的，使用statelesswidget即可，能够使用statelesswidget的时候，也尽量使用它，statefulwidget在页面更新的时候，会存在额外的开销。
flutter的自定义控件，写起来可能会比原生的更简单，它更多的是一些基础控件的组合使用，而很少涉及到底层的一些重写。
5.2 关于生命周期
这是很蛋疼的一个问题，一个纯flutter的app，类似于android中的单activity应用。某个具体的页面就算去监听native层的生命周期，也仅仅是获取到base activity的，而无法获取到页面层级的。
5.3 感想
flutter如果*足够的话，还是非常吸引人的，在熟悉了这些基础组件过后，编写起来，速度会非常快。自定义控件的实现，也比较简单。但是，性能方面，还是存在比较大的问题，复杂页面首次载入，速度还是比较慢。对于高端机型来说，整体流畅度很不错，堪比原生的app，低端机型，表现就比较捉急吧。整体来说，flutter表现还是挺不错的，可以上手试试，把玩把玩吧。就是写起来，写着写着就觉得恶心，是真的恶心的那种恶心，看着各种嵌套标签，感觉被降维成了web开发。
近期看到一些基于flutter的自动布局解决方案，之前也有想过，完全可以基于flutter做出布局的工具，仅仅是拖拽就可以实现完成度非常高的布局页面。也得益于flutter本身的思想和实现机制，web方面的很多东西，个人觉得都可以借鉴到flutter上。单纯从ui层来说，flutter确实有自己独特的地方。如果flutter在最开始，就仅仅是一套跨平台的ui的话，可能更容易被人们接受吧。
前几天看了官方的camera插件，还是挺蛋疼的，对于国内的android端来说，直接拿来商用几乎是不可能的。插件基于camera2去实现，国内大部分厂商对于camera2的支持很差，一些很容易复现的crash也没有去解决。
如果决定在现有项目中使用flutter，则需要做好埋坑造*的觉悟。如果人力紧缺的话，不应该在这上面去投入，人力富余的时候，可以投入人力跟进研究，让业界觉得你们很棒很前沿。
6. 后话
笔者建了一个flutter学习相关的项目，github地址，里面包含了笔者写的关于flutter学习相关的一些文章，会定期更新，也会上传一些学习demo，欢迎大家关注。