G这个缩写在可视化圈子里其实很容易让人懵住。我先说清楚这篇文章里的 G 是指 AntV G也就是蚂蚁集团开源的那款图形渲染引擎不是 G2、G6也不是什么光刻线宽。我用 Vue 3 配合它做了个高校学生打卡数据可视化大屏从数据接口设计、屏幕适配到核心图表绘制、性能调优和上线运维都走了一遍。这篇文章会把整个过程的关键决策和踩坑点都摊开讲适合正在做可视化大屏、或者想在 Vue 项目里用 AntV G 做自定义渲染的同学参考。1. 为什么选 Vue AntV G 做打卡大屏1.1 大屏可视化对技术栈的隐藏要求刚开始接这个高校打卡大屏项目时我下意识先用 ECharts 出图毕竟上手快、文档多、示例也丰富。但做到第二版就被打脸了ECharts 能覆盖常规的柱状图、饼图、折线图不假可打卡大屏这东西的需求远不止画几张图这么简单。它有几个隐藏要求。第一大屏是长时间运行的。学工处的屏从早上 8 点挂到晚上 8 点期间数据每分钟都在变化浏览器不能越跑越卡每秒钟 60 帧的刷新率也不能因为一次推送就掉到 20 帧。第二信息密度极高。一块 1920x1080 的屏幕上可能同时出现十几个模块包括全校打卡率、各学院排行、近 7 日趋势、时段分布、缺卡名单滚动、体温异常提醒每个模块的视觉语言必须高度统一甚至需要自定义发光、描边、渐变、异形图形。这种程度的定制在 ECharts 里也能做但往往要把 option 配置项撑到几百行改一个细节就要重查一遍文档项目后期维护成本非常高。第三交互虽然少但交互形态特殊。大屏上的鼠标不像后台系统那样有键盘输入更多的是悬停高亮、点击下钻、自动轮播。我需要的是对绘图元素粒度的控制能力而不是图表级别的黑盒封装。第四视觉效果直接决定项目评价。给学校领导演示的时候比起标准柱状图他们更吃有科技感的大屏。这不是说要盲目上 3D但需要丰富的视觉体感。这时候 AntV G 的价值就体现出来了。它不提供现成的柱状图或饼图而是提供 Canvas/SVG 渲染能力以及圆、矩形、文本、路径这些图形原子。你可以把它理解成前端的 PS 画布画什么完全由你自己掌控。这不是说 ECharts 不好而是大屏项目的需求层次不同需要的工具层级也不同。1.2 G 与图表库是互补关系不是替代关系这里有一个常见误区以为用了 AntV G 就得放弃所有图表库。其实 G2 也是构建在 G 之上的G2Plot 和 G6 同样基于 G。它们的关系是地基和房子的关系。在实际项目中我的分工方式是这样的常规统计图表用 G2Plot 快速搭建比如学院打卡率横向条形图、时段分布柱状图而大屏核心的打卡率环形进度宿舍楼网格热力发光数字牌这类高度定制化组件直接用 G 绘制。这样分层的核心原因是效率和灵活度的平衡。G2Plot 让我 10 分钟出图G 让我对最终像素级效果负责。你在做技术选型时建议先想清楚项目里 80% 的图表是不是常规图表如果答案是肯定的就不要让工程师用 G 从零画柱状图那是学步车的痛苦反而要有用图表库为主、用 G 做定制组件的思想准备。2. 打卡数据模型与大屏信息架构2.1 后端接口设计前端只消费宽表可视化大屏最怕的不是图表难画而是数据接口设计得东一块西一块。第一个版本后端同学把打卡记录、学生档案、学院组织分成三个接口返回我在前端要做大量的 groupBy、map、reduce 才能拼出大屏需要的数据结构性能也差。后来我们约定了一种更省力的模式后端直接输出前端画图需要什么就返回什么的宽表接口。比如大屏首页的主接口结构大概是这样的{ code: 0, data: { summary: { totalStudents: 12860, checkedCount: 11902, checkRate: 92.55, abnormalTempCount: 12, currentTime: 2024-06-12 09:30:00 }, collegeRank: [ { collegeName: 计算机学院, checkRate: 98.2, checkedCount: 1830, totalCount: 1864 }, { collegeName: 机械学院, checkRate: 95.1, checkedCount: 1452, totalCount: 1527 } ], hourlyTrend: [ { hour: 7, count: 523 }, { hour: 8, count: 3210 }, { hour: 9, count: 4190 } ], dormGrid: [ { building: 梅苑1栋, checkedCount: 356, totalCount: 380 }, { building: 梅苑2栋, checkedCount: 289, totalCount: 310 } ] } }这样前端每个组件都只要拿自己的那一段数据画图的逻辑就变得很纯粹。不过这种宽表设计有前提条件对数据实时性要求不是毫秒级大屏需要的聚合结果可以由后端定时任务或缓存层提前算好。打卡场景天然满足这个条件——每分钟聚合一次完全够用。至于底层的原始打卡流水表结构倒不用太复杂CREATE TABLE checkin_records ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL COMMENT 学号, college_id INT NOT NULL COMMENT 学院ID, dorm_building VARCHAR(32) DEFAULT NULL COMMENT 宿舍楼, check_in_time DATETIME NOT NULL COMMENT 打卡时间, temperature DECIMAL(4,2) DEFAULT NULL COMMENT 体温, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0缺卡, KEY idx_check_in_time (check_in_time), KEY idx_college_time (college_id, check_in_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;2.2 从数据指标到视觉组件的映射拿到宽表之后下一步是做信息架构设计。大屏不是把数据全部堆上去而是要回答三个问题领导先看什么发现异常后怎么定位盯屏时什么信息最重要我在这个项目里把指标分成了三个层级层级核心信息视觉组件数据频率全局总览今日打卡率、应到/实到人数中央环形仪表 发光数字每 30 秒轮询或 WebSocket分布分析各学院排行、24h 时段分布、近 7 日趋势横向条形图、柱状图、迷你趋势线每 1 分钟聚合预警定位体温异常、缺卡学生名单、宿舍楼进度滚动列表、彩色标签、热力网格WebSocket 实时推送有了这张表开发顺序就很清晰了。先把全局总览的视觉气质定下来再做分布分析最后做预警定位。每块组件的数据来源、刷新策略也都一清二楚不用做到一半再去问后端这个字段有没有。2.3 前端数据流WebSocket 推送 轮询兜底打卡数据的实时性分两种。一种是大屏主界面的准实时30 秒内能看到最新数据就可以接受另一种是异常预警比如体温异常最好几秒内就飘出来。我采用的是WebSocket 推送 30 秒轮询兜底的组合方案。WebSocket 用于推送两类消息一类是聚合数据变更后端每 1 分钟广播一次新的 summary、collegeRank 等另一类是异常事件比如有学生体温异常后端通过 WEBSOCKET_MESSAGE 推送一条包含学院、姓名、楼栋的消息前端接收到后立即在滚动列表顶部插入。轮询兜底是为了防止 WebSocket 链路在校园网环境下意外断开后整个大屏变成僵尸屏。我的实现思路是每 30 秒拉一次主聚合接口同时判断 WebSocket 连接状态如果断开则切换成纯轮询模式恢复后自动切回。代码逻辑大概是这样的type CheckinSocketMessage | { type: SUMMARY_UPDATE; payload: SummaryData } | { type: ABNORMAL_ALERT; payload: AbnormalItem }; export function useCheckinSocket(onMessage: (msg: CheckinSocketMessage) void) { let ws: WebSocket | null null; let reconnectTimer: number | undefined; let heartbeatTimer: number | undefined; const connect () { ws new WebSocket(wss://your-domain/api/ws/checkin); ws.onmessage (event) { try { const msg JSON.parse(event.data) as CheckinSocketMessage; onMessage(msg); } catch (e) { console.error(消息解析失败, e); } }; ws.onclose () scheduleReconnect(); ws.onerror () ws?.close(); }; const scheduleReconnect () { window.clearTimeout(reconnectTimer); reconnectTimer window.setTimeout(connect, 5000); }; // 启动心跳 heartbeatTimer window.setInterval(() { if (ws?.readyState WebSocket.OPEN) ws.send(ping); }, 10000); connect(); return { close: () { ws?.close(); window.clearInterval(reconnectTimer); window.clearInterval(heartbeatTimer); }, }; }这里有个细节容易被忽略WebSocket 的连接地址不要写死要通过/config.js这样的运行时配置注入。因为大屏部署在教室时访问域名的 IP 可能和内网开发环境不同硬编码地址会导致每次换环境都要重新构建。3. 从零搭建大屏项目的两个关键工程决策3.1 屏幕适配方案1920 设计稿 scale 缩放大屏适配是个老话题我见过很多人用 rem 方案做响应式大屏结果越做越乱。原因在于 rem 方案本质上是流式布局适合内容多、可滚动的网页而大屏需要的是固定设计稿 等比缩放。我的做法很传统所有页面按 1920x1080 设计稿开发根容器固定 1920 宽、1080 高然后在启动时计算实际浏览器窗口与设计稿的比例用 CSStransform: scale整体缩放。function fitScreen(container: HTMLElement, width 1920, height 1080) { const winW document.documentElement.clientWidth; const winH document.documentElement.clientHeight; const scale Math.min(winW / width, winH / height); container.style.width ${width}px; container.style.height ${height}px; container.style.transformOrigin left top; container.style.transform scale(${scale}); }这个方案的优势是内部布局不用考虑任何响应式问题绝对定位、固定间距、统一字号都按设计稿来简单粗暴且不容易出错。但有几个隐藏细节要注意。缩放之后的容器会占据原始尺寸依然为 1920x1080 的已缩放区域但页面外层如果居中对齐容易出现留白或者滚动条。我通常在外层包一个 flex 容器设置align-items: center; justify-content: center; overflow: hidden让缩放后的画布自动居中。同时图表中鼠标悬停、点击事件如果依赖屏幕坐标必须把 clientX / clientY 除以 scale 再换算成设计稿坐标否则定位永远偏一截。3.2 组件化拆分与异步加载大屏模块多如果所有图表在首页同时初始化首屏渲染时间会肉眼可见地变长。我的处理策略是两条腿走路。第一逻辑上每个视觉模块独立成一个.vue组件。组件内部维护自己的数据状态和 G 画布实例互不干扰。例如CheckRateRing.vue、CollegeRankBar.vue、AbnormalList.vue等。这些组件对外只暴露data属性或update()方法适合团队协作并行开发。第二对非首屏必须立即展示的次级模块使用异步组件。Vue 3 的defineAsyncComponent配合动态 import 可以让这些模块按需加载。我实际项目里的写法是import { defineAsyncComponent } from vue; const DormGridPanel defineAsyncComponent( () import(/components/DormGridPanel.vue) );如果只是少量模块建议不要做路由懒加载因为大屏本质上是一个单页面切换时不希望出现白屏。异步组件只需要保证首屏关键区域的图形先出来次要模块在 1 到 2 秒内慢慢补上即可视觉上反而是内容渐进呈现的效果。全局状态我用一个轻量的reactivestore 管理不放 Vuex/Pinia 也完全够。大屏的数据流其实很单纯WebSocket 收到消息 - 更新 store - 各个组件通过computed得到自己关心的数据。用 Pinia 也不算重但没必要为了用而用。4. 基于 G 实现核心可视化组件4.1 全校打卡率环形图的实现环形打卡率是大屏最核心的视觉焦点。用 AntV G 画这个图本质上是先画一个背景圆环再画一个按百分比截断的进度圆环最后在圆心放文字。以antv/g5的 API 为例先初始化渲染器import { Canvas, Circle, Text } from antv/g; import { Renderer as CanvasRenderer } from antv/g-canvas; const renderer new CanvasRenderer(); const canvas new Canvas({ container: ringContainer.value, width: 360, height: 360, renderer, });进度环我用的是Circle的lineDash技巧。先算出圆环周长再根据百分比把有颜色的线段和空白的缺口设置进 lineDashconst radius 150; const circumference 2 * Math.PI * radius; const percent 0.9255; const dashLen circumference * percent; const gapLen circumference * (1 - percent); const progressRing new Circle({ style: { r: radius, lineWidth: 26, stroke: #3f7cff, strokeOpacity: 1, lineDash: [dashLen, gapLen], lineCap: round, }, });背景圆环则是一个灰色、线宽更大的Circle不加 lineDash。这样两个圆叠在一起就形成了底部轨道和顶部进度的效果。接下来是文字。文字不能画在 Canvas 初始化之前或者字体加载完成之前否则会出现文字不渲染或回退默认字体的问题。我这里等document.fonts.ready之后再用Text节点更新数值const numberText new Text({ style: { text: 92.6%, fontSize: 56, fontFamily: DIN Alternate, Roboto, sans-serif, fill: #ffffff, textAlign: center, textBaseline: middle, x: 180, y: 160, }, });这是常规图表库能做但控制力比较弱的场景因为你对颜色渐变、发光阴影、动画缓动每一步都有绝对控制权。比如进度环末尾加一个白色小圆点作为端点只需再创建一个Circle坐标通过三角函数根据角度计算即可。4.2 近 7 日连续打卡热力网格打卡大屏另一个关键组件是近 7 日趋势我没有用传统的折线图而是做成了一个 7 列的网格热力每一格代表某一天的数据完成度颜色从深红到亮绿渐变。用 G 画这个图不算复杂就是创建 7 个矩形根据数据值设置不同的填充色import { Rect, Group } from antv/g; const group new Group(); const dayData [ { label: 周一, value: 88 }, { label: 周二, value: 92 }, { label: 周三, value: 85 }, ]; dayData.forEach((item, index) { const bar new Rect({ style: { x: 40 index * 70, y: 200 - item.value * 1.2, width: 40, height: item.value * 1.2, fill: getHeatColor(item.value), radius: 6, shadowColor: getHeatColor(item.value), shadowBlur: 12, }, }); group.appendChild(bar); }); canvas.appendChild(group);这里用到的shadowColor和shadowBlur是 G 的 Canvas 渲染器支持的特效能让每个柱块带一点发光质感大屏科技感一下子就出来了。但要注意不能过度使用全屏 200 个节点都带大 radius 阴影的话Canvas 的绘图开销会拖低帧率这也是我在做性能优化时真实遇到过的坑下一章节会细讲。4.3 滚动流水列表不一定要用 G 画最后说滚动流水列表。我建议这种长列表不要用 G 硬画因为列表的滚动、裁剪、逐条插入动画如果用 DOM 来做Vue 本身就能很自然地处理而且 CSS 的 transform 动画性能也足够。我的做法是用 Vue 的TransitionGroup包一层列表收到 WebSocket 推送的异常预警时在最前面插入一条数据并让超过 20 条的旧数据自动出队。视觉上用 CSS 遮罩做一个渐隐让列表底部看起来是淡出消失配合整个大屏的深色背景非常自然。结论就是G 适合承担图形密集型的组件SVG/DOM 适合承担文本密集型的组件。做技术选型时不要只盯着一门技术能简单就不要复杂。5. 大屏性能调优和渲染避坑记录5.1 高频数据更新导致的掉帧问题打卡数据在高峰时段早上 7 点到 9 点推送非常频繁几乎每分钟都有几十条消息。如果每收到一条消息就把整个 G 画布全部销毁重建帧率会跌到没法看。正确的做法是对已经存在画布上的节点做增量更新而不是整体重建。以环形图为例每次数据刷新时只需要更新进度环的lineDash和文字内容不需要重新appendChildfunction updateRing(newPercent: number) { const dashLen circumference * newPercent; progressRing.attr({ lineDash: [dashLen, circumference - dashLen], }); numberText.attr(text, ${(newPercent * 100).toFixed(1)}%); }如果再激进一点可以把多次数据更新合并到同一帧里处理。核心思路是收到推送时只把最新数据存入变量真正执行绘图逻辑的触发函数用一个requestAnimationFrame包裹。这样即使 1 秒内收到 5 条推送也只在下一帧画一次避免 CPU 被无意义的重复绘制打满。5.2 分辨率适配与分层 Canvas大屏项目最容易翻车的适配点不是 CSS而是 Canvas。有些校园教室的电脑设置了 Windows 125% 或 150% 的显示缩放如果不处理devicePixelRatio所有 G 图形都会发虚字像蒙了一层雾。G 的 Canvas 初始化里有一个devicePixelRatio选项。比较稳妥的做法是动态读取const canvas new Canvas({ container: el, width: 360, height: 360, renderer, devicePixelRatio: window.devicePixelRatio || 1, });除了 DPR另一个有效的性能手段是分层 Canvas。我把大屏中静态背景装饰层和动态数据层分开静态层只绘制一次之后不再更新动态层才响应 WebSocket 数据变更。这样做的收益在长时间运行时非常明显静态层的绘制压力完全被移除了动态层的重绘范围也小很多。5.3 字体加载与中文渲染我第一次在 G 里写大段中文标签时发现有些中文字体在 Canvas 环境下出现了严重的基线偏移偏上或者偏下字与字之间还可能出现异常宽度。查了社区讨论后确认这是 Canvas 字体渲染的老问题尤其是在 Windows 上使用微软雅黑配合textBaseline: middle时比较明显。解决方案有两个。一是把textBaseline从middle调整为alphabetic或者top不同字体需要微调二是等document.fonts.ready完成后再绘制。中文字体如果还没加载完成Canvas 会退化到默认字体字形宽度和预期完全不同导致居中布局错乱。项目里用了自定义数字字体做统计数字这个问题尤其需要重视document.fonts.ready.then(() { numberText.attr(text, 92.6%); });如果你追求更稳定的排版也可以把文字拆分成 DOM 元素叠在 Canvas 上面。这种做法叫Canvas 背景 DOM 前景在很多大屏项目里都常见可读性和可维护性都会更好。6. 部署上线与日常维护经验6.1 构建体积优化与 CDN 分离大屏项目不等于包越大越好。用 Vue 3 AntV G 打包后基础体积并不小如果部署在校园网内一台普通的服务器上首屏加载时间可能长达 5 秒以上。我把第三方库比较稳定的部分Vue、AntV G、G2Plot通过 CDN 引入并在 Vite 配置里把 external 排除出打包产物首屏体积能减少 30% 左右。同时生产环境配置 Nginx 开启 gzip 或 Brotli 压缩。如果你用的是 Vite构建出来的 js/css 文件已经做了 hash 缓存配合 Nginx 的静态资源长缓存大屏第二次打开会流畅很多。6.2 长时间运行的稳定性保障大屏不是开机演示 5 分钟就关掉的。它经常从早上挂到晚上期间不能有人盯着控制台。所以我针对长时间运行做了几个特别处理。第一是 WebSocket 断线重连。校园网偶尔会调度 IP 或者 DHCP 租约到期连接可能毫无征兆地断开。我实现了一个指数退避的重连逻辑第一次失败等 2 秒第二次 4 秒最多 60 秒避免断线风暴导致服务器被打挂。第二是内存泄漏防范。Vue 组件卸载时一定要调用 G 画布实例的 destroy 方法否则 Canvas 监听器、纹理资源不会被释放。这个问题的隐蔽之处在于大屏开发过程中组件频繁热更新内存泄漏在开发环境不一定明显但上线运行 10 小时后浏览器标签页可能占用 2GB 内存。onBeforeUnmount(() { canvas.destroy(); });第三是自愈机制。我用一个独立的心跳脚本每隔 30 秒检测主线程是否有响应如果页面卡死超过 10 秒就自动刷新页面。做法很简单在主线程任务里隔一段时间标记一个时间戳心跳线程通过对比时间戳判断主线程是否还活着。第四是时间同步。大屏上显示的当前时间和倒计时不能直接用设备本地时间因为教室电脑的系统时间快了慢了都有可能出现。所有时间显示都用后端接口返回的serverTime进行计算前端只负责每秒做一次增量。这些措施单个看起来都不起眼组合起来却是大屏稳定运行的保命符。最后说一个我自己的体会做数据可视化大屏真正花时间的往往不只是画图而是理解数据、组织通信、设计渲染策略。Vue 负责组件AntV G 负责像素控制WebSocket 负责实时流动三者配合好高校打卡场景里那些看似复杂的需求都能逐个落地。如果你正准备做同类型的大屏项目建议先用这套思路做一版最小闭环不要一上来就追求满屏 3D 效果。等主流程跑通之后再慢慢给图形加发光、渐变、动画体验完全不同。
G这个缩写在可视化圈子里其实很容易让人懵住。我先说清楚这篇文章里的 G 是指 AntV G也就是蚂蚁集团开源的那款图形渲染引擎不是 G2、G6也不是什么光刻线宽。我用 Vue 3 配合它做了个高校学生打卡数据可视化大屏从数据接口设计、屏幕适配到核心图表绘制、性能调优和上线运维都走了一遍。这篇文章会把整个过程的关键决策和踩坑点都摊开讲适合正在做可视化大屏、或者想在 Vue 项目里用 AntV G 做自定义渲染的同学参考。1. 为什么选 Vue AntV G 做打卡大屏1.1 大屏可视化对技术栈的隐藏要求刚开始接这个高校打卡大屏项目时我下意识先用 ECharts 出图毕竟上手快、文档多、示例也丰富。但做到第二版就被打脸了ECharts 能覆盖常规的柱状图、饼图、折线图不假可打卡大屏这东西的需求远不止画几张图这么简单。它有几个隐藏要求。第一大屏是长时间运行的。学工处的屏从早上 8 点挂到晚上 8 点期间数据每分钟都在变化浏览器不能越跑越卡每秒钟 60 帧的刷新率也不能因为一次推送就掉到 20 帧。第二信息密度极高。一块 1920x1080 的屏幕上可能同时出现十几个模块包括全校打卡率、各学院排行、近 7 日趋势、时段分布、缺卡名单滚动、体温异常提醒每个模块的视觉语言必须高度统一甚至需要自定义发光、描边、渐变、异形图形。这种程度的定制在 ECharts 里也能做但往往要把 option 配置项撑到几百行改一个细节就要重查一遍文档项目后期维护成本非常高。第三交互虽然少但交互形态特殊。大屏上的鼠标不像后台系统那样有键盘输入更多的是悬停高亮、点击下钻、自动轮播。我需要的是对绘图元素粒度的控制能力而不是图表级别的黑盒封装。第四视觉效果直接决定项目评价。给学校领导演示的时候比起标准柱状图他们更吃有科技感的大屏。这不是说要盲目上 3D但需要丰富的视觉体感。这时候 AntV G 的价值就体现出来了。它不提供现成的柱状图或饼图而是提供 Canvas/SVG 渲染能力以及圆、矩形、文本、路径这些图形原子。你可以把它理解成前端的 PS 画布画什么完全由你自己掌控。这不是说 ECharts 不好而是大屏项目的需求层次不同需要的工具层级也不同。1.2 G 与图表库是互补关系不是替代关系这里有一个常见误区以为用了 AntV G 就得放弃所有图表库。其实 G2 也是构建在 G 之上的G2Plot 和 G6 同样基于 G。它们的关系是地基和房子的关系。在实际项目中我的分工方式是这样的常规统计图表用 G2Plot 快速搭建比如学院打卡率横向条形图、时段分布柱状图而大屏核心的打卡率环形进度宿舍楼网格热力发光数字牌这类高度定制化组件直接用 G 绘制。这样分层的核心原因是效率和灵活度的平衡。G2Plot 让我 10 分钟出图G 让我对最终像素级效果负责。你在做技术选型时建议先想清楚项目里 80% 的图表是不是常规图表如果答案是肯定的就不要让工程师用 G 从零画柱状图那是学步车的痛苦反而要有用图表库为主、用 G 做定制组件的思想准备。2. 打卡数据模型与大屏信息架构2.1 后端接口设计前端只消费宽表可视化大屏最怕的不是图表难画而是数据接口设计得东一块西一块。第一个版本后端同学把打卡记录、学生档案、学院组织分成三个接口返回我在前端要做大量的 groupBy、map、reduce 才能拼出大屏需要的数据结构性能也差。后来我们约定了一种更省力的模式后端直接输出前端画图需要什么就返回什么的宽表接口。比如大屏首页的主接口结构大概是这样的{ code: 0, data: { summary: { totalStudents: 12860, checkedCount: 11902, checkRate: 92.55, abnormalTempCount: 12, currentTime: 2024-06-12 09:30:00 }, collegeRank: [ { collegeName: 计算机学院, checkRate: 98.2, checkedCount: 1830, totalCount: 1864 }, { collegeName: 机械学院, checkRate: 95.1, checkedCount: 1452, totalCount: 1527 } ], hourlyTrend: [ { hour: 7, count: 523 }, { hour: 8, count: 3210 }, { hour: 9, count: 4190 } ], dormGrid: [ { building: 梅苑1栋, checkedCount: 356, totalCount: 380 }, { building: 梅苑2栋, checkedCount: 289, totalCount: 310 } ] } }这样前端每个组件都只要拿自己的那一段数据画图的逻辑就变得很纯粹。不过这种宽表设计有前提条件对数据实时性要求不是毫秒级大屏需要的聚合结果可以由后端定时任务或缓存层提前算好。打卡场景天然满足这个条件——每分钟聚合一次完全够用。至于底层的原始打卡流水表结构倒不用太复杂CREATE TABLE checkin_records ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_no VARCHAR(20) NOT NULL COMMENT 学号, college_id INT NOT NULL COMMENT 学院ID, dorm_building VARCHAR(32) DEFAULT NULL COMMENT 宿舍楼, check_in_time DATETIME NOT NULL COMMENT 打卡时间, temperature DECIMAL(4,2) DEFAULT NULL COMMENT 体温, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 0缺卡, KEY idx_check_in_time (check_in_time), KEY idx_college_time (college_id, check_in_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;2.2 从数据指标到视觉组件的映射拿到宽表之后下一步是做信息架构设计。大屏不是把数据全部堆上去而是要回答三个问题领导先看什么发现异常后怎么定位盯屏时什么信息最重要我在这个项目里把指标分成了三个层级层级核心信息视觉组件数据频率全局总览今日打卡率、应到/实到人数中央环形仪表 发光数字每 30 秒轮询或 WebSocket分布分析各学院排行、24h 时段分布、近 7 日趋势横向条形图、柱状图、迷你趋势线每 1 分钟聚合预警定位体温异常、缺卡学生名单、宿舍楼进度滚动列表、彩色标签、热力网格WebSocket 实时推送有了这张表开发顺序就很清晰了。先把全局总览的视觉气质定下来再做分布分析最后做预警定位。每块组件的数据来源、刷新策略也都一清二楚不用做到一半再去问后端这个字段有没有。2.3 前端数据流WebSocket 推送 轮询兜底打卡数据的实时性分两种。一种是大屏主界面的准实时30 秒内能看到最新数据就可以接受另一种是异常预警比如体温异常最好几秒内就飘出来。我采用的是WebSocket 推送 30 秒轮询兜底的组合方案。WebSocket 用于推送两类消息一类是聚合数据变更后端每 1 分钟广播一次新的 summary、collegeRank 等另一类是异常事件比如有学生体温异常后端通过 WEBSOCKET_MESSAGE 推送一条包含学院、姓名、楼栋的消息前端接收到后立即在滚动列表顶部插入。轮询兜底是为了防止 WebSocket 链路在校园网环境下意外断开后整个大屏变成僵尸屏。我的实现思路是每 30 秒拉一次主聚合接口同时判断 WebSocket 连接状态如果断开则切换成纯轮询模式恢复后自动切回。代码逻辑大概是这样的type CheckinSocketMessage | { type: SUMMARY_UPDATE; payload: SummaryData } | { type: ABNORMAL_ALERT; payload: AbnormalItem }; export function useCheckinSocket(onMessage: (msg: CheckinSocketMessage) void) { let ws: WebSocket | null null; let reconnectTimer: number | undefined; let heartbeatTimer: number | undefined; const connect () { ws new WebSocket(wss://your-domain/api/ws/checkin); ws.onmessage (event) { try { const msg JSON.parse(event.data) as CheckinSocketMessage; onMessage(msg); } catch (e) { console.error(消息解析失败, e); } }; ws.onclose () scheduleReconnect(); ws.onerror () ws?.close(); }; const scheduleReconnect () { window.clearTimeout(reconnectTimer); reconnectTimer window.setTimeout(connect, 5000); }; // 启动心跳 heartbeatTimer window.setInterval(() { if (ws?.readyState WebSocket.OPEN) ws.send(ping); }, 10000); connect(); return { close: () { ws?.close(); window.clearInterval(reconnectTimer); window.clearInterval(heartbeatTimer); }, }; }这里有个细节容易被忽略WebSocket 的连接地址不要写死要通过/config.js这样的运行时配置注入。因为大屏部署在教室时访问域名的 IP 可能和内网开发环境不同硬编码地址会导致每次换环境都要重新构建。3. 从零搭建大屏项目的两个关键工程决策3.1 屏幕适配方案1920 设计稿 scale 缩放大屏适配是个老话题我见过很多人用 rem 方案做响应式大屏结果越做越乱。原因在于 rem 方案本质上是流式布局适合内容多、可滚动的网页而大屏需要的是固定设计稿 等比缩放。我的做法很传统所有页面按 1920x1080 设计稿开发根容器固定 1920 宽、1080 高然后在启动时计算实际浏览器窗口与设计稿的比例用 CSStransform: scale整体缩放。function fitScreen(container: HTMLElement, width 1920, height 1080) { const winW document.documentElement.clientWidth; const winH document.documentElement.clientHeight; const scale Math.min(winW / width, winH / height); container.style.width ${width}px; container.style.height ${height}px; container.style.transformOrigin left top; container.style.transform scale(${scale}); }这个方案的优势是内部布局不用考虑任何响应式问题绝对定位、固定间距、统一字号都按设计稿来简单粗暴且不容易出错。但有几个隐藏细节要注意。缩放之后的容器会占据原始尺寸依然为 1920x1080 的已缩放区域但页面外层如果居中对齐容易出现留白或者滚动条。我通常在外层包一个 flex 容器设置align-items: center; justify-content: center; overflow: hidden让缩放后的画布自动居中。同时图表中鼠标悬停、点击事件如果依赖屏幕坐标必须把 clientX / clientY 除以 scale 再换算成设计稿坐标否则定位永远偏一截。3.2 组件化拆分与异步加载大屏模块多如果所有图表在首页同时初始化首屏渲染时间会肉眼可见地变长。我的处理策略是两条腿走路。第一逻辑上每个视觉模块独立成一个.vue组件。组件内部维护自己的数据状态和 G 画布实例互不干扰。例如CheckRateRing.vue、CollegeRankBar.vue、AbnormalList.vue等。这些组件对外只暴露data属性或update()方法适合团队协作并行开发。第二对非首屏必须立即展示的次级模块使用异步组件。Vue 3 的defineAsyncComponent配合动态 import 可以让这些模块按需加载。我实际项目里的写法是import { defineAsyncComponent } from vue; const DormGridPanel defineAsyncComponent( () import(/components/DormGridPanel.vue) );如果只是少量模块建议不要做路由懒加载因为大屏本质上是一个单页面切换时不希望出现白屏。异步组件只需要保证首屏关键区域的图形先出来次要模块在 1 到 2 秒内慢慢补上即可视觉上反而是内容渐进呈现的效果。全局状态我用一个轻量的reactivestore 管理不放 Vuex/Pinia 也完全够。大屏的数据流其实很单纯WebSocket 收到消息 - 更新 store - 各个组件通过computed得到自己关心的数据。用 Pinia 也不算重但没必要为了用而用。4. 基于 G 实现核心可视化组件4.1 全校打卡率环形图的实现环形打卡率是大屏最核心的视觉焦点。用 AntV G 画这个图本质上是先画一个背景圆环再画一个按百分比截断的进度圆环最后在圆心放文字。以antv/g5的 API 为例先初始化渲染器import { Canvas, Circle, Text } from antv/g; import { Renderer as CanvasRenderer } from antv/g-canvas; const renderer new CanvasRenderer(); const canvas new Canvas({ container: ringContainer.value, width: 360, height: 360, renderer, });进度环我用的是Circle的lineDash技巧。先算出圆环周长再根据百分比把有颜色的线段和空白的缺口设置进 lineDashconst radius 150; const circumference 2 * Math.PI * radius; const percent 0.9255; const dashLen circumference * percent; const gapLen circumference * (1 - percent); const progressRing new Circle({ style: { r: radius, lineWidth: 26, stroke: #3f7cff, strokeOpacity: 1, lineDash: [dashLen, gapLen], lineCap: round, }, });背景圆环则是一个灰色、线宽更大的Circle不加 lineDash。这样两个圆叠在一起就形成了底部轨道和顶部进度的效果。接下来是文字。文字不能画在 Canvas 初始化之前或者字体加载完成之前否则会出现文字不渲染或回退默认字体的问题。我这里等document.fonts.ready之后再用Text节点更新数值const numberText new Text({ style: { text: 92.6%, fontSize: 56, fontFamily: DIN Alternate, Roboto, sans-serif, fill: #ffffff, textAlign: center, textBaseline: middle, x: 180, y: 160, }, });这是常规图表库能做但控制力比较弱的场景因为你对颜色渐变、发光阴影、动画缓动每一步都有绝对控制权。比如进度环末尾加一个白色小圆点作为端点只需再创建一个Circle坐标通过三角函数根据角度计算即可。4.2 近 7 日连续打卡热力网格打卡大屏另一个关键组件是近 7 日趋势我没有用传统的折线图而是做成了一个 7 列的网格热力每一格代表某一天的数据完成度颜色从深红到亮绿渐变。用 G 画这个图不算复杂就是创建 7 个矩形根据数据值设置不同的填充色import { Rect, Group } from antv/g; const group new Group(); const dayData [ { label: 周一, value: 88 }, { label: 周二, value: 92 }, { label: 周三, value: 85 }, ]; dayData.forEach((item, index) { const bar new Rect({ style: { x: 40 index * 70, y: 200 - item.value * 1.2, width: 40, height: item.value * 1.2, fill: getHeatColor(item.value), radius: 6, shadowColor: getHeatColor(item.value), shadowBlur: 12, }, }); group.appendChild(bar); }); canvas.appendChild(group);这里用到的shadowColor和shadowBlur是 G 的 Canvas 渲染器支持的特效能让每个柱块带一点发光质感大屏科技感一下子就出来了。但要注意不能过度使用全屏 200 个节点都带大 radius 阴影的话Canvas 的绘图开销会拖低帧率这也是我在做性能优化时真实遇到过的坑下一章节会细讲。4.3 滚动流水列表不一定要用 G 画最后说滚动流水列表。我建议这种长列表不要用 G 硬画因为列表的滚动、裁剪、逐条插入动画如果用 DOM 来做Vue 本身就能很自然地处理而且 CSS 的 transform 动画性能也足够。我的做法是用 Vue 的TransitionGroup包一层列表收到 WebSocket 推送的异常预警时在最前面插入一条数据并让超过 20 条的旧数据自动出队。视觉上用 CSS 遮罩做一个渐隐让列表底部看起来是淡出消失配合整个大屏的深色背景非常自然。结论就是G 适合承担图形密集型的组件SVG/DOM 适合承担文本密集型的组件。做技术选型时不要只盯着一门技术能简单就不要复杂。5. 大屏性能调优和渲染避坑记录5.1 高频数据更新导致的掉帧问题打卡数据在高峰时段早上 7 点到 9 点推送非常频繁几乎每分钟都有几十条消息。如果每收到一条消息就把整个 G 画布全部销毁重建帧率会跌到没法看。正确的做法是对已经存在画布上的节点做增量更新而不是整体重建。以环形图为例每次数据刷新时只需要更新进度环的lineDash和文字内容不需要重新appendChildfunction updateRing(newPercent: number) { const dashLen circumference * newPercent; progressRing.attr({ lineDash: [dashLen, circumference - dashLen], }); numberText.attr(text, ${(newPercent * 100).toFixed(1)}%); }如果再激进一点可以把多次数据更新合并到同一帧里处理。核心思路是收到推送时只把最新数据存入变量真正执行绘图逻辑的触发函数用一个requestAnimationFrame包裹。这样即使 1 秒内收到 5 条推送也只在下一帧画一次避免 CPU 被无意义的重复绘制打满。5.2 分辨率适配与分层 Canvas大屏项目最容易翻车的适配点不是 CSS而是 Canvas。有些校园教室的电脑设置了 Windows 125% 或 150% 的显示缩放如果不处理devicePixelRatio所有 G 图形都会发虚字像蒙了一层雾。G 的 Canvas 初始化里有一个devicePixelRatio选项。比较稳妥的做法是动态读取const canvas new Canvas({ container: el, width: 360, height: 360, renderer, devicePixelRatio: window.devicePixelRatio || 1, });除了 DPR另一个有效的性能手段是分层 Canvas。我把大屏中静态背景装饰层和动态数据层分开静态层只绘制一次之后不再更新动态层才响应 WebSocket 数据变更。这样做的收益在长时间运行时非常明显静态层的绘制压力完全被移除了动态层的重绘范围也小很多。5.3 字体加载与中文渲染我第一次在 G 里写大段中文标签时发现有些中文字体在 Canvas 环境下出现了严重的基线偏移偏上或者偏下字与字之间还可能出现异常宽度。查了社区讨论后确认这是 Canvas 字体渲染的老问题尤其是在 Windows 上使用微软雅黑配合textBaseline: middle时比较明显。解决方案有两个。一是把textBaseline从middle调整为alphabetic或者top不同字体需要微调二是等document.fonts.ready完成后再绘制。中文字体如果还没加载完成Canvas 会退化到默认字体字形宽度和预期完全不同导致居中布局错乱。项目里用了自定义数字字体做统计数字这个问题尤其需要重视document.fonts.ready.then(() { numberText.attr(text, 92.6%); });如果你追求更稳定的排版也可以把文字拆分成 DOM 元素叠在 Canvas 上面。这种做法叫Canvas 背景 DOM 前景在很多大屏项目里都常见可读性和可维护性都会更好。6. 部署上线与日常维护经验6.1 构建体积优化与 CDN 分离大屏项目不等于包越大越好。用 Vue 3 AntV G 打包后基础体积并不小如果部署在校园网内一台普通的服务器上首屏加载时间可能长达 5 秒以上。我把第三方库比较稳定的部分Vue、AntV G、G2Plot通过 CDN 引入并在 Vite 配置里把 external 排除出打包产物首屏体积能减少 30% 左右。同时生产环境配置 Nginx 开启 gzip 或 Brotli 压缩。如果你用的是 Vite构建出来的 js/css 文件已经做了 hash 缓存配合 Nginx 的静态资源长缓存大屏第二次打开会流畅很多。6.2 长时间运行的稳定性保障大屏不是开机演示 5 分钟就关掉的。它经常从早上挂到晚上期间不能有人盯着控制台。所以我针对长时间运行做了几个特别处理。第一是 WebSocket 断线重连。校园网偶尔会调度 IP 或者 DHCP 租约到期连接可能毫无征兆地断开。我实现了一个指数退避的重连逻辑第一次失败等 2 秒第二次 4 秒最多 60 秒避免断线风暴导致服务器被打挂。第二是内存泄漏防范。Vue 组件卸载时一定要调用 G 画布实例的 destroy 方法否则 Canvas 监听器、纹理资源不会被释放。这个问题的隐蔽之处在于大屏开发过程中组件频繁热更新内存泄漏在开发环境不一定明显但上线运行 10 小时后浏览器标签页可能占用 2GB 内存。onBeforeUnmount(() { canvas.destroy(); });第三是自愈机制。我用一个独立的心跳脚本每隔 30 秒检测主线程是否有响应如果页面卡死超过 10 秒就自动刷新页面。做法很简单在主线程任务里隔一段时间标记一个时间戳心跳线程通过对比时间戳判断主线程是否还活着。第四是时间同步。大屏上显示的当前时间和倒计时不能直接用设备本地时间因为教室电脑的系统时间快了慢了都有可能出现。所有时间显示都用后端接口返回的serverTime进行计算前端只负责每秒做一次增量。这些措施单个看起来都不起眼组合起来却是大屏稳定运行的保命符。最后说一个我自己的体会做数据可视化大屏真正花时间的往往不只是画图而是理解数据、组织通信、设计渲染策略。Vue 负责组件AntV G 负责像素控制WebSocket 负责实时流动三者配合好高校打卡场景里那些看似复杂的需求都能逐个落地。如果你正准备做同类型的大屏项目建议先用这套思路做一版最小闭环不要一上来就追求满屏 3D 效果。等主流程跑通之后再慢慢给图形加发光、渐变、动画体验完全不同。
