渲染机制与性能优化

渲染管线（从元数据到像素）：
  元数据加载
    → 解析与校验（Schema → 内部结构）
      → 求值（表达式、联动、数据绑定）
        → 构建组件树（虚拟 DOM / 组件实例）
          → 渲染（框架渲染）
            → 布局与绘制

性能优化的目标：让每一环都「只做必要的工作」
  解析：缓存解析结果
  求值：依赖追踪，精确重算
  构建：结构共享，避免整树重建
  渲染：粒度控制，避免全量重渲染

解释执行：
  运行时遍历元数据 → 逐步生成组件
  优点：改动即时生效
  缺点：每次渲染都遍历，开销随页面大小线性增长

预编译：
  构建期把元数据编译为渲染函数/组件
  优点：运行时开销低
  缺点：需构建步骤

折中：
  首次渲染时编译为「渲染计划」并缓存
  后续渲染直接复用计划

type RenderPlan = (ctx: RenderContext) => VNode;

const planCache = new WeakMap<object, RenderPlan>();

function getPlan(schema: PageSchema): RenderPlan {
  let plan = planCache.get(schema);
  if (!plan) {
    plan = compileToPlan(schema);   // 编译一次
    planCache.set(schema, plan);
  }
  return plan;
}

粗粒度：整个页面一个渲染单元
  改任何字段 → 整页重渲染
  简单，但页面一大就卡

中粒度：每个组件一个渲染单元
  改字段 → 重渲染该组件
  需要精确的订阅与记忆化

细粒度：响应式信号（signal）
  改字段 → 只更新用到该字段的 DOM 节点
  最优，但实现复杂

// 中粒度：用 memo + 精确 props 控制重渲染
const FieldRenderer = React.memo(function FieldRenderer({ field, value, onChange }) {
  return <FieldComponent value={value} onChange={onChange} />;
}, (prev, next) => {
  // 只在值或字段定义变化时重渲染
  return prev.value === next.value && prev.field === next.field;
});

需要追踪的依赖：
  1. 表达式 → 它引用了哪些字段
  2. 组件 → 它绑定了哪些数据源与变量
  3. 数据源 → 它依赖哪些变量

当某字段/变量变化：
  查依赖图 → 得到受影响的表达式/组件 → 只更新它们

class DependencyTracker {
  private deps = new Map<string, Set<string>>();   // source -> dependents
  private reverse = new Map<string, Set<string>>(); // dependent -> sources

  track(dependent: string, sources: string[]) {
    for (const s of sources) {
      if (!this.deps.has(s)) this.deps.set(s, new Set());
      this.deps.get(s)!.add(dependent);
    }
    this.reverse.set(dependent, new Set(sources));
  }

  affected(changed: string): Set<string> {
    const result = new Set<string>();
    const queue = [changed];
    while (queue.length) {
      const cur = queue.shift()!;
      for (const d of this.deps.get(cur) ?? []) {
        if (!result.has(d)) { result.add(d); queue.push(d); }   // 传递闭包
      }
    }
    return result;
  }
}

问题：10000 行表格全渲染 → 10000 个 DOM 节点 → 卡死

虚拟化：只渲染视口内的行 + 少量缓冲
  视口 20 行 + 上下各 5 行缓冲 = 30 个 DOM 节点

变高行虚拟化：
  需预先测量或动态测量行高
  动态测量复杂度高，低代码场景建议固定行高

function useVirtualRows(total: number, rowHeight: number, viewportHeight: number) {
  const [scrollTop, setScrollTop] = useState(0);
  const start = Math.max(0, Math.floor(scrollTop / rowHeight) - 5);
  const visible = Math.ceil(viewportHeight / rowHeight) + 10;
  const end = Math.min(total, start + visible);
  return {
    start, end,
    offsetY: start * rowHeight,
    totalHeight: total * rowHeight,
    onScroll: (e: React.UIEvent) => setScrollTop(e.currentTarget.scrollTop),
  };
}

常见浪费：
  1. 重复请求：多个组件绑定同一数据源，各请求一次
  2. 全量刷新：改一个变量刷新所有数据源
  3. 瀑布请求：串行依赖导致请求链很长
  4. 无缓存：返回列表再进详情又请求一次

优化手段：
  - 请求去重（同一查询并发只发一次）
  - 依赖追踪（只刷新受影响的数据源）
  - 并行化（无依赖的请求并行）
  - 缓存 + 失效（SWR / React Query 模式）

// 请求去重：相同 key 的并发请求合并
const inflight = new Map<string, Promise<unknown>>();

function fetchOnce(key: string, fn: () => Promise<unknown>) {
  if (inflight.has(key)) return inflight.get(key)!;
  const p = fn().finally(() => inflight.delete(key));
  inflight.set(key, p);
  return p;
}

元数据加载链路：
  请求 → 服务端查询 → 传输 → 解析 → 校验 → 缓存

优化：
  1. CDN/边缘缓存：元数据是只读的，适合边缘缓存
  2. 增量更新：只传 diff，而非全量
  3. 版本化 URL：/meta/{app}/{version}.json，可长期缓存
  4. 预取：进入应用前预取常用页面元数据
  5. 客户端缓存：LocalStorage / IndexedDB + 版本校验

async function loadMeta(appId: string, version: number) {
  const key = `meta:${appId}:${version}`;
  const cached = await idb.get(key);
  if (cached) return cached;
  const meta = await fetch(`/api/meta/${appId}?v=${version}`).then((r) => r.json());
  await idb.set(key, meta);
  return meta;
}

首屏优化：
  1. 元数据内联：首屏页面的元数据直接内联进 HTML，省一次请求
  2. 并行加载：元数据与数据并行，而非串行
  3. 骨架屏：元数据到达前先渲染骨架
  4. 关键路径：只加载首屏需要的组件代码（代码分割）
  5. 服务端渲染：元数据已知，可在服务端直接渲染首屏

串行（慢）：
  请求元数据 → 解析 → 请求数据 → 渲染
  = RTT(meta) + RTT(data) + 渲染

并行（快）：
  请求元数据 ┐
             ├→ 渲染
  请求数据   ┘
  = max(RTT(meta), RTT(data)) + 渲染

度量指标：
  - 首屏时间（FCP / LCP）
  - 交互延迟（INP）
  - 元数据加载耗时
  - 单次交互的重渲染组件数
  - 渲染帧率（拖拽/滚动时）

预算（示例）：
  - 首屏 < 2s
  - 单次交互重渲染组件数 < 50
  - 拖拽帧率 > 50fps

// 埋点：记录单次交互的重渲染组件数
function trackRerender(interaction: string, count: number) {
  if (count > 50) {
    report('rerender-budget-exceeded', { interaction, count });
  }
}

反模式 1：把选中态/悬停态放进组件树
  → 每次悬停全量重渲染，应放覆盖层

反模式 2：表达式无依赖追踪
  → 每次输入全量重算，应建依赖图

反模式 3：数据源绑定不做去重
  → 同一查询并发多次，应请求合并

反模式 4：元数据每次渲染都重新解析
  → 应缓存渲染计划

反模式 5：大列表不虚拟化
  → DOM 爆炸，应默认虚拟化

反模式 6：全量元数据下发
  → 首屏加载巨大，应增量/按需