Espruino项目中的Promise处理机制变更导致BLE设备使用中断问题分析

问题背景

在Espruino项目的2v21.114版本中，对Bangle.js 2设备的蓝牙心率监测功能(bthrm和bthrmlite)造成了破坏。核心问题源于NRF.requestDevice()函数未能正确返回Promise对象，导致后续的then方法调用失败。

技术细节分析

该问题本质上与Promise处理机制的内部实现变更有关。在之前的版本中，jspromise_create()函数会创建一个标准的Promise对象，而在新版本中，该函数改为创建一个空对象(称为"box")，这个对象不具备Promise的标准特性。

具体表现为：

• 旧版本(2v21)中，NRF.requestDevice({filters:[]})会返回"Promise: { }"
• 新版本(2v21.114)中，同样的调用仅返回"{ }"

这种变更导致了以下问题链：

1. 用户代码期望获取一个标准的Promise对象
2. 实际获取的是一个普通对象
3. 当尝试调用.then()方法时失败
4. 虽然底层Promise逻辑仍在执行，但错误处理机制被破坏，导致"Uncaught Error: Unhandled promise rejection"等错误

底层机制解析

Espruino的BLE(蓝牙低功耗)功能实现中，大量使用了jspromise_create()来创建Promise对象。典型的流程是：

1. 调用jspromise_create()创建Promise容器
2. 执行异步操作
3. 完成后通过jspromise_resolve()或jspromise_reject()处理结果

在变更后的实现中，jspromise_create()创建的是一个包含隐藏子Promise的容器对象，而非直接返回Promise。这种设计虽然优化了内存管理，但破坏了与现有代码的兼容性。

影响范围

这种变更不仅影响了NRF.requestDevice()，还可能波及以下功能：

• 蓝牙连接/断开操作
• 数据写入
• 通知订阅
• Bangle.js设备的蜂鸣、震动、压力传感器等功能

解决方案方向

要解决这个问题，需要调整实现方式，确保：

1. 对外暴露的是标准的Promise对象
2. 内部仍能保持优化的内存管理
3. 兼容现有的用户代码

一种可行的方案是修改jspromise_create()的实现，使其返回容器中的子Promise，而非容器本身，同时确保引用计数和内存管理不受影响。

开发者启示

这个案例提醒我们：

1. 底层API变更需要谨慎评估兼容性影响
2. Promise实现是JavaScript异步编程的核心，其行为变更会产生广泛影响
3. 在优化内部实现时，必须确保对外接口的稳定性

对于使用Espruino进行蓝牙开发的开发者，建议在升级版本时特别注意Promise相关功能的测试验证，特别是在涉及以下场景时：

• 设备发现
• 服务发现
• 特征值操作
• 通知订阅

通过这个问题的分析，我们可以更深入地理解Espruino内部Promise机制的工作原理，以及在系统升级时需要注意的关键点。