蓝牙智能挂锁App的React Native混合架构实践：哪些环节必须原生兜底

蓝牙智能挂锁这个品类这两年出货量涨得很凶。锁体本身的技术门槛其实不算高真正让团队头疼的几乎全在APP那一侧。蓝牙配对链路、锁的状态同步、固件升级、多设备管理这些功能堆下来如果Android和iOS各养一套原生开发小团队直接就被拖垮了。所以“APP全部使用React Native开发”这个方案几乎是每个做智能硬件的初创团队都会认真考虑一次的问题。这篇内容就围绕我这边一次真实的项目评估来写方案是蓝牙智能挂锁横跨移动端和设备端重点是判断RN能不能扛起整条业务链路以及哪些环节必须留原生兜底。如果你也在评估“自己这个硬件产品的APP能不能用跨平台方案”这篇东西应该能帮你避开不少认知上的坑。1. 项目需求拆解智能挂锁的APP到底在管什么1.1 核心功能链路从扫码绑锁到OTA固件升级智能挂锁的APP表面上功能不多但每一条都踩在蓝牙通信的痛点上。我按实际项目里P0到P2的优先级把功能重新梳理了一遍第一优先级是配网绑锁。用户拿到锁之后APP通过扫码或者手动输入锁底部的序列号建立锁与账号的绑定关系。这一步看起来简单但里面藏着一个非常核心的权限设计——谁绑定的锁谁才能开锁管理员能不能授权临时访客。锁端和APP之间需要交换公钥、生成会话密钥、存下设备证书这一套流程如果RN层来做就必须依赖蓝牙库能把足够长的数据包稳定地写进去。第二优先级是开关锁操作。这里分成两种情况一种是手机贴近锁体通过BLE直接发指令唤醒锁芯电机另一种是远程授权用户人在外面让家里的临时访客通过微信小程序或者APP一次性开锁。远程授权走的是服务器下发临时密码锁体本身有没有联网模组决定了实现复杂度。如果锁里只有蓝牙那远程授权其实是云端把一次性密码算好下发到APP再由APP靠近锁体后通过蓝牙写进去。第三优先级是状态同步。锁体电量、锁舌开关状态、开锁记录、防撬报警、离线事件。BLE和WiFi不一样它不是一个时刻在线的通道APP只有在靠近锁体并且主动连接时才能拉取到最新状态。所以数据同步的核心是设计一套增量拉取的协议——锁端能记录最近500条事件APP连接后从最新的序列号开始拉。第四优先级是OTA固件升级。这个是最折磨人的。挂锁的MCU存储空间极小又要保证升级过程中断电不把锁搞成砖一般会分成bootloader和app两段每次只能写入一个很小的分包。BLE的MTU就算扩到247字节一次固件包几百KB也要分几千包传输中间任何一包丢了或者连接断了轻则重传重则锁直接变砖。这些链路拆完之后就能看出来智能挂锁APP的技术核心并不是UI而是蓝牙通信的可靠性、数据协议的健壮性、和后台服务器的同步策略。RN能不能用首先要看这些底层能力RN能不能无障碍地调起来。1.2 双端一致性为什么智能锁比纯软件项目更怕平台差异纯软件APP遇到Android和iOS的差异顶多就是UI错位、返回键逻辑不一样。但智能挂锁APP遇到的平台差异直接落在蓝牙协议栈、系统权限、后台调度策略上任何一个不一致都会让用户觉得“这个锁是不是坏了”。先看配对环节。iOS的CoreBluetooth对BLE设备的发现、连接、配对有一套非常严格的规则首次配对时弹出来的系统配对框APP是没办法定制的而且iOS在配对后会自己管理密钥APP拿到的只是系统说“配对成功”的消息具体密钥交换过程对上层完全透明。Android这边就五花八门了不同厂商对蓝牙权限的命名不一样Android 12之前需要定位权限才能扫描到BLE设备Android 12之后又引入了“附近设备”权限如果你的APP没有适配到位在Android 13以上机型上直接扫描不到任何锁。再看后台运行。iOS对后台蓝牙的限制是——APP退到后台之后系统会断开普通的BLE连接只有声明了bluetooth-central后台模式并且你的APP确实在做主动扫描或者长连接任务时系统才会保留相关回调。Android的后台更混乱国产ROM对后台App的清理策略各不相同小米、华为、OPPO都有各自的“省电策略”“自启动管理”APP退到后台后蓝牙Gatt连接很容易被系统直接杀掉。这两条差异意味着RN层写的代码虽然是双端一份但底层触发逻辑完全不同。你在iOS上测试得好好的同一套RN代码跑到Android上很可能就因为缺了一个权限声明或者后台模式没配置直接蓝牙连不上。这也是我做技术评估时第一个要确认的问题——RN社区的三方蓝牙库究竟帮我们把双端差异封装到了什么程度。2. 蓝牙通信链路解析RN能直接管到哪一层2.1 BLE协议栈的分层逻辑APP、系统、锁体三者怎么配合要评估“RN开发蓝牙APP”这个方案必须先搞懂BLE通信的分层逻辑。简单来说一条开锁指令的完整路径是这样的APP应用层RN的JS代码发出指令 - RN蓝牙库的JS接口 - 原生桥接层调用iOS CoreBluetooth或Android BluetoothGatt - 系统蓝牙协议栈 - 射频物理层 - 挂锁的BLE模组 - 锁MCU解析指令 - 驱动电机开锁。这个链路跟咱们平时用WiFi是完全不一样的。WiFi是手机和路由器建立TCP/IP连接HTTP请求发过去就完事了。BLE更像是USB串口手机和锁之间建立起一条GATT连接两边通过Characteristic特征值来读写数据。每个BLE设备都有一个GATT Server里面包含若干个Service服务每个Service下面有若干个Characteristic数据交换就是靠读写这些Characteristic来完成的。RN层能做的就是通过三方库拿到这些Service和Characteristic的UUID然后往对应的Characteristic里写字节数组或者监听Characteristic的通知回调来接收数据。但RN层接触不到GAP层的广播包也接触不到链路层的连接参数这些全被系统蓝牙栈封装死了。这个分层意味着一个很现实的事情RN里能写的代码本质上跟原生里写蓝牙是同一套GATT读写逻辑只是API长成了JS风格。如果你对BLE的Service/Characteristic模型理解不清楚就算用原生开发也照样写不出能用的蓝牙APP这锅RN不背。反过来如果开发团队已经吃透了BLE协议RN做了多少封装反而不重要因为你写起来几乎是平移到JS的。2.2 react-native-ble-plx和跨端蓝牙库的真实能力边界RN生态里做蓝牙最主流的库有两个一个是react-native-ble-plx另一个是react-native-ble-manager。我做评估时重点考察了react-native-ble-plx因为它在双端一致性上做得更细也是社区维护最活跃的一个。react-native-ble-plx主要封装了这些能力扫描周边BLE设备拿到设备名、MAC地址iOS上拿不到真实的MAC是系统生成的UUID、广播数据里的厂商自定义字段建立GATT连接、断开连接、监听连接状态变化发现服务列表和特征值列表读写Characteristic支持写带响应、写不带响应、同时读写大块数据监听Characteristic的Notify和Indicate上报数据调整MTUMaximum Transmission UnitAndroid上可以主动申请较大的MTUiOS上由系统决定但通常能到185字节左右初始化一个蓝牙管理器写法大概是这样的import { BleManager } from react-native-ble-plx; const manager new BleManager(); // 请求权限后开始扫描 await manager.startDeviceScan(null, null, (error, device) { if (error) { console.log(Scan error, error); return; } if (device device.name SmartLock_1234) { // 停止扫描尝试连接 manager.stopDeviceScan(); connectToDevice(device); } }); // 连接并获取服务 const device await manager.connectToDevice(deviceId, { requestMTU: 247 }); await device.discoverAllServicesAndCharacteristics(); const services await device.services(); const characteristics await device.characteristicsForService(serviceUUID);这段代码看着很简单但实际跑起来坑非常多。比如manager.connectToDevice这个方法如果在Android上锁体已经跟手机建立过连接需要先调用cancelDeviceConnection把旧连接清掉否则会出现“连接上了但读不到任何服务特征”的问题。这种情况在原生开发里也存在但RN库会把这层错误再包装一层错误信息变得更难定位。再说说RN蓝牙库的能力边界。它封装的是系统蓝牙API原生层支持的能力它都能透传但它不会帮你重新实现一套蓝牙协议栈。比如挂锁的OTA升级需要用到GATT的Write Long Characteristic流程这在原生API里本身就是自动分包的react-native-ble-plx也能透传但如果你在JS层直接写一个超大的ArrayBuffer进去部分Android机型会把数据截断你必须自己在JS层处理分片逻辑。这个说到底是数据分包协议的问题跟RN无关但它会直接影响开发工期。2.3 广播包解析和厂商私有协议RN能透传但没人帮你解挂锁的蓝牙广播包通常不只是广播一个设备名那么简单。厂商会在广播包里塞进一堆自定义数据——锁的序列号、固件版本、是否需要OTA更新、防拆报警状态。这些数据按照厂商自定义的字节排列方式打包APP拿到广播原始数据后需要自己按字节解析。用react-native-ble-plx可以拿到设备的manufacturerData比如// android可以拿到完整的广播数据 const raw device.manufacturerData; // 例如 0x00590A0B0C0D...然后你需要按厂商协议解析这一段十六进制字符串。假设协议约定前四位是产品类型第五位是固件大版本第六位是锁状态比特位那么解析逻辑就是用字符串切割或者Uint8Array转字节再按位去判断。这里我想强调一个RN层容易踩的坑——广播数据解析时不同平台的字节序和返回格式并不完全一致。Android上manufacturerData是十六进制字符串iOS上可能返回的是一个ArrayBuffer或者需要走serviceData字段读取。同一个协议到了双端要写两套解析代码而且这些代码是没法抽成公共逻辑的因为数据格式本身都被平台包装过了。如果你的团队计划用RN“一套代码跑两端”这里就会给你泼第一盆冷水——UI代码确实一套但蓝牙数据解析必须双端维护至少是双端跑不同的分支逻辑。3. 全RN方案的技术可行性验证哪些能跑哪些必须打补丁3.1 锁体端到端的通信验证从GATT读写到电机驱动的闭环测试评估不能只停留在看文档我这里实际搭了一套验证环境。锁体端用的是ESP32系列做BLE从机模拟挂锁的GATT服务和开锁指令处理。因为挂锁的存储空间和功耗都有限BLE服务结构尽量精简只保留三个核心Service设备信息服务Device Info、安全认证服务Auth Service、锁控制服务Lock Control。安全认证服务的流程比较关键APP与锁之间的首次绑定需要一次ECDH密钥交换。简单说锁生成一对公私钥把自己的公钥通过GATT广播给APPAPP也生成一对公私钥双方交换公钥后在本地各自算出相同的会话密钥之后的开锁指令都用这个会话密钥做AES-GCM加密。RN层负责把这些字节写进GATT通道加密算法可以在JS层用纯JS实现也可以用tweetnacl之类的加密库。实测下来RN能稳定完成这套流程问题出在锁端MCU的处理速度上。ESP32作为从机一次GATT写入之后MCU需要时间解析指令、计算响应如果你的RN代码连续快速写多个Characteristic中间没有等待锁端处理完毕就会丢包。解决办法是在每次写入握手成功后等待锁端Notify一个确认帧再发下一包。这种“请求-确认”机制在原生开发里也要做但RN层的异步回调模式下如果你忘了在then回调里排发下一包很容易把顺序逻辑写乱。开锁指令的下发实测延迟在300ms到800ms之间取决于MTU大小和锁端处理速度。这个延迟体感上还是可以接受的用户按一下开锁键半秒左右锁舌弹开跟原生方案的差异几乎感知不到。真正让RN显露出问题的是大数据量的固件升级场景。3.2 OTA升级的一次真实压测MTU协商与丢包重传智能挂锁的固件包通常在200KB以内我用一个128KB的测试固件包做了压测。GATT默认MTU是23字节实际可用载荷只有20字节。iOS上通常能协商到185字节MTU185-3182字节可用Android一般能协商到247字节MTU。把MTU拉大之后传输速度会明显提升但问题也随之而来。用react-native-ble-plx做MTU请求时Android上有些锁体模组不支持立即调整MTU需要先断开连接再重新连接才能生效。iOS上系统自己决定MTUAPP层主动请求也没用得看锁端支不支持。两个平台最终协商的MTU可能不一样这就意味着同一个OTA算法在iOS上每包能传182字节在Android上可能只有100多字节传输总包数和时间都不一样。OTA分包协议里最让人头疼的是丢包重传机制。BLE链路的可靠性其实没有想象中那么高在某些干扰严重的环境下数据包就是会丢。我们的协议里约定每发100包锁端必须回一个确认序号APP收到确认后继续发下100包。如果连续超时就要将发送窗口减半降低速度重传。这个窗口控制逻辑在JS层实现起来比原生更繁琐。RN的JS运行在异步事件循环上蓝牙回调本身也是异步的你为了控制发送速率不得不用递归或者定时器去排队发包。如果直接写一个for循环瞬间发完几百包锁端MCU就会因为缓冲区溢出而疯狂回错误码。后来我用了一个带间隔的发送器每次发送后等100ms再发下一包实测最大稳定速度在每秒800字节左右整包128KB大约需要3分钟。原生方案可以把这个时间压缩到1分半以内但考虑到挂锁OTA本来就不是高频操作3分钟还在可接受范围内。这次压测让我得到一个明确的结论RN能不能做OTA能做但必须是“协议层写扎实、限速机制做保守”否则大规模用户升级固件时会有连锁翻车事件。3.3 权限申请与后台模式Android和iOS的配置清单RN层写蓝牙代码之前原生工程的配置文件必须先配齐否则跑都跑不起来。这里把双端的关键配置整理出来都是我踩过坑之后确认过的最简清单。Android侧的配置主要在AndroidManifest.xml!-- Android 12及以上需要 -- uses-permission android:nameandroid.permission.BLUETOOTH_SCAN / uses-permission android:nameandroid.permission.BLUETOOTH_CONNECT / !-- Android 11及以下需要定位权限 -- uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION /注意Android 12以上BLUETOOTH_SCAN还需要配合neverForLocation属性来声明你的扫描不是为了定位如果漏了这个属性部分机型会跳出一个吓人的“是否允许APP获取位置信息”的弹窗。版本兼容这块处理方式是把旧权限和新权限同时声明代码里再按Build.VERSION做判断。iOS侧的配置在Info.plistkeyNSBluetoothAlwaysUsageDescription/key string需要访问蓝牙以连接您的智能挂锁/string keyNSBluetoothPeripheralUsageDescription/key string需要蓝牙权限以连接挂锁配件/string keyUIBackgroundModes/key array stringbluetooth-central/string stringbluetooth-peripheral/string /arrayiOS上如果不声明UIBackgroundModes里的bluetooth-centralAPP一退到后台就会被系统杀掉蓝牙连接用户体验直接崩盘。而且后台模式声明之后App Store审核时会问你这个模式的具体用途你得能解释清楚“为什么APP需要在后台保持蓝牙连接”对智能锁来说理由很充分——用户退到后台只是切出去看消息回来还要立刻能用APP开锁。权限这块RN本身没有帮你做任何事用的还是原生的权限声明体系。好在react-native-ble-plx提供了统一的权限请求API能在JS层直接拉起系统权限弹窗不用自己写原生代码这块体验还是不错的。4. 实践验证后的技术架构不是“RN代替原生”而是“混合各司其职”4.1 最终采用的方案RN外壳 原生蓝牙容器验证完所有关键链路之后我的结论不是“全用RN”而是“RN做壳原生做蓝牙容器”。产品界面、业务逻辑、用户体系、WebView内嵌的管理后台全部用RN写但蓝牙的发现、连接、GATT通信、OTA升级链路封装成一个原生模块通过RN提供JS接口给上层调用。这个架构的核心好处是——UI迭代速度飞快硬件通信稳定性有保障。RN团队改一个开锁按钮的样式不需要重新走原生发布的流程热更新就能直接上而锁体的OTA协议如果出了问题只需要改原生模块不牵动RN层的业务代码。说白了就是用混合架构把“跨平台开发效率”和“硬件通信可靠性”这两个互相打架的目标拆开了。原生容器模块对外暴露的接口设计得很精简RN层只关心几个高频方法// 暴露给RN使用的原生蓝牙模块接口 NativeModules.BleLockModule.scanLocks() - PromiseLockInfo[] NativeModules.BleLockModule.connectLock(deviceId) - PromiseSessionInfo NativeModules.BleLockModule.openLock(sessionId, encryptedPayload) - PromiseOpenResult NativeModules.BleLockModule.startOta(deviceId, otaFilePath) - PromiseOtaProgressRN层不需要知道GATT的Service UUID、不用担心数据分包和MTU协商也不需要在JS层写字节拼接逻辑。原生模块内部把这些脏活全消化了RN拿到的是“扫描到的锁数组”、“连接成功后的会话标识”、“开锁返回的状态码”这种高度封装的业务数据。等于说是把RN当作一个纯前端框架来用蓝牙能力全部藏进原生的黑盒里。4.2 为什么我会放弃纯RN方案的背后逻辑再往深一层说为什么不直接打死纯RN方案实事求是地讲纯RN不是不行在某些特定场景下甚至可行但工程风险太大了。纯RN方案的隐藏成本有三块。第一块是调试成本RN跑了三层栈——JS层、RN Bridge层、原生层一个蓝牙问题报出来你要先分清楚是哪个层出的问题。用一个connection lost错误举例它可能是锁端断电导致可能是系统蓝牙被用户关掉也可能是RN Bridge的线程卡死导致回调没有触达JS层。定位这几种问题的手段完全不同纯RN团队如果没有懂原生的人排查效率会非常低。第二块是三方库的维护风险。react-native-ble-plx是社区维护不是官方出品的项目。一旦RN大版本升级三方库跟不上整个项目的升级计划就会被绑架。这种事在RN生态里太常见了很多项目最后卡在某个RN版本上三五年不敢动就是因为依赖库不兼容。但如果你只把RN当UI层核心蓝牙逻辑在原生模块里三方库崩了顶多花几天重新封装一个风险完全可控。第三块是性能敏感路径的执行效率。RN的JS和原生之间隔着一层Bridge每次蓝牙回调的数据量大时Bridge的序列化开销会拖慢处理速度。实测OTA过程中每秒有几百个进度回调在跑RN Bridge上偶尔会出现回调堆积导致锁端的确认帧处理不及时进而触发锁端的超时重发整个OTA速度进一步下降。原生模块把这些高频回调拦截在底层只把汇总后的进度数值上报给JS层性能问题就消失了。4.3 关键模块的职责划分和接口约定最后放一下这个项目里RN和原生的职责边界表方便你直接拿去做自己项目的架构参考功能模块归属方职责说明UI交互、页面流转RN层扫码页、设备列表页、开锁页、设置页用户登录与云端APIRN层JWT鉴权、设备绑定关系查询、远程授权指令请求BLE权限申请RN层调用统一API拉起系统权限弹窗BLE扫描与过滤原生容器管理扫描起始、停止、按厂商协议过滤设备GATT连接与会话管理原生容器连接、断开、自动重连、session保活数据加解密原生容器ECDH密钥协商、AES-GCM加解密指令、防重放多分包传输原生容器大文件分片、MTU协商、窗口限速、超时重传推送通知RN层开锁提醒、低电量提醒、防拆报警推送这套架构跑下来RN层的维护成本和对原生蓝牙的依赖程度分得很开换任何一个蓝牙模组厂商只要原生容器的接口不变RN层一行代码都不用动。在我做过的智能硬件APP项目里这种分工方式一直是所有方案里翻车率最低的。5. 常见问题与踩坑记录从白屏到锁死5.1 每次启动白屏2秒RN的初始化到底慢在哪开发期间遇到最让人恼火的问题就是启动白屏。APP冷启动时RN的JS引擎要从磁盘读取打包后的JS Bundle执行初始化逻辑等原生侧和JS侧完成首轮通信之后首屏组件才能渲染出来。这个时间在我的项目上实测是1.5秒到2.5秒看起来不长但给用户的感觉就是“点了APP没反应”跟锁死了一样。后面优化做了三件事。一是开启RN的inline require和transform优化把非首屏用到的模块延迟加载不全部打包进bundle。二是把启动页改成原生页面先显示一个品牌Logo的Activity等JS首屏渲染完毕后再切过去用户感知不到白屏。三是把蓝牙管理器的初始化从启动流程中挪到用户进入“设备列表页”时才执行避免初始化蓝牙扫描的耗时卡在启动路径上。说实话这个优化做完之后用户体验基本接近原生但要注意RN的新架构Fabric、TurboModule虽然已经大幅缩短了启动时间却没有消除它。只要你在做RN项目启动页方案就省不了别偷懒。5.2 Android上扫描不到锁八成栽在权限和缓存两个坑扫描不到挂锁是出现频率最高的故障。Android 11以前你要检查定位权限给没给Android 12以后要检查附近设备权限给没给这两个权限在RN的权限弹窗里都可能被用户误点“拒绝”一旦拒绝扫描列表永远是空的。而且App没有引导用户去设置页重新授权的逻辑的话用户就卡死在这一步了。第二个坑是系统蓝牙缓存。Android上蓝牙设备地址在某些机型上会缓存到系统设置里如果之前配对失败或者连接超时再次扫描时锁设备不会出现在广播列表里。解决办法是把锁体重置到待配对状态然后在手机系统设置里“忽略此设备”之后回APP重新扫描。我在项目里加了一个“扫描不到锁”的引导页面把权限检查、蓝牙开关检查、系统缓存清理提示全部放了进去。这个页面上线后“无法绑定”类反馈的发单量下降了六成左右。做硬件APP这种引导页面不是锦上添花是必须有的保命功能。5.3 锁体连接上了但读写特征值一直超时还有个特别隐蔽的坑RN库里连接成功之后你以为万事大吉实际上锁体端可能在忙别的事情比如正在处理上一次的连接残留或者GATT Server的MTU还没完成协商。此时你立刻discoverAllServicesAndCharacteristics()锁端根本没空响应就会一直超时。实测下来的稳妥做法是连接成功后先等待800ms到1秒再执行服务发现。这个等待时间最好做成可配置项因为不同锁体模组的固件处理速度不一样有的300ms就绪有的要1.5秒。如果服务发现失败不要立刻重试先断开连接再重连一次成功率反而更高。另外一个线索是日志里看锁端的错误返回码。我们锁体固件定义了一组自定义错误码比如0x10表示“指令格式错误”0x11表示“会话密钥无效”0x12表示“电量低于开锁阈值”。RN层调试时要把这些错误码实时打印出来不然你看到的就是一堆“Write Failed”完全不知道锁端到底在拒绝什么。5.4 双端行为不一致以OTA断点续传为例OTA过程做断点续传时Android和iOS的表现截然不同。Android上如果GATT连接断开react-native-ble-plx会走到onDisconnected回调你可以在这个回调里记住已传输的帧序号等信号恢复后重连从断点继续发。iOS上有的情况下系统会静默地帮你自动重连但不会通知RN层导致RN层以为连接已断开、实际系统层还保有一条连接你再发起新连接就会出现“Gatt 133”这种状态码。处理方式是在原生容器里统一管理连接状态机不依赖RN层的连接状态回调。原生层维护一个currentState枚举是scanning、connecting、connected、disconnecting、otaTransferring任何状态变化都走一个统一的回调通道上报RN层。这样双端表现就一致了RN层永远拿到的是业务状态而不是系统层的原始回调。6. 评估结论与最终落地经验6.1 这套混合方案跑下来的实际效果项目上线后的实际数据APP端Crash率压在0.3%以内蓝牙连接成功率稳定在97%以上OTA升级成功率从最初原生Demo的86%提升到混合方案的95%。这个成绩说明架构选型是对的——RN负责快速迭代界面和业务原生容器把蓝牙相关的不确定性全部兜住。开发效率方面一个熟悉RN的iOS开发、一个Android开发、一个嵌入式MCU工程师三周时间完成了从协议联调到App内测的整个流程。如果走双端原生开发光写蓝牙通信层就得两周起步RN纯方案可能还要再加两周解决Bridge性能和双端差异问题。混合方案在这边的工期优势非常明显。6.2 我踩过这些坑之后给你几条最实在的建议第一如果你团队里没人写过原生蓝牙代码就不要碰纯RN方案。RN社区库再活跃也替代不了你面对真实设备调试时需要的底层认知。至少你要有一名成员能读懂iOS的CoreBluetooth和Android的BluetoothGatt源码否则你根本排不动错。第二做智能硬件APP永远把OTA当成第一优先级来设计。很多团队把OTA排到产品迭代三期以后结果硬件量产时固件必须远程升级才发现APP连升级通道都没预留整个项目推倒重来。你在架构阶段就要把OTA的模块边界画出来不管首发做不做接口先预留。第三锁体端MCU要多留点日志上报能力。调试RN层和蓝牙层的通信问题光看手机端日志是不够的锁体端的执行流程、收到的字节流、加解密结果都必须能上报出来。我们方案里锁体端通过一个隐藏的Debug Service把日志透传到APP再让APP传回后台这套机制在排查问题时救了无数次。第四不要高估“远程开锁”的用户需求。智能挂锁依然是近场交互为主的产品用户真正高频使用的是“靠近即解锁”和“碰一碰开锁”远程开锁只会用于临时授权场景。别为了远程开锁去给每一把锁加WiFi或者蜂窝模组成本和功耗完全划不来。把近场的稳定性和解锁速度做好产品的口碑就有了。这套评估做完我自己最大的体会是工具的选型从来不是“新就好”而是“哪一层的东西放在哪一层”。RN的边界就在于它能演好前台但通信链路背后的脏活累活原生容器会更可靠。如果你也在做类似带蓝牙硬件的APP选型把我的这份评估拿来当参考至少能帮你少填三个大坑。