布局控件完结篇

首先这篇文章是转载的，原文是这里
https://juejin.im/post/5bab35ff5188255c3272c228
我在最近的学习布局控件中主要看的就是这个。结合自己的一些理解，和测试。

下面是主要内容

本文对Flutter的29种布局控件进行了总结分类，讲解一些布局上的优化策略，以及面对具体的布局时，如何去选择控件。

1. 单节点控件

分类

在这小节里，我尝试从多个维度去对这些控件进行分类，希望这样可以帮助大家理解。

按照继承划分

Flutter单节点布局控件继承分类
上面是这18种控件的父节点层面的继承关系，唯一不同的一个控件就是Container。所以按照是否继承自SingleChildRenderObjectWidget的分类如下：

• 继承自StatelessWidget的控件，有Container。
• 继承自SingleChildRenderObjectWidget的控件，有Padding、Align、Center、FittedBox、AspectRatio、ConstrainedBox、Baseline、FractionallySizedBox、IntrinsicHeight、IntrinsicWidth、LimitedBox、Offstage、OverflowBox、SizedBox、SizedOverflowBox、Transform、CustomSingleChildLayout。
  Container是一个组合控件，不是一个基础控件，这点从继承关系就可以看出来。

按照功能是否单一划分

分类如下：

• 功能不单一的控件，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走向易用的一小步。

按照功能划分

在此处我按照定位、尺寸、绘制三部分来尝试着去做功能的划分，当然这个划分并不绝对，仁者见仁吧。

• 定位控件：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还是分出了一个控件。

Flutter单节点布局控件功能分类

使用

单节点控件虽然这么多，但是大部分不会挨个去尝试。对于大部分人而言，都是佛系的用法，一个控件能够使用，就一直用到死。

在布局上，大方向还是不停的拆，把一张设计图，拆成一棵树，每个节点根据需要，选择合适的控件，然后从根部开始不停嵌套，布局就完成了。

控件的选择

控件种类繁多，真正使用的时候该如何去选择呢？有万金油的做法，不管啥都用Container，这也是很多初接触的人经常干的方式。这么做的确可以按照设计图把布局给实现了，但是会涉及到一些性能上的问题。

控件的选择，按照控件最小功能的标准去选择。例如需要将子节点居中，可以使用Container设置alignment的方式，也可以使用Center。但是从功能上，Center是最小级别的，因此选择它的话，额外的开销会最小。

将UI实现了，这只是最基本的，当达到这一步了，应该更多的去思考，如何更好的布局，使得性能更高。

2.多节点控件

分类

多节点控件内部实现比单节点控件复杂的多，会从继承以及功能两个方向去做分类。

按照继承划分

Flutter多节点布局控件继承分类

从上图可以看出，多节点布局控件基本上可以分为三条线

• 继承自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。知道了这些过后，对继承关系的理解会有更好的帮助。

按照功能划分

这个对于多节点布局控件来说，还是比较难以划分的，笔者试着做了如下划分：

• 列表：GridView、ListView；
• 单列单行或者多列多行：Row、Column、Flow、Wrap、ListBody、Table；
• 显示位置相关：Stack、IndexedStack、CustomMultiChildLayout。
  个人觉得这种分类方式不是特别的稳妥，但还是写下来了，请大家仁者见仁。

GridView和ListView分为一类，一个是因为其实现非常的相似，另一个原因是这两个控件内容区域可以无限，不像其他控件的内容区域都是固定的，因此将这两个划分为一类。

关于单列单行多列多行的，也并不是说很严格的，Row、Column、Table、ListBody可能会遵守这种划分，Flow以及Wrap则是近似的多列多行。这种划分绝对不是绝对的，只是个人的一种考量划分方式。

使用

多节点控件种类较少，而且功能重叠的很少，因此在使用上来说，还是简单一些。比较常用的GridView、ListView、Row、Column、Stack，这几个控件基本上涵盖了大部分的布局了。

控件的选择

多节点控件功能重叠的较少，因此选择上，不会存在太多模凌两可的问题，需要什么使用什么即可。

3.性能优化

性能优化这块儿，可能仁者见仁，并没有一个统一的说法，毕竟现在Flutter各方面都还不完善。但是，大方向还是有的，尽量使用功能集更小的控件，这个对于渲染效率上还是有所帮助的。

优化

在这里我试着去列举一些，并不一定都正确。

• 对于单节点控件，如果一个布局多个控件都可以完成，则使用功能最小的，可以参照上面控件分类中的功能划分来做取舍；
• 对于多节点控件，如果单节点控件满足需求的话，则去使用单节点控件进行布局；
• 对于ListView，标准构造函数适用于条目比较少的情况，如果条目较多的话，尽量使用ListView.builder；
• 对于GridView，如果需要展示大量的数据的话，尽量使用GridView.builder；
• Flow、Wrap、Row、Column四个控件，单纯论效率的话，Flow是最高效的，但是使用起来是最复杂的；
• 如果是单行或者单列的话，Row、Column比Table更高效；
• Stack和CustomMultiChildLayout如果同时满足需求的话，CustomMultiChildLayout在某些时候效率会更高一些，但是取决于Delegate的实现，且使用起来更加的复杂；

上面所列的比较杂，但是归纳起来，无非这几点：

• 功能越少的控件，效率越高；
• ListView以及GridView的builder构造函数效率更高；
• 实现起来比较复杂的控件，效率一般会更高。