Flutter 小技巧之通过 MediaQuery 优化 App 性能

许久没更新小技巧系列,温故知新,在两年半前的《 MediaQuery 和 build 优化你不知道的秘密》 我们聊过了在 Flutter 内 MediaQuery 对应 rebuild 机制,由于 MediaQuery 在 MaterialApp 内,并且还是一个 InheritedWidget所以每当你使用一个 MediaQuery.of(context) ,其实就是在向 InheritedWidget 内登记更新绑定

具体例子如下图所示:

  • 我们在 MyHomePage 使用了 MediaQuery.of(context)
  • 然后我们跳转到 EditPage
  • EditPage 打开键盘,然后作为上一级页面的 MyHomePage 触发了一些列 rebuild 打印

上面的例子很好诠释了 MediaQuery.of(context) 使用不当的后果,特别是当堆栈内页面多的时候,就有很多不必要的开销 ,而要知道 MediaQuery 涉及 20 来参数,从各种边界到字体大小再到界面比例,可以说在 UI 适配时是经常使用的对象,特别是折叠屏场景更是必不可少,所以合理使用 MediaQuery 就非常重要。

而事实上同样代码,你只需要将 MediaQuery.of(context) 挪到页面 Scaffold 内去使用它的 ctx,就会发现第二个页面打开键盘时第一个页面不会触发 rebuild 了:

而为什么放到页面 Scaffold 内去使用 context 就好很多?这是因为 Scaffold 内通过「覆盖」MediaQuery ,让他的 body 等 child 部分在 MediaQuery.of(context) 时获取到的是 Scaffold 内的 MediaQueryData

另外由于 Scaffold 内部也大量使用 MediaQuery ,在触发 MediaQueryData 更新时,也会触发 Scaffold 的更新, 所以其内部像 body 等参数,也会通过 widget.body 实例等方式,从而避免由于 MediaQuery 更新导致其 child 重复 rebuild 的问题 :

更多细节可见:《 MediaQuery 和 build 优化你不知道的秘密》

所以我们知道,使用 MediaQuery 拿的是哪个 context 很重要 ,如果用错了非 Scaffold 的 context ,那么就很容易造成不必要的性能损耗。

而不同 context 也可能让你拿到不一样的参数结果,比如各种 padding 。

但是,前面我们说到 MediaQuery 本身带有那么多参数,如果我们只是在意 size ,但是键盘弹出的时候改变的是 viewInsets ,如果这样也导致页面更新,好像也不是很合理,所以后来(3.10) Flutter 更新了 MediaQuery.propertyOf 系列方法。

比如还是一开始的代码,但是我把 MediaQuery.Of(context) 换成 MediaQuery.sizeOf(context) ,入下图所示,在弹出键盘时同样不会触发上一级的 MyHomePage 的 rebuild ,因为此时它关联的是独立的 size 参数:

事实上类似的用法在 Scaffold 内部也用到了,基本上能通过 paddingOf sizeOfviewInsetsOf 等 propertyOf 方法获取到参数的,就不要直接用 .Of(context) ,这也是 3.10 之后 MediaQuery 上针对性的性能提升:

而之所以 propertyOf 系列参数可以做到约束 MediaQueryData 更新时只触发绑定参数的能力,内部主要还是在 context 登记时,通过 aspect 单独触发 InheritedModel 实现。

每个 InheritedModel 都是一个单独的 InheritedWidget 的实现,而这样 InheritedModel 内部的 InheritedModelElement 就会记录每个子组件依赖的 aspect,从而形成一个新的独立类型映射,因此 InheritedModel 支持订阅特定模型的变化。

另外,关于 MediaQueryData.fromWindow ,在上古版本内还有 MediaQueryData.fromWindow 这样的 API ,而现在都是 MediaQueryData.fromView ,而之所以这么调整是因为:

起初 Flutter 假定了它只支持一个 Window 的场景,所以会有 SingletonFlutterWindow 这样的 instance window 对象存在,同时 window 属性又提供了许多和窗口本身无关的功能,而这种设定在未来多窗口逻辑下会显得很另类。

所以后来开始废除单例 window ,改为 View.of(context) ,也就是可以通过 MediaQueryData.fromView(View.of(context)) 这样的方式获取 MediaQueryData ,类似的还有:

ini 复制代码
/// 3.10 之前
double dpr = WidgetsBinding.instance.window.devicePixelRatio;
Locale locale = WidgetsBinding.instance.window.locale;
double width =
   MediaQueryData.fromWindow(WidgetsBinding.instance.window).size.width;
​
​
/// 3.10 之后
double dpr = View.of(context).devicePixelRatio;
Locale locale = View.of(context).platformDispatcher.locale;
double width =
   MediaQueryData.fromView(View.of(context)).size.width;
​

可以看到,这里的 View 内部肯定也是一个 InheritedWidget ,它将 FlutterView 通过 BuildContext 往下共享,从而提供类似上古时代 「window」 的参数能力,而通过 View.of 获取的参数:

  • FlutterView 本身的属性值发生变化时,是不会通知绑定的 context 更新,这个行为类似于之前的 WidgetsBinding.instance.window
  • 只有当 FlutterView 本身发生变化时,比如 context 绘制到不同的 FlutterView 时,才会触发对应绑定的 context 更新

可以看到现在 View.of 这个行为考虑的是「多 FlutterView」 下的更新场景,如果在单 FlutterView 场景下,它几乎就是静态的,如果你不关心 MediaQuery 动态更新的场景,后者你更应该使用这类「静态获取」的方式。

更多可见 《一起来了解 View.of 和 PlatformDispatcher》

好了,今天的小技巧就到这里,温故知新,基本上今天的内容都是过去的片段,把它们放在一起之后,你应该就知道如何使用 MediaQuery 可以让你的 Flutter App 性能有所提升了吧?

相关推荐
字节暗面几秒前
四款 APP 加固强度测评:让 AI 拆了四个包,结果有点出乎意料
android·逆向工程·加固
七牛开发者3 分钟前
解读 Cordis:dsh 一切皆插件背后的运行时设计
前端·javascript·后端
BigTopOne12 分钟前
ArLiveLite 学习计划
前端
网安蟹佬霸27 分钟前
蓝队防御实战:SIEM与SOAR构建安全运营中心(万字详解+实战配置)
android·安全·web安全·网络安全·网安
慧都小项31 分钟前
夜间Web回归跑到一半停了?TestComplete 15.83提升批量测试稳定性
前端·测试工具·数据挖掘·回归·汽车·web
两只羊ovo34 分钟前
Agent ≠ 聊天机器人:从一问一答到 ReAct 循环,到底差在哪?
前端
摇曳的精灵42 分钟前
前端缓存优化
前端·缓存·缓存优化
老王以为1 小时前
走进 AI Agent 第二篇:决定 AI Agent 能力上限的关键技术
前端·人工智能·机器学习
何以解忧,唯有..1 小时前
Python 异常处理完全指南:从基础到高级实践
开发语言·前端·python
Buke..1 小时前
【小程序逆向】某游快爆 AI 逆向 sign参数:AI 辅助分析与 MCP 工具链实战
前端·人工智能·爬虫·python·小程序·notepad++