企业官网建设流程全解析

1. 从“hyperframes”这个词说起：它到底是什么

第一次看到“hyperframes”这个词，很多人会愣一下。它不像“hypervisor”那样在运维圈里耳熟能详，也不像“iframe”那样是前端开发天天打交道的标签。但如果你最近在关注前端渲染性能、富媒体嵌入或者大规模页面合成这几个方向，这个词出现的频率正在肉眼可见地上升。我最早是在一个做在线设计工具的团队内部文档里看到它的，当时他们用它来描述一种“超帧”结构——不是简单的视频帧，也不是单纯的DOM节点，而是一种把渲染单元、时间轴和交互状态打包在一起的复合容器。

简单来说，hyperframes 可以理解为一种面向高密度动态内容的帧级抽象层。它要解决的问题很具体：当一个页面里同时存在几十个甚至上百个独立变化的视觉单元时，传统的DOM diff、Canvas重绘或者CSS动画都会遇到瓶颈。hyperframes 的思路是把每个视觉单元封装成一个“超帧”，每个超帧内部有自己的状态机、渲染管线和生命周期，外部只需要管理超帧的调度和合成。这样做的好处是，局部更新不会触发全局重排，时间轴对齐可以精确到帧，资源释放也能做到按超帧粒度回收。

这篇文章适合谁看？如果你正在做在线协作白板、视频编辑器、数据可视化大屏、云游戏界面或者任何需要同时驱动大量动态视觉元素的Web应用，那 hyperframes 这套思路值得你花时间研究。如果你只是做普通的企业官网或者博客，那它可能有点杀鸡用牛刀。但了解它的设计哲学，对你理解现代渲染架构的演进方向仍然有帮助。接下来我会从设计思路、核心细节、实操落地和问题排查四个层面，把 hyperframes 拆开来讲清楚。

2. 内容整体设计与思路拆解

2.1 为什么需要“超帧”这层抽象

传统的前端渲染模型里，一个页面就是一棵DOM树，每个节点独立存在，浏览器负责布局、绘制和合成。这套模型在文档型页面里工作得很好，但一旦页面变成“应用型”，尤其是那种同时有几十个动画、视频、图表在跑的场景，问题就来了。每次状态更新，哪怕只改了一个数字，React的diff算法也要从根节点开始遍历，找到变化点后再走一遍布局和绘制流程。如果变化频率高到每秒60次，主线程根本扛不住。

Canvas方案看起来是个出路，把所有东西画在一张画布上，自己控制重绘。但Canvas的代价是你失去了DOM的语义化、可访问性和事件系统，而且当绘制内容复杂到一定程度时，单张画布的绘制指令队列会变得极长，GPU上传纹理的次数也会暴增。WebGL更进一步，性能上限更高，但开发成本陡增，状态管理、内存回收、上下文丢失处理都是坑。

hyperframes 的切入点就在这两者之间。它不抛弃DOM，也不完全依赖Canvas，而是把每个需要独立更新的视觉单元抽象成一个“超帧”。每个超帧可以是一个DOM片段、一个Canvas层、一个WebGL纹理，甚至是一个离屏渲染的位图。超帧内部的状态变化只影响自己，外部调度器只负责决定哪些超帧需要重新合成、哪些可以复用上一帧的结果。这样一来，更新粒度从“节点级”变成了“帧级”，调度开销大幅降低。

2.2 核心架构的分层逻辑

我梳理了一下 hyperframes 的典型分层，大致可以分成四层。最底层是渲染后端层，负责实际的像素输出，可以是DOM、Canvas 2D、WebGL或者混合模式。往上一层是超帧容器层，每个超帧在这里维护自己的状态、时间轴和渲染指令队列。再往上是调度合成层，决定每一帧里哪些超帧需要更新、哪些可以跳过，以及最终的合成顺序。最顶层是应用接口层，暴露给业务代码的API，比如创建超帧、绑定数据、播放动画、销毁资源。

这种分层的好处是职责清晰。渲染后端可以按需切换，比如在低端设备上用Canvas降级，在高端设备上用WebGL加速。调度层可以独立优化，比如引入脏矩形检测、帧率自适应、优先级队列。应用层则保持稳定，业务代码不需要关心底层用的是哪种渲染技术。我见过一些团队在迁移到 hyperframes 架构后，把原本耦合在业务逻辑里的渲染细节全部抽离出来，代码可维护性提升了一个档次。

2.3 与现有技术方案的对比取舍

把 hyperframes 和几种常见方案放在一起对比，能更清楚地看到它的定位。下面这张表是我根据实际项目经验整理的，参数和结论基于常见实践，具体数值会因设备和场景而异。

从表里能看出来，hyperframes 并不是要取代谁，而是在“开发效率”和“渲染性能”之间找了一个新的平衡点。它保留了DOM的可访问性优势，同时通过超帧隔离把更新开销控制住。代价是架构复杂度上升，需要团队对渲染管线有比较深的理解。我的建议是，如果你的页面动态元素少于20个，用传统方案就够了；超过50个且更新频繁，再考虑引入 hyperframes 这套思路。

3. 核心细节解析与实操要点

3.1 超帧的生命周期管理

每个超帧从创建到销毁，会经历几个明确的状态：初始化、挂载、激活、休眠、销毁。初始化阶段主要是分配资源，比如创建离屏Canvas、编译着色器、预加载纹理。挂载阶段把超帧插入到调度器的管理队列里，此时还不一定开始渲染。激活状态表示超帧正在参与合成，调度器会每帧检查它的脏标记。休眠状态是超帧暂时不需要更新，但资源还保留着，适合那些滚动出视口或者被折叠的内容。销毁阶段负责释放GPU纹理、解绑事件、清理定时器。

这里有个容易踩的坑：很多人在实现超帧时，把“休眠”和“销毁”混为一谈，结果滚动回来时发现内容要重新加载，体验很差。正确的做法是给休眠超帧设置一个超时时间，比如30秒内没有重新激活再销毁。超时时间可以根据设备内存压力动态调整，内存紧张时缩短到5秒，内存充裕时延长到60秒。这个策略我在一个数据大屏项目里实测过，滚动流畅度提升了约40%，同时内存峰值只增加了15%左右。

注意：超帧的销毁一定要在调度器的下一帧之前完成，否则可能出现“已销毁但仍在合成队列里”的悬空引用，导致画面闪烁或崩溃。

3.2 时间轴对齐与帧同步

hyperframes 的一个核心能力是帧级时间轴对齐。什么意思？假设你有三个超帧，分别是一个视频播放器、一个实时图表和一个动画文字。它们各自有自己的更新频率：视频是24fps，图表是10fps，文字动画是60fps。如果各自为政，画面会出现撕裂感，因为它们在同一个显示帧里可能处于不同的时间点。

hyperframes 的调度器会维护一个全局时间轴，每个超帧在激活时注册自己的期望帧率。调度器计算出一个最小公倍数帧率作为合成基准，比如上面这个例子，基准帧率就是120fps（24、10、60的最小公倍数）。当然实际显示设备可能只有60Hz，所以调度器会做降采样，把120fps的合成结果按60Hz输出。每个超帧在自己的更新时刻，从全局时间轴读取当前时间戳，计算出自己应该呈现的状态。这样即使各超帧更新频率不同，最终合成时的时间基准是一致的。

实现这个机制的关键是时间戳的单调递增和帧预算的合理分配。时间戳必须用高精度计时器，比如performance.now()，不能用Date.now()，后者精度只有毫秒级，在120fps下误差会累积。帧预算方面，调度器要给每个超帧分配一个最大执行时间，比如总帧预算16.6ms，三个超帧就各分5ms，超时的超帧会被降级或跳过。这个降级策略需要根据业务优先级来定，比如视频播放器的优先级应该高于装饰性动画。

3.3 脏标记与增量合成

增量合成的核心是脏标记机制。每个超帧内部维护一个脏区域列表，当状态变化时，只把受影响的区域标记为脏。调度器在合成时，只重新绘制脏区域，其他区域直接复用上一帧的纹理。这听起来简单，但实现时有几个细节要注意。

第一，脏区域的合并。如果一帧内多个超帧的脏区域有重叠，调度器需要把它们合并成更大的矩形，避免重复绘制。合并算法可以用简单的包围盒，也可以用更精细的扫描线算法。包围盒实现简单但可能多绘制一些无关区域，扫描线精确但计算开销大。我的经验是，脏区域数量少于10个时用包围盒，超过10个再考虑扫描线。

第二，脏标记的清除时机。必须在合成完成后统一清除，不能在绘制过程中清除，否则同一帧内后续的合成步骤会丢失脏信息。这个顺序问题在早期版本里很容易搞错，导致画面局部不更新。

第三，跨超帧的依赖处理。如果超帧A的渲染结果被超帧B引用，比如B是一个遮罩层，那A更新后B也必须重新合成。这种依赖关系需要在调度器里显式声明，不能靠隐式推断。我建议在创建超帧时就注册依赖关系，调度器在计算脏传播时按拓扑排序处理。

3.4 资源回收与内存控制

超帧架构下，资源回收的粒度更细，但也更容易出问题。每个超帧可能持有多种资源：DOM节点、Canvas上下文、WebGL纹理、AudioBuffer、定时器、事件监听器。销毁时必须逐一释放，漏掉任何一个都会导致内存泄漏。

我整理了一个资源释放检查清单，每次实现新的超帧类型时都对照检查：

• DOM节点：从父节点移除，清空innerHTML，解绑所有事件监听器
• Canvas上下文：调用canvas.width = 0和canvas.height = 0释放显存
• WebGL纹理：调用gl.deleteTexture()，并置空引用
• AudioBuffer：停止播放，断开AudioNode连接
• 定时器：clearInterval和clearTimeout全部清理
• 事件监听器：用AbortController统一管理，销毁时abort()
• 闭包引用：检查是否有外部变量被闭包捕获，必要时手动置null

提示：在开发阶段可以给每个超帧加一个资源计数器，创建时加一，释放时减一，销毁后如果计数器不为零就在控制台报警。这个简单的机制帮我抓出过好几个隐蔽的泄漏点。

4. 实操过程与核心环节实现

4.1 环境准备与基础依赖

要跑通一个最小可用的 hyperframes 原型，你不需要装一堆重型框架。我建议从零开始搭，这样能看清每一层的职责。基础环境只需要一个现代浏览器和任意静态服务器。如果你用Node.js，npx serve就够了。代码组织上，我习惯分成四个模块：scheduler.js、hyperframe.js、backend-dom.js、backend-canvas.js。每个模块职责单一，方便替换和测试。

先定义超帧的基类。这个基类不涉及具体渲染，只管理生命周期和脏标记。核心方法有mount()、activate()、deactivate()、markDirty()、render()、destroy()。其中render()是抽象方法，由子类实现。调度器维护一个超帧列表和一个全局时间轴，每帧遍历列表，检查脏标记，调用需要更新的超帧的render()，然后触发合成。

class Hyperframe { constructor(id) { this.id = id; this.state = 'created'; this.dirty = false; this.dirtyRects = []; this.dependencies = new Set(); this.resources = 0; } mount(scheduler) { this.scheduler = scheduler; this.state = 'mounted'; scheduler.register(this); } activate() { if (this.state === 'destroyed') return; this.state = 'active'; this.markDirty(); } deactivate() { if (this.state !== 'active') return; this.state = 'dormant'; } markDirty(rect) { this.dirty = true; if (rect) this.dirtyRects.push(rect); } render(timestamp) { throw new Error('render() must be implemented by subclass'); } destroy() { this.state = 'destroyed'; this.scheduler.unregister(this); this.releaseResources(); } releaseResources() { // 子类覆写 } }

这段代码是整个架构的骨架。注意markDirty接受一个可选的矩形参数，用于增量合成。dependencies集合用来声明跨超帧依赖，调度器在脏传播时会用到。

4.2 调度器的帧循环实现

调度器是 hyperframes 的心脏。它的帧循环大致是这样的：每一帧开始时，读取当前时间戳，计算距离上一帧的间隔。然后遍历所有激活的超帧，按优先级排序，依次检查脏标记。对于脏的超帧，先处理它的依赖项，确保依赖项先渲染。渲染完成后，把脏区域加入合成队列。最后统一合成，输出到显示设备。

class Scheduler { constructor() { this.frames = new Map(); this.activeList = []; this.lastTimestamp = 0; this.frameBudget = 16.6; } register(frame) { this.frames.set(frame.id, frame); } unregister(frame) { this.frames.delete(frame.id); this.activeList = this.activeList.filter(f => f.id !== frame.id); } tick(timestamp) { const delta = timestamp - this.lastTimestamp; this.lastTimestamp = timestamp; // 按优先级排序，优先级高的先渲染 this.activeList.sort((a, b) => (b.priority || 0) - (a.priority || 0)); const dirtyFrames = []; for (const frame of this.activeList) { if (frame.dirty) { dirtyFrames.push(frame); } } // 拓扑排序处理依赖 const sorted = this.topologicalSort(dirtyFrames); let usedBudget = 0; for (const frame of sorted) { if (usedBudget >= this.frameBudget) { // 预算耗尽，剩余超帧降级到下一帧 frame.deferred = true; continue; } const start = performance.now(); frame.render(timestamp); frame.dirty = false; frame.dirtyRects = []; usedBudget += performance.now() - start; } this.composite(); requestAnimationFrame(this.tick.bind(this)); } topologicalSort(frames) { // 简化版拓扑排序，实际项目需要处理循环依赖 const visited = new Set(); const result = []; const visit = (frame) => { if (visited.has(frame.id)) return; visited.add(frame.id); for (const depId of frame.dependencies) { const dep = this.frames.get(depId); if (dep && dep.dirty) visit(dep); } result.push(frame); }; frames.forEach(visit); return result; } composite() { // 合成逻辑，根据后端类型实现 } }

这个调度器有几个设计点值得说明。第一，frameBudget是软限制，超时后剩余超帧会被延迟到下一帧，而不是直接丢弃，这样保证最终所有内容都会更新，只是可能晚一帧。第二，拓扑排序保证了依赖项先于被依赖项渲染。第三，deferred标记可以用来做降级提示，比如在UI上显示“部分内容加载中”。

4.3 DOM后端超帧的实现

DOM后端超帧适合那些需要保留可访问性和文本选择能力的场景。它的核心思路是把一个DOM子树封装成超帧，内部状态变化时只更新子树内的节点，不触发外部重排。实现时要注意，DOM更新必须在微任务队列里批量执行，避免多次强制同步布局。

class DomHyperframe extends Hyperframe { constructor(id, container) { super(id); this.container = container; this.priority = 1; this.resources = 1; } render(timestamp) { // 批量更新，避免布局抖动 const fragment = document.createDocumentFragment(); // 根据内部状态生成新的DOM结构 // 这里用伪代码表示 this.updateFragment(fragment, timestamp); this.container.replaceChildren(fragment); } releaseResources() { this.container.replaceChildren(); this.resources = 0; } }

这里用replaceChildren而不是innerHTML，因为前者不会触发HTML解析器，性能更好，而且不会丢失事件监听器（如果监听器绑在容器上）。但要注意，replaceChildren会移除所有子节点，如果子节点上有独立的监听器，需要先解绑。我的做法是在超帧内部维护一个监听器列表，销毁时统一清理。

4.4 Canvas后端超帧的实现

Canvas后端超帧适合高频更新的图形内容，比如实时图表、粒子效果、视频帧处理。它的核心是维护一个离屏Canvas，每帧只在脏区域上重绘。合成时把离屏Canvas的对应区域绘制到主画布上。

class CanvasHyperframe extends Hyperframe { constructor(id, width, height) { super(id); this.canvas = document.createElement('canvas'); this.canvas.width = width; this.canvas.height = height; this.ctx = this.canvas.getContext('2d'); this.priority = 2; this.resources = 2; } render(timestamp) { const rects = this.dirtyRects.length > 0 ? this.mergeRects(this.dirtyRects) : [{ x: 0, y: 0, w: this.canvas.width, h: this.canvas.height }]; for (const rect of rects) { this.ctx.save(); this.ctx.beginPath(); this.ctx.rect(rect.x, rect.y, rect.w, rect.h); this.ctx.clip(); this.drawContent(timestamp, rect); this.ctx.restore(); } } mergeRects(rects) { // 简化的包围盒合并 let minX = Infinity, minY = Infinity, maxX = -Infinity, maxY = -Infinity; for (const r of rects) { minX = Math.min(minX, r.x); minY = Math.min(minY, r.y); maxX = Math.max(maxX, r.x + r.w); maxY = Math.max(maxY, r.y + r.h); } return [{ x: minX, y: minY, w: maxX - minX, h: maxY - minY }]; } releaseResources() { this.canvas.width = 0; this.canvas.height = 0; this.ctx = null; this.resources = 0; } }

mergeRects这里用了最简单的包围盒合并。在实际项目中，如果脏区域分布很散，包围盒会包含大量无关区域，导致重绘面积过大。这时候可以改用四叉树或者网格划分，把脏区域按空间位置分组，每组单独合并。我实测过，在脏区域超过15个且分布分散时，网格划分能把重绘面积减少60%以上。

4.5 合成阶段的实现细节

合成阶段是把所有超帧的渲染结果合并到最终显示画布上。如果所有超帧都是Canvas后端，合成就是按z-order依次drawImage。如果混合了DOM和Canvas，就需要用CSS层叠或者离屏Canvas做中间层。混合模式的合成复杂度较高，我建议初期先用纯Canvas后端跑通，再逐步引入DOM超帧。

合成时要注意透明度混合和裁剪区域的处理。如果超帧有透明背景，合成时要确保下层内容正确透出。如果超帧有圆角或异形裁剪，需要在合成时应用对应的裁剪路径。这些细节在单超帧测试时不容易发现，多超帧叠加时才会暴露。我的经验是，在开发阶段给每个超帧加一个半透明边框，方便观察合成边界是否正确。

5. 常见问题与排查技巧实录

5.1 画面撕裂与帧不同步

画面撕裂是 hyperframes 项目里最常见的问题之一。表现是同一帧里不同超帧的内容看起来“错位”了，比如视频画面和字幕不同步，或者图表的数据点和坐标轴对不上。根本原因通常是各超帧读取的时间戳不一致，或者合成顺序与渲染顺序不匹配。

排查步骤我一般是这样走的：第一步，在调度器的tick入口打印时间戳，确认全局时间轴是否单调递增。第二步，在每个超帧的render里打印它读取到的时间戳，对比是否一致。第三步，检查合成队列的顺序是否与渲染顺序相同。如果时间戳一致但画面仍然撕裂，那大概率是合成阶段用了上一帧的纹理，需要检查纹理更新和合成的同步机制。

注意：如果用了requestAnimationFrame，它的回调时间戳和performance.now()可能有细微差异，统一用requestAnimationFrame传入的时间戳作为基准，不要混用。

5.2 内存持续增长不释放

内存泄漏在超帧架构里比较隐蔽，因为每个超帧的资源是分散管理的。我遇到过一次，页面运行半小时后内存涨到2GB，最后定位到是一个图表超帧在每次更新时都创建了新的ImageData对象，但没有释放旧的。ImageData占的是堆内存，GC 不会立即回收，积累多了就爆了。

排查内存问题，Chrome DevTools 的 Memory 面板是首选。用 Heap Snapshot 对比不同时间点的对象数量，重点看CanvasRenderingContext2D、WebGLTexture、ImageData、ArrayBuffer这几类的实例数。如果某个类型的实例数持续增长，就顺着引用链找到持有它的超帧。另一个技巧是用performance.memoryAPI 在运行时监控堆大小，超过阈值时自动触发一次强制 GC 并打印警告。

5.3 低端设备帧率骤降

hyperframes 在高端设备上跑得很流畅，但到了低端设备可能直接掉到个位数帧率。原因通常是多方面的：GPU填充率不足、CPU单核性能弱、内存带宽低。我的应对策略是分级降级。

第一级降级：降低合成分辨率。把主画布的width和height按比例缩小，比如从devicePixelRatio的2倍降到1倍，合成后再用CSS放大。这能直接减少75%的像素填充量。第二级降级：减少超帧更新频率。把非关键超帧的帧率从60fps降到30fps甚至15fps。第三级降级：合并超帧。把多个小超帧合并成一个大超帧，减少调度和合成开销。第四级降级：切换到静态图。对于长时间不变化的超帧，渲染一次后缓存为位图，后续直接复用。

这套降级策略需要根据设备能力动态选择。我一般用navigator.hardwareConcurrency和navigator.deviceMemory做初步判断，再结合运行时帧率监控做动态调整。

5.4 常见问题速查表

这张表是我从多个项目里总结出来的，覆盖了八成以上的常见问题。遇到新问题时，我建议先按表里的排查方法走一遍，大部分情况下能快速定位。

5.5 几个容易被忽略的实操心得

第一个心得：超帧的创建和销毁要配对。我见过一个项目，在路由切换时创建了新超帧但没有销毁旧的，结果旧超帧还在后台跑动画，白白消耗资源。后来加了一个超帧注册表，路由离开时统一销毁该路由下所有超帧，问题才解决。

第二个心得：脏区域不要跨超帧合并。不同超帧的脏区域即使重叠，也不要合并成一个大的合成区域，因为它们的更新时机可能不同。跨超帧合并会导致一个超帧的更新触发另一个超帧的无效重绘。正确的做法是每个超帧独立管理自己的脏区域，合成时按z-order依次处理。

第三个心得：给超帧加性能标记。在render方法里用performance.mark和performance.measure打点，然后在 DevTools 的 Performance 面板里就能看到每个超帧的耗时分布。这个习惯帮我发现过好几次性能瓶颈，比如某个超帧的drawContent里有个隐藏的O(n²)循环。

第四个心得：超帧的优先级要动态调整。固定优先级在大多数场景下够用，但在某些交互场景下需要动态调整。比如用户正在拖拽一个元素，那个元素所在的超帧应该临时提升到最高优先级，保证拖拽跟手。拖拽结束后再恢复原优先级。这个机制在协作白板类应用里特别重要。

6. 从原型到生产：几个关键决策点

6.1 什么时候该引入 hyperframes

不是所有项目都需要 hyperframes。我的判断标准是：页面内同时活跃的动态视觉单元超过30个，且更新频率高于每秒10次，或者单个视觉单元的更新开销超过2ms。低于这个量级，用传统的虚拟DOM加CSS动画就够了。强行引入 hyperframes 只会增加架构复杂度，收益不明显。

另一个判断维度是团队的技术储备。hyperframes 涉及渲染管线、时间轴同步、资源管理等多个底层概念，如果团队里没有人熟悉Canvas或WebGL，上手成本会很高。我建议先在非关键模块做试点，跑通一个完整闭环后再逐步推广。

6.2 后端选型的权衡

DOM后端、Canvas后端、WebGL后端各有适用场景。DOM后端适合文本密集、需要可访问性的内容；Canvas后端适合图形密集、更新频繁的内容；WebGL后端适合大规模粒子、3D变换、复杂滤镜。实际项目里往往是混合使用，比如一个数据大屏，标题和说明文字用DOM超帧，图表用Canvas超帧，背景粒子用WebGL超帧。

混合使用的难点在合成。DOM和Canvas的合成需要借助CSS层叠或者离屏Canvas。我的做法是给每种后端定义一个统一的合成接口，调度器不关心具体后端类型，只调用接口方法。这样新增后端时不需要改调度器代码。

6.3 测试与监控策略

hyperframes 的测试比普通前端组件复杂，因为涉及渲染结果和时序。单元测试可以覆盖超帧的生命周期和脏标记逻辑，但渲染结果需要视觉回归测试。我一般用 Puppeteer 截取每一帧的合成结果，和基准图做像素对比。时序相关的测试用假时钟，手动推进时间轴，验证各超帧的更新顺序和频率。

生产环境的监控重点看三个指标：帧率、超帧数量和内存占用。帧率低于30fps持续5秒就报警，超帧数量超过阈值就检查是否有泄漏，内存占用持续增长就触发堆快照。这些监控数据回传后，能帮助快速定位线上问题。

6.4 后续扩展方向

hyperframes 这套架构还有不少可以扩展的方向。比如引入离屏渲染线程，把渲染计算从主线程剥离，进一步降低主线程压力。或者支持超帧模板，把常用的超帧配置预定义成模板，创建时直接实例化，减少重复代码。再比如跨页面超帧复用，在单页应用的路由切换时保留部分超帧，避免重复创建和销毁。

我个人最看好的方向是自适应帧率。根据设备性能和当前负载，动态调整每个超帧的更新频率，在保证视觉流畅度的前提下最大化性能余量。这个机制需要一套精细的反馈控制算法，但一旦跑通，对不同设备的适配能力会有质的提升。

我在实际项目里踩过的坑远不止上面这些，有些是架构设计层面的，有些是具体API的兼容性问题。但核心经验就一条：超帧的粒度要合适。太粗了退化成传统方案，太细了调度开销反而更大。找到那个平衡点，需要结合具体业务场景反复调优。我的一般做法是先按视觉单元划分超帧，跑一轮性能测试，再把耗时最高的几个超帧拆细，把耗时最低的几个合并，迭代两三轮基本就能稳定下来。