你会flutter吗,flutter如何

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 里去处理 。

相关问答

Q1: Flutter：手把手教你使用滚动型列表组件：ListView

ListView的基础创建使用有三种方式：

通过默认构造函数来创建列表，应用场景 = 短列表

这种方式创建的列表存在一个问题：对于那些长列表或者需要较昂贵渲染开销的子组件，即使还没有出现在屏幕中但仍然会被ListView所创建，这将是一项较大的开销，使用不当可能引起性能问题甚至卡顿。

长列表

列表子项之间需要分割线

ListView的进阶使用主要包括：下拉刷新 上拉加载

在Flutter中，ListView结合RefreshIndicator组件实现下拉刷新

通过包裹一层RefreshIndicator，自定义onRefresh回调方法实现

方式有两种：

通过ListView.controller属性可以判断ListView是否滑动到了底部，再进行上拉加载

NotificationListener是一个Widget，可监听子Widget发出的Notification

ListView在滑动时中会发出ScrollNotification类型的通知，可通过监听该通知得到ListView的滑动状态，判断是否滑动到了底部，从而进行上拉加载

NotificationListener有一个onNotification属性，定义了监听的回调方法，通过它来处理加载更多逻辑

不定期分享关于 安卓开发 的干货，追求 短、平、快 ，但 却不缺深度 。

Q2: Flutter 开发笔记

下面这种情况下，为 InkWell 设置的 splashColor 不会生效：

需要用 Material 去除背景色，然后将颜色设置在 InkWell 外部：

在 Dialog builder 中使用 WillPopScope 禁用返回键返回：

注意：使用此方法同时也会禁用 iOS 上的手势滑动返回功能，推荐判断平台后再使用。

修改对话框中的复选框状态，最简便的方法是通过 Element 中的 markNeedsBuild 方法：

当然，更推荐的做法是通过 StatefulBuilder ，然后就可以在 Dialog 中调用 setState 方法了，不过在调用 setState 时需要判断 Dialog 是否已经关闭，否则会造成 setState() called after dispose() 的错误，可以通过添加一个标志位来解决，如下：

在 Web 中加载网络图片有时会失败，遇到这样的报错： Exception caught by image resource service... ，造成该错误的原因通常是，图片跨域了（见 跨域资源共享 ）。最简单的解决办法是， 使用 HTML 渲染加载 ，而不是默认的 CanvasKit。

Flutter 中所有的 list 默认都是没有 ScrollBar 的，必须使用 ScrollBar 组件。ScrollBar 组件通过监听 ScrollView 的 ScrollNotification 来刷新位置，所以 List 的长度必须是固定的。

当使用 WebView 等高度不定的组件时会出现内容被截断的情况，通常可以使用 NestedScrollView 来解决该问题，需要在 WebView 外部嵌套 SingleChildScrollView。

虽然使用了缓存，而且也是用 builder 加载图片的，但是发现一个现象：滑动屏幕后图片短暂消失并重新加载了。图片高度很高时这种现象更加明显，其原因是超出屏幕范围一定距离的组件被重新渲染了。解决方法是在 ListView 上设置 cacheExtent 参数:

该参数的作用是改变超出屏幕高度后继续渲染的范围（以像素为单位），比如设置成 9999 后意味着超出屏幕 10000 像素以内的内容都会被保留下来。

借助 IntrinsicHeight 组件：

另外，IntrinsicHeight 还可以用于 Dialog 或者 BottomSheet 中，使得其中的元素 显示内在元素的高度 ，从而避免元素因为约束的存在而不显示或者高度太高（比如在使用了 Column 或者 Row 的时候）。

在通过 Uri 的 queryParameters 获取 query 参数时，发现有些链接会抛出下面异常：

造成该异常的原因是 Uri 默认使用 utf-8 解码超链接字符串，如果链接中包含非 utf-8 字符，就会造成上面的错误，相关 issue 见： issue #31621 。目前该 issue 处于 open 的状态，暂时的解决办法是，在所有使用到 queryParameter 的地方用 try..catch 捕捉可能抛出的异常。

Flutter 开发非常依赖各种官方或第三方的插件，而在使用这些插件时多少都会遇到一些问题，大部分问题都可以通过搜索和查找 issue 来解决。这里记录下一些我在使用部分插件时遇到的问题及其解决方法。

目前该库没有图片加载完成的回调（见 issue #545 ），不过我们可以通过在 imageBuilder 中来添加回调：

这是一个应用内更新插件，安卓 10 以上安装时需要在 manifest 中添加以下内容：

目前功能最强大的 WebView 插件，基本能满足绝大部分移动端网页加载的需求，而且可定制化程度高。

一般通过 CookieManager 修改 Cookie，拦截请求并修改请求对象的 Header 不会生效。

InAppWebViewOptions 的 userAgent 只在 iOS 上生效，而 applicationNameForUserAgent 只在 Android 上生效，所以最好的做法是分平台设置 InAppWebViewOptions ，而且需要注意，由于设置 userAgent 后会覆盖默认的 UserAgent，所以如果需要在默认的 UserAgent 上添加其它参数，iOS 上需要通过 InAppWebViewController.getDefaultUserAgent() 获取默认 UserAgent 参数，而 Android 不需要添加。

如果图片源或者请求是 http 的，为了在 Android 上正常加载请求，必须在 AndroidInAppWebViewOptions 中将 mixedContentMode 设置为 AndroidMixedContentMode.MIXED_CONTENT_ALWAYS_ALLOW 。

当我们想要设置全屏图片的时候，由于默认的 Constraint 会将图片居中显示，所以图片四周会留有空隙。为了去除这个限制，我们需要 Xcode 中打开 LaunchScreen.storyboard，然后在 View Controller 的 View 和 LaunchImage 上的 Safe Area 去掉。

具体设置方法：右侧 Inspector 面板 Show the Size inspector 解选 Layout Margins 中的 Safe Area Relative Margins，拖动图片占满全屏，然后根据 View Controller Scene 的 Warning，更新 Constraint 就可以了。

在集成某些三方库之后，在使用命令行运行 iOS 模拟器的时候可能会遇到下面这个报错：

这是因为 iOS 模拟器未来将会兼容 arm64 架构，但是目前还不支持，所以我们需要修改 Build Setting 使得能够在 x86_64 的模拟器上运行，操作步骤见 这里 。

Q3: 你会喜欢Flutter的5个理由

❖

在 Google I/O ’17 上，Google 向我们介绍了Flutter —— 一款新的用于创建移动应用的开源库。

正如你所想的那样，Flutter 是能够帮助创建拥有漂亮 UI 界面的跨平台移动应用解决方案。Flutter 的界面设计与 web 应用类似，因此，你能够从 Flutter 上找到像使用 HTML/CSS 那样熟悉的感觉。

Google 表示：Flutter 将会帮你更容易，更快速的开发出界面美观的移动应用。

听起来很美好，但是首先要说的是，我对其他跨平台解决方案，诸如 Xamarin，PhoneGap，Cordova，React Native，weex, ionic等并不是很认可。 大家都知道，这些解决方案互有利弊，很难选择。虽然我并不确定 Flutter 是否会与它们有所不同，但是我很期待。

Flutter 在 移动 前端开发上具有很多特色，很有吸引力。这篇文章，我将会告诉大家我之所以喜欢 Flutter 的真正原因，我们现在就开始吧！

为什么要用 Flutter ？

你可能会好奇，然后问自己一个问题：

Flutter 有什么创新之处？它是如何工作的？与 React Native 有什么不同之处？

简要来说，Flutter 是一个移动 SDK ，允许我们创建跨平台移动应用（这样你就可以编写一份代码，在 Android 和 iOS 都可以运行这个应用程序）。你使用dart 语言编写代码，这是一种由谷歌开发的语言，如果你以前用过 Java ，那看它会觉得非常熟悉。你不再需要用 XML 文件构建布局树，而是像这样：

好的，现在就开始吧！

1、热重载

我们从一个基本的应用开始。我们有三个按钮，它们中的每一个都能改变文本的颜色：