嵌入式设备上跑 JavaScript这念头我当初看着也觉得有点“胡来”。直到我亲手把业务脚本从 C 代码里抽出来、让运营人员直接改脚本上线才彻底明白了这件事的价值。这个代号叫 xuan 的运行时最终固件体积 6MB 出头这里面包含了解释器、核心语法分析器、基础标准库和硬件外设绑定层占用资源不算小但对于一颗带 8MB Flash、32MB PSRAM、主频 400MHz 的小型 SoC 来说完全喘得过来。做这件事之前我用过的方案基本就是“业务一变、全量烧录”一个简单的上报策略调整都要走一遍编译、烧录、测试流程慢则半天快则两小时怎么想都别扭。所以我把注意力放在了“能不能在设备端给出一层可解释的脚本能力”上JS 又正好是你我他都会一点的语言xuan 就这么被逼出来了。这篇文章想把整个设计过程和踩坑记录完整写一遍。你会看到我为什么没直接用别人写好的迷你引擎、语言子集是怎么划的、字节码怎么设计、内存和 GC 怎么取舍以及实测数据、常见问题、排查技巧。如果你正好在做一个资源没那么紧张但又没有 Linux 的嵌入式平台也想给设备加一层脚本扩展能力这篇文章应该能让你少走不少弯路。1. 为什么要在嵌入式设备上跑 JavaScript1.1 业务脚本化的刚需很多时候我们说的“嵌入式开发”其实大部分时间不是在写特别底层的驱动而是在写业务逻辑。比如一个采集器什么时候采样、采到什么值触发上报、上报完数据怎么处理这些逻辑在产品迭代中变动的频率非常高。如果全部用 C 写成固件每改一次都是一次烧录流程特别是设备已经铺到现场的情况下升级一次固件还要考虑传输失败、断电变砖的可能性工作量很大。我在某个边缘控制器项目里遇到的就是这个问题。硬件已经锁死了我在上面既要跑各类采集控制逻辑又要给上层提供策略接口。后来跟团队商量干脆把策略脚本化C 只做驱动、内存管理、网络协议这些跑得快且跟硬件强相关的事情业务脚本则用 JS 来写运行时负责解析和执行。运维人员远程下发一段脚本不用改固件不用重启设备业务就能更新。这体验比重新烧录强了不知道多少倍。这个思路并不新鲜很多带屏设备、路由器、智能音箱都在做类似的事情。但真正到了资源受限的 MCU 级别能做好的不多。关键是两个问题没解决一是运行时体积能不能塞进 Flash二是内存能不能撑起一个解释器。xuan 的做法是把体积压到 6MB 以下把运行时内存控制在 1.5MB 以内总算在性能和可用性之间找到了一个相对舒服的点。1.2 为什么不用现成的引擎刚开始我也想过直接移植别人写的开源迷你引擎。市面上的确有很多内存占用比较小的 JS 引擎有的编译后缩到一两百 KB甚至更小语法支持也不错。但真到具体项目里试用问题就出来了。第一是裁剪成本。那些引擎虽然小但他们的代码结构、内存模型、平台抽象层都是围绕“通用”设计的你要嵌入到一个特定硬件平台得自己适配串口、SPI、I2C、GPIO、网络栈还要把引擎内部的平台相关代码抠出来重写。这个过程一点都不比从零开始写一个解释器省事甚至更费劲。第二是依赖关系。有的引擎虽然顶层 API 看着简洁底下却依赖了不少标准 C 库特性还有些用了比较重的编译器和 linker 特性。在裸机环境下这些隐藏依赖一个个冒出来最痛苦的是你根本不知道它哪个模块偷偷 malloc 了一大块堆。第三是控制力。我需要把外设访问直接暴露成 JS 原生对象需要在脚本执行到某个特定地方时能够精确地暂停、超时、监控内存水位还需要在硬件中断上下文里安全地唤醒 JS 任务。这些能力在现成引擎里不是说没有但做起来总觉得像隔着一层纱不如自己写的那么顺手。所以最终决定是自己写一个。xuan 并不追求把所有 ECMAScript 规范都实现而是把设备项目里真正用到的语法和 API 实现好同时留出足够的扩展能力。这个决定的直接收益是我可以完全控制内存布局可以把每个对象的布局都在脑海里画出来出了问题基本看一眼代码就能定位。1.3 6MB 这个数字意味着什么先说体积。6MB 放在 PC 上就是一个小文件但在嵌入式世界里很多低端 MCU 的 Flash 总共才 128KB 到 512KB连这 6MB 的零头都装不下。所以 xuan 对应的平台是那些带外部 Flash、带 MMU、主频在 300MHz 以上的小型 SoC比如某些 WiFi/BLE 双模芯片、边缘网关主控等。这类芯片通常有 8MB 到 16MB 的 Flash 空间6MB 的运行时加基础库加上系统固件、协议栈和资源文件勉强能压进 8MB 的 bin 分区里。这 6MB 是怎么构成的实际编译器产物大概分三块引擎核心代码约 4.2MB包括词法分析、语法解析、字节码编译器、虚拟机执行循环、垃圾回收、标准库外设绑定层约 1.1MB包含各种硬件模块注册和设备操作的桥接代码剩下 0.7MB 是各种初始化数据、启动检查、调试冲印模块。这里面引擎核心的占比最大因为几乎每条 JS 功能的背后都对应着几十到几百行 C 代码。说实话6MB 不是一个小体积。如果你追求极致的省 Flash肯定不该选这个思路。但 xuan 的目标是在保证语言表达能力和开发效率的前提下做体积优化而不是把自己变成一条“能用就行的极简命令解释器”。从实际效果看业务脚本的复杂度和开发效率都明显提升了这 6MB 花得值。2. xuan 的整体设计与取舍2.1 语言子集的划定做自研运行时第一件大事就是决定支持哪些语法。ECMAScript 规范几百页要全部实现的话这不是 6MB 规模的项目而是几十万行起步的大工程。况且嵌入式场景里跑的脚本根本不需要浏览器那一整套东西也不需要完整的模块系统、迭代器等高级特性。xuan 选择的是“ES5.1 为底座向上摘取一部分 ES6 甜点”的路线。基础语法支持 var、function、对象字面量、数组字面量、for/while/do-while、switch、try-catch、逻辑表达式、三目运算符、位运算等这些是业务脚本里最常用的部分。ES6 方面我们支持了 let/const、箭头函数、模板字符串、解构赋值的基础场景还做了 Promise 的精简实现方便写异步回调链。没有实现的东西也值得列一下不打算支持完整的 class 继承体系用函数式混入代替、不打算支持生成器 Generator、不打算支持 Proxy/Reflect、不打算支持正则表达式的完整引擎只支持一种简单的字符串匹配模式。这些决定在立项阶段就要跟业务团队对齐否则他们写脚本时用到某个不存在的语法报错信息又不够直观就会很痛苦。实际开发中我专门写了一个“语法能力检测工具”在 PC 上先对业务代码做一遍预检查把不支持的语法点直接标记出来。这比在设备端运行时报错然后反查方便得多。另外xuan 还支持一个“严格模式标记”如果脚本开头写了 “use xuan-embedded”运行时会直接拒绝某些高开销语法例如动态 eval 和超长字符串拼接。2.2 字节码与虚拟机设计JavaScript 代码不能直接在设备上异步解释执行每条语句那样速度太慢语法分析也会反复做。所以 xuan 的架构是先把 JS 源码编译成字节码再交给虚拟机执行。这个编译步骤可以在设备端做也可以在 PC 上预编译成字节码文件再下发后者的启动速度要快很多。字节码设计上我选了基于栈的虚拟机。为什么不用寄存器式虚拟机寄存器式虚拟机指令数更少、执行更快但指令格式复杂编译器生成代码的难度也更高。栈式虚拟机的指令实现简单、代码清晰在嵌入式设备上栈多几个内存访问并没有那么致命换来的是极高的可维护性。xuan 的每一条指令都是 16 位定长操作数直接编码在指令中比如 LOAD_CONST 指令用一个字节表示常量索引另一个字节表示操作数类型。整个指令集一共 128 条左右分成了几类常量与变量操作LOAD_CONST、LOAD_VAR、STORE_VAR、LOAD_FIELD、STORE_FIELD运算指令ADD_INT、SUB_INT、MUL_INT、DIV_INT、COMPARE、JUMP_IF_FALSE 等对象与数组NEW_OBJ、NEW_ARR、ARR_GET、ARR_SET函数与调用CALL_FUNC、RETURN、MAKE_CLOSURE控制流JUMP、JUMP_IF_TRUE、JUMP_IF_FALSE、LOOP_BACK这些指令不是拿来当摆设的。以 LOAD_FIELD 为例它在读对象属性时实际上先查一下属性是否存在不存在直接抛异常避免在解释器里反复处理 undefined。指令集定好后编译器的输出就很规整了后面做字节码优化也简单很多。2.3 内存模型与 GC 策略嵌入式环境最难受的就是内存碎片和堆空间上限。xuan 没有直接依赖 C 库的 malloc/free 做所有分配而是自己封装了一个内存池分块管理。对象节点、字符串数据、数组缓冲区、函数闭包上下文各自有独立的池子这样不同类型对象的分配不会互相污染也方便做性能统计。GC 用的是最经典的标记-清除算法没有做分代没有做移动对象。为什么不做得复杂一点因为嵌入式平台上的对象引用关系已经足够简单分代带来的收益不明显而移动对象需要更新所有指针对于手写解释器来说风险很大。标记-清除的代价是有时会暂停几十毫秒这在业务脚本可接受范围内。不过我在实现时做了一点改进标记阶段采用显式栈不用递归避免在对象图很深的时候把调用栈打爆。分配策略上还有一个重要原则能复用就复用。字符串拼接会频繁产生新字符串xuan 内部做了短字符串驻留表重复出现的小字符串直接返回同一个对象。数组如果缩到很小也不会立即缩容避免频繁 resize 导致的内存抖动。这些细节加起来内存碎片率比直接用 malloc 低了不少。由于只能使用固定大小的堆xuan 在启动时就会确定好 GC 堆大小比如 1MB。如果脚本内存占用超过阈值GC 会先启动多次 GC 后仍然不够就抛出“内存不足”异常。这个设计的副作用是如果某段循环代码反复分配大数组会频繁触发 GC但至少不会出现进程崩溃后现场完全无法调试的情况。2.4 标准库裁剪与外设绑定标准库是所有运行时里最难取舍的部分。嵌入式脚本不需要文件系统、网络 HTTP 全套、定时器也跟桌面环境不一样。xuan 最初只做了四组 APIconsole 系列、定时器、事件注册表和硬件访问抽象层。后来随着需求增加又补了 JSON 解析和简单字符串处理。console 是调试的基础但设备端没有屏幕也没有终端我把 console.log 重定向成串口输出或者日志缓冲区。这样脚本里打日志最终会通过硬件抽象层进入到上位机诊断工具。定时器在嵌入式 RTOS 环境下要跟系统 tick 对齐xuan 的 setInterval、setTimeout 内部会注册到系统的时间轮上回调时再进入 JS 执行环境。硬件访问这块特别讲究。xuan 暴露给 JS 的不是一个个 GPIO 函数而是一组“设备对象”比如 board.led、board.sensor.temperature、board.uart0。内部实现时每个设备对象背后都关联了一个 C 结构体操作函数直接绑定底层驱动。这样脚本里写 board.led.on()效果等价于调用一个底层 C 函数来拉高引脚电平几乎没有额外的中间开销。外设对象的注册方式采用“原生模块注册表”JS 代码里 importNative(gpio) 会拿到一个对象对象上的每个属性都对应 C 侧的一个函数指针。这样做有几个好处第一不是所有原生函数都暴露给脚本安全可控第二每个原生函数的参数检查在 C 侧完成避免 JS 层误传类型导致硬件操作异常第三脚本层和 C 层的调用来回成本很低因为参数直接通过 VM 栈传递。3. 从零搭建运行时的核心实现3.1 词法分析与语法解析整个 xuan 的编译前端是我手写的没有用工具生成。词法分析器是一个标准的状态机负责把源码拆成 token。token 类型包括关键字、标识符、数字、字符串、运算符和分隔符。这部分看着简单但坑很多。最典型的就是数字解析JS 里允许十六进制、八进制、二进制的前缀还有浮点数科学计数法状态机会很复杂。我最后参考 ECMAScript 规范里数字字面量的产生式一点点改才把测试用例全部跑过。字符串那块也很容易出问题。xuan 内部统一用 UTF-8 保存字符串所以词法分析时碰到转义字符 \uXXXX 就得正确处理。这里容易踩的坑是中文字符和 emoji 在源码里是多字节的如果你按 char 循环处理就会把字符截断。我的做法是词法阶段就把源字符串按 UTF-8 解码后的码点边界对齐后面所有字符串操作都按字符索引走。语法解析采用的是最经典的递归下降解析器。JS 的表达式优先级有十几层递归下降写出来很长但每一层函数独立调试起来真的舒服。我在解析表达式时用了 Pratt Parsing 中对二元运算符优先级处理的方式用一个优先级表搞定加法、乘法、比较、逻辑运算等避免了深层的 if/else 嵌套。解析器产出的是一棵 AST。AST 节点在设计时尽量轻量每个节点用 16 字节对齐节点类型、源码位置和子节点索引打包在结构里。因为嵌入式设备内存有限AST 不适合长期存在所以编译成字节码后立刻释放。这里有个值得注意的点xuan 并没有把 AST 序列化到 flash 做缓存因为设备端源码更新频率不高每次启动重新解析也就多花几毫秒没必要为这个增加复杂度。3.2 编译器与字节码生成过程从 AST 到字节码的转换是编译器的核心。我采用的是单趟扫描边遍历 AST 边生成字节码。每个函数都会生成一个独立的字节码块函数入口先做参数检查然后执行函数体里的语句序列。变量作用域处理是比较麻烦的一块。xuan 支持函数闭包也就是说内层函数能访问外层函数的局部变量。这里我的方案是编译每个函数时维护一张“变量槽位表”外层变量如果被内层捕获就分配到一个“闭包上下文”对象里普通变量则直接放在 VM 的栈帧上。从 VM 视角看访问一个局部变量可能是一次栈访问也可能是一次闭包上下文访问取决于编译器标记。字节码生成时还有一层优化常量合并。比如表达式 1 2编译器会直接算成 3不生成两条指令。再比如字符串模板abc${x}def在语法解析阶段就拆成字符串拼接调用。这些优化看着小儿科但在嵌入式脚本里很常见累积下来能省不少执行时间。生成了字节码之后会做一次简单的寄存器分配器式调整吗不会栈式虚拟机不需要太复杂的分配。但我会做一次跳转地址回填把所有 JUMP 指令的目标地址从符号位置改成真实偏移。这一步做完字节码就能直接交给虚拟机跑了。下面是 xuan 里一个极简函数的编译结果示意仅供参考function add(a, b) { return a b; }[0] LOAD_CONST 0 // 常量 a [1] LOAD_VAR 0 // 压入参数 a [2] LOAD_VAR 1 // 压入参数 b [3] ADD_INT [4] RETURN3.3 解释器的执行循环VM 主循环是我花了最多时间打磨的地方。xuan 使用经典的大 switch-case 指令分派没有做间接跳转表虽然间接跳转理论上更快但在某些编译器的优化下表现不一定稳定我宁愿选一个所有平台都表现一致的写法。每条指令执行完成后更新程序计数器 PC然后进入下一轮循环。这个循环最关键的优化点是减少边界检查。比如访问当前栈帧变量时会直接按索引从栈顶数组读取而不是逐个校验索引范围。这个操作是建立在编译器已经保证变量索引合法的前提上的VM 只需要信任字节码。函数调用在 VM 里是最昂贵的操作。每次 CALL_FUNC 需要切换栈帧、准备参数区、可能创建闭包上下文。我在设计时特意把“参数个数不匹配”的检查提前到字节码校验阶段而不是每次调用时做完整检查这样正常路径少了几个分支。异常处理算是解释器里另一个大难点。JS 的 try-catch 需要 VM 能在执行中任意位置把控制流跳转到 catch 块。我的做法是在编译时生成异常处理器表每条可能抛异常的指令如果位于 try 块内就在表里登记。异常抛出的瞬间VM 会沿当前调用栈向上查找最近的异常处理器找到后重设 PC 并压入异常对象。这个机制实现后业务脚本里的 try-catch 终于像那么回事了。3.4 原生函数注册与调用没有原生函数绑定xuan 就只是一个玩具。我在 C 侧定义了统一的桥接接口原生函数长这样static xu_value_t native_gpio_write(xu_vm_t *vm, xu_value_t args[], int argc);每个原生函数接收一个 VM 句柄、参数数组和参数个数返回一个 JS 值。参数数组里的 xu_value_t 是一个 union 类型可以是 int、double、对象指针、字符串指针、布尔值等。JS 层调用原生函数时VM 会自动把 JS 值转换成 xu_value_tC 函数内部再按类型取用。注册的方式很简单把 C 函数指针绑定到某个 JS 对象属性上xu_module_register(vm, gpio, write, native_gpio_write);这个调用执行后JS 里的 gpio.write 就会被解释器识别成原生调用走一条快路径直接执行 C 函数而不是再通过字节码解释一层。整个调用开销大概只有普通 JS 函数调用的 1.5 倍这个数字对嵌入式脚本来说非常能接受。这里容易疏忽的是参数生命周期。原生函数收到的字符串和对象必须保证执行期间不被 GC 回收。xuan 的处理方式是在调用原生函数前把传入参数对象全部标记为临时根引用函数返回后再清除标记。这样即使原生函数内部执行了任何触发 GC 的操作对象也不会突然从底下消失。3.5 构建与体积优化xuan 整个项目用 C 语言编写构建系统用的是内部统一的多平台构建脚本。交叉编译到目标板时几个关键的编译选项直接影响最终体积。第一个是优化等级。我用了偏向尺寸优化的 O2 级别同时打开函数节function-sections和数据节data-sections配合链接器的垃圾回收可以把未引用的代码段全部剥掉。这个操作效果非常明显光是把所有调试符号去掉再加上节裁剪体积就能减少三分之一。第二个是禁用了 C 异常和标准模板库。你可能会问C 项目怎么禁用这些因为有的时候会不小心链接进来一些 C 运行库特别是从第三方芯片 SDK 里带过来的。我特意检查了最终的链接 map 文件把那些因为弱符号被拉进来的 C 依赖都清掉了。第三个是静态库的提炼。xuan 把不常用的标准库函数做成了可裁剪模块比如正则匹配、浮点数格式化输出、复杂 JSON 解析等。不需要的话构建脚本里加一个宏定义就能从编译中剔除。最终交付时我做了两组配置开发版完整镜像 6MB发布版裁剪后只有 4.7MB。4. 实际跑起来的性能与稳定性4.1 启动流程与内存占用实测xuan 的设备端启动流程大致分四步初始化内存池、注册原生模块、加载主脚本源码、执行字节码。启动第一步不是加载 JS而是先把内存池的 Header 和块管理结构初始化好。这块代码在板子上运行非常快大概 200 微秒。然后是原生模块注册所有绑定的 C 函数都会挂到一个全局注册表上耗时约 1.5 毫秒。真正耗时的是源码加载和解析。如果源码是一份 200KB 的文本词法和语法解析大概要花 20 到 30 毫秒字节码生成再加 10 毫秒左右。整个启动到主脚本第一行执行实测在 40 毫秒到 50 毫秒之间比我预期要好。内存占用方面如果给 xuan 分配了 1.5MB 的堆空间冷启动后 GC 堆几乎没怎么用系统堆会吃几百 KB。等业务脚本运行一段时间、创建了一些对象后内存水位通常在 40% 到 60% 之间。峰值内存出现在大量字符串拼接或者数组增长时最多可以摸到 80%但因为有 GC一般不会直接打满。这块要特别说明我不建议给 xuan 分配超过 2MB 的堆。因为标记-清除算法下堆越大GC 暂停时间越长。实测 2MB 堆做一次全量 GC 大约 40 毫秒1MB 堆只需要 15 毫秒左右。对业务来说15 毫秒的停顿已经勉强可接受40 毫秒就有点卡了。4.2 简单基准测试数据我不打算做完整的 benchmark只测了三个跟业务直接相关的场景你也可以把这当成一个参考。第一个是空函数调用一百万次xuan 大约需要 220ms也就是说一次简单 JS 函数调用大概是 220ns 级别。第二个是循环里做整数累加从 1 加到 100 万耗时约 80ms。第三个是创建一万个对象并给属性赋值执行时间 350ms期间触发了两次 GC。作为参考我用同样的逻辑在 PC 上的完整 JS 引擎跑速度可能快 10 到 20 倍但 xuan 的性能对于设备脚本来说足够用了。真正的瓶颈不在 JS 执行速度而在于外设读取、网络等待这类异步操作。业务逻辑里 99% 的时间都在等待硬件JS 解释器怎么都比硬件快。有一个数字需要警惕浮点运算。开发板若不带硬件 FPUxuan 的浮点运算直接走 C 库软浮点性能会掉到整数运算的二十分之一。如果你写脚本大量使用浮点就必须在脚本层用整数刻度来规避。通常我会建议业务方能转成 mM、mV 这种整数单位的绝不用浮点。实在要浮点时就用 xuan 提供的 Decimal 模式内部按定点数计算。4.3 防死循环和异常处理机制脚本语言跑在设备上最怕的就是死循环。一旦脚本进入 while(1)设备侧控制逻辑就全部停摆这是绝对不能接受的。xuan 提供了两套防护。第一套是执行指令预算。每执行 10 万条指令VM 就会检查一次当前是否超时。如果超时会抛出一个特殊异常“脚本执行超时”默认情况下脚本会在该处中断。这个预算可以通过 API 动态调整比如某些长时间计算的任务可以放大预算一般业务逻辑保持在 100 万条以内。第二套是看门狗协作。xuan 在每次 VM 回到事件循环入口时会喂一次系统看门狗。如果脚本长时间不结束导致看门狗被饿死整个设备会重启。重启虽然暴力但总比设备完全变成砖头好。后来我在日志里看到过两次看门狗触发查下来都是业务方在脚本里写了 expect 0 的条件死循环这种低级错误有了防护才能兜底。异常处理上xuan 允许脚本用 try-catch 捕获运行时错误比如类型错误、属性不存在、内存不足。未捕获的异常会进入全局错误钩子钩子默认把错误信息写到日志缓冲区同时通过串口上报。实际排查问题时这个错误钩子比什么都管用因为你能直接在设备端拿到出错的文件和行号。5. 常见问题与排查实录5.1 内存碎片与堆耗尽xuan 用内存池虽然减少了很多碎片但业务脚本如果频繁创建不同大小的数组、字符串仍然可能出现碎片化。典型症状是GC 明明回收了一堆对象但马上分配一个大数组时仍然报内存不足。排查方法很简单我加了一个内存状态查询函数能打印出每个内存池的已用块数、空闲块数和最大连续空闲块。如果最大连续空闲块远小于总空闲空间基本就说明碎片很严重了。应对手段有两个一是调整池的分配粒度让大对象固定走单独的分配器二是清理脚本里反复创建后丢弃的大字符串。说实话这些问题的根源大多是脚本写得比较随意比如在循环体内做字符串拼接每轮循环都生成新字符串。我会在代码评审时重点提醒团队养成“能复用的对象不复用能预分配的不动态增长”的习惯。5.2 GC 标记阶段栈溢出早期版本我用递归做标记对象图一旦很深C 调用栈就爆了。当时遇到一个问题脚本创建一个很深的链表然后这个链表变成垃圾触发 GC 时系统直接 hardfault查了半天才在日志里发现调用栈指针异常。后来我把标记阶段改成了显式栈迭代用一个动态增长的数组保存待扫描对象。这个修复让 GC 可以处理非常深的对象图递归深度受限问题彻底消失。这个经验也适用于所有嵌入式场景凡是可能深度遍历的地方尽量不要用 C 递归除非你能明确控制最大深度。5.3 回调上下文丢失与闭包语义业务脚本里经常出现 setTimeout 回调如果回调里依赖 this 或者外部变量很容易出现“上下文丢失”。我遇到过最典型的问题是脚本里从设备对象取了某个临时值然后放进定时器回调里等回调真正执行时临时值已经变成了 undefined。这个问题的本质是闭包上下文生命周期没管理好。xuan 的闭包上下文是在创建函数对象时生成的如果只是把匿名函数作为回调参数传进去按正常 JS 语义其作用域链应该是保留的。但我的第一版实现里setTimeout 内部没有把传入的闭包对象标记为根引用导致该回调函数和它的上下文在定时器等待期间被 GC 回收了。修复方式很简单所有已注册的定时器回调都加入全局根集合回调执行完或者定时器取消时再移除。从这里我也学到一个教训嵌入式 JS 引擎的 GC 根集合不仅包含调用栈和全局对象还必须包含所有“未来可能唤醒”的挂起任务。凡是跟事件循环挂钩的对象都需要单独管理生命周期否则很容易踩到 GC 的坑。5.4 浮点性能的坑xuan 在没有 FPU 的平台上跑浮点计算速度慢到让人怀疑人生。我做过一个测距脚本需要通过三角函数和浮点运算来算一个角度值完整执行一次要花 180ms而同样是这段逻辑用整数查表法加定点数乘法只需要 12ms。这个差距让所有依赖浮点的算法都变得不现实。我的建议很简单设备端脚本里尽量避免浮点运算。如果一定要用先检查平台是否支持硬件浮点不支持就把所有浮点系数转换为整数倍率或者用 xuan 提供的定点数对象。定点数的加减乘除是整数运算只有乘法可能涉及到溢出成本比软浮点低几个数量级。如果实在绕不开浮点另一个方案是将这部分算法下沉到 C 原生函数里JS 只负责传参和读取结果。这样脚本层的表达力没有降低实际执行却跑在 C 函数里又快又稳。这也是我设计原生模块注册机制的初衷性能敏感的代码永远不应该用解释执行来扛。5.5 字符串编码与中文脚本xuan 的字符串统一是 UTF-8这本来没什么问题但业务脚本有时候会从串口或文件读入一段二进制数据里面夹着非 UTF-8 字节然后又把它当字符串做处理结果就是各种乱码和解析错乱。后来我做了严格检测字符串创建时如果发现非法 UTF-8 序列直接抛异常不会静默生成一个脏字符串。同时在 console.log 输出时会按字节打印保证调试信息不丢内容。开发过程中踩到的另一个点是 JS 的字符串长度ECMAScript 规范里 length 代表 UTF-16 码元数而 xuan 为了节省内存用的是 UTF-8 长度这就导致同样一个中文字符串在标准 JS 里和 xuan 里 length 值不一样。为了兼容我实现字符串 length 时先进行编码转换计算保持 length 语义跟标准一致虽然每次获取 length 会多一点开销但至少脚本不会因为中文就出错。这个问题也提醒我做一个“看起来兼容”的运行时很容易但要真正让脚本在设备端和 PC 端行为一致必须把字符编码这类底层细节全部对齐否则调试时就只能靠逐个字节抠。6. 一些实际操作中的体会xuan 从立项到跑稳整个过程大概花了一个季度中间大部分时间都不是在写功能而是在处理上面这些小坑。回顾下来我最深的体会是做嵌入式运行时不是代码越多越牛而是你要清楚自己到底解决什么问题。如果你的业务脚本只是几十行逻辑外设操作也极简单那真的没必要自己写一个运行时用一个现成的极简解释器足够了。但如果你的业务场景复杂度上来了需要对象、回调、闭包、异常处理而且你还想对内存、体积、异常行为有细颗粒度的掌控那自己做一个反而是省心的选择。后来我把 xuan 的裁剪配置做成了几个模板开发版、发布版、最小版分别对应不同的 Flash 预算。团队里的嵌入式工程师不再为改脚本而头疼业务方也能更快地验证新策略。一个很有意思的结果是以前需要编译烧录两三天的需求现在改成远程发脚本后平均半天就能上线设备的故障率也没有明显上升。如果你也想在类似项目上试试我建议你一定要在一开始就写一个“内存和异常可视化工具”把设备端的内存占用、GC 用时、未捕获异常都打印出来。这会在后面调优时省下无数时间。还有就是要给脚本加执行预算和看门狗协作没有这套保命机制业务脚本一旦跑飞再好的架构也白搭。最后再掏个底跑这种运行时稳定性和可观察性的优先级永远要排在掌握新语言特性的前面。