Flutter技巧,flutter经验

有关游泳的英文单词

一.

游泳的基本词汇

把脸埋入水中（词组）:

put

face

in

water

吐气泡（词组）:

blow

bubbles

漂浮（动词）:

float

游泳（动词）:

swim,

bathe

趟水（动词）：wade

池中嬉戏:

play

in

pool

跳水（动词）：dive

跳入泳池：jump

in

pool

技巧:

technique

二.

游泳的竞技比赛用词

strokes

（stroke的复数）用作表示

methods

of

swimming

游泳方法，包括：

1.蝶泳：Butterfly

或简称

fly

海豚式踢腿动作被称为

dolphin

kick

（kick=踢）

2.仰泳：Backstroke,

racing

backstroke,

或

back

crawl

踢腿动作被称为

浅打水：flutter

kick

3.蛙泳：Breaststroke

蛙式踢腿动作

frog

kick,

modified

frog

kick

or

whip

kick

4.自由泳：Freestyle,

front

crawl

或

forward

crawl

二十世纪初有两种提高速度的发展

Australian

Crawl

（澳大利亚式）与

American

crawl

（美国式）

5.个人混合泳：Individual

Medley

(IM)

指一个人连续游上述四种样式，每种姿势距离为100，200

或400米

6.四人接力：relay

每个人的赛程叫

leg，最后一位选手被称为anchor

三.

其他：知识

花絮

..侧泳：Sidestroke

剪刀式踢腿

scissors

kick

..狗爬式游泳：

Dog

Paddle

..爬泳：Trudgen

Crawl

..“溺死的蛾子”

=

通常形容人们第一次尝试蝶泳的样子：Drowning

moth

..踏水：Treading

water

不是一种姿势。它是一套使游泳者在水中身体保持竖直的腿部动作。

水球运动员常依靠它。水球：Water

polo

运动员们：players

..同游表演：Synchronized

swimming

被称为

=

花样游泳：water

ballet

成对表演（2-8人）

..游泳道的分界线：lane

lines

有时是人的“救生索”

lifelines

通常不许人靠在上面的原因有四：

1）他们不结实，会断

2）救生员会认为你有危险

救生员：lifeguard

3）真正有困难的人更不容易及时扶到了

4）把它压下去，它失去了边界警示的功能

四.大家平时都接触的（实用的:）

女游泳衣:

swimsuit

男式游泳短裤:

swimming

trunks

(永远用复数形式，因为泳裤两条腿)

游泳帽：swimcap

游泳镜:

swimming

google

防雾:

anti-fog

防紫外线镜片:

UV

Protection

Lens

游泳装备:

swim

gear

踢水板:

kickboard

双手扶上面，腿来踢水

漂浮物:

floats

绑胳膊上的

耳/鼻夹子：ear/nose

clip

脚蹼：swim

fins

秒表：stopwatch

（小孩子带到水中的）泳池玩具:

pool

toy

穿上泳衣

（女孩）：put

on

swimsuit

（男孩）：put

on

swimming

trunks

梳子:

hairbrush

淋浴(名词):

shower

香波（名词）:

shampoo

洗头（动词）:

shampoo

坐在池边:

sit

on

edge

从池中出来:

get

out

of

pool

池边地滑:

slippery

by

pool

擦干身体:

dry

off

穿上衣服:

get

dressed

游泳池:

swimming

pool

波浪池:

wave

pool

儿童池(浅水池):

wading

pool

水上滑梯：water

slide

泳道:

lane

把泳道分开的漂浮线：lane

lines

环绕游泳：Circle

Swim

是

游泳礼节：lane

etiquette

两人以上在同一泳道，始终贴近身体右边的泳道线，并间隔五秒的距离

不在池中方便:

don't

pee

in

pool

救生衣:

life

jacket

救生圈：ring

buoy

救生员:

lifeguard

游泳教练:

swimming

instructor，coach

相关问答

Q1: Android开发之WebView（一）配置&小技巧

背景：原生时间紧没时间开发任务量大的任务，而前端又闲着打酱油

方案：原生+webview混合开发

缺点：对于比较复杂的页面，webview在性能上力不从心；且与原生通信频繁也增加了隐藏的工作量

优点：能自带支持动态更新（js），能充分利用人力

webview是一个基于webkit引擎，展示web页面的控件。Android上的webview在低版本和高版本采用了不同的webkit版本内核，Android4.4（19）后直接使用了Chrome内核；WebView控件功能强大，除了具有一般View的属性和设置外，还可以对url请求，页面加载，渲染，页面交互进行强大的处理。一般来说webview可单独使用，也可联合其工具类一起使用

移动应用的主体是webview，主要以网页语言编写，穿插Native功能的Hybrid App开发类型。激活webview为活跃状态，能正常执行网页的响应；当webview 的页面被失去焦点切换到后台不可见状态onPause时，需要通知自己暂停所有的动作，比如DOM的解析，plugin的执行，JavaScript的执行等

1，显示和渲染web页面

2，直接使用本地assets或者网络上的html文件作为布局

3，可和JavaScript进行互相调用

1，直接在布局文件里写死

2，动态添加进viewgroup中

注：不管以哪种方式，都必须注意webview的销毁，否则可能会造成内存泄漏最终导致内存溢出crash

下面是WebView的一些常用的方法列举，一些已经过时的方法未列出

下面是WebSettings的一些常用的方法列举，一些已经过时的方法就没有写出来了

一般不管是动态生成还是xml写死，只要处理好了引用持有问题，就能有效的避免内存泄漏；下面是我尝试的方案，在工具类WebViewUtils.java里封装好，在activity销毁的时候调用

1，清除webview缓存和记录

2，可以设置不启用缓存

3，H5的一些控件标签不支持导致的白屏

4，xml启用软件加速

5，通过menifest的来配置，在目标webview的activity设置

解决方案：

解决方案：

解决方案：

上一篇： Flutter入门-01-工程创建目录介绍

Q2: flutter和ruffle的区别

使用的不同。

相比来说ruffle的使用更加的方便简单，不需要过多复杂的使用技巧，使用更加的方便快捷。

Q3: flutter 基于pageview 制作上下轮播文字功能

先制作一个纵轴滚动的pageview

然后我们利用time组件实现自动轮播，这里面有个小技巧，掌握了这个小技巧就可以做无缝的循环播放，比如我有 a b c三项，我们在构造pageview item的时候人为的构造成a b c a，在c的后面加上a,当c滚动到a的时候，比如每次动画变换时间是500毫秒，那么就延迟500好秒快速的跳到第一个a页面，刚好等它滚动完就快速变换

在视觉上完全看不出来，这样就造成了无缝循环滚动的假象，同理如果你想反方向也可以无缝循环滚动，那么你在构造pageview item的时候就可以 这样c a b c a构造,只要控制好逻辑，完全没有任何问题

Q4: Flutter 小技巧之优化你使用的 BuildContext

Flutter 里的 BuildContext 相信大家都不会陌生，虽然它叫 Context，但是它实际是 Element 的抽象对象，而在 Flutter 里，它主要来自于 ComponentElement 。

关于 ComponentElement 可以简单介绍一下，在 Flutter 里根据 Element 可以简单地被归纳为两类：

所以一般情况下，我们在 build 方法或者 State 里获取到的 BuildContext 其实就是 ComponentElement 。

那使用 BuildContext 有什么需要注意的问题 ？

首先如下代码所示，在该例子里当用户点击 FloatingActionButton 的时候，代码里做了一个 2秒的延迟，然后才调用 pop 退出当前页面。

正常情况下是不会有什么问题，但是当用户在点击了 FloatingActionButton 之后，又马上点击了 AppBar 返回退出应用，这时候就会出现以下的错误提示。

可以看到此时 log 说，Widget 对应的 Element 已经不在了，因为在 Navigator.of(context) 被调用时， context 对应的 Element 已经随着我们的退出销毁。

一般情况下处理这个问题也很简单， 那就是增加 mounted 判断，通过 mounted 判断就可以避免上述的错误 。

上面代码里的 mounted 标识位来自于 State ， 因为 State 是依附于 Element 创建，所以它可以感知 Element 的生命周期 ，例如 mounted 就是判断 _element != null; 。

那么到这里我们收获了一个小技巧： 使用 BuildContext 时，在必须时我们需要通过 mounted 来保证它的有效性 。

那么单纯使用 mounted 就可以满足 context 优化的要求了吗 ？

如下代码所示，在这个例子里：

由于在 5 秒之内，Item 被划出了屏幕，所以对应的 Elment 其实是被释放了，从而由于 mounted 判断， SnackBar 不会被弹出。

那如果假设需要在开发时展示点击数据上报的结果，也就是 Item 被释放了还需要弹出，这时候需要如何处理 ？

我们知道不管是 ScaffoldMessenger.of(context) 还是 Navigator.of(context) ，它本质还是通过 context 去往上查找对应的 InheritedWidget 泛型，所以其实我们可以提前获取。

所以，如下代码所示，在 Future.delayed 之前我们就通过 ScaffoldMessenger.of(context); 获取到 sm 对象，之后就算你直接退出当前的列表页面，5秒过后 SnackBar 也能正常弹出。

为什么页面销毁了，但是 SnackBar 还能正常弹出 ？

因为此时通过 of(context); 获取到的 ScaffoldMessenger 是存在 MaterialApp 里，所以就算页面销毁了也不影响 SnackBar 的执行。

但是如果我们修改例子，如下代码所示，在 Scaffold 上面多嵌套一个 ScaffoldMessenger ，这时候在 Item 里通过 ScaffoldMessenger.of(context) 获取到的就会是当前页面下的 ScaffoldMessenger 。

这种情况下我们只能保证Item 不可见的时候 SnackBar 还能正常弹出， 而如果这时候我们直接退出页面，还是会出现以下的错误提示，因为 ScaffoldMessenger 也被销毁了 。

所以到这里我们收获第二个小技巧： 在异步操作里使用 of(context) ，可以提前获取，之后再做异步操作，这样可以尽量保证流程可以完整执行 。

既然我们说到通过 of(context) 去获取上层共享往下共享的 InheritedWidget ，那在哪里获取就比较好 ？

还记得前面的 log 吗？在第一个例子出错时，log 里就提示了一个方法，也就是 State 的 didChangeDependencies 方法。

为什么是官方会建议在这个方法里去调用 of(context) ？

首先前面我们一直说，通过 of(context) 获取到的是 InheritedWidget ，而 当 InheritedWidget 发生改变时，就是通过触发绑定过的 Element 里 State 的 didChangeDependencies 来触发更新， 所以在 didChangeDependencies 里调用 of(context) 有较好的因果关系 。

那我能在 initState 里提前调用吗 ？

当然不行，首先如果在 initState 直接调用如 ScaffoldMessenger.of(context).showSnackBar 方法，就会看到以下的错误提示。

这是因为 Element 里会判断此时的 _StateLifecycle 状态，如果此时是 _StateLifecycle.created 或者 _StateLifecycle.defunct ，也就是在 initState 和 dispose ，是不允许执行 of(context) 操作。

当然，如果你硬是想在 initState 下调用也行，增加一个 Future 执行就可以成功执行

那我在 build 里直接调用不行吗 ？

直接在 build 里调用肯定可以，虽然 build 会被比较频繁执行，但是 of(context) 操作其实就是在一个 map 里通过 key - value 获取泛型对象，所以对性能不会有太大的影响。

真正对性能有影响的是 of(context) 的绑定数量和获取到对象之后的自定义逻辑 ，例如你通过 MediaQuery.of(context).size 获取到屏幕大小之后，通过一系列复杂计算来定位你的控件。

例如上面这段代码，可能会导致键盘在弹出的时候，虽然当前页面并没有完全展示，但是也会导致你的控件不断重新计算从而出现卡顿。

所以到这里我们又收获了一个小技巧： 对于 of(context) 的相关操作逻辑，可以尽量放到 didChangeDependencies 里去处理 。