1. 工业现场为什么需要一套自己的界面协议1.1 从一次产线改造说起去年下半年我参与了一个离散制造车间的数字化改造项目现场有十二条产线每条产线上分布着PLC、工控机、扫码枪、称重仪表、视觉检测相机还有若干块大小不一的显示终端。项目初期我们按照常规思路用Web技术栈做了一套管理后台跑在办公区的电脑上一切正常但一搬到车间就出问题了。车间里的终端五花八门有七寸的嵌入式触摸屏有十点一寸的工业平板还有挂在产线尽头的五十五寸看板。分辨率从800×480到1920×1080不等操作系统有Android、Linux、Windows浏览器内核版本参差不齐。同一套页面在不同设备上的表现差异极大布局错位、字体模糊、动画卡顿都是家常便饭。更麻烦的是车间网络环境不稳定页面加载慢的时候操作员要盯着白屏等好几秒这在快节奏的生产节拍里是不可接受的。这个痛点逼着我们去思考一个问题工业现场的界面到底应该怎么做传统的响应式Web方案在这里水土不服因为它的假设是设备性能足够、网络足够好、浏览器足够新而工业现场恰恰相反。我们需要一套更轻、更可控、更贴近硬件能力的方案。这就是后来我们选择AG-UI协议配合Canvas渲染引擎的起点。1.2 AG-UI协议到底解决了什么问题AG-UI这个名字听起来像是一个通用标准但在我们的实践里它更像是一套为工业场景量身定制的界面描述协议。它的核心思路是把界面拆解成三层数据层、布局层、渲染层。数据层负责和PLC、传感器、MES系统对接拿到实时的生产数据布局层用一套领域特定语言DSL描述界面的结构和样式渲染层则负责把DSL翻译成具体的绘制指令。为什么要在中间加一层DSL直接写HTML和CSS不行吗这里有个关键考量。工业现场的界面元素其实高度重复无非是数值显示、状态指示灯、趋势曲线、报警列表、按钮控制这几类。如果每个页面都手写HTML维护成本极高而且不同工程师写出来的代码风格不统一后期改起来很痛苦。DSL的好处是把这些重复模式抽象出来用声明式的方式描述界面比如“在左上角放一个温度显示绑定PLC的DB1.DBD0地址超过80度变红”这样一句话就能生成对应的界面元素。更重要的是DSL可以被程序解析和优化。我们的渲染引擎拿到DSL之后不是简单地逐条执行而是会做一轮预处理合并相同图层的绘制指令、剔除不可见区域的元素、根据设备性能动态调整刷新频率。这些优化在纯HTML方案里很难做到因为浏览器有自己的渲染管线你很难干预它的决策。1.3 Canvas渲染引擎的选型逻辑确定了DSL方案之后下一个问题是拿什么来渲染。我们评估了三条路线DOM渲染、SVG渲染、Canvas渲染。DOM渲染就是常规的HTML元素堆叠优点是开发简单、生态成熟缺点是元素数量一多性能就崩。我们做过测试一个页面上放两百个DOM节点在低端工控机上滚动就开始掉帧。SVG渲染比DOM好一些适合矢量图形但节点多了同样有性能瓶颈而且SVG的动画在老旧浏览器上表现不稳定。Canvas渲染的优势在于它是像素级的绘制所有内容画在一张画布上没有DOM树的开销。对于工业界面这种元素密集、更新频繁的场景Canvas的性能优势非常明显。我们实测下来同样两百个元素Canvas方案的帧率能稳定在五十帧以上而DOM方案只有二十帧左右。当然Canvas也有代价。它没有DOM那样的事件冒泡机制所有点击、悬停都要自己算坐标它也没有自动的布局系统每个元素的位置都要手动计算文本渲染的清晰度在某些设备上不如DOM。但这些代价在工业场景里是可以接受的因为工业界面的交互逻辑相对简单布局也相对固定我们完全可以用DSL把这部分复杂度封装起来。选型这件事没有银弹关键是想清楚你的场景最不能妥协的是什么。工业现场最不能妥协的是稳定性和性能所以Canvas胜出。2. DSL设计把工业界面抽象成可复用的积木2.1 界面元素的分类与抽象设计DSL的第一步是搞清楚工业现场到底有哪些界面元素。我花了大概两周时间把车间里所有终端上显示的界面截了图然后归类整理。最后发现无非是这么几类数值显示类温度、压力、速度、产量、良率通常需要绑定数据源支持单位换算和格式化。状态指示类运行、停止、故障、待机用颜色和图标区分需要实时刷新。趋势曲线类温度曲线、压力曲线、产量趋势需要历史数据支撑支持时间轴缩放。报警列表类按时间倒序排列的报警记录需要支持确认和过滤。控制按钮类启动、停止、复位、参数下发需要防误触和权限控制。容器布局类分组框、标签页、滚动区域用来组织其他元素。这六类基本覆盖了百分之九十以上的工业界面需求。DSL的设计就围绕这六类展开每一类定义一个标签标签内部用属性来描述具体行为。比如数值显示定义为value标签属性包括source数据源地址、format格式化规则、unit单位、alarm报警阈值。2.2 DSL的语法设计取舍语法设计上我们纠结了很久最后选择了类XML的风格。原因是XML的嵌套结构天然适合描述界面层级而且解析器成熟工程师上手快。但纯XML太啰嗦所以我们做了一些简化属性值可以省略引号如果不含空格布尔属性可以只写名字不写值支持简写标签。一个典型的DSL片段长这样page title一号线监控 group label挤出机 x0 y0 w400 h300 value sourcePLC1.DB1.DBD0 format%.1f unit℃ alarm80:red,90:blink x20 y40 w160 h60/ value sourcePLC1.DB1.DBD4 format%.0f unitrpm x200 y40 w160 h60/ trend sourcePLC1.DB1.DBD0 range300 x20 y120 w340 h160/ /group group label报警 x410 y0 w300 h300 alarmlist max20 x10 y30 w280 h260/ /group /page这段DSL描述了一个页面左边是挤出机的监控组包含两个数值显示和一个趋势曲线右边是报警列表。所有坐标都是相对于父容器的这样布局计算会简单很多。为什么不用JSONJSON在描述层级结构时不如XML直观而且属性名和标签名混在一起可读性差。为什么不用YAMLYAML的缩进敏感特性在工业现场是个隐患工程师复制粘贴的时候很容易搞乱缩进。XML虽然老派但胜在稳定可靠。2.3 数据绑定的设计细节工业界面的核心是数据DSL必须解决数据绑定的问题。我们的方案是给每个需要数据的元素定义一个source属性值是一个地址字符串。渲染引擎在初始化时解析这些地址建立数据订阅关系。地址的格式我们设计成协议.区域.偏移量的形式比如PLC1.DB1.DBD0表示一号PLC的数据块1中偏移0的双字。这个格式和西门子PLC的寻址方式类似工程师不需要额外学习。对于非PLC的数据源比如MES系统的产量数据我们用MES.LINE1.OUTPUT这样的格式由数据网关负责转换。数据更新采用推模式。渲染引擎启动时向数据网关注册订阅网关在数据变化时主动推送。这样做的好处是渲染引擎不需要轮询减少了不必要的网络开销。推送频率可以配置默认是两百毫秒一次对于大多数工业参数来说足够了。如果某个参数需要更快的刷新可以在DSL里单独指定rate属性。数据绑定的一个坑是类型转换。PLC传来的往往是原始字节需要根据数据类型解析成整数或浮点数。我们在DSL里增加了type属性来指定默认是float32如果是整数就写int16或int32。这个细节不注意的话显示出来的数值会完全不对。3. Canvas渲染引擎的实现要点3.1 渲染管线的设计渲染引擎的核心是一条流水线解析DSL、构建场景树、布局计算、绘制指令生成、Canvas绘制。每个环节都有优化空间。解析DSL用的是一个手写的递归下降解析器没有用现成的XML库因为我们需要在解析过程中做语义检查比如检查数据源地址是否合法、报警阈值是否合理。手写解析器虽然代码量大一些但控制力更强错误提示也更友好。场景树是DSL的内存表示每个节点包含类型、属性、子节点列表、计算后的布局信息。场景树构建完成后会做一轮优化合并相同图层的节点、剔除完全被遮挡的节点、把静态内容标记出来避免重复绘制。布局计算是相对坐标转绝对坐标的过程。我们实现了一个简化的盒模型支持padding和margin但不支持flex和grid因为工业界面的布局通常很简单用绝对定位加分组就够了。每个节点的最终位置和尺寸都算好之后存回场景树。绘制指令生成是把场景树翻译成Canvas的API调用序列。这一步会做脏矩形优化只有发生变化的区域才重新绘制其他区域保留上一帧的内容。对于工业界面这种大部分区域静态、小部分区域动态的场景脏矩形能大幅降低CPU占用。3.2 文本渲染的清晰度问题Canvas渲染文本有一个众所周知的痛点在高DPI屏幕上如果不做处理文字会模糊。原因是Canvas的默认坐标系是CSS像素而实际屏幕是物理像素两者之间有缩放比。解决方案是获取devicePixelRatio然后把Canvas的宽高乘以这个比值再用ctx.scale把坐标系缩放回去。这样绘制出来的文字就是物理像素级别的清晰度。代码大概是这样const dpr window.devicePixelRatio || 1; const rect canvas.getBoundingClientRect(); canvas.width rect.width * dpr; canvas.height rect.height * dpr; canvas.style.width rect.width px; canvas.style.height rect.height px; const ctx canvas.getContext(2d); ctx.scale(dpr, dpr);但这里有个坑如果devicePixelRatio不是整数比如1.25或1.5缩放后的坐标会出现小数导致线条模糊。我们的做法是在绘制前把坐标取整牺牲一点精度换取清晰度。对于工业界面来说一个像素的偏差完全可以接受。另一个问题是字体。工业终端上可用的字体很少有些设备甚至只有一种点阵字体。我们的策略是优先使用系统自带的无衬线字体如果检测不到就回退到内置的位图字体。位图字体虽然不好看但胜在渲染快、清晰度高在小尺寸下反而比矢量字体更易读。3.3 动画与刷新的平衡工业界面不需要花哨的动画但有些动画是必要的比如报警闪烁、数值滚动、曲线平移。这些动画如果处理不好会拖垮整个渲染性能。我们的原则是能用CSS动画的就不用Canvas动画能用定时器的就不用requestAnimationFrame。报警闪烁用CSS的animation属性实现因为它是合成器层面的动画不占用主线程。数值滚动用定时器每帧更新一个数字因为它的更新频率低没必要用requestAnimationFrame。只有趋势曲线的平移需要每帧重绘才用requestAnimationFrame。刷新频率我们做了分级静态内容只在初始化时绘制一次低频数据如温度每秒刷新一次高频数据如振动每两百毫秒刷新一次动画元素每帧刷新。这样可以根据实际需要分配计算资源避免不必要的重绘。有个细节值得注意requestAnimationFrame在页面不可见时会自动暂停这对工业终端来说是好事可以省电。但如果你的终端需要后台运行就要用定时器代替。4. 工业现场部署的实战经验4.1 设备适配的坑与对策理论上的方案再漂亮到了现场还是要面对各种奇葩设备。我们遇到过的典型问题包括某些Android工控机的WebView不支持devicePixelRatio返回undefined某些Linux终端的Canvas实现有bug绘制大量路径时会崩溃某些Windows平板的触摸事件坐标偏移点不准。针对这些问题我们总结了一套适配策略。首先是在启动时做能力检测把设备分成几个等级A级支持所有特性B级支持大部分特性C级只支持基础特性。然后根据等级动态调整渲染策略。比如C级设备关闭脏矩形优化全量重绘虽然费性能但至少不会出错。触摸事件的坐标偏移问题比较隐蔽原因是某些设备的WebView没有正确处理getBoundingClientRect的返回值。我们的解决方案是用offsetX和offsetY代替clientX和clientY前者是相对于目标元素的坐标不受页面滚动影响。如果offsetX也不可靠就手动计算用clientX减去Canvas的getBoundingClientRect().left。4.2 网络不稳定的应对车间网络不稳定是常态有时候会断几秒钟。如果渲染引擎在这期间疯狂重连反而会加重网络负担。我们的做法是加一个退避机制第一次断线后等一秒重连第二次等两秒第三次等四秒最多等三十秒。同时界面上显示一个断线提示让操作员知道数据可能不是实时的。数据缓存也很重要。断线期间界面继续显示最后一次收到的数据但会加一个灰色的遮罩表示数据已过期。这样操作员至少能看到历史状态不会完全抓瞎。重连成功后遮罩自动消失数据恢复更新。还有一个细节是数据补传。有些数据网关支持断线重连后补传断线期间的数据我们的渲染引擎要能处理这种突发的大量数据。策略是加一个队列按时间顺序逐条处理避免一次性更新太多导致界面卡顿。4.3 现场调试的实用技巧工业现场调试和办公室开发完全是两回事。车间里噪音大、光线差、空间窄抱着笔记本蹲在设备旁边改代码是常态。为了提高效率我们做了几件事。第一是加了一个远程调试通道。渲染引擎内置一个轻量级的HTTP服务器可以在局域网内访问查看当前场景树、数据订阅状态、渲染帧率等信息。这样大部分问题在办公室就能定位不用每次都跑现场。第二是做了配置热更新。DSL文件放在一个可配置的路径下修改后不需要重启应用引擎会检测文件变化并重新加载。这个功能在调试布局的时候特别有用改一个坐标就能立刻看到效果。第三是加了日志分级。默认只输出错误和警告调试时可以通过URL参数打开详细日志。日志会记录每个数据更新的时间戳和值方便排查数据问题。现场调试最怕的是“在我电脑上是好的”。所以每次改完代码一定要在实际设备上验证而且要在不同型号的设备上都试一遍。我吃过亏一个在A设备上完美的布局在B设备上因为字体宽度不同文字溢出了容器。5. 性能优化的几个关键手段5.1 脏矩形与图层分离脏矩形是Canvas性能优化的基本功。原理很简单只重绘发生变化的区域其他区域保留上一帧的像素。实现上需要维护一个脏矩形列表每次数据更新时把受影响的元素区域加入列表绘制时只清除和重绘这些区域。但脏矩形有个前提Canvas的内容是分层的。如果所有元素都画在同一层脏矩形就无从谈起。所以我们在场景树里引入了图层的概念把静态元素和动态元素分到不同图层。静态图层只在初始化时绘制一次之后不再重绘动态图层根据脏矩形局部重绘。图层分离的另一个好处是可以用多个Canvas元素叠加。静态图层用一个Canvas动态图层用另一个两者用CSS定位重叠。这样动态图层的重绘不会影响静态图层浏览器的合成器可以更高效地处理。5.2 数据更新的节流与防抖工业数据的特点是变化频繁但幅度小。比如温度值可能在78.1和78.2之间反复跳动如果每次变化都触发重绘纯属浪费。我们的做法是加一个阈值过滤只有变化幅度超过设定值比如0.5度才触发重绘。这个阈值可以在DSL里配置默认是量程的百分之一。对于报警列表这种需要实时性的元素阈值过滤不适用但可以用节流不管数据来得多快最多每两百毫秒更新一次界面。这样既保证了实时性又避免了频繁重绘。防抖用在窗口大小变化的时候。工业终端有时候会因为旋转屏幕或切换分辨率触发resize事件如果每次resize都重新布局和重绘会卡顿。我们的做法是等resize停止两百毫秒后再执行重布局。5.3 内存管理与垃圾回收JavaScript的垃圾回收在工业场景下是个隐患。如果渲染引擎频繁创建临时对象GC触发时会暂停主线程导致界面卡顿。我们的优化策略是尽量复用对象避免在渲染循环里创建新对象。具体做法包括用对象池管理绘制指令用预分配的数组存储脏矩形用缓存避免重复计算文本宽度。这些优化单独看效果不明显但累积起来能把GC频率降低一个数量级。还有一个容易忽略的点是事件监听器。每次页面切换时旧页面的事件监听器要及时移除否则会内存泄漏。我们实现了一个简单的生命周期管理页面销毁时自动清理所有监听器和定时器。6. 常见问题排查速查6.1 界面显示异常现象可能原因排查方法解决方案文字模糊devicePixelRatio未处理检查canvas的width和style.width是否一致按dpr缩放canvas尺寸元素错位坐标计算错误打印场景树的布局信息检查父容器的padding和margin颜色不对颜色格式不兼容检查Canvas的fillStyle赋值统一用rgba格式闪烁重绘频率过高查看帧率统计加脏矩形或降低刷新率白屏数据未到达查看数据订阅状态检查数据源地址和网关连接6.2 性能问题界面卡顿是最常见的性能问题。排查思路是从上到下先看帧率如果低于三十帧就是性能问题再看CPU占用如果某个函数占用过高就优化它最后看内存如果内存持续增长就是泄漏。一个容易被忽略的性能杀手是阴影和渐变。Canvas的shadowBlur和createLinearGradient在低端设备上非常耗性能。如果非用不可尽量用预渲染的图片代替。另一个是字体加载。如果用了自定义字体字体文件加载完成前Canvas会用默认字体绘制加载完成后又重绘一遍造成闪烁。解决方案是用FontFaceObserver等字体加载完成后再初始化渲染引擎。6.3 数据问题数据不更新通常有三个原因订阅没建立、地址写错了、网关没推送。排查时先看订阅列表确认地址在列表里再看网关日志确认有推送记录最后看渲染引擎的日志确认收到了推送但没触发重绘。数据值不对通常是类型解析错误。比如把浮点数当整数解析或者字节序搞反了。排查时把原始字节打印出来手动解析一遍和显示值对比。我遇到过一个奇葩问题某个PLC的浮点数是小端序但网关默认按大端序解析导致温度显示成几万度。后来在DSL里加了endian属性才解决。这种问题不看原始数据根本查不出来。7. 这套方案还能怎么扩展7.1 支持更多图表类型目前的趋势曲线只支持折线图实际生产中还需要柱状图、饼图、仪表盘。扩展的思路是在DSL里增加chart标签用type属性区分图表类型。渲染引擎里为每种图表实现一个绘制函数共享坐标轴和网格的绘制逻辑。仪表盘比较特殊它需要绘制圆弧和指针用Canvas的arc和rotate可以实现。关键是角度的映射把数据范围映射到指针的旋转角度这个计算要处理好边界值。7.2 引入Web Worker目前所有渲染都在主线程如果数据量特别大或者图表特别复杂可能会阻塞UI。下一步可以把布局计算和绘制指令生成放到Web Worker里主线程只负责最终的Canvas绘制。这样即使计算量大界面也不会卡死。但Web Worker和Canvas的配合有个限制Worker不能直接操作Canvas只能通过OffscreenCanvas。OffscreenCanvas的兼容性在工业终端上是个问题需要做降级处理。7.3 支持多屏协同工业现场经常有多块屏幕显示不同内容但彼此有关联。比如主屏显示总览副屏显示细节。目前的方案是每个屏幕独立运行一个渲染引擎彼此不通信。下一步可以加一个消息总线让多个引擎之间同步状态。比如主屏点击某个设备副屏自动切换到该设备的详情页。这个功能的技术难点在于状态同步的实时性和一致性。用WebSocket做消息通道用版本号解决冲突应该能满足大部分场景。我在实际项目里最大的体会是工业软件和互联网软件的设计哲学完全不同。互联网软件追求快速迭代、用户体验优先工业软件追求稳定可靠、不出错优先。这套AG-UI加Canvas的方案本质上是用声明式的DSL降低出错概率用像素级的渲染保证性能底线。它不完美但在工业现场这个特定场景下它比通用Web方案更合适。如果你也在做类似的事情建议先从一个小页面开始验证跑通了再推广到整个车间。