前言
我们可以通过MediaQuery.of(context)
方法获取到一些设备和系统的相关信息,比如状态栏的高度、当前是否是黑暗模式等等,使用起来相当方便,但是也要注意可能引起的页面rebuild问题。本文会介我们可以通过MediaQuery.of(context)
方法获取到一些设备和系统的相关信息,比如状态栏的高度、当前是否是黑暗模式等等,使用起来相当方便,但是也要注意可能引起的页面rebuild问题。本文会介绍一个典型的例子,并深入源码来探讨引起rebuild的原因,最后介绍避免rebuild的几个办法。
绍一个典型的例子,并深入源码来探讨引起rebuild的原因,最后介绍避免rebuild的几个办法。
典型例子
以快递App中的查快递场景举例,首页用MediaQuery.of(context).padding.top
获取了状态栏高度,用户点击“查快递”按钮会跳转到查快递界面,在查快递界面,用户输入单号可进行查询操作。
当首页的build方法被调用时,会输出我们提前加好的日志。我们发现,当查快递界面的键盘弹出时,首页的build方法被调用了多次:
主界面的build代码如下:
源码探究
既然是因为主界面在build方法里使用了MediaQuery.of(context)
,从而导致当键盘弹出/隐藏时进行rebuild操作,那么就先来看下MediaQuery
类。
其继承自InheritedWidget
,自身并没有重写createElement
方法,从flutter三棵树的角度讲,对应的Element
即为InheritedElement
。有两个属性,data和child,我们可以从data中获取一些设备/系统相关的属性。
另外还有两个比较重要的方法:
此方法直接返回_MediaQueryFromWindow
对象,后面会详细介绍。
of(context : BuildContext)
方法里调用了dependOnInheritedWidgetOfExactType,接下来我们详细分析下背后的调用流程。
MediaQuery.of(context) 调用流程
入参是context
,本例中的主界面是StatelessWidget
,那么这里的context
便是StatelessElement
。整体调用流程如下:
从_inheritedWidgets
列表中查询是否有MediaQuery
类型的InheritedElement
,从三棵树的角度讲,就是从当前节点一直向上查找,找到最近的MediaQuery
控件。如果找到,则调用dependOnInheritedElement
方法(一般情况下是一定能找到的,下面再详细介绍)。
dependOnInheritedElement
此方法负责将找到的InheritedElement
(也就是MediaQuery
对应的Element
)存起来,并且调用InheritedElement#updateDependencies
方法。
updateDependencies
setDependencies
最后两个方法很简单,其作用是将主页对应的StatelessElement
存储到了MediaQuery
对应的InheritedElement#_dependents
中。
研究完MediaQuery.of(context)
背后的原理,我们可以知道:通过调用of方法,主界面对应的Element
和MediaQuery
建立了绑定关系,MediaQuery
对应的InheritedElement
存储了主界面Element
的引用。
Rebuild起点
当介绍dependOnInheritedWidgetOfExactType
方法时,我们提道:从当前节点往父节点寻找,一般情况下是一定能找到的MediaQuery
控件的。这是因为在WidgetsApp
里会自动给我们创建一个根MediaQuery
。
在main
方法里,无论使用CupertinoApp
还是MaterialApp
,最后都会在内部创建WidgetsApp
。我们直接看_WidgetsAppState#build
方法里的一个代码片段:
会首先检查widget.useInheritedMediaQuery
,这个属性默认为false
。如果你创建MaterialApp
/CupertinoApp
时,没有设置useInheritedMediaQuery
属性,或者设置了这个属性为null,但找不到MediaQueryData
,那么这里就会调用MediaQuery.fromWindow
方法。
上面介绍MediaQuery#fromWindow
时,我们知道它会创建_MediaQueryFromWindow
控件。
_MediaQueryFromWindow
的代码不是很多,把和本文相关的代码全部贴出来了,大家可以自己看下,代码如上图所示。
build
方法里创建了MediaQuery
控件,并实现了didChangeMetrics
方法,当手机发生旋转、键盘弹出/隐藏时就会调用此方法,didChangeMetrics
内部又调用了setSate
,从而导致build
方法被重新调用。
通过flutter三颗树的原理我们可以知道,上述所说的“build方法被重新调用”涉及到MediaQueryFromWindow
对应的Element
的updateChild
方法,简单看下updateChild
的内部处理规则:
对MediaQueryFromWindow而言,每次都会创建新的MediaQuery Widget,根据Element#updateChild源码(不是本文讨论重点,不再详细分析其源码)得知,最终会调用MediaQuery对应的Element的update方法。
经过一系列的跳转过后,最终会调用到下面的两个核心方法:
上面介绍的MediaQuery.of(context)
方法最终会把入参Context
放到_dependents
变量里,而这里会遍历这个map
,调用每一个Context
的didChangeDependecies
方法,didChangeDependecies
会将此Context
置为dirty状态,下一帧来临时会被重新绘制,并调用此Context
的build
方法。
所以,破案了,当键盘弹起/隐藏时快递主页会被rebuild的原因找到了!
整体的rebuild调用流程如下,感兴趣的可以结合这个调用流程图去看源码:
避免rebuild的办法
研究过源码后,解决方案就变的很简单。
- 自定义
useInheritedMediaQuery
属性为true,并在最外面包一层MediaQuery
,让WidgetsApp
创建时使用MediaQuery
,而不去使用监听了application尺寸变化的_MediaQueryFromWindow
控件。
- 避免在页面中使用
MediaQuery.of(context)
方法,可以使用对应的替代方法,比如本例可以采用下面的代码进行替代,注意单位的转换。
- 如果必须要使用
MediaQuery.of(context)
方法,可以使用Builder
控件包裹下,of方法的入参传入此Builder
的context
即可,这样被rebuild仅是Builder
控件包裹下的widget子树。
总结
app界面逐渐复杂时,我们不得不考虑去优化界面性能。本文中介绍的例子在开发中是很常见的,如果不了解MediaQuery.of的机制,可能会引起大量使用此方法的界面发生重绘操作,造成页面卡顿、帧率下降。我们详细分析了背后的源码逻辑,介绍了解决办法,希望能给大家的调优工作提供些许帮助。
作者:京东物流 沈明亮
来源:京东云开发者社区