Flutter第七期 - 布局总结篇

Flutter 布局控件完结篇

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

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，则须要作好埋坑造轮子的觉悟。若是人力紧缺的话，不该该在这上面去投入，人力富余的时候，能够投入人力跟进研究，让业界以为大家很棒很前沿。