新建网站如何做关键词搬家网站建设公司

新建网站如何做关键词,搬家网站建设公司,开公司怎么找客户,做网站和微信小程序在各类XAML UI框架中#xff0c;Grid 是一种非常灵活且常用的布局控件#xff0c;它可以创建复杂的用户界面布局。Grid 允许开发者通过定义行和列来组织界面元素#xff0c;每个元素可以精确地放置在网格的特定区域内 本文以 Avalonia 框架为例#xff0c;讲解 Grid 控件的…在各类XAML UI框架中Grid是一种非常灵活且常用的布局控件它可以创建复杂的用户界面布局。Grid允许开发者通过定义行和列来组织界面元素每个元素可以精确地放置在网格的特定区域内本文以 Avalonia 框架为例讲解Grid控件的工作原理事实上UWP、WinUI 3 和 Avalonia 等XAML框架中Grid控件的源码全都源自于 WPF 中的实现以至于绝大部分代码乃至注释都是相同的因此本文中你能了解到的机制也可应用于其他 XAML UI 框架Measure 阶段快速路径当仅仅存在一个行/列(或未定义行列)时将子元素中最大的宽和高设置为为Grid的大小即可。/* by yours.tools - online tools website : yours.tools/zh/dnstt.html */ gridDesiredSize new Size( Math.Max(gridDesiredSize.Width, child.DesiredSize.Width), Math.Max(gridDesiredSize.Height, child.DesiredSize.Height));在一般情况下我们定义了两个及以上以上的行/列就需要一套特定的算法进行计算我们知道Grid的行/列定义有Auto、Star、Pixel三类简化后的定义如下/* by yours.tools - online tools website : yours.tools/zh/dnstt.html */ 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; }// 最终偏移量 }此处将Width/Height更改为Size不再区分行列源代码中为了性能上面的一些属性如FinalSize、MaxSize使用的是同一个字段为便于理解这里将他们拆分开来单独列出。具体代码可以自行前往Avalonia存储库查看在测量 (Measure) 的过程中Grid遵循可确定大小优先的原则。因此他们将要渲染的元素分为四组来决定测量顺序PxAutoStarPx113Auto113Star424通常情况下测量的顺序如下flowchart LR X[初始化] -- A[分组] -- B[测量Group1] -- C[解析Star行] -- D[测量Group2] -- E[解析Star列] -- F[测量Group3] -- G[测量Group4]根据Group2、Group3元素的存在情况测量组和解析Star项的顺序会有所不同但Group1和Group4的测量顺序始终不变具体流程将在后面介绍我们先依次介绍Measure过程中使用的主要算法ValidateDefinitionsStructure、ValidateDefinitionsLayout初始化行/列定义分组前Grid会先初始化行/列定义的结构如果只有行定义Grid会自动添加一个Width *的列定义同理如果只有列定义会自动添加一个行定义同时如果传入了无限的长或宽其对应的所有Star定义都会被视作Auto项ValidateCells分组预处理所有子元素分组过程中Grid中的每个元素都将被视作一个Cell他们根据所在行/列的类型被分配到不同组中以便稍后进行进一步的计算所有Cell以链表的形式被缓存每个CellGroup存储的是当前组的头节点在后续测量中使用Cell.Next进行遍历MeasureCellsGroup测量组Group 1项的类型为Px/Auto测量每个元素的机制如下Px项def.Size作为元素Measure边界Auto项传入无限尺寸作为元素Measure边界同时当某个元素测量完成时还会根据元素的高度更新元素所在项的最小大小项最小尺寸的初始值与最大尺寸由用户设定如RowDefinition.Min/MaxHeightdef.MinSize Math.Clamp(child.DesiredSize, def.MinSize, def.MaxSize)若元素的RowSpan 1可能跨项则不更新项最小值并且在其他元素均测量完毕后确保这些跨项元素尺寸在其所在所有项尺寸的最小值/最大值之间Group ≠ 1元素在某个Star类型的项中根据顺序此时已完成目标组Star项的大小解析因此definitions.MeasureSize是有值的使用GetMeasureSizeForRange方法遍历元素跨越的所有项将这些项的最小值(Auto项)或测量值(Star项)相加得到元素测量时的边界private static double GetMeasureSizeForRange( IReadOnlyListDefinitionBase definitions, int start/*起始项位置*/, int count/*跨越项数(RowSpan)*/, double spacing) { double measureSize -spacing; int i start count - 1; do { measureSize spacing // 跨行元素可忽视所跨项之间的spacing (definitions[i].SizeType LayoutTimeSizeType.Auto ? definitions[i].MinSize : definitions[i].MeasureSize); } while (--i start); return measureSize; }同理每个元素测量完成时也会更新其所在项的最小值也会在所有元素测量完成后确保跨项元素尺寸在正确范围内ResolveStar统一解析Star项分配权重Group1测量完毕后我们已经得到了所有固定元素的尺寸现在以以下流程计算各Star项的尺寸预处理权重遍历definitions统计Star项的数量并得到最大权重maxStar同时将所有Star项的MeasureSize设置为 1.0表示尚未在后续阶段解析。引入scale值用于后续缩放防止浮点溢出若存在 Infinity 权重设置scale -1.0若不存在 Infinity 权重但权重和可能溢出(starCount * maxStar Double.Max)将scale设置为 2 的负次幂计算可用空间预处理约束再次遍历definitions计算所有非Star项所占用的空间takenSize对于Star项计算缩放后的权重值starWeight star * scale并累计到totalStarWeight若 scale 0存在Infinity权重将 Infinity 项映射为 1其余映射为 0如果项存在最小约束(MinSize 0由用户设置)将该项加入最小约束列表并暂存比率def.minRatio starWeight / def.MinSize同理若存在最大约束(MaxSize ≠ Infinity)将该项加入最大约束列表暂存def.maxRatio starWeight / def.MaxSize为提升性能实际实现中最小约束列表和最大约束列表存储在同一列表definitionIndices中分别为前后两个部分迭代解析约束项来看一个例子!--C1--ColumnDefinition Width* MinWidth120/ !--C2--ColumnDefinition Width2*/ !--C3--ColumnDefinition Width3* MaxWidth150/假设可用尺寸S400这时候我们可以发现如果要满足定义中的Min/MaxWidth约束是无法实现 1 : 2 : 3 的比例的。因此我们需要将与比例差距最大的项锁定为Min/MaxWidth但我们又希望锁定后的比例尽可能接近定义的比例因此Grid使用了以下算法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先对最小约束列表按照比率降序最大约束列表按照比率升序排序初始remainingAvailableSizeS400remainingStarWeightW6下面按照每次锁定差异最大的一个definition来迭代解析约束项第一次迭代从最小/最大约束列表中分别选出C1.minRatio 1/120 0.008333 C3.maxRatio 3/150 0.02计算比例proportion remainingStarWeight / remainingAvailableSize 6/400 0.015判定是否违反比例违反最小约束minRatio proportion 0.008333 0.015成立违反最大约束maxRatio proportion 0.02 0.015成立如果认为比例不好理解可以从反面考虑假设步骤 2 中def.MinSize / starWeight代表每颗星的最小大小minStarSizedef.MaxSize / starWeight代表每颗星允许的最大大小maxStarSize那么remainingAvailableSize / remainingStarWeight代表当前每颗星的大小currentStarSize必须满足minStarSize ≤ currentStarSize ≤ maxStarSize否则就需要选择偏离最大的项进行锁定二者都需要锁定选择偏离更大的一项对最小约束的偏离proportion / minRatio 0.015 / 0.008333 ≈ 1.8对最大约束的偏离maxRatio / proportion 0.02 / 0.015 ≈ 1.3331.8 1.333 优先锁定C1尺寸为C1.MinSize执行锁定设置C1尺寸为约束最小值resolvedSize C1.MinSize 120更新可用空间和剩余权重remainingAvailableSize 400 - resolvedSize 400-120 280remainingStarWeight 6 - C3.starWeight 6 - 1 5第二次迭代maxRatio 0.02仍为C3proportion 5/280 ≈ 0.017857仅违反最大约束0.02 0.017857 C3尺寸锁定为C3.MaxSize执行锁定设置C3尺寸为约束最大值resolvedSize C3.MaxSize 150remainingAvailableSize 280 -150 130remainingStarWeight 5 - 3 2最小/最大约束列表均为空 退出。检测异常场景并重复执行 2、3完成步骤 3 后可能会有以下异常场景remainingAvailableSize 0且Star项全部处理完毕所有Star项都被其最大约束锁定但所有最大约束之和仍小于边界遍历所有项解锁存在最小约束的项重新执行步骤 2、3 为其分配空间remainingAvailableSize 0某些项被最小约束锁定但所有最小约束之和超过了边界同理解锁存在最大约束的项重新执行 2、3前缀和算法分配剩余空间相比权重/权重总和*剩余空间此算法可以避免浮点数计算带来的精度丢失可以用一个例子说明此算法假设权重分别为[1, 2, 3]剩余空间为 6计算权重前缀和[1, 3, 6]现在以权重从大到小的顺序开始分配分配6*(3/6) 3剩余空间 6-33分配3*(2/3) 2剩余空间 3-21分配1*(1/1) 1剩余空间 1-10完成简化后的算法如下此处默认所有项的类型为StarArray.Sort(definitions); // 计算前缀和 totalStarWeight 0.0; for (int i 0; i definitions.Length; i) { DefinitionBase def definitions[i]; totalStarWeight def.MeasureSize;// MeasureSize在此处代表Star数量 def.SizeCache totalStarWeight;// SizeCache用于缓存前缀和结果 } // 从后向前遍历 for (int i definitions.Length - 1; i 0; --i) { DefinitionBase def definitions[i]; double resolvedSize (availableSize - takenSize) * (def.MeasureSize / def.SizeCache); def.MeasureSize resolvedSize; takenSize resolvedSize; }现在你应该对测量中使用的算法有了大概了解。但测量顺序具体是怎么样的呢以及为什么要遵守这样的测量顺序我们再看一下之前的分组表PxAutoStarPx113Auto113[A]Star42[B]4重点看加粗的部分以A部分(在Group3中)为例在测量这部分的元素前必须得到Auto列的大小。因此测量Group3前必须完成对Group1和Group2的测量同样B 部分在测量之前也必须得到Auto行的大小在测量Group2前必须完成对Group1和Group3的测量AB 部分的共同特性就是同时存在于Auto和Star项中我们可以得出以下结论A 部分中存在元素测量Group1、Group2后才能测量Group3B 部分中存在元素测量Group1、Group3后才能测量Group2如果 A、B 部分都存在元素呢比如下面的情况column widthAutocolumn width*row heightAutocell 1 2[A]row height*cell 2 1[B]由于cell 2 1的宽度决定了Auto列的宽度进而间接决定cell 1 2所在列的宽度需要先计算cell 2 1。然而由于cell 1 2的高度决定了Auto行的高度同理cell 2 1也理应先被计算——Auto与Star的行列相互影响这就是Grid行列解析中的循环依赖问题。综上所述Grid共有三种不同的测量顺序流程图如下graph TD %% 流程开始 Start([MeasureOverride]) -- VC[分组brValidateCells] -- MG1[测量Group1] MG1 -- CondV{能否解析Star行brA中没有元素} %% 分支 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列brB中没有元素} %% 子分支 2A可以 Resolve StarsU (Yes) CondU -- 是br(先解析Star列即可) -- RSU2[解析Star列] RSU2 -- MG3_2[测量Group3] MG3_2 -- RSV2[解析Star行] %% 子分支 2B不能 Resolve StarsU (No) CondU -- 否br -- MG2P[测量Group2br(使用无限高度)] 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([结束])循环依赖的处理对于产生了循环依赖的布局我们无法直接测量 AB 组的大小。因此我们需要先在测量Group2也就是 B 组 时使用无限高度以先得到其宽度再解析Star列Star列被解析完毕后就可以测量Group3中的元素了此时再解析Star行即可重新以正确的行高测量Group2更为极端的情况如果Group2中的元素再使用不同高度测量时得到的宽度不同例如纵向排列的WrapPanel这代表第一次使用无限高度测量Group2后解析得到Star列的宽度是错误的这时候我们需要返回并重新对Group3进行测量...在重新测量的过程中我们还要将Auto项的尺寸恢复到测量Group1后的状态来尽可能保证测量Group2时的参数相等此流程会一直循环直到两次Group2宽度的测量结果相同或循环次数 ≥5Arrange 阶段由于行列大小计算已经在Measure阶段完成Arrange阶段只需要计算每个行列的最终位置并处理一些特殊设置即可。重新解析Star项由于Measure阶段提供的约束可能与Arrange阶段提供的空间不一致我们需要使用与ResolveStar相同的方式再次解析一遍Star项至于为何两个阶段提供的空间可能不一致就涉及到Measure/Arrange机制了具体可参阅 布局 - WPF | Microsoft LearnSpacing处理在Measure阶段前我们在原边界大小的基础上减去所有间距之和后再进行测量对spacing的单独处理仅限于跨行元素见GetMeasureSizeForRange。因此在处理元素最终的偏移量FinalOffset时我们需要在每次迭代都加上对应的spacingfor (int i 0; i definitions.Count; i) { definitions[(i 1) % definitions.Count].FinalOffset definitions[i].FinalOffset definitions[i].FinalSize spacing; }布局舍入 (LayoutRounding)为了避免影响前面的测量进程布局舍入在Arrange的最后阶段执行遍历所有项将其尺寸根据当前 DPI 四舍五入并把舍入后大小 - 原始大小写入RoundingErrors计算舍入后大小roundedTakenSize与舍入前大小finalSize的差值。若不相等就需要进一步调节各项以分配余额或去除溢出将所有项根据RoundingErrors排序在差值最大的项上增加或减少像素以dpiIncrement 1 / dpi为单位进行调节同时确保不低于MinSize顺带一提代码中用了一段很长的注释来说明当前的布局舍入算法是存在问题且无法解决的由 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可用像素的数量。 // 并且如上所述它在实践中产生了足够好的结果。 // // 重申一点所有这些仅在启用布局舍入时适用。 // 当允许小数尺寸时该算法在受限于最小/最大约束和 // 浮点计算精度的情况下表现尽可能良好。 // 但是最终的显示结果会受到抗锯齿问题的影响。天下没有免费的午餐 [TANSTAAFL]。总结通过了解Grid的有关算法我们可以得到一些结论Grid的工作流程相当复杂。尽管存在快速分支仍然会进行很多不必要的判断与计算因此对于不需要定义行列的简单多元素布局需求我们应尽量使用其他控件代替如 Avalonia 中的Panel控件尽量不要将非固定大小元素如WrapPanel同时放在Star和Auto项中这可能导致循环依赖并多次对元素进行测量。而对于WrapPanel这类列表控件测量的开支是非常大的Grid仍然存在一些未定义的行为参见 WPF/UWP 的 Grid 布局竟然有 Bug还不止一个了解 Grid 中那些未定义的布局规则 - walterlv例如这篇文章中提到的第一个问题就是在ValidateDefinitionsLayout的过程中Star项被视作Auto项导致的但官方文档并没有进行明确的记载如果有时间我可能会再写一篇文章来单独说明这些未定义布局规则的原因能够考虑到如此多的极端情况微软的 WPF 工程师确实有实力...——当然对于一个广泛使用的 UI 框架这些情况也是有必要考虑在内的