Flutter开发蓝牙智能挂锁APP可行吗？BLE技术选型与踩坑指南

最近在评估一个蓝牙智能挂锁的配套APP项目硬件那边锁体已经打样手机端要在一两个月内出可演示版本。团队里Flutter经验比原生丰富所以第一版技术方案直接抛过来一句话全Flutter开发行不行这个问题看着简单真要拍板落地得把蓝牙通信选型、系统权限、平台差异、插件维护状态、协议设计全部过一遍。这篇就把我这次评估的完整思路和实操记下来给正在做智能锁、共享设备或者任何蓝牙硬件APP的Flutter团队一个参考。先说结论纯Flutter做蓝牙智能挂锁APP技术上完全走得通但有几个前置条件必须满足。最核心的一条是硬件侧必须走BLE低功耗蓝牙如果锁里塞的还是HC-05这类经典蓝牙SPP模块那iOS端就别想纯Flutter了Apple压根不开放传统蓝牙RFCOMM通道给普通APP。第二条是插件的选择不能用老掉牙的flutter_blue那玩意儿在Android 12之后的权限模型下基本是半残状态。第三条是架构上要给平台通道留好口子因为蓝牙协议里总有厂家私有SDK、安全芯片固件升级这类绕不开原生的场景。下面按需求拆解、技术选型、Demo实操、常见问题四个维度展开全程带代码和踩坑记录。1. 先搞清需求蓝牙智能挂锁的APP到底要做什么1.1 挂锁APP的核心功能清单拆解做可行性评估最容易犯的错就是一上来就研究蓝牙API结果做到一半发现锁的协议根本不支持某项关键功能。我习惯先把APP要干的事列成一张功能清单再逐条落到蓝牙技术点上。一个典型的蓝牙智能挂锁APP核心需求大概分六块。第一是扫码绑定用户扫描锁体上的二维码或输入序列号APP通过蓝牙广播里的设备名或自定义广播数据完成配对绑定。第二是近场开锁这是最高频的交互用户靠近挂锁APP自动扫描并连接发送开锁指令锁体校验后驱动电机开锁整个过程要控制在两三秒内否则用户会觉得这锁反应真慢。第三是状态查询实时获取电量百分比、锁舌状态是否完全闭合、锁体温度、开关锁历史记录等。第四是固件升级这是硬件产品迟早要面对的事锁出厂后要修Bug、加安全补丁APP要能通过蓝牙把新固件分包写进去。第五是设备管理包括解绑、改名、多把锁分组、给家人授权分享钥匙。第六是个容易被忽略的点——离线开锁如果锁支持离线临时密码或者加密钥匙分享APP要能本地生成和校验这些凭证。把功能清单落成蓝牙技术动作就是这个映射关系功能需求蓝牙技术点实现难度扫码绑定扫描广播、通过设备名/广播数据匹配低近场开锁GATT连接、写特征值发送指令、读回复中状态查询读特征值或订阅Notify实时上报低固件升级分包写入、Notify上报进度、断点续传高设备管理本地数据库存储设备ID与绑定关系低离线开锁本地密钥存储、时间戳/滚动码生成高这一步走完基本能得出一个初步判断这些功能依赖的BLE能力Flutter生态都能覆盖。真正的风险点在固件升级和离线开锁这种需要长连接、大数据量交互的场景这两块后面单独说。1.2 通信方案选型BLE还是经典蓝牙SPP蓝牙挂锁这个品类市面上存在两种硬件方案软件团队必须在立项阶段就跟硬件把这件事对齐。第一种是BLE方案也是我强烈推荐的方向。BLE设备像是个勤奋但省电的邮递员平时只在广播信道上轻声喊我在这里APP收到广播后发起连接然后通过GATT服务里的特征值读写来交换数据。优点是手机兼容性极好iOS和Android原生支持系统API稳定功耗低到锁里一颗纽扣电池能撑大半年。缺点是传输速率一般不适合传大文件但你开锁指令就几十个字节完全够用。第二种是经典蓝牙SPP方案常见的模块就是HC-05、HC-06很多传统智能锁、物流挂锁还在用。这类模块的好处是协议简单像操作串口一样两端app和锁约定好帧格式就能收发送数据。但坏处非常致命iOS至今不给第三方APP开放SPP通道CoreBluetooth框架只支持BLE。也就是说如果锁上焊的是HC-05Android端Flutter还能通过rf_bluetooth这类插件勉强连一下而且坑很多iOS端基本没戏除非你用MFi认证芯片走External Accessory框架那就不叫全Flutter了得写一坨原生代码。所以我在评估表上第一行就写了硬件蓝牙模块必须选用BLE且必须支持标准HID或自定义GATT服务。如果产品经理拿HC-05便宜来压你就把iOS不支持SPP这条拍回去一个不能连iPhone的智能锁市场说服力直接腰斩。1.3 全Flutter可行性的初步判断做完整张功能清单和通信选型分析后我心里其实已经有谱了。这里先给一个粗颗粒的可行性矩阵细节后面展开。纯Flutter可独立完成设备列表、扫描导航、UI交互、状态展示、设置项、本地数据库、云端API对接。Flutter为主、需少量原生辅助Android/iOS蓝牙权限申请的具体适配、锁固件升级时的系统唤醒策略、部分老设备BLE异常拉黑处理。必须原生介入厂商私有安全芯片的配网和认证流程、经典蓝牙SPP连接如果硬件方案不改的话、双模蓝牙音频相关场景挂锁用不到略过。整体判断是Flutter的蓝牙生态已经能覆盖智能挂锁90%以上的APP需求剩下10%通过MethodChannel写三五百行原生代码也能兜住。结论不是能不能做而是怎么把架构设计得让这10%原生代码不被Flutter层卡脖子。2. Flutter侧技术栈拆解选对插件和架构是关键2.1 蓝牙插件怎么选flutter_blue_plus和其他方案的对比Flutter做蓝牙插件这块水很深。我见过太多团队一搜Flutter Bluetooth就装了flutter_blue然后在Android 12的模拟器上跑到崩溃。这里把主流方案逐个说透。flutter_blue最早出名的Flutter蓝牙插件但项目早已停更多年作者很久不管了。Android 12对蓝牙权限的改造运行时BLUETOOTH_SCAN/BLUETOOTH_CONNECT权限它根本没有适配新设备上扫描经常静默失败偶尔还要靠设备重启才能恢复。这个插件直接在技术选型阶段划掉。flutter_blue_plus这是社区fork出来的维护版原作者不干了之后一批开发者接力把它养了起来。目前是Flutter BLE生态的绝对主力API和flutter_blue基本兼容但补上了Android 12权限、连接参数设置、MTU协商、扫描过滤这些关键能力。我们Demo用的就是它后面所有代码都基于这个插件。flutter_reactive_ble另一个维护很积极的插件API设计采用Stream流式风格对复杂的连接状态管理支持更好适合做多设备并发连接的场景。缺点是上手门槛比flutter_blue_plus高一点资料相对少。团队如果蓝牙经验丰富可以选它追求快速出活还是flutter_blue_plus更稳。rf_bluetoothFlutter里少数支持经典蓝牙SPP的插件但兼容性一言难尽部分三星、小米设备上连接会莫名失败。只适合内部测试工具不建议上生产。厂商SDK像杰理、泰凌微这些蓝牙芯片厂通常只提供Android/iOS原生SDK没有Flutter版。这种情况只能通过MethodChannel封装一层原生代理Flutter层发指令、收回调。这就是我说的必须写原生代码的场景。插件对比直接看这张表插件维护状态BLE支持经典蓝牙推荐度flutter_blue停更有但残缺不支持不推荐flutter_blue_plus活跃完整不支持主力推荐flutter_reactive_ble活跃完整不支持进阶选择rf_bluetooth低频维护不支持支持但脆弱仅测试用2.2 Android和iOS的权限与平台差异蓝牙权限是新手翻车重灾区而且Android和iOS完全是两套逻辑必须分开处理。Android这边从Android 12API 31开始权限模型大变。老的BLUETOOTH权限被细分成了BLUETOOTH_SCAN扫描、BLUETOOTH_CONNECT连接、BLUETOOTH_ADVERTISE广播三个运行时权限。更坑的是Android 12以下版本扫描BLE还需要定位权限也就是ACCESS_FINE_LOCATION实际扫描结果里会附带RSSI信号强度系统认为这算位置信息。所以一个兼容Android 8到14的APP要同时申请定位和蓝牙两套权限顺序还不能乱。正确做法是先判断系统版本Android 12及以上请求BLUETOOTH_SCAN和BLUETOOTH_CONNECTAndroid 11及以下请求定位权限。Android 13之后系统对BLUETOOTH_SCAN权限做了进一步限制如果APP从未获得过定位权限扫描结果中的广播数据会被过滤你拿不到厂商自定义的那段设备识别信息导致扫码绑定失败。解决方法是继续把定位权限也申请上或者改用广播里的设备名做匹配。iOS这边相对简单Info.plist里加NSBluetoothAlwaysUsageDescription就行第一次使用时会弹窗用户拒绝后要引导去设置页手动打开。另外如果APP需要在后台保持蓝牙连接比如锁在后台主动上报状态必须开启Background Modes里的bluetooth-central同时使用蓝牙时要小心App Store审核他们审核时会检查你的后台模式是不是真的有必要。2.3 平台通道给纯Flutter方案留好的原生兜底口子虽然说了纯Flutter理论上可行但现实项目里几乎一定会遇到Flutter插件覆盖不到的边角。我把项目管理阶段趟出来的经验浓缩成一句话别把Promise下死MethodChannel设计好后面能救你一命。MethodChannel的用法不复杂Flutter侧通过MethodChannel调用原生方法原生返回结果。重要的是眉目清晰建议按功能域划分比如BleSecurityChannel管安全芯片相关、OtaChannel管固件升级、SpChannel管经典蓝牙兜底。每个通道的入参出参提前定义好数据类型用Map传递结构化参数。举一个我真实遇到的场景。锁体有个安全芯片要求APP在开锁前先做双向认证认证过程涉及芯片内部的随机数挑战、签名计算这些逻辑写在原生SDK里。Flutter显然没法直接调我就开了一个BleSecurityChannelFlutter发一个challenge原生SDK计算完response后通过MethodChannel回传Flutter再把它写成BLE特征值发给锁。整个过程对Flutter层来说就是异步函数调用UI层根本没感觉到跨了原生。另一个容易忽略的是系统级状态监听比如蓝牙开关状态、系统定位开关状态。这些在原生层注册监听更可靠通过EventChannel把状态变化推给Flutter让UI及时显示蓝牙未开启请打开蓝牙这类引导。flutter_blue_plus虽然提供了adapterState流但在部分国产ROM上延迟很大体验不够好。所以技术架构我建议这样定Flutter负责一切UI和业务状态BleChannel统一封装蓝牙交互Native层只做插件覆盖不到的脏活累活两边通过MethodChannel和EventChannel通信。这套架构下全Flutter的口号成立但心里要清楚原生兜底通道是最后一道保险。3. 落地实操搭建一个可运行的BLE智能锁Demo3.1 工程初始化与关键配置光说不练没意义这部分带大家把一个最小可运行的BLE智能锁Demo搭出来。假设你已经有一个带BLE GATT服务的锁体硬件服务UUID是0000fff0-0000-1000-8000-00805f9b34fb里面有写指令的特征值和上报状态的特征值。第一步创建工程执行flutter create ble_lock_demo。然后编辑pubspec.yaml加依赖dependencies: flutter_blue_plus: ^1.32.0 permission_handler: ^11.0.0 flutter_bloc: ^8.1.0 equatable: ^2.0.0然后处理Android配置。打开android/app/build.gradle把minSdk提到21以上建议23targetSdk至少33。别小看minSdkflutter_blue_plus底层用了很多较新的Android API低于21直接编不过。再打开AndroidManifest.xml把权限声明写全uses-permission android:nameandroid.permission.BLUETOOTH_SCAN android:usesPermissionFlagsneverForLocation / uses-permission android:nameandroid.permission.BLUETOOTH_CONNECT / uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION android:maxSdkVersion30 /usesPermissionFlagsneverForLocation是Android 12引入的告诉系统这个APP扫描蓝牙不是为了定位可以少弹一次权限确认。但注意加了它之后广播数据会被过滤如果你要靠厂商自定义广播识别设备就别加这个标记。iOS侧打开Info.plistkeyNSBluetoothAlwaysUsageDescription/key string我们需要蓝牙连接您的智能挂锁/string keyUIBackgroundModes/key array stringbluetooth-central/string /array配置到这一步工程骨架就立起来了。3.2 扫描、连接、发现服务的完整调用链接着写核心蓝牙逻辑。我习惯把蓝牙相关操作封装成一个BleService单例页面层用起来干净。先看扫描。这里有个细节如果你知道锁的广播名直接按名字过滤最省电也最准如果不知道就用扫描结果里的RSSI做距离判断靠近某个阈值才展示避免在办公楼里扫出一堆别人的设备。Futurevoid startScan() async { // 清空上次扫描结果避免重复展示 FlutterBluePlus.scanResults.listen((results) { for (ScanResult r in results) { if (r.advertisementData.advName.contains(Lock)) { _devices.add(r.device); } } }); // 启动扫描超时15秒自动停止 await FlutterBluePlus.startScan( timeout: const Duration(seconds: 15), allowDuplicates: false, ); }扫描到设备后就是连接。连接操作最怕的就是卡死所以一定要加超时。我遇到过某些锁体固件对连接请求响应慢不加timeout的话APP会一直转圈。FutureBluetoothDevice? connectToDevice(BluetoothDevice device) async { try { await device.connect(timeout: const Duration(seconds: 10)); // 连接成功后协商MTU默认23字节协商到185能一次多传数据 final mtu await device.mtu.first; await device.requestMtu(185); // 发现服务 await device.discoverServices(); return device; } on Exception catch (e) { debugPrint(connect failed: $e); return null; } }发现服务后从services列表里找到锁体的GATT服务然后拿到我们要的那个特征值。注意一个坑有些锁体把几个功能塞进同一个特征值靠指令码区分而有些锁体每个功能一个特征值。这取决于硬件协议怎么定APP侧要写清楚UUID映射表别在代码里到处硬编码。3.3 开锁指令、状态通知与MTU分包实现现在进入最核心的开锁流程。假设协议是这样定义的写特征值0000fff1指令格式是AA55 指令码 长度 载荷 CRC校验。开锁指令码是01。Futurebool unlock(BluetoothCharacteristic writeChar) async { final cmd [0xAA, 0x55, 0x01, 0x03, 0x00, 0x01, 0x00, 0x8C]; await writeChar.write(cmd, withoutResponse: false); // 等待锁体通过通知特征值回复开锁结果 return _waitForUnlockAck(); }这条指令看着简单但背后有个安全细节必须考虑指令里加递增序列号和随机因子。如果开锁指令是固定的有人拿一个BLE抓包工具录下你每次开锁的报文回放一遍就能黑掉你的锁。所以生产环境的锁通常要求APP端生成一个随机数锁体验完回个签名两边再来个双向认证。这些信息理论上Flutter都能算但出于合规和安全考虑很多厂家把签名算法放在安全芯片或原生SDK里Flutter只负责把原生算好的密文写成特征值。状态通知这边要订阅锁体的Notify特征值。在flutter_blue_plus里先setNotifyValue(true)然后监听lastValueStream。这里有一个反直觉的坑lastValueStream每次只发最新的一条数据如果锁体在一个连接里连续上报5条状态你只收到最后一条。需要改成onValueReceived流或者自己用队列缓存。顺带一提部分锁体的上报数据是粘包比如一次通知里带了电量锁舌状态温度APP这端要按协议逐字节拆包。固件升级是MTU分包最典型的场景。一个完整的固件包可能几百KBBLE每个通知包最多传MTU-3个字节因为ATT层的头占3字节所以我们得手动分包发送Futurevoid sendFirmware(BluetoothCharacteristic fwWrite, Listint firmwareData) async { final mtu await _currentMtu(); final maxChunk mtu - 3; for (int i 0; i firmwareData.length; i maxChunk) { final end (i maxChunk firmwareData.length) ? i maxChunk : firmwareData.length; await fwWrite.write(firmwareData.sublist(i, end), withoutResponse: false); await Future.delayed(const Duration(milliseconds: 20)); // 等锁体处理 } }每包之间加延时非常关键有的锁体Flash写入需要时间发太快会丢包锁直接变砖。20到50毫秒是常见区间具体要看锁的datasheet和实测。升级过程中还要锁屏常亮防止系统休眠把蓝牙断了。3.4 状态管理用Cubit管理蓝牙连接状态机蓝牙连接涉及大量异步状态流转扫描中、已发现、连接中、已连接、认证中、已认证、开锁中、开锁完成、断开、异常。如果用setState硬扛回调一多直接乱套。我强烈建议用状态管理库把蓝牙状态机钉死。推荐flutter_bloc里的Cubit比Bloc轻量适合这种线性状态流转。定义几个枚举enum BleConnectionState { idle, // 空闲 scanning, // 扫描中 connecting, // 连接中 authenticating,// 双向认证中 ready, // 可操作 unlocking, // 开锁中 disconnected, // 已断开 error, // 异常 }然后Cubit里监听bluetooth连接状态流把底层事件映射到业务状态class ConnectionCubit extends CubitBleConnectionState { ConnectionCubit() : super(BleConnectionState.idle); void onConnecting() emit(BleConnectionState.connecting); void onConnected() { // 先认证再置ready emit(BleConnectionState.authenticating); _authService.authenticate().then((ok) { if (ok) { emit(BleConnectionState.ready); } else { emit(BleConnectionState.error); } }); } void onUnlock() emit(BleConnectionState.unlocking); void onDisconnected() emit(BleConnectionState.disconnected); }UI层就根据当前状态决定按钮可点性、加载动画显示、错误提示文案。这样把蓝牙协议的复杂性和UI彻底解耦后面接云端逻辑也方便。状态管理这块还有一个实用技巧状态恢复。用户在App使用过程中切到后台Android可能把蓝牙活动杀掉回来时要能检测到连接断了自动重连或者至少弹个提示别让用户对着一个僵尸界面猛点。推荐在App生命周期resumed回调里检查connectionState断了就主动重连重连失败再刷新扫描列表。4. 踩坑实录蓝牙挂锁开发中最常见的五个问题4.1 扫描不到设备HC-05连不上怎么办这个问题的经验值极高十个做蓝牙的人九个遇到过。先分清场景硬件是BLE模块还是HC-05这类SPP模块如果是HC-05App走BLE扫描当然啥也扫不到因为HC-05根本不上BLE广播信道它走的是经典蓝牙的Inquiry发现流程。前面说过iOS直接用不了SPPAndroid上要用rf_bluetooth插件走Classic通道而且得先在系统蓝牙设置里完成配对APP里才能通过已配对设备列表拿到它。千万别觉得HC-05协议简单就硬上你会被驱动的兼容性折腾到怀疑人生。如果是BLE模块但扫不到排查顺序按这几步。第一权限确认Android 12的BLUETOOTH_SCAN权限给没给iOS的NSBluetoothAlwaysUsageDescription弹窗点了允许没有第二系统蓝牙开关和定位开关Android 11及以下扫描BLE尽管技术上不需要定位服务但代码里如果没申请定位权限扫描结果就是空的。第三锁体是否处于可发现状态很多锁体为了省电平时不广播只有按下锁上的按键才进入广播状态或者只在锁体处于未配对状态时才广播。这个坑最隐蔽建议让硬件同事确认下广播策略。如果这些都排除了还有个容易漏的设备已经被其他手机连接了。BLE是点对点连接一个BLE从设备同一时刻只能被一个主设备连接如果锁还挂在测试工程师手机A上手机B的APP自然扫不到或者连不上。遇到这种情况先把锁放进箱子里让它断开或者按锁上的复位键强制Standby。4.2 连接后频繁断开连接本身成功了但每次用不到几秒钟就断开这种问题多半在连接参数协商上。BLE连接间隔Connection Interval是锁体的物理层面的配置锁体可能设了15ms快速刷新也可能设了45ms省电模式。如果APP侧不主动调连接参数系统会按默认值来结果就是锁体认为链路质量差主动断开。Flutter侧可以通过iOS/Android原生的connectionPriority来做flutter_blue_plus也提供了device.requestConnectionPriority之类的封装。一般分三个级别lowPower、balanced、highPerformance。开锁这种要求低延迟的操作临时切highPerformance平时查询电量用balanced锁放口袋里没操作就lowPower。这个切换要动态做别一个参数吃到死。另外一个常见原因是MTU协商失败。部分老款BLE芯片的MTU只支持23字节你一下requestMtu到185锁直接拒绝然后连接不稳定。稳妥做法是request失败就别强行降级到23字节分包逻辑适配两种MTU场景代码里做判断。4.3 打开通知后收不到数据订阅了Notify特征值setNotifyValue(true)也调了但锁体上报时APP就是没反应。这个问题我排查过很多次九成原因是CCCDClient Characteristic Configuration Descriptor没配置对。BLE协议里要接收通知/指示不只设置特性本身还要往该特征值对应的描述符CCCD里写值。在flutter_blue_plus里setNotifyValue(true)其实会帮忙做这件事但如果锁体用了自定义的4153描述符UUID或者特征值属性不同Notify vs Indicate就可能导致订阅失效。解决办法是手动确认一下CCCD的写入或者直接把setNotifyValue(true)换成显式写描述符await char.setNotifyValue(true); // 检查char.isNotifying if (!char.isNotifying) { final cccd char.descriptors.firstWhere((d) d.uuid.toString().contains(2902)); await cccd.write([0x01, 0x00]); // 0x01开启notify0x02开启indicate }还有个小概率原因锁体只有一个特征值既承担写指令又承担上报状态你监听的时候监听错UUID了。开发时在断点里打出来所有特征值看一眼能少白折腾一小时。4.4 后台运行被系统杀死连接智能挂锁最恶心场景是用户开完锁把手机塞口袋里锁体想主动上报个电量低或者异常触碰报警但APP已经挂了消息发了个寂寞。Android后台限制不是闹着玩的。从Android 8开始后台APP的蓝牙连接会被系统在低内存时杀掉Android 12之后前台服务启动限制更严格。如果你确实需要后台收通知几条路可以选择最规范的做法是起一个前台服务带一个常驻通知让系统知道这个APP在干活蓝牙连接拿BluetoothDevice.connectGatt时传autoConnecttrue这样即使断线了Android会在后台自动尝试重连但前提是你的APP进程还活着。iOS相对好办开启UIBackgroundModes里的bluetooth-central后系统允许APP在后台保持蓝牙协议栈活跃但Apple对后台模式审核很严被拒的案例不少。建议给产品经理讲清楚智能挂锁这类设备真正可靠的后台报警还是要靠锁体端有云端通道APP做后台接收只是体验增强不是安全兜底。锁体在报警时先通过WiFi/4G直连云端策略APP只负责云端推送这才是生产级架构。4.5 功耗与解锁体验的平衡问题这个坑是硬件团队容易忽略、但在用户端感知极强的。如果APP一直保持低功耗的连接参数开锁延迟会高到用户崩溃如果一直都高功耗手机电量哗哗掉锁的电量也飞快消耗用户更崩溃。我实测过一组数据对比连接间隔单次开锁耗时手机/锁体功耗推荐场景7.5ms0.8-1.2秒高开锁前临时切换15ms1-1.5秒中无30ms1.5-2秒低在线待机50ms2.5-3秒极低仅状态同步所以开锁流程完整设计应该是用户靠近锁体→APP扫描发现目标→建立连接→协商MTU和连接参数为高性能→认证→发开锁指令→收ACK→主动断开并切换回低功耗参数。别让APP长时间占着连接不松手用完就断下次再扫再连这个模式对两端都省电。另外还有一个产品层面的功耗设计比连接参数更重要尽量用锁体上的物理按键触发广播和连接而不是一直开着广播。如果锁体每分钟广播一次一颗CR2032电池撑几个月就没了改成用户按压锁体按键后广播60秒电池用一两年毫无压力。软件再怎么调也补不了硬件广播策略的窟窿。写在最后把这次可行性评估的底稿整理出来之后我给团队最终落了个结论全Flutter方案可以立项但要把全字理解成Flutter主导、原生兜底主动把硬件方案的BLE路线确认死插件锁死在flutter_blue_plus架构上预留好MethodChannel的扩展点。这三条钉死了剩下都是工作量问题。我个人在实际操作中体会最深的一点是评估蓝牙项目的可行性别盯着代码能不能跑要先看硬件协议和系统API的兼容边界。蓝牙这玩意有个特点真机行为千奇百怪不同安卓ROM、不同蓝牙芯片、不同锁体固件版本排列组合出来的诡异问题一堆。所以我的习惯是写代码之前先用厂家给的测试APP跟锁体做一轮完整的功能遍历记录下每个操作的时序和报文作为Flutter开发时的行为基线。这个习惯帮我省了至少两次返工供你参考。这个Demo搭完之后后面还能往上扩展的方向有两块一是把开锁记录同步到云端做家人授权和远程查看二是接入手表/手环等高频率穿戴设备让用户可以通过手表BLE直接开锁那又是另一套UX设计。一步一步来吧。