13518219792
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 里去处理 。
先制作一个纵轴滚动的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构造,只要控制好逻辑，完全没有任何问题
针对日常不同的需求，我们时常需要自定义 Dialog ，而小菜在尝试过程中遇到一些小问题，简单记录总结一下；
小菜在自定义含有文本框的 Dialog 时，文本框获取焦点时，软键盘会部分遮挡对话框，但当小菜替换为 AlertDialog 时，文本框获取焦点时，对话框会向上浮动，避免软键盘遮挡；
对于含有文本框的自定义 Dialog ，小菜在最外层使用的是 Material 嵌套，小菜通过采用 Scaffold 来嵌套处理，默认 Scaffold 中 resizeToAvoidBottomPadding / resizeToAvoidBottomInset 为 true ，当设置为 false 时，文本框获取焦点时，依旧会被软键盘遮挡；因为在固定情景可以配合 resizeToAvoidBottomPadding 实现是否被软键盘遮挡效果；
resizeToAvoidBottomPadding 主要用于自身 Widget 是否避免被其他窗口遮挡；其中小菜查资料介绍在 Flutter 1.1.9 之后更推荐使用 resizeToAvoidBottomInset ；
小菜自定义一个可以多选 item 的 Dialog ，但 Dialog 中并没有状态更新的 State ，如何进行 Dialog 中状态更新呢？
小菜之前在 showDialog 时直接创建了 TypeListDialog ，此时是无状态的，当 WidgetBuilder 创建一个 StatefulBuilder 有状态的构造器即可，可以将 state 传递到 Dialog 中；
小菜在自定义 Dialog 时如何在一个回调方法中传递多个参数？
小菜在 Dialog 的回调方法中传递两个 List ，而在接收回调方法中匹配两个参数即可；小菜简单看作是一个函数方法；
小菜在重写 AppBar 时，如何取消默认的返回按钮？
取消 AppBar 前面的返回图标有多种方式；
自定义 Dialog 案例源码
小菜对于 Flutter 的应用还不够熟悉，很多常用的场景会处理的很不到位，小菜会对日常的小问题进行简单记录，逐步学习；如有错误，请多多指导！
