江宁网站建设制作,wordpress指定域名,wordpress风格化页面,wordpress能做多用户theme: cyanosis 前言 本文来分享一下#xff0c;通过查看源码和布局信息解决的一个实际中的布局小问题#xff0c;也希望通过本文的分享#xff0c;当你遇到布局问题时#xff0c;可以靠自己的脑子和双手解决问题。 如下所示#xff0c;将 TextField 作为 AppBar 组件的 … theme: cyanosis 前言 本文来分享一下通过查看源码和布局信息解决的一个实际中的布局小问题也希望通过本文的分享当你遇到布局问题时可以靠自己的脑子和双手解决问题。 如下所示将 TextField 作为 AppBar 组件的 title 入参可以看出它非常高看着很不舒适。想将其高度变窄下意识地使用 Padding 组件给一个竖直边距这样由于竖直约束减少会迫使 TextField 变窄。但是事与愿违它竟纹丝不动我大呼有趣事出反常必有妖源码分析走一波。开整 ~ const TextField( decoration: InputDecoration( filled: true, fillColor: Color(0xffF3F6F9), border: UnderlineInputBorder( borderSide: BorderSide.none, borderRadius: BorderRadius.all(Radius.circular(8)), ), hintText: 输入 0~99 数字, hintStyle: TextStyle(fontSize: 14)), ) 1. 通过布局分析原因 靠脑子想想应该是 AppBar#title 组件在竖直方向上的约束有所反常。 所以立刻打开 Flutter Inspector 查看 TextField 收到的约束信息果然其下第一个渲染对象约束在高度上是 0~Infinity 难怪 Padding 无法生效。 解决方案其实就很简单了既然竖直方向为无限约束那只要修改约束即可。因为是 0~Infinity 所以想指定固定高度也很简单SizedBox 施加紧约束就行了。 正好借此机会来了解一下 TextField 可以看出其尺寸高度是 48 那这个 48 是如何确定的又如何更改呢 我们继续看布局树之后的节点会发现一个很有意思的事其下的 _Editable 尺寸高度是 19 。 那么从 19 - 48 之间肯定存在一个突变点。这个点就非常可能是决定 TextField 高度的关键只要沿布局树自下而上查找尺寸是 48 的渲染对象就行了。然后可以很轻松地找到高度的突变是由 _Decorator 产生的装饰宽产生高度的变化也合情合理。 2.从 TextField 源码看 _Decorator 既然已经找到了嫌疑犯那就进源码里瞟一眼_Decorator 组件是何时被构建入 TextField 中的。也不用盲目寻找从布局树中很容易看出 _Decorator 组件是在 InputDecorator 组件之中的 使用很明显是 TextField 构建装饰时嵌入到结构中的如下所示 在 InputDecorator 的状态类中可以看到使用了 _Decorator 组件 3. _Decorator 组件的约束来源 紧接着可以看出 _Decorator 组件会被通过 ConstrainedBox 组件施加约束。约束值会取装饰对象的约束属性如果没有会取主题数据中输入装饰的约束 可以通过调试来查看一下可以看出默认情况下是主题中没有装饰约束也就是说默认情况下 48 的高度是由 _Decorator 组件对于的渲染对象在布局时确定的。 到这里就很容易知道如何优雅地修改 TextField 的高度。只要轻轻地在 InputDecoration 中加入一个 constraints 约束即可。这个约束对象的 药效生效 的时机在刚才已经从源码中看过了。 TextField( decoration: InputDecoration( constraints: BoxConstraints(maxHeight: 35), //略... 4. 渲染对象的尺寸确定 上面说默认情况下 _Decorator 组件对于的渲染对象高度是 48 。你有没有好奇这个 48 在源码中究竟是如何计算出来的没兴趣的话到这里你就可以走人了 ~ 通过源码可以看出 _Decorator 组件集成自 RenderObjectWidget 这在 Widget 族系中算比较高层的衍生。 RenderObjectWidget 的作用是创建和维护对于的渲染对象它的子类将实现相关方法。在 createRenderObject 方法中很容易看出组件对应的渲染对象是 _RenderDecoration 。 也就是说默认高度 48 的幕后黑手就是它。 _RenderDecoration 继承自 RenderBox 我们知道 RenderBox 一族已经有了 size 的概念。而尺寸的确定一般是在渲染对象覆写的 performLayout 方法中进行的。 如下所示就是 _RenderDecoration 渲染对象为 size 成员属性赋值的时机。而上层传递的约束会作为改尺寸的限制条件生动形象地体现出了上层传递过来的约束对于当前渲染对象自身尺寸的作用力 从调试中可以很清楚地看出 overallHeight 是 48 至于它为什么是 48 overallHeight 是在一个方法在的局部变量它是如何被赋值的并不难被追踪。话都说到这里了感兴趣的可以自己调试追一下。 本文通过一个问题衍生出对尺寸和约束的分析。希望大家在日常开发中遇到问题也可以多多思考从源码的角度去审视一切对问题进行降维打击。那本文就到这里谢谢观看 ~
