React Native 硬件交互设计模式：Context、单例与鲁棒性控制React Native 硬件交互设计模式：

React Native 硬件交互设计模式：Context、单例与鲁棒性控制

在开发涉及 PDA 硬件交互（扫码、RFID、打印机）的 React Native 应用时，如何优雅地管理硬件状态和生命周期是一个核心问题。本文总结了项目中 ScanContext、RFIDContext 和 PrinterContext 三种不同的实现策略，分析了 Context 模式与单例模式的优劣，以及如何通过“回退机制”提升代码的鲁棒性。

1. 三种 Context 的实现策略对比

项目中针对不同的硬件特性，采用了三种不同的 Context 管理策略：

特性	ScanContext (红外扫码)	RFIDContext (射频识别)	PrinterContext (蓝牙打印)
硬件特性	输入型 (被动接收广播)	输入型 (主动/被动)	交互型 (连接/状态/指令)
核心实现	`PhysicalKeyScanManager` (单例)	`RFIDManager` (单例)	`PrinterContext` (React State)
Context 作用	全局历史记录、调试日志	全局状态 (`isScanning`)	核心驱动 (连接状态、UI反馈)
鲁棒性控制	支持回退 (Fallback)	支持回退 (Fallback)	强依赖 (Strict)
脱离 Provider	✅ 功能可用 (降级为单例)	✅ 功能可用 (降级为单例)	❌报错 (必须包裹)

1.1 ScanContext & RFIDContext：混合模式 (Hybrid Pattern)

这两者采用了 "Context + 单例回退" 的混合模式。这种设计提供了最大的灵活性。

核心逻辑：硬件的初始化、监听、销毁逻辑全部封装在单例 Manager (PhysicalKeyScanManager, RFIDManager) 中。
Context 层：仅作为“增强层”，负责提供全局的 React 状态（如扫描历史、全局开关状态）。
Hook 实现 (useScan, useRFID)：

export const useScan = () => {
  const context = useContext(ScanContext);
  
  // 鲁棒性控制：回退机制 (Fallback Strategy)
  // 如果组件未被 Provider 包裹，不报错，而是直接返回单例
  if (!context) {
    return {
      scanManager: physicalKeyScanManager, // 核心功能依然可用
      history: [], // 增强功能失效（返回空值）
      isScanning: false
    };
  }
  return context;
};

优点：

高鲁棒性：即使开发者忘记包裹 <ScanProvider>，扫码功能依然正常工作，不会导致 App 崩溃。
灵活性：对于不需要全局状态的简单页面，可以直接使用功能，减少样板代码。

1.2 PrinterContext：纯 Context 模式 (Pure Context Pattern)

打印机采用了 "强依赖 Context" 的模式。

核心逻辑：连接状态 (isConnected)、设备列表 (devices) 等直接作为 React State 存储在 Provider 中。
Hook 实现 (usePrinterContext)：

export const usePrinterContext = () => {
  const context = useContext(PrinterContext);
  
  // 严格控制 (Strict Control)
  // 强制要求必须在 Provider 内部使用
  if (!context) {
    throw new Error('usePrinterContext must be used within a PrinterProvider');
  }
  return context;
};

为什么这么做？

状态强耦合：打印机的操作（如点击连接）会立即触发 UI 变化（Loading -> Connected）。如果脱离了 Context 的 useState，UI 无法响应状态变化。
生命周期绑定：打印机的蓝牙连接通常跟随 App 生命周期，需要 Provider 统一管理连接保持和断开。

2. 单例模式 vs Context 模式

为什么有了单例还需要 Context？或者说什么时候该用哪个？

2.1 单例模式 (Singleton)

适用于 "功能驱动" 且 "无 UI 强绑定" 的场景。

原理：JS 模块缓存机制，export default new Manager()。
优势：
- 性能极高：不涉及 React 渲染周期。
- 跨组件通信：支持观察者模式 (listeners Set)，A 页面跳转 B 页面，扫码事件互不干扰。
- 随时调用：任何 JS 文件（包括非组件文件）均可导入使用。
劣势：
- 无法驱动 UI：数据变了，React 页面不会自动刷新（除非手动写 useState + addListener）。
- 生命周期模糊：难以优雅地处理 App 退出时的资源清理。

2.2 Context 模式

适用于 "状态驱动" 且 "全局共享" 的场景。

原理：React Context API。
优势：
- 响应式 UI：Context 状态更新 -> 所有订阅组件自动重绘。
- 生命周期管理：Provider 挂载/卸载对应硬件的开启/关闭。
- 全局能力：轻松实现“全局扫描历史”、“全局连接状态栏”等功能。
劣势：
- 性能开销：频繁更新可能导致不必要的重渲染（需配合 useMemo 优化）。
- 使用限制：只能在 React 组件树内部使用。

3. 最佳实践总结

底层用单例，上层用 Context：
- 将硬件操作封装为纯 JS 单例（如 ScanManager），保证逻辑独立和可测试性。
- 用 Context 包裹单例，将数据流转为 React State，暴露给 UI 层。
为通用 Hook 提供回退机制：
- 像 useScan 一样，检测 context 是否为空。为空时返回单例实例，保证核心功能可用。这能极大降低代码耦合度，提升开发体验。
对于强交互硬件，保持严格模式：
- 像打印机这种需要实时反馈连接状态的硬件，坚持使用 Context 并抛出错误，强迫开发者遵循规范，避免出现 UI 状态不同步的 Bug。