[g] 提升首屏性能

[xiaoiver]

目前在每一帧结束后，都会针对发生改变的节点重新构建 R 树，在这一过程中会重新计算脏节点的包围盒，是开销较大的环节：

renderingService.hooks.endFrame.tap(PrepareRendererPlugin.tag, () => {
  this.syncRTree();
});

但 g-canvas 的渲染在脏矩形同样在 endFrame 这一 hook 中完成，且由于是顺序执行，因此需要等待上面构建 R 树完成后：

renderingService.hooks.endFrame.tap(CanvasRendererPlugin.tag, () => {
  if (this.clearFullScreen) {
    // 全屏擦除
    renderByZIndex(this.renderingContext.root);
  } else {
    // 脏矩形渲染
  }
});

但对于首屏来说并不需要等待这一过程，构建 R 树的目的也是为了后续脏矩形最小粒度更新以及快速拾取判定。
因此可以将该过程改成异步非阻塞，至少对于首次渲染应当如此。

[xiaoiver]

另一个影响首屏的点是排序，并不是每次添加子节点，都需要重新对父节点排序：

sortable.sorted = displayObject.childNodes.slice().sort(sortByZIndex);

例如新添加的子节点并没有设置 z-index 时不需要触发父节点的重排，可以直接使用子节点列表。

在 5w 节点的场景下可以节省 1s 的排序时间：

实际渲染时间如下：

[xiaoiver]

最后就是可以减少状态切换。可以看出大量的开销出在对于原生方法例如 context.stroke() context.fill() 的调用上：

这一点 ECharts 也在文章中提及：
https://www.infoq.cn/article/ByHjSpUD0KrhKSulyYED

[xiaoiver]

@antv/util 中构建后存在的 __spreadArray 也会影响，因此可以避免 ... 的使用：

[xiaoiver]

对比 4.0 在渲染时间上耗时几乎一致：

更大的开销反倒是在创建 Path 的部分。

[xiaoiver]

另外应当尽量减少对于 gl-matrix 的使用，特别是每个对象都有的属性例如 AABB、Transform。
很多渲染引擎都会自己实现 Vec3 或者 Mat4，这样可以避免大量 vec3.create() 的调用，减少底层 Float32Array 的使用。

[xiaoiver]

#1120

多余的事件传递可以精简，例如 MOUNTED 没必要冒泡，直接在根节点上触发即可。

[xiaoiver]

大量 GC 发生在 memoized 方法中，这是由于解析属性时转换创建 CSSUnitValue 带来的，对于 Number 类型的值没有必要创建额外的带单位的 CSSValue 类。

[xiaoiver]

画布初始化阶段使用异步方法，原本是考虑到：

• WebGPU 初始化 API 本身就是异步的
• 部分渲染插件初始化是异步的，例如 g-plugin-yoga 加载 WASM，g-plugin-canvaskit-renderer 加载系统字体

但这会导致 g-canvas 和 g-svg 这样没使用异步特性的插件集受到影响：

• 编译出的代码包含 asyncToGenerator，导致运行时 run microtask 非常耗时（见下图）
• 过深的调用栈带来大量 GC 耗时（见下图）

换成同步方法后，同样初始化画布耗时大幅减少（10k Circles 140 -> 80ms），microtask 这一项直接没了：

需要异步初始化方法：

• g-webgpu 现在需要在异步加载完成后内部再触发一次渲染，过程中 mounted 的图形加入一个 pending 列表，加载完成后触发它们的 mounted 事件

[xiaoiver]