React Native与Flutter在三层SaaS门禁系统的架构选型咨询

项目背景 #

正在构建三层移动生态系统：

• Worker App：身份管理与安全告警
• Management App：实时监控与站点控制
• Devices App：硬件桥接（人脸识别、二维码、RFID扫描）

现有技术栈：

• Web Dashboard：React.js
• 数据库：MongoDB
• 基础设施：AWS
• 通信：MQTT实现低延迟硬件告警

当前在React Native（新架构）与Flutter之间做选型，咨询以下问题：

1. React Native新架构（Fabric/TurboModules）是否已足够缩小与Flutter的性能差距，可处理高频硬件轮询（生物识别/RFID）？ #

React Native新架构确实大幅缩小了与Flutter的性能差距，尤其是原生模块通信和UI渲染层面。针对门禁场景的高频硬件轮询：

• TurboModules的懒加载与同步调用能力，能降低原生硬件模块与JS层的通信开销，处理RFID这类100ms级别的轮询完全没问题；
• Fabric架构的UI渲染管线更贴近原生，规避了旧架构JS线程阻塞的问题，生物识别的实时回调也能做到低延迟；
• 仅当需要超高频（10ms级）硬件数据采集时，Flutter的Dart原生线程调度才会略占优势——因为它无需跨JS-原生上下文切换，但门禁场景的生物识别/RFID轮询通常达不到这个量级，RN新架构完全够用。

2. 为性能收益维护独立Dart代码库（Flutter）是否值得，还是React（Web）与React Native（移动端）共享逻辑的单仓方案更具可持续性？ #

决策核心看团队资源与业务迭代节奏：

• 如果团队已精通React技术栈，单仓共享逻辑的收益远大于Flutter的性能优势：可共享身份认证、MQTT通信、业务规则等核心逻辑，减少重复开发，Web与移动端的迭代节奏能保持一致，长期维护成本更低；
• 仅当Devices App的硬件交互性能成为核心瓶颈（比如需要极致的实时人脸识别处理），且团队有足够精力维护独立Dart代码库时，才值得选择Flutter。否则，RN跨端共享逻辑带来的效率提升，在SaaS项目的长期迭代中更具可持续性；
• 补充：RN新架构支持TypeScript，与React Web的TS代码兼容性良好，单仓可借助NX、TurboRepo等工具做Monorepo管理，进一步提升协作效率。

3. 在React Native与Flutter中使用MQTT及基于BLE的门禁控制器是否存在已知限制？ #

MQTT场景

两者都有成熟的第三方库，功能层面无明显限制：

• RN可使用react-native-mqtt或mqtt.js（配合WebSocket），需注意iOS上要配置后台模式以保持长连接，Android上需处理Doze模式的影响；
• Flutter可使用mqtt_client或flutter_mqtt，跨平台API更统一，但同样需要处理系统后台保活的限制；
• 两者均能满足门禁场景的低延迟告警需求，无功能缺失。

BLE门禁控制器场景

• React Native：依赖react-native-ble-plx这类库，需注意：
  • Android 12+对BLE扫描权限限制更严格，需动态申请BLUETOOTH_SCAN、BLUETOOTH_CONNECT权限；
  • 部分安卓机型的BLE兼容性存在差异，需针对性做适配测试；
• Flutter：依赖flutter_blue_plus或flutter_reactive_ble，优势是Dart层的BLE逻辑更统一，但：
  • iOS上的BLE后台扫描有时间限制，长时间后台运行可能被系统暂停；
  • 复杂的BLE特征读写操作，两者都需要原生层的定制优化，无本质性能差距；
• 总结：两者均能支持BLE门禁控制器，限制主要来自系统本身，而非框架。

内容的提问来源于stack exchange，提问作者Akash Gamage