Avalonia源码解读:Grid(网格控件)
<p>在各类XAML UI框架中,<code>Grid</code> 是一种非常灵活且常用的布局控件,它可以创建复杂的用户界面布局。<code>Grid</code> 允许开发者通过定义行和列来组织界面元素,每个元素可以精确地放置在网格的特定区域内</p><p>本文以 Avalonia 框架为例,讲解 <code>Grid</code> 控件的工作原理</p>
<blockquote>
<p>事实上,UWP、WinUI 3 和 Avalonia 等XAML框架中 <code>Grid</code> 控件的源码全都源自于 WPF 中的实现,以至于绝大部分代码乃至注释都是相同的</p>
<p>因此,本文中你能了解到的机制也可应用于其他 XAML UI 框架</p>
</blockquote>
<hr>
<h1 id="measure-阶段">Measure 阶段</h1>
<blockquote>
<p><strong>快速路径</strong>:当仅仅存在一个行/列(或未定义行列)时,将子元素中最大的宽和高设置为为 <code>Grid</code> 的大小即可。</p>
<pre><code class="language-csharp">gridDesiredSize = new Size(
Math.Max(gridDesiredSize.Width, child.DesiredSize.Width),
Math.Max(gridDesiredSize.Height, child.DesiredSize.Height));
</code></pre>
</blockquote>
<p>在一般情况下,我们定义了两个及以上以上的行/列,就需要一套特定的算法进行计算</p>
<p>我们知道,Grid的行/列定义有<code>Auto</code>、<code>Star</code>、<code>Pixel</code>三类</p>
<p>简化后的定义如下:</p>
<pre><code class="language-csharp">public class Definition
{
public double MinSize { get; set; }// 对应MinHeight(MinWidth),以Pixel为单位
public double MaxSize { get; set; }// 对应MaxHeight(MaxWidth),以Pixel为单位
public GridLength Size { get; set; }// 对应Height(Width),对应不同单位下的值
double MeasureSize { get; set; }// 测量阶段的结果
double FinalSize { get; set; }// 排列阶段的结果
double FinalOffset { get; set; }// 最终偏移量
}
</code></pre>
<blockquote>
<p>此处将 <code>Width/Height</code> 更改为 <code>Size</code>,不再区分行列</p>
<p>源代码中为了性能,上面的一些属性(如<code>FinalSize</code>、<code>MaxSize</code>)使用的是同一个字段,为便于理解,这里将他们拆分开来单独列出。具体代码可以自行前往Avalonia存储库查看</p>
</blockquote>
<p>在测量 (<code>Measure</code>) 的过程中,<code>Grid</code> 遵循"<strong>可确定大小优先</strong>"的原则。因此,他们将要渲染的元素分为四组来决定测量顺序</p>
<table>
<thead>
<tr>
<th></th>
<th><code>Px</code></th>
<th><code>Auto</code></th>
<th><code>Star</code></th>
</tr>
</thead>
<tbody>
<tr>
<td><code>Px</code></td>
<td>1</td>
<td>1</td>
<td>3</td>
</tr>
<tr>
<td><code>Auto</code></td>
<td>1</td>
<td>1</td>
<td>3</td>
</tr>
<tr>
<td><code>Star</code></td>
<td>4</td>
<td>2</td>
<td>4</td>
</tr>
</tbody>
</table>
<p>通常情况下,测量的顺序如下:</p>
<div class="mermaid">flowchart LR
X[初始化] --> A[分组] --> B[测量Group1] --> C[解析Star行] --> D[测量Group2] --> E[解析Star列] --> F[测量Group3] --> G[测量Group4]
</div><blockquote>
<p>根据 <code>Group2</code>、<code>Group3</code> 元素的存在情况,测量组和解析 <code>Star</code> 项的顺序会有所不同,但 <code>Group1</code> 和 <code>Group4</code> 的测量顺序始终不变</p>
<p>具体流程将在后面介绍</p>
</blockquote>
<p>我们先依次介绍 <code>Measure</code> 过程中使用的主要算法</p>
<hr>
<h2 id="validatedefinitionsstructurevalidatedefinitionslayout初始化行列定义"><code>ValidateDefinitionsStructure、ValidateDefinitionsLayout</code>:初始化行/列定义</h2>
<p>分组前,<code>Grid</code> 会先初始化行/列定义的结构:如果只有行定义,<code>Grid</code> 会自动添加一个<code>Width = *</code>的列定义;同理,如果只有列定义,会自动添加一个行定义</p>
<p>同时,如果传入了无限的长或宽,其对应的所有 <code>Star</code> 定义都会被视作 <code>Auto</code> 项</p>
<h2 id="validatecells分组预处理所有子元素"><code>ValidateCells</code>:分组,预处理所有子元素</h2>
<p>分组过程中,<code>Grid</code> 中的每个元素都将被视作一个 <code>Cell</code>,他们根据所在行/列的类型被分配到不同组中,以便稍后进行进一步的计算</p>
<p>所有 <code>Cell</code> 以链表的形式被缓存,每个 <code>CellGroup</code> 存储的是当前组的头节点,在后续测量中使用 <code>Cell.Next</code> 进行遍历</p>
<h2 id="measurecellsgroup测量组"><code>MeasureCellsGroup</code>:测量组</h2>
<h3 id="group--1项的类型为-pxauto">Group = 1:项的类型为 <code>Px/Auto</code></h3>
<p>测量每个元素的机制如下:</p>
<ul>
<li>
<p><code>Px</code> 项:<code>def.Size</code> 作为元素 <code>Measure</code> 边界</p>
</li>
<li>
<p><code>Auto</code> 项:传入无限尺寸作为元素 <code>Measure</code> 边界</p>
<p>同时,当某个元素测量完成时,还会<strong>根据元素的高度更新元素所在项的最小大小</strong></p>
<p><em>项最小尺寸的<strong>初始值</strong>与最大尺寸由用户设定,如<code>RowDefinition.Min/MaxHeight</code></em></p>
<pre><code>def.MinSize = Math.Clamp(child.DesiredSize, def.MinSize, def.MaxSize)
</code></pre>
<p>若元素的 <code>RowSpan > 1</code>(可能跨项),则<strong>不更新项最小值</strong>,并且在其他元素均测量完毕后,确保这些跨项元素尺寸在<strong>其所在所有项尺寸</strong>的最小值/最大值之间</p>
</li>
</ul>
<h3 id="group--1元素在某个--star-类型的项中">Group ≠ 1:元素在某个<code>Star</code> 类型的项中</h3>
<blockquote>
<p>根据顺序,此时已完成目标组 <code>Star</code> 项的大小解析,因此 <code>definitions.MeasureSize</code> 是有值的</p>
</blockquote>
<p>使用 <code>GetMeasureSizeForRange</code> 方法,遍历元素跨越的所有项,将这些项的最小值(<code>Auto</code> 项)或测量值(<code>Star</code> 项)相加,得到元素测量时的边界</p>
<pre><code class="language-csharp">private static double GetMeasureSizeForRange(
IReadOnlyList<DefinitionBase> definitions,
int start/*起始项位置*/,
int count/*跨越项数(RowSpan)*/,
double spacing)
{
double measureSize = -spacing;
int i = start + count - 1;
do
{
measureSize +=
spacing + // 跨行元素可忽视所跨项之间的spacing
(definitions.SizeType == LayoutTimeSizeType.Auto ?
definitions.MinSize :
definitions.MeasureSize);
} while (--i >= start);
return measureSize;
}
</code></pre>
<p>同理,<strong>每个元素测量完成时也会更新其所在项的最小值</strong>,也会在所有元素测量完成后确保跨项元素尺寸在正确范围内</p>
<h2 id="resolvestar统一解析star项分配权重"><code>ResolveStar</code>:统一解析Star项,分配权重</h2>
<p><code>Group1</code> 测量完毕后,我们已经得到了所有固定元素的尺寸,现在以以下流程计算各 <code>Star</code> 项的尺寸:</p>
<ol>
<li>
<h3 id="预处理权重">预处理权重</h3>
<p>遍历 <code>definitions</code>,统计Star项的数量并得到最大权重 <code>maxStar</code>,同时将所有Star项的 <code>MeasureSize</code> 设置为 1.0,表示尚未在后续阶段解析。</p>
<p>引入 <code>scale</code> 值用于后续缩放,防止浮点溢出:</p>
<ul>
<li>若存在 Infinity 权重,设置 <code>scale = -1.0</code></li>
<li>若不存在 Infinity 权重但权重和可能溢出(<code>starCount * maxStar > Double.Max</code>),将 <code>scale</code> 设置为 2 的负次幂</li>
</ul>
</li>
<li>
<h3 id="计算可用空间预处理约束">计算可用空间,预处理约束</h3>
<p>再次遍历 <code>definitions</code> ,计算所有非Star项所占用的空间 <code>takenSize</code></p>
<p>对于 <code>Star</code> 项,计算缩放后的权重值 <code>starWeight = star * scale</code>,并累计到 <code>totalStarWeight</code></p>
<ul>
<li>若 scale < 0(存在Infinity权重),将 Infinity 项映射为 1,其余映射为 0</li>
</ul>
<p>如果项存在最小约束(<code>MinSize > 0</code>,由用户设置),将该项加入"最小约束列表",并暂存比率 <code>def.minRatio = starWeight / def.MinSize</code></p>
<p>同理,若存在最大约束(<code>MaxSize ≠ Infinity</code>),将该项加入"最大约束列表",暂存 <code>def.maxRatio = starWeight / def.MaxSize</code></p>
<blockquote>
<p>为提升性能,实际实现中"最小约束列表"和"最大约束列表"存储在同一列表 <code>definitionIndices</code> 中,分别为前后两个部分</p>
</blockquote>
</li>
<li>
<h3 id="迭代解析约束项">迭代解析约束项</h3>
<p>来看一个例子:</p>
<pre><code class="language-xaml"><!--C1--><ColumnDefinition Width="*" MinWidth="120"/>
<!--C2--><ColumnDefinition Width="2*"/>
<!--C3--><ColumnDefinition Width="3*" MaxWidth="150"/>
</code></pre>
<p>假设可用尺寸 <code>S=400</code>,这时候我们可以发现:如果要满足定义中的 <code>Min/MaxWidth</code> 约束,是无法实现 1 : 2 : 3 的比例的。因此,我们需要将与<strong>比例差距最大</strong>的项"锁定"为 <code>Min/MaxWidth</code></p>
<p>但我们又希望锁定后的比例尽可能接近定义的比例,因此 <code>Grid</code> 使用了以下算法:</p>
<div class="mermaid">flowchart TD
A["阶段3:处理约束项"]
B["按照 最小比率、最大比率 排序约束列表"]
C{"有剩余空间且存在未处理的约束项?"}
D["计算当前比例"]
E{"是否违反某个约束?"}
F["选择偏差最大的约束"]
G["将该项尺寸锁定为此约束值"]
H["更新剩余权重与剩余空间"]
I["结束"]
A --> B --> C
C -- "是" --> D
D --> E
C -- "否" --> I
E -- "是" --> F
F --> G --> H
E -- "否" --> I
H --> C
</div><p>先对最小约束列表按照比率<strong>降序</strong>,最大约束列表按照比率<strong>升序</strong>排序</p>
<p>初始 <code>remainingAvailableSize=S=400</code>,<code>remainingStarWeight=W=6</code></p>
<p>下面按照每次锁定"差异最大"的一个 <code>definition</code> 来迭代解析约束项:</p>
<h5 id="第一次迭代">第一次迭代:</h5>
<ul>
<li>
<p>从最小/最大约束列表中分别选出 <code>C1.minRatio</code> == 1/120 == 0.008333 ,<code>C3.maxRatio</code> == 3/150 == 0.02</p>
</li>
<li>
<p>计算比例 <code>proportion = remainingStarWeight / remainingAvailableSize</code> = 6/400 = 0.015</p>
</li>
<li>
<p>判定是否违反比例:</p>
<ul>
<li>违反最小约束:<code>minRatio < proportion</code> => 0.008333 < 0.015(成立)</li>
<li>违反最大约束:<code>maxRatio > proportion</code> => 0.02 > 0.015(成立)</li>
</ul>
<blockquote>
<p>如果认为"比例"不好理解,可以从反面考虑:</p>
<p>假设步骤 2 中 <code>def.MinSize / starWeight</code> 代表<strong>每颗星的最小大小</strong> <code>minStarSize</code>,<code>def.MaxSize / starWeight</code> 代表<strong>每颗星允许的最大大小</strong><code>maxStarSize</code></p>
<p>那么 <code>remainingAvailableSize / remainingStarWeight</code> 代表<strong>当前每颗星的大小</strong><code>currentStarSize</code></p>
<p>必须满足 <code>minStarSize ≤ currentStarSize ≤ maxStarSize</code>,否则就需要选择偏离最大的项进行锁定</p>
</blockquote>
</li>
<li>
<p>二者都需要锁定,选择<strong>偏离更大</strong>的一项:</p>
<ul>
<li>
<p>对最小约束的偏离:<code>proportion / minRatio</code> = 0.015 / 0.008333 ≈ 1.8</p>
</li>
<li>
<p>对最大约束的偏离:<code>maxRatio / proportion</code> = 0.02 / 0.015 ≈ 1.333</p>
</li>
<li>
<p>1.8 > 1.333 => 优先锁定 <code>C1</code> 尺寸为 <code>C1.MinSize</code></p>
</li>
</ul>
</li>
<li>
<p>执行锁定:</p>
<ul>
<li>
<p>设置 <code>C1</code> 尺寸为约束最小值:<code>resolvedSize = C1.MinSize= 120</code></p>
</li>
<li>
<p>更新可用空间和剩余权重:</p>
<p><code>remainingAvailableSize = 400 - resolvedSize= 400-120 = 280</code></p>
<p><code>remainingStarWeight = 6 - C3.starWeight = 6 - 1 = 5</code></p>
</li>
</ul>
</li>
</ul>
<h5 id="第二次迭代">第二次迭代:</h5>
<ul>
<li>
<p><code>maxRatio</code> = 0.02(仍为 <code>C3</code> )</p>
</li>
<li>
<p><code>proportion</code> = 5/280 ≈ 0.017857</p>
</li>
<li>
<p>仅违反最大约束:0.02 > 0.017857 => <code>C3</code> 尺寸锁定为 <code>C3.MaxSize</code></p>
</li>
<li>
<p>执行锁定:</p>
<ul>
<li>设置 <code>C3</code> 尺寸为约束最大值:<code>resolvedSize = C3.MaxSize</code> = 150</li>
<li><code>remainingAvailableSize</code> = 280 -150 = 130;<code>remainingStarWeight</code> = 5 - 3 = 2</li>
</ul>
</li>
</ul>
<p>最小/最大约束列表均为空 => 退出。</p>
</li>
<li>
<h3 id="检测异常场景并重复执行-23">检测异常场景并重复执行 2、3</h3>
<p>完成步骤 3 后,可能会有以下异常场景:</p>
<ul>
<li>
<p><code>remainingAvailableSize > 0</code> 且 <code>Star</code> 项全部处理完毕:所有 <code>Star</code> 项都被其最大约束锁定,但所有最大约束之和仍小于边界</p>
<p>遍历所有项,解锁<strong>存在最小约束</strong>的项,重新执行步骤 2、3 为其分配空间</p>
</li>
<li>
<p><code>remainingAvailableSize < 0</code>:某些项被最小约束锁定,但所有最小约束之和超过了边界</p>
<p>同理,解锁<strong>存在最大约束</strong>的项,重新执行 2、3</p>
</li>
</ul>
</li>
<li>
<h3 id="前缀和算法分配剩余空间">前缀和算法分配剩余空间</h3>
<p>相比<code>权重/权重总和*剩余空间</code>,此算法<strong>可以避免浮点数计算带来的精度丢失</strong></p>
<p>可以用一个例子说明此算法:</p>
<p>假设权重分别为 <code></code>,剩余空间为 6</p>
<p>计算权重前缀和 <code></code></p>
<p>现在以权重从大到小的顺序开始分配</p>
<ul>
<li>分配 <code>6*(3/6) = 3</code>,剩余空间 6-3=3</li>
<li>分配 <code>3*(2/3) = 2</code>,剩余空间 3-2=1</li>
<li>分配 <code>1*(1/1) = 1</code>,剩余空间 1-1=0,完成</li>
</ul>
<p>简化后的算法如下(此处默认所有项的类型为 <code>Star</code> ):</p>
<pre><code class="language-csharp">Array.Sort(definitions);
// 计算前缀和
totalStarWeight = 0.0;
for (int i = 0; i < definitions.Length; ++i)
{
DefinitionBase def = definitions;
totalStarWeight += def.MeasureSize;// MeasureSize在此处代表Star数量
def.SizeCache = totalStarWeight;// SizeCache用于缓存前缀和结果
}
// 从后向前遍历
for (int i = definitions.Length - 1; i >= 0; --i)
{
DefinitionBase def = definitions;
double resolvedSize = (availableSize - takenSize) * (def.MeasureSize / def.SizeCache);
def.MeasureSize = resolvedSize;
takenSize += resolvedSize;
}
</code></pre>
</li>
</ol>
<hr>
<p>现在,你应该对测量中使用的算法有了大概了解。但测量顺序具体是怎么样的呢?以及,为什么要遵守这样的测量顺序?</p>
<p>我们再看一下之前的分组表:</p>
<table>
<thead>
<tr>
<th></th>
<th><code>Px</code></th>
<th><code>Auto</code></th>
<th><code>Star</code></th>
</tr>
</thead>
<tbody>
<tr>
<td><code>Px</code></td>
<td>1</td>
<td>1</td>
<td>3</td>
</tr>
<tr>
<td><code>Auto</code></td>
<td>1</td>
<td>1</td>
<td><strong>3</strong> <em></em></td>
</tr>
<tr>
<td><code>Star</code></td>
<td>4</td>
<td><strong>2</strong> <em></em></td>
<td>4</td>
</tr>
</tbody>
</table>
<p>重点看加粗的部分:以 <strong>A部分</strong> (在 <code>Group3</code> 中)为例,在测量这部分的元素前,必须得到 <code>Auto</code> 列的大小。因此,测量 <code>Group3</code> 前必须完成对 <code>Group1</code> 和 <code>Group2</code>的测量</p>
<p>同样,B 部分在测量之前也必须得到 <code>Auto</code> 行的大小,在测量 <code>Group2</code> 前必须完成对 <code>Group1</code> 和 <code>Group3</code> 的测量</p>
<p>AB 部分的共同特性就是<strong>同时存在于 <code>Auto</code> 和 <code>Star</code> 项</strong>中,我们可以得出以下结论:</p>
<ul>
<li>A 部分中存在元素:测量 <code>Group1</code>、<code>Group2</code> 后才能测量 <code>Group3</code></li>
<li>B 部分中存在元素:测量 <code>Group1</code>、<code>Group3</code> 后才能测量 <code>Group2</code></li>
</ul>
<p>如果 A、B 部分都存在元素呢?比如下面的情况:</p>
<table>
<thead>
<tr>
<th></th>
<th style="text-align: left">column width="Auto"</th>
<th>column width="*"</th>
</tr>
</thead>
<tbody>
<tr>
<td>row height="Auto"</td>
<td style="text-align: left"></td>
<td>cell 1 2 <em></em></td>
</tr>
<tr>
<td>row height="*"</td>
<td style="text-align: left">cell 2 1 <em></em></td>
<td></td>
</tr>
</tbody>
</table>
<p>由于 <code>cell 2 1</code> 的宽度决定了 <code>Auto</code> 列的宽度,进而间接决定 <code>cell 1 2</code> 所在列的宽度,需要先计算 <code>cell 2 1</code>。然而,由于 <code>cell 1 2</code> 的高度决定了 <code>Auto</code> 行的高度,同理, <code>cell 2 1</code> 也理应先被计算—— <code>Auto</code> 与 <code>Star</code> 的行列相互影响,这就是 <code>Grid</code> 行列解析中的<strong>循环依赖</strong>问题。</p>
<p>综上所述,<code>Grid</code> 共有三种不同的测量顺序,流程图如下:</p>
<div class="mermaid">graph TD
%% 流程开始
Start() --> VC[分组<br>ValidateCells] --> MG1[测量Group1]
MG1 --> CondV{能否解析Star行?<br>A中没有元素}
%% 分支 1:可以 Resolve StarsV (Yes)
CondV -- 是<br>(一般路径,先解析Star行) --> RSV1[解析Star行]
RSV1 --> MG2[测量Group2]
MG2 --> RSU1[解析Star列]
RSU1 --> MG3_1[测量Group3]
%% 分支 2:不能 Resolve StarsV (No) -> 进入第二个判断
CondV -- 否 --> CondU{能否解析Star列?<br>B中没有元素}
%% 子分支 2A:可以 Resolve StarsU (Yes)
CondU -- 是<br>(先解析Star列即可) --> RSU2[解析Star列]
RSU2 --> MG3_2[测量Group3]
MG3_2 --> RSV2[解析Star行]
%% 子分支 2B:不能 Resolve StarsU (No)
CondU -- 否<br> --> MG2P["测量Group2<br>(使用无限高度)"]
subgraph CYCLE[循环依赖]
MG2P --> RSU3[解析Star列]
RSU3 --> MG3_3[测量Group3]
MG3_3 --> RSV3[解析Star行]
RSV3 --> MG2PP["测量Group2"]
MG2PP --> CondR{总宽未改变<BR>或循环次数≥5}
CondR -- 否 --> RSU3
end
%% 汇聚点
MG3_1 --> MG4[测量Group4]
RSV2 --> MG4
CondR -- 是 --> MG4
%% 结束
MG4 --> Exit([结束])
</div><h2 id="循环依赖的处理">循环依赖的处理</h2>
<p>对于产生了循环依赖的布局,我们无法直接测量 AB 组的大小。因此,我们需要先在测量 <code>Group2</code>(也就是 B 组) 时使用无限高度以先<strong>得到其宽度</strong>,再解析 <code>Star</code> 列</p>
<p>Star列被解析完毕后,就可以测量 <code>Group3</code> 中的元素了,此时再解析Star行即可重新以正确的行高测量 <code>Group2</code></p>
<p><img src="https://img2024.cnblogs.com/blog/3275657/202512/3275657-20251216014123058-445879001.gif" alt="Grid_1" loading="lazy"></p>
<h3 id="更为极端的情况">更为极端的情况</h3>
<p>如果 <code>Group2</code> 中的元素再使用<strong>不同高度测量时得到的宽度</strong>不同(例如,纵向排列的 <code>WrapPanel</code> ),这代表第一次使用无限高度测量 <code>Group2</code> 后解析得到<strong><code>Star</code>列的宽度是错误的</strong>!这时候我们需要返回并重新对 <code>Group3</code> 进行测量...</p>
<p>在重新测量的过程中,我们还要将 <code>Auto</code> 项的尺寸恢复到测量 <code>Group1</code> 后的状态,<strong>来尽可能保证测量 <code>Group2</code> 时的参数相等</strong></p>
<p>此流程会一直循环,直到<strong>两次<code>Group2</code>宽度的测量结果相同</strong>或循环次数 ≥5</p>
<p><img src="https://img2024.cnblogs.com/blog/3275657/202512/3275657-20251216013856017-1740783861.gif" alt="Grid_2" loading="lazy"></p>
<h1 id="arrange-阶段">Arrange 阶段</h1>
<p>由于行列大小计算已经在 <code>Measure</code> 阶段完成,<code>Arrange</code> 阶段只需要计算每个行列的最终位置并处理一些特殊设置即可。</p>
<h2 id="重新解析-star-项">重新解析 <code>Star</code> 项</h2>
<p>由于 <code>Measure</code> 阶段提供的约束可能与 <code>Arrange</code> 阶段提供的空间不一致,我们需要使用与 <code>ResolveStar</code> 相同的方式再次解析一遍 <code>Star</code> 项</p>
<p>至于为何两个阶段提供的空间可能不一致,就涉及到 <code>Measure/Arrange</code> 机制了,具体可参阅 布局 - WPF | Microsoft Learn</p>
<h2 id="spacing-处理"><code>Spacing</code> 处理</h2>
<p>在 <code>Measure</code> 阶段前,我们在原边界大小的基础上减去所有间距之和后再进行测量,对 <code>spacing</code> 的单独处理仅限于跨行元素(见<code>GetMeasureSizeForRange</code>)。</p>
<p>因此,在处理元素最终的偏移量 <code>FinalOffset</code> 时,我们需要在每次迭代都加上对应的 <code>spacing</code></p>
<pre><code class="language-csharp">for (int i = 0; i < definitions.Count; ++i)
{
definitions[(i + 1) % definitions.Count].FinalOffset = definitions.FinalOffset + definitions.FinalSize + spacing;
}
</code></pre>
<h2 id="布局舍入-layoutrounding">布局舍入 (<code>LayoutRounding</code>)</h2>
<p>为了避免影响前面的测量进程,布局舍入在 <code>Arrange</code> 的最后阶段执行</p>
<ul>
<li>遍历所有项,将其尺寸根据当前 DPI 四舍五入,并把<strong>舍入后大小 - 原始大小</strong>写入 <code>RoundingErrors</code></li>
<li>计算舍入后大小 <code>roundedTakenSize</code> 与舍入前大小 <code>finalSize</code> 的差值。若不相等,就需要进一步调节各项以分配余额或去除溢出</li>
<li>将所有项根据 <code>RoundingErrors</code> 排序,在<strong>差值最大的项</strong>上增加或减少像素(以 <code>dpiIncrement = 1 / dpi</code> 为单位)进行调节,同时确保不低于 <code>MinSize</code></li>
</ul>
<blockquote>
<p>顺带一提,代码中用了一段很长的注释来说明当前的布局舍入算法是存在问题且无法解决的:</p>
<pre><code>(由 Gemini 3 Pro 翻译)
// 理论和历史说明。当前的问题——即在带有星号权重(*-weights)、
// 最小和最大约束以及布局舍入的情况下向列(或行)分配空间——由来已久。
// 特别是那个著名的特例:50列,最小值为1,可用空间为435——
// 这正是根据人口比例向50个州分配美国众议院席位的问题。
// 关于这一问题的算法和论文无数,最早可追溯到1700年代,包括这本书:
// Balinski, M. 和 H. Young 所著的《Fair Representation》(公平代表),耶鲁大学出版社,纽黑文,1982年。
//
// 所有这些研究得出的一个惊人结果是:*任何*算法都难免会遭受一个或多个
// 不良特性的困扰,例如“人口悖论”或“阿拉巴马悖论”。
// 在这种情况下(套用我们的术语来说),增加一个像素的可用空间实际上
// 可能会减少分配给特定列的空间,或者增加某列的权重反而可能会减少其分配量。
// 这一点值得了解,以防有人抱怨这种行为;这与其说是一个 Bug,
// 不如说是问题本身固有的特性。引用上面提到的书或数百篇参考文献之一,
// 然后将其标记为“不予修复”(WontFix)。
//
// 幸运的是,我们的场景通常只有少量的列(约10列或更少),
// 每列分配大量的像素(约50个或更多),人们甚至注意不到
// 理论上不可避免的那种1像素的偏差,或者即使注意到了也不在乎。
// 至少他们不应该在乎——没人应该使用 WPF 网格布局的结果来做
// 定量决策;它的工作是产生合理的显示效果,而不是分配国会席位。
//
// 我们的算法比当前用于国会席位分配的算法(“亨廷顿-希尔”算法)
// 更容易出现悖论,但它的运行速度更快:
// 复杂度为 O(N log N) vs. O(S * N),其中 N=定义的数量,S=可用像素的数量。
// 并且如上所述,它在实践中产生了足够好的结果。
//
// 重申一点:所有这些仅在启用布局舍入时适用。
// 当允许小数尺寸时,该算法在受限于最小/最大约束和
// 浮点计算精度的情况下表现尽可能良好。
// (但是,最终的显示结果会受到抗锯齿问题的影响。天下没有免费的午餐 。)
</code></pre>
</blockquote>
<h1 id="总结">总结</h1>
<p>通过了解 <code>Grid</code> 的有关算法,我们可以得到一些结论</p>
<ul>
<li>
<p><code>Grid</code> 的工作流程<strong>相当复杂</strong>。尽管存在快速分支,仍然会进行很多不必要的判断与计算</p>
<p>因此,对于<strong>不需要定义行列</strong>的简单多元素布局需求,我们应尽量使用其他控件代替,如 Avalonia 中的 <code>Panel</code> 控件</p>
</li>
<li>
<p>尽量不要将<strong>非固定大小元素</strong>(如 <code>WrapPanel</code>)同时放在 <code>Star</code> 和 <code>Auto</code> 项中</p>
<p>这可能导致循环依赖并多次对元素进行测量。而对于 <code>WrapPanel</code> 这类列表控件,测量的开支是非常大的!</p>
</li>
<li>
<p><code>Grid</code> 仍然存在一些未定义的行为,参见 WPF/UWP 的 Grid 布局竟然有 Bug,还不止一个!了解 Grid 中那些未定义的布局规则 - walterlv</p>
<p>例如这篇文章中提到的第一个问题,就是在 <code>ValidateDefinitionsLayout</code> 的过程中 <code>Star</code> 项被视作 <code>Auto</code> 项导致的,但官方文档并没有进行明确的记载</p>
<p>如果有时间,我可能会再写一篇文章来单独说明这些未定义布局规则的原因</p>
</li>
<li>
<p><s>能够考虑到如此多的极端情况,微软的 WPF 工程师确实有实力...</s></p>
<p>——当然对于一个广泛使用的 UI 框架,这些情况也是有必要考虑在内的</p>
</li>
</ul><br><br>
来源:https://www.cnblogs.com/BettaFish/p/19354900/avalonia-grid
頁:
[1]