跳转至

概述

本文档对应用程序的主要集成点进行了高层次概述——介绍 WebView、原生 Android 层、BLE 协议栈和后端 API 之间的协作方式。

目标是解释各组件之间的通信关系,以及涉及哪些契约(回调、处理器、端点),而不深入底层实现细节。

整体架构

从整体来看,主要分为三个层次:

  1. WebView(前端 JS)

    • 负责渲染 UI。
    • 通过 bridgeWebView 与原生 Android 层通信。
  2. 原生 Android 层

    • BaseWebViewActivity 及相关类中实现。
    • 暴露一组桥接处理器(如 startBleScanconnBleByMacAddressinitBleData 等)。
    • 与 Android BLE 协议栈及网络/API 客户端集成。
  3. 后端 / 外部服务

    • 应用程序调用的 HTTP/REST 或 GraphQL 端点,用于获取配置、设备元数据、用户数据等。
    • 可选的第三方服务(日志、分析、身份验证),如已配置。

每一层都有明确的契约,以便各层能够独立演进。

1. WebView ↔ 原生桥接集成

目的:允许在 WebView 中运行的 JavaScript 调用原生函数并接收回调。

核心概念:

  • bridgeWebView.callHandler(name, payload, callback)

    • JS → 原生调用(如 startBleScanconnBleByMacAddressinitBleData)。
    • payload 通常是序列化的 JSON 对象字符串。
    • callback 接收来自原生的 JSON 字符串响应。
  • bridgeWebView.registerHandler(name, callback)

    • 原生 → JS 调用(事件通知)。
    • JS 注册如下处理器:
      • findDeviceCallback(扫描过程中发现设备时触发)
      • connectSuccess(设备连接成功时触发)
      • connectFail(连接失败或超时时触发)
      • onCompleteCallback(BLE 数据初始化完成时触发)
      • 以及其他应用特定事件。

职责说明:

  1. WebView 从不直接与 BLE 或操作系统通信。
  2. WebView 只调用定义好的桥接方法,并监听已注册的回调。
  3. 桥接层充当 JS 与 Android 之间的薄层 API。

可以将其视为暴露给前端的迷你"内部 API"。

2. 原生层 ↔ BLE 协议栈集成

目的:将所有 BLE 操作封装在一组稳定的 Java ↔ JS 桥接方法之后。

典型职责包括: - 检查手机 BLE 状态 - getPhoneBleStatus() 暴露给 JS,使用 Android API 检查:

    - 蓝牙硬件支持情况
    - 蓝牙是否已开启
    - 所需权限是否已授予
  • 扫描设备

    • startBleScan() / stopBleScan() 映射到 Android 的 BLE 扫描 API。
    • 发现设备时,原生层将设备信息序列化为 JSON 并在 JS 中触发 findDeviceCallback
  • 连接设备

    • connBleByMacAddress(macAddress) 封装连接逻辑。
    • 成功/失败/超时时,在 JS 侧触发 connectSuccessconnectFail
  • 数据初始化

    • initBleData() 封装了以下操作:
      • 服务和特征的发现
      • 可选的初始读取
      • 为后续的读/写/通知操作准备内部映射。
  • 初始化完成后,触发 JS 中的 onCompleteCallback

该集成将所有 BLE 复杂性保留在原生代码中,同时向 WebView 暴露简单的高级 API。

3. WebView / 原生 ↔ 后端 API 集成

目的:将设备状态和用户操作与后端同步。

具体位置取决于架构设计:

  • WebView → 后端

    • JS 直接从 WebView 调用 HTTP/GraphQL API(用于设备元数据、用户账户、仪表板等)。
  • 原生 → 后端

    • 当 BLE 操作需要与服务端状态关联时,原生 Android 代码调用 API(如注册设备、发送遥测数据或同步配置)。

典型集成点:

  • 身份验证

    • 向后端端点传递令牌/请求头。
    • 处理令牌过期和重新认证流程。
  • 设备注册与元数据

    • 将发现的 MAC 地址或序列号映射到后端设备记录。
    • 用服务端元数据(名称、型号、所有者等)丰富 BLE 数据。
  • 遥测 / 日志

    • 可选地将 BLE 读取数据、错误信息和会话日志发送到后端,用于监控和分析。

这些 API 通常在 API 与端点章节中单独说明(路径、请求/响应格式、版本管理)。

4. 集成间的版本控制与兼容性

由于存在多个层次,版本控制至关重要:

  • 桥接 API 版本

    • 处理器集合(如 startBleScanconnBleByMacAddress)构成 WebView 与原生层之间的契约。
    • 任何重大变更都应升级桥接版本,并在各应用版本之间协调发布。
  • BLE 协议版本

    • 设备的 GATT 结构(服务、特征、负载格式)应进行版本管理,尤其是固件随时间演进时。

集成文档应明确说明哪些版本可以协同工作。

5. 跨集成的错误处理与重试

集成层往往是大多数故障的发生地,因此我们将错误处理视为一等关注点:

  • WebView ↔ 原生

    • 所有 callHandler 的响应都应包含成功标志和错误消息或错误码。
    • JS 应显示用户友好的错误提示,并提供重试选项。
  • 原生 ↔ BLE

    • 处理常见的 BLE 问题:超时、断连、权限、不支持的功能。
    • 将底层错误码映射为简单结果(connectFail、timeout 等),供 JS 消费。
  • 应用 ↔ 后端

    • 网络故障和 HTTP 错误应以结构化错误响应的形式呈现,而非崩溃。
    • 在适当的地方实现安全的重试策略(幂等操作)。

后续阅读

本集成概述旨在作为入口点。各集成的详细行为记录在专属页面中:

  • BLE 工作流程 – 逐步 BLE 操作序列(状态检查 → 扫描 → 连接 → 初始化 → 读/写/通知)。
  • WebView 初始化 – WebView 的设置方式、桥接附加方式,以及启动时注册的处理器。
  • API 与端点 – 后端路由、负载、身份验证和版本管理的详细参考。