@逍为(hustcc)

G2 从很早的版本，就是使用 auto padding 的机制去布局，这个并没有什么问题，未来的 G2 依然会会有 padding 的概念。

但是因为之前的 auto padding 计算逻辑，会带来一些额外布局问题，所以这里将布局过程改成使用约束布局的逻辑，这其中具体的，之前很多文档提过，这里不赘述。

这里就分成几步，保证在 4.2 版本中兼容，并且未来的 5.x 代码很容易的去升级组件：

  • 约束布局求解器（以后可能会在很多地方用到
  • 生成约束条件
  • 求解（布局）
  • 移动组件到对应的位置

约束布局

约束布局，也是在 UI 布局中经常使用的东西，利用一次不等式方程组，可以计算出每个部分的位置宽高，达到布局的目的。

对于 G2 的场景来说，我们进行一些优化，因为 G2 的场景可以理解是当前并不需要使用不等式组，完全使用等式方程，可以有效提高约束布局计算的性能。

那么对于约束条件都是等式的求解，其实就是高斯消元法了。具体在 G2 的实现为：#3622。是一个非常独立的模块，未来也是可以完全抽离出来的。

生成约束

之前的逻辑是，按照四个方向，不断的去裁剪 bbox，在裁剪过程中，去计算对应组件的 x y w h。然后裁剪剩余的大小就是 geometry bbox 也就是 coordinate 的位置大小。

现在的逻辑会改成：

  • 遍历不同方向的组件，存储起来
  • 根据方向和组件，生成详尽约束条件（只准冗余，不能缺少）
    • 组件的初始大小（新建一个虚拟实例，获取大小，后续这部分会变成 width、height 的百分比，用户可以设置固定的 px）
    • 约束关系
  • new Solver().clac()
  • 更新对应组件的 x y width height
  • render

这里的核心问题：

  1. 怎么逻辑性好的生成全面的 constraint，因为如果生成不全，求解不出答案
  2. 性能对比、性能优化，约束布局的性能对比见这里，这里因为优化为等式求解，所以性能会高很多

具体的 PR 见：#3622

收益效果