大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
相对于iOS开发,Flutter的布局更具有灵活性,每个页面设计都不一样,相同页面可选择的布局方式也不一样,如果单纯的说应该如何去布局,我觉得不现实,大家可以参考下 Flutter官方的布局教程 。接下来,笔者,通过项目中的一个页面,来一步一步的拆解布局的流程。整个过程,基本上按照拆解、组件封装、具体布局这三步来的。
宜良ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18980820575(备注:SSL证书合作)期待与您的合作!
根据设计图,可以看出整体可以分成两部分,上面一部分是系统介绍模块,下面一部分是真正的登录内容,因为涉及到叠加,因此考虑用Stack;
系统介绍模块部分:整体也是涉及到叠加,考虑用Stack,分为四部分。最底部渐变色背景用一个contanier,无须指定位置,全视图扩展;载放logo图标在上一层,用Image。最后两个Text同级放在最上层。Image,Text各用Positioned包裹去指定位置。
登录内容模块是最外层是一个Contanier容器,去控制背景色和圆角。然后是一个Column元素,逐行排列。
第一行为Image,
第二行为Text,
第三行可以看成一个小Column,分两块进行布局
第四行可以看成一个小Column,分两块进行布局
第五行可以看作一个TextButton,
第六行可以看作一个Row,分三块进行布局
通过上面这样一步一步的分析后,基本上对大致的布局有了一个了解,最外层的控件大致选对(只要能实现的话,就是复杂度以及效率的问题),然后一步一步的拆解每一行的元素,如果有重复的或者觉得可以封装出来的部分,则进行下一步。
每一行的拆解,大致也是按照这个思路来进行,因此笔者在这里就不做讲解了。
在做到第三第四行的时候,发现这两个很相似,而且设计到一些交互逻辑,笔者就想对第三第四行的这种展示进行封装,觉得今后的布局可能会用到,因此在这一步,可以先把这一块儿抽离出一个控件。利用TextField来实现这种输入操作,具体的实现笔者不再详细的描述了。
经过这一步,整体的规划设计图已经有了,各个组件也都有了,接下来的工作就是组装了。
具体布局设计到一些细节的地方,例如整体Column的居中对齐(crossAxisAlignment)、间隔(Padding或Container包裹,笔者更喜欢用SizedBox占位)、居左居右居中(Align)、点击事件(GestureDetector)以及圆角(BorderRadius)等一些特殊情况。
像第六行row是放在底部的,就可以在第六行前面增加一个Spacer()去填充空白区域。
对文字颜色大小等,可以用TextStyle直接设置。
对于输入框的删除按钮,可以用Offstage这种Flutter特有的控制显示隐藏的控件。
最近在做的一个项目,项目的前期采用Weex开发。但是随着交互复杂度的增加,Weex一处开发多处多处运行的特征并没有很好的体现,相反很多时候我们还是需要做IOS和Android的适配。如今火热的Flutter相比Weex和Rn来说,给出了更好的跨平台解决方案。所以我们设计了一套基于Weex实现,底层跑在Flutter Engine上的框架。
底层的Runtime采用isolate engine,框架业务逻辑,Dom的解析逻辑和Render逻辑都跑在这里。
渲染引擎采用Flutter的Skia,彻底剥离了Android和IOS的差异性.
将Weex VirsualDom的解析都替换成Flutter Widget.
设计基于Weex2Dart的Brider,使JS和Dart可以相互调用
weex-demo的性能展示
release环境下采用AOT模式,性能会有质的飞跃。
Android-Release版本只有10m大小
相比Weex和Rn具有更好的性能,同时具有更好的跨平台性
相比Flutter,具有动态部署的能力(Flutter Release采用AoT模式并没有动态部署的能力,即使Debug版本也只是开发环境下才有动态化能力并没有可以实施项目的能力)
只需要会Weex开发或则Rn开发就可以,不需要额外学习Dart,已有的Weex项目可以无缝切换。
在做移动端的时候, 很多时候会需要下图所示的需求,如图 自己所示:
先进行需求分析, 这个模块可以设计成Container包含GridView, GridView中子内容个数由后台数据控制, 但是在直接写Container包含GridView控件时会出现 "Failed assertion: line 1920 pos 12: 'hasSize'" 有关的错误, 如果直接给Container一个高度的话, 又不满足我们的需求.
我们想要的结果是由数据控制GridView的个数, 而Container大小跟随GridView个数的变化而变化, 而不去直接设置Container的大小,
因此,我们点开GridView的api发现, 有一个shrinkWrap属性, 设置shrinkWrap:true即可, 运行一下即可达到效果, 但是又会发现另一个问题, 虽然Container大小可以自适应了, 但是里面的内容又会在局部进行滚动, 而我们的想法是想让内容在整个屏幕中滚动, 并没有局部滚动的效果, 因此, 我们设置另一个属性physics: NeverScrollableScrollPhysics()
在GridView.builder中添加
Container跟随GridView内容变化高度: shrinkWrap:true,
取消滚动效果: physics:NeverScrollableScrollPhysics(),
流式布局(Liquid)的特点(也叫"Fluid") 是页面元素的宽度按照屏幕分辨率进行适配调整,但整体布局不变。栅栏系统(网格系统),用户标签等。在Flutter中主要有Wrap和Flow两种Widget实现。
在介绍Row和Colum时,如果子widget超出屏幕范围,则会报溢出错误,在Flutter中通过Wrap和Flow来支持流式布局,溢出部分则会自动折行。
上述有很多属性和Row的相同,其意义其实也是相同的,这里我就不一一介绍了,主要介绍下不同的属性:
我们一般很少会使用Flow,因为其过于复杂,需要自己实现子widget的位置转换,在很多场景下首先要考虑的是Wrap是否满足需求。Flow主要用于一些需要自定义布局策略或性能要求较高(如动画中)的场景。Flow有如下优点:
我们对六个色块进行自定义流式布局:
实现TestFlowDelegate:
可以看到我们主要的任务就是实现paintChildren,它的主要任务是确定每个子widget位置。由于Flow不能自适应子widget的大小,我们通过在getSize返回一个固定大小来指定Flow的大小,实现起来还是比较麻烦的。
细心的开发者会发现flutter构建的App体积比native的大一些,是什么原因造成App体积大呢?
其实flutter 在release时App体积和native的大小差不多,而debug时体积通常会大。debug版本体积较大是为了Hot reload和快速编译。如果有flutter开发经验的朋友都体验过,如果您修改一下App的背景颜色,只需save一下就可以立刻看到修改后效果。我称之为“像艺术家一样在创造App”,因此为了实现这些目标,提高开发的效率,debug将占用全部资源。而当我们构建release版时,flutter又会采用AOT策略,提高App运行效率,release版只打包必需的资源,因而体积又会减少。
另外,flutter团队也一直在寻找减小程序大小的方法。
1、 新版本Flutter SDK 引入了 extension的机制。可以对某个class 进行扩展。(swift中有类似机制)
2、屏幕适配一直是一个老生常谈的问题,随着机型越来越多,适配的场景也越来越复杂。
3、之前有了解过 微信小程序的适配方案,个人一直感觉是一个比较好的方式( iPhone6为标准尺寸)下面????将引用小程序的方案来进行对 Flutter的尺寸设置。
size_fit.dart 文件
double_extension.dart 文件
int_extension.dart 文件
通过上面的设置,在不同设备上,展示的widget的尺寸就会不一样了。