一、flutter的build阶段,layout阶段,render阶段分别作了那些事情。
答:Flutter 的渲染过程可以分为三个主要阶段:Build
阶段、Layout
阶段 和 Render
阶段。这些阶段是 Flutter 构建 UI 的核心部分,每个阶段都有其特定的职责和流程。下面将详细介绍每个阶段的作用和具体执行的任务。
1. Build 阶段
Build
阶段是 Flutter 构建 Widget 树的过程,它负责根据应用的当前状态和输入生成一棵新的 Widget 树。
主要任务:
- 构建 Widget 树:
BuildContext
和State
会调用build()
方法,生成一个由 Widget 组成的树结构。这棵树代表了应用当前帧的 UI。 - 响应状态变化:当应用的状态发生变化(比如用户输入、数据更新等),Flutter 会触发
build()
方法,重新构建部分或全部 Widget 树。 - 优化 Widget 树:Flutter 尽量只重新构建那些发生变化的部分,而不是整个 Widget 树,从而提升性能。
关键点:
- 不可变性:Widget 是不可变的,一旦创建就不能更改。如果 UI 需要改变,Flutter 会构建一个新的 Widget。
- Element 树:
Build
阶段创建的是 Widget 树,但真正被管理和保留的是 Element 树,它维护了 Widget 的实例和相应的渲染对象之间的关系。
2. Layout 阶段
Layout
阶段负责计算每个 Widget 的位置和大小,它使用父组件传递下来的布局约束条件来确定子组件的布局。
主要任务:
- 传递布局约束:从根节点(如
RenderView
)开始,每个父节点向其子节点传递布局约束 (constraints
)。这些约束定义了子组件可以占用的最大和最小空间。 - 计算大小和位置:子节点根据接收到的约束计算自己的大小 (
size
) 和在父容器中的位置 (offset
)。 - 双向传递信息:在
layout
过程中,父节点通过constraints
将信息传递给子节点,而子节点将自己的大小信息反馈给父节点,以便父节点根据这些信息决定自身的布局。
关键点:
- 单次布局原则:每个渲染对象(
RenderObject
)在一帧内通常只会被布局一次。 - 递归布局:布局过程是一个自顶向下的递归过程,父节点为子节点提供约束,子节点计算并返回自身大小。
3. Render 阶段
Render
阶段是 Flutter 绘制 UI 的过程,这个阶段将之前计算出的布局信息转换为可以显示在屏幕上的像素数据。
主要任务:
- 创建绘制指令:Flutter 为每个
RenderObject
生成一组绘制指令(如绘制矩形、圆形、文本等),这些指令会传递给 Skia 图形引擎。 - 绘制过程:从根节点开始,每个
RenderObject
递归地调用其paint()
方法,将自己的绘制指令传递给子节点,并最终生成一系列可以在屏幕上显示的图形。 - 处理叠加效果:Flutter 可以通过
Layer
对象管理多个绘制层,以支持复杂的叠加效果(如透明、阴影等)。
关键点:
- RenderObject:在这个阶段,
RenderObject
是关键的渲染实体,它不仅负责绘制,还负责处理命中测试(如点击事件)和合成层的管理。 - 效率优化:Flutter 会尝试避免不必要的绘制操作,只绘制那些发生变化或需要更新的部分,以提高渲染效率。
总结
- Build 阶段 生成不可变的 Widget 树,并通过 Element 树将其与渲染对象关联。
- Layout 阶段 负责计算每个 Widget 的大小和位置,通过递归的方式传递布局约束并计算布局信息。
- Render 阶段 根据布局信息生成具体的绘制指令,并由图形引擎将这些指令绘制到屏幕上。
二、 在实际项目开发中,这三个阶段如何提高或者优化性能
在 Flutter 项目开发中,提高和优化 Build
、Layout
和 Render
阶段的性能至关重要,因为这直接影响到应用的响应速度和用户体验。下面将详细说明如何在实际项目中优化这三个阶段的性能。
1. Build 阶段的性能优化
Build
阶段的性能优化主要集中在减少不必要的 Widget 重建和提升构建 Widget 树的效率。
优化策略:
-
使用
const
构造函数:尽量使用const
构造函数来创建不可变的 Widget。这样可以让 Flutter 重用这些 Widget,而不是在每次重建时重新创建它们。dart 复制代码 const Text('Hello, World!');
-
减少 Widget 重建:避免在
build()
方法中进行不必要的重建。可以通过将不需要频繁更新的子树拆分到独立的 Widget 中,或使用shouldRebuild()
方法来控制是否重建。 -
利用
AutomaticKeepAlive
和CacheExtent
:在长列表或分页加载场景中,使用AutomaticKeepAlive
来保持列表项的状态,或调整CacheExtent
来减少不必要的构建和销毁。 -
使用
Builder
或ValueListenableBuilder
:对于局部状态更新,使用Builder
或ValueListenableBuilder
来只重建特定的部分,而不是整个 Widget 树。 -
避免
State
过于复杂:将复杂的State
拆分成多个小的State
,减少每次重建时需要处理的逻辑。
2. Layout 阶段的性能优化
Layout
阶段的优化重点在于减少复杂布局的开销,以及避免不必要的布局重算。
优化策略:
- 避免过度嵌套:减少 Widget 的层级嵌套,尤其是在复杂布局中。可以通过使用
CustomMultiChildLayout
或Stack
等更灵活的布局组件来简化布局结构。 - 使用
IntrinsicWidth
和IntrinsicHeight
谨慎:这些 Widget 会强制子节点执行两次布局计算,从而增加开销。尽量避免在频繁更新的布局中使用它们。 - 使用
Align
和Center
:这些 Widget 帮助减少额外的布局步骤,通过直接调整子节点的位置和大小,可以避免多次布局计算。 - 合理使用
Expanded
和Flexible
:在Row
和Column
中,合理使用Expanded
和Flexible
组件,以优化布局的灵活性和减少不必要的计算。 - 避免过多的
GlobalKey
:GlobalKey
会导致 Flutter 重新布局整个子树,使用时要谨慎,尽量避免在大型布局中广泛使用。
3. Render 阶段的性能优化
Render
阶段的优化目标是减少不必要的绘制操作和确保绘制效率。
优化策略:
-
使用
RepaintBoundary
:在需要隔离重绘的组件外层包裹一个RepaintBoundary
。这可以将渲染工作限制在边界内,避免整个 Widget 树的重绘。dart 复制代码 RepaintBoundary( child: ComplexWidget(), );
-
避免
Opacity
多次嵌套:Opacity
会强制子树重绘,尽量避免在嵌套布局中多次使用Opacity
。可以通过BlendMode
或ColorFiltered
来实现类似的效果,同时减少重绘开销。 -
优化动画:在动画中使用
vsync
来避免不必要的重绘,并确保动画控制器的范围适当。使用AnimatedBuilder
或AnimatedWidget
来优化动画的性能。 -
减少复杂图形渲染:在
CustomPainter
中绘制复杂图形时,确保只在需要时调用paint()
方法,并尽量减少复杂计算的频率。 -
使用
ClipRect
和ClipRRect
谨慎:裁剪操作会增加渲染负担,尤其是在需要频繁更新的场景中。尽量减少使用或优化裁剪区域的大小。
总体优化策略
- Profile 和 Benchmark:使用 Flutter 提供的
DevTools
和Flutter Inspector
等工具进行性能分析,找出应用中的性能瓶颈,并针对性地优化。 - 按需重构:对经常发生性能问题的代码部分进行重构,减少不必要的计算和操作。
- 异步操作:对于可能阻塞主线程的操作,尽量使用异步任务来处理,例如
FutureBuilder
或StreamBuilder
,确保 UI 渲染流畅。 - Flutter 批处理更新:在频繁更新状态时,使用
setState
时可以将多次状态更新合并为一次,减少不必要的重建。
三、理解 Flutter 的构建、布局和渲染过程时,将 Widget、Element、RenderObject 及其生命周期方法结合起来进行解释,会更有助于掌握整个流程的细节。下面是详细的解释:
1. Widget, Element, RenderObject 三者的关系
- Widget: 是 Flutter 构建用户界面的基础单元,是描述 UI 的不可变配置。Widget 是一个蓝图,描述了界面应该如何显示。
- Element: 是 Widget 的实例,负责管理 Widget 在树中的位置,并维护与其相关的状态。Element 是可变的,可以在树中保留以支持增量更新。
- RenderObject: 是负责实际绘制的对象。它管理布局、绘制和命中测试(hit testing)。
RenderObject
是与屏幕上的显示内容直接相关的对象。
2. 生命周期与关键方法
Widget 的生命周期
-
构造函数:
- 当 Widget 被创建时,Flutter 调用其构造函数以配置其外观和行为。Widget 是不可变的,这意味着在其生命周期中不会发生变化。
-
createElement()
:- 每个 Widget 都会创建一个与之对应的 Element。当 Flutter 构建 Widget 树时,调用
createElement()
方法生成对应的 Element。 - 例如,
StatelessWidget
和StatefulWidget
都会实现这个方法,分别返回StatelessElement
和StatefulElement
。
- 每个 Widget 都会创建一个与之对应的 Element。当 Flutter 构建 Widget 树时,调用
-
build()
:build()
方法是 Widget 的核心方法,负责描述 Widget 的子 Widget。Flutter 框架调用这个方法来生成 Widget 树的下一级。StatelessWidget
和StatefulWidget
都有这个方法,返回一个 Widget 树。
Element 的生命周期
-
mount()
:- Element 树的构建过程始于
mount()
方法。该方法将 Element 插入到树中,并与父 Element 建立联系。 mount()
还会调用 Widget 的build()
方法来创建子 Widget,并递归地将其挂载到树中。
- Element 树的构建过程始于
-
update()
:- 当与 Element 相关联的 Widget 发生变化时(例如,
setState()
被调用时),Flutter 不会销毁旧的 Element,而是调用update()
方法来更新 Element。这个方法会比较新的 Widget 和旧的 Widget,并只更新必要的部分。 - 对于
StatefulElement
,这个方法还会调用State
的setState()
方法来触发重建。
- 当与 Element 相关联的 Widget 发生变化时(例如,
-
deactivate()
:- 当 Element 从树中移除时,Flutter 调用
deactivate()
方法。此时,Element 被标记为无效,但还没有被销毁。
- 当 Element 从树中移除时,Flutter 调用
-
unmount()
:- 最终,Element 完全从树中移除时,调用
unmount()
方法。这是 Element 生命周期的结束,所有与 Element 相关的资源都会被释放。
- 最终,Element 完全从树中移除时,调用
RenderObject 的生命周期
-
createRenderObject()
:- 当 Element 树需要渲染时,
RenderObjectWidget
会调用createRenderObject()
方法来创建对应的RenderObject
。这个方法是连接 Widget 与其底层渲染层的桥梁。 RenderObject
是可变的对象,表示屏幕上的可见部分。
- 当 Element 树需要渲染时,
-
updateRenderObject()
:- 在 Widget 的配置发生变化时,
updateRenderObject()
方法会被调用,以更新RenderObject
的属性。例如,当 Widget 的某个属性发生变化时,RenderObject 可以根据新的属性重新计算布局或触发重绘。
- 在 Widget 的配置发生变化时,
-
attach()
和detach()
:RenderObject
在插入渲染树时会调用attach()
,并在从渲染树中移除时调用detach()
。这两个方法分别用于连接和断开与渲染树的关联。
-
layout()
:- 在布局阶段,Flutter 调用
RenderObject
的layout()
方法,计算每个RenderObject
的尺寸和位置。这个方法会通过performLayout()
来实现实际的布局计算。
- 在布局阶段,Flutter 调用
-
paint()
:- 在渲染阶段,
RenderObject
的paint()
方法负责将内容绘制到屏幕上。这个方法通常会使用Canvas
对象进行绘制操作。
- 在渲染阶段,
3. 结合生命周期理解 Build、Layout 和 Render 过程
Build 阶段
-
构建 Widget 树:
- Flutter 通过递归调用每个 Widget 的
build()
方法来构建 Widget 树。 - 每个 Widget 通过调用
createElement()
方法生成与之对应的 Element,并挂载到树中。此时,Element 会创建相应的RenderObject
(如果需要)。
- Flutter 通过递归调用每个 Widget 的
-
增量更新:
- 当 Widget 树发生变化时,Flutter 通过 Element 的
update()
方法来更新相应的部分,而不是重建整个树。这种机制有效地提高了性能。
- 当 Widget 树发生变化时,Flutter 通过 Element 的
Layout 阶段
-
布局计算:
- Flutter 调用每个
RenderObject
的layout()
方法来计算其尺寸和位置。这个过程是从根节点开始,递归向下执行的。 layout()
方法会在布局完成后标记RenderObject
为已布局,并将布局结果传递给其子节点。
- Flutter 调用每个
-
约束传递:
- 布局过程依赖于父
RenderObject
向子RenderObject
传递布局约束。每个RenderObject
都在这些约束下计算自身的大小和位置。
- 布局过程依赖于父
Render 阶段
-
渲染绘制:
- 渲染过程从根节点的
RenderObject
开始,调用每个RenderObject
的paint()
方法进行绘制。 - 每个
RenderObject
会根据布局阶段计算的结果将内容绘制到屏幕上的相应位置。
- 渲染过程从根节点的
-
局部重绘:
- 当某个部分的 UI 需要更新时,Flutter 只会重绘受影响的部分。
markNeedsPaint()
方法可以用于标记RenderObject
需要重绘。
- 当某个部分的 UI 需要更新时,Flutter 只会重绘受影响的部分。
总结
- Widget 是描述性蓝图,通过
build()
方法生成 UI 的结构。在createElement()
过程中,Widget 实例化为 Element,并创建相应的RenderObject
。 - Element 是管理 Widget 树的关键,负责将 Widget 的变化反映到渲染树中,并通过
update()
和unmount()
等方法实现 UI 的高效更新和删除。 - RenderObject 是最终的渲染执行者,通过
layout()
和paint()
方法处理布局和绘制。它直接控制了 UI 的表现。
四、flutter中widget的build()方法为什么参数不定义成Element对象,而要定义成BuildContext ?
在 Flutter 中,Widget
的 build
方法参数定义为 BuildContext
而不是 Element
对象主要有以下几个重要原因:
一、抽象与封装
-
BuildContext
提供了一种更高层次的抽象,它隐藏了底层Element
的具体实现细节。这使得开发者可以专注于构建用户界面,而不必深入了解Element
的复杂结构和生命周期。 -
这种抽象有助于保持代码的简洁性和可读性。如果直接使用
Element
,开发者可能会被底层的实现细节所困扰,增加了理解和维护代码的难度。
二、灵活性和可扩展性
-
BuildContext
可以在不同的场景下被广泛使用,不仅仅局限于与特定的Element
交互。它可以用于获取主题数据、导航服务、查找其他Widget
等多种用途。 -
例如,通过
BuildContext
可以轻松地访问Theme.of(context)
来获取当前的主题信息,或者使用Navigator.of(context)
进行页面导航。这种灵活性使得开发者能够更加方便地构建功能丰富的应用。
三、分离关注点
-
将
build
方法的参数定义为BuildContext
有助于分离Widget
的构建逻辑和底层的渲染机制。Widget
只需要关心如何根据给定的上下文构建自己的界面,而不必了解Element
的具体操作。 -
这样的设计使得 Flutter 的框架更加模块化,不同的部分可以独立发展和优化,而不会相互影响。
四、未来的可维护性
-
随着 Flutter 框架的不断发展和演进,底层的实现细节可能会发生变化。如果
build
方法直接依赖于Element
对象,那么当Element
的结构或行为发生改变时,可能会导致大量的代码需要进行修改。 -
而使用
BuildContext
作为参数,由于其更高层次的抽象性,能够更好地适应框架的变化,减少了代码的维护成本。
例如,当你需要在一个 Widget
中获取主题颜色时,可以使用 Theme.of(context).primaryColor
,而无需关心底层 Element
是如何与主题系统进行交互的。
总之,将 Widget
的 build
方法参数定义为 BuildContext
是 Flutter 框架设计的一个重要决策,它提供了抽象、灵活性、分离关注点和未来的可维护性,使得开发者能够更加高效地构建 Flutter 应用。
五、在 build 方法中使用 BuildContext 对象时,需要注意哪些问题?
在 Flutter 中,在 build
方法中使用 BuildContext
对象时,需要注意以下几个问题:
一、正确理解作用域
-
BuildContext
在特定的 widget 树上下文中是有作用域的。确保在正确的位置使用它来获取所需的信息或执行特定的操作。 -
例如,在一个子 widget 中获取主题信息时,使用的
BuildContext
应该是该子 widget 的上下文,而不是父 widget 的上下文,否则可能获取到错误的主题信息。
二、避免过度使用
-
不要过度依赖
BuildContext
来获取各种信息。过度使用可能会导致代码的可读性降低,并且使得 widget 的构建逻辑与外部依赖过于紧密。 -
考虑将一些常用的信息通过参数传递给 widget,而不是总是依赖
BuildContext
来获取。
三、注意性能影响
-
频繁地使用
BuildContext
来获取信息可能会对性能产生一定的影响,特别是在复杂的 widget 树中。 -
例如,频繁地调用
Theme.of(context)
可能会导致不必要的重新构建,因为主题的变化可能会触发依赖它的 widget 进行重建。
四、处理空值情况
-
在使用
BuildContext
来获取可能为空的对象时,要进行空值检查。 -
例如,使用
ModalRoute.of(context)
来获取当前路由信息时,如果在 widget 树中没有找到对应的路由,可能会返回 null。在这种情况下,需要进行适当的空值处理,以避免出现空指针异常。
五、避免在异步操作中使用
- 尽量避免在异步操作中使用
BuildContext
。因为在异步操作完成时,原始的BuildContext
可能已经不再有效。 - 如果需要在异步操作中使用与
BuildContext
相关的信息,可以在异步操作开始之前将所需的信息保存下来,或者使用其他方式来传递信息,而不是依赖于当时的BuildContext
。
六、buildContext 的作用域是如何影响性能的?
BuildContext
的作用域对性能有以下几方面的影响:
一、不必要的重建
-
如果在一个较大的 widget 树中,错误地使用了具有较广作用域的
BuildContext
,可能会导致不必要的 widget 重建。-
例如,如果在一个深层嵌套的子 widget 中使用了从根节点获取的
BuildContext
来获取主题信息,当主题发生变化时,整个 widget 树可能都会重建,即使只有部分子树需要更新主题。 -
相比之下,如果在需要主题信息的子 widget 附近的合适位置获取主题信息,使用更局部的
BuildContext
,那么只有直接依赖该主题的子树会重建,从而提高性能。
-
二、查找效率
-
使用
BuildContext
进行查找操作(如查找祖先 widget)时,作用域的大小会影响查找的效率。-
如果在一个庞大的 widget 树中频繁地使用广作用域的
BuildContext
进行深度查找,可能会导致性能下降。因为 Flutter 需要从当前 widget 向上遍历整个 widget 树,直到找到目标 widget。 -
例如,使用
context.findAncestorWidgetOfExactType<SomeWidget>()
在一个很深的 widget 树中查找特定类型的祖先 widget,如果使用了不合适的BuildContext
,可能会花费较长时间进行查找。
-
三、资源获取
-
当通过
BuildContext
获取资源(如主题、本地化信息等)时,作用域的选择也会影响性能。-
如果在一个频繁重建的 widget 中每次都使用从根节点获取资源的方式,可能会导致重复的资源获取操作,增加了不必要的开销。
-
例如,一个动画效果的 widget 在每一帧都使用
Theme.of(context)
获取主题信息,如果这个 widget 在一个大型应用的深层嵌套中,每次获取主题都需要从根节点开始遍历,这可能会影响动画的流畅性。
-
四、状态管理
-
在状态管理中,
BuildContext
的作用域决定了状态的传播范围。- 如果状态管理的范围过大,可能会导致不必要的状态更新和 widget 重建。例如,使用
Provider
进行状态管理时,如果一个状态的作用域被设置得过大,当这个状态发生变化时,可能会导致很多不相关的 widget 也进行重建。 - 相反,如果能够合理地划分状态的作用域,只让真正需要该状态的 widget 进行重建,就可以提高性能。
- 如果状态管理的范围过大,可能会导致不必要的状态更新和 widget 重建。例如,使用
七、如何避免在 Flutter 中使用具有广作用域的 BuildContext?
以下是一些在 Flutter 中避免使用具有广作用域的 BuildContext
的方法:
一、传递必要的上下文
-
当创建自定义 widget 时,如果需要特定的上下文信息,可以通过构造函数将其作为参数传递进去,而不是依赖于在
build
方法中使用广作用域的BuildContext
。-
例如,如果一个子 widget 需要访问主题信息,可以将主题作为参数传递给它,而不是在子 widget 的
build
方法中使用Theme.of(context)
。 -
代码示例:
-
class MyChildWidget extends StatelessWidget {
final ThemeData theme;
MyChildWidget(this.theme);
@override
Widget build(BuildContext context) {
return Container(
color: theme.backgroundColor,
child: Text('My Text', style: TextStyle(color: theme.textColor)),
);
}
}
-
在父 widget 中创建子 widget 时传递主题:
class MyParentWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
final theme = Theme.of(context);
return MyChildWidget(theme);
}
}
二、使用局部上下文
-
在可能的情况下,尽量使用更局部的
BuildContext
。例如,如果一个 widget 只需要在其直接父 widget 的上下文中获取信息,就使用父 widget 的BuildContext
,而不是从根节点开始查找。-
例如,如果一个子 widget 需要访问父 widget 的状态,可以通过
InheritedWidget
或者状态管理方案,使得子 widget 能够直接从局部的上下文获取所需的状态,而不是通过广作用域的BuildContext
进行查找。 -
代码示例(使用
InheritedWidget
):
-
class MyData extends InheritedWidget {
final int data;
MyData({required Widget child, required this.data}) : super(child: child);
static MyData of(BuildContext context) {
return context.dependOnInheritedWidgetOfExactType<MyData>()!;
}
@override
bool updateShouldNotify(MyData oldWidget) {
return data!= oldWidget.data;
}
}
class MyParentWidget extends StatefulWidget {
@override
_MyParentWidgetState createState() => _MyParentWidgetState();
}
class _MyParentWidgetState extends State<MyParentWidget> {
int counter = 0;
void incrementCounter() {
setState(() {
counter++;
});
}
@override
Widget build(BuildContext context) {
return MyData(
data: counter,
child: Column(
children: [
Text('Counter: $counter'),
ElevatedButton(
onPressed: incrementCounter,
child: Text('Increment'),
),
MyChildWidget(),
],
),
);
}
}
class MyChildWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
final data = MyData.of(context).data;
return Text('Data: $data');
}
}
三、优化状态管理
-
使用合适的状态管理方案,避免在 widget 树中使用广作用域的
BuildContext
来获取状态。-
例如,使用
Provider
、Bloc
等状态管理库,可以将状态的作用域限制在需要的部分,而不是让整个 widget 树都依赖于从根节点获取的状态。 -
代码示例(使用
Provider
):
-
import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
class Counter with ChangeNotifier {
int _count = 0;
int get count => _count;
void increment() {
_count++;
notifyListeners();
}
}
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return MaterialApp(
home: Scaffold(
appBar: AppBar(title: Text('Example')),
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: [
// 使用 Provider.of<Counter>(context).count 获取状态
Text('Count: ${Provider.of<Counter>(context).count}'),
ElevatedButton(
onPressed: () => Provider.of<Counter>(context, listen: false).increment(),
child: Text('Increment'),
),
],
),
),
),
);
}
}
四、避免深度查找
-
尽量避免在 widget 树中进行深度查找操作,因为这通常需要使用广作用域的
BuildContext
。- 如果需要查找特定类型的 widget,可以考虑使用更直接的方式,例如通过命名路由传递参数或者使用状态管理库来共享信息,而不是依赖于在 widget 树中进行深度查找。
- 例如,使用
Navigator.pushNamed
并传递参数,而不是在 widget 树中查找特定的路由管理 widget 来获取参数。 - 代码示例:
class MyFirstPage extends StatelessWidget {
@override
Widget build(BuildContext context) {
return ElevatedButton(
onPressed: () {
Navigator.pushNamed(
context,
'/secondPage',
arguments: {'data': 'Some data'},
);
},
child: Text('Go to Second Page'),
);
}
}
class MySecondPage extends StatelessWidget {
@override
Widget build(BuildContext context) {
final args = ModalRoute.of(context)!.settings.arguments as Map<String, dynamic>;
return Text('Received data: ${args['data']}');
}
}
通过以上方法,可以有效地避免在 Flutter 中使用具有广作用域的 BuildContext
,提高应用的性能和可维护性。