问题：iOS和Android在BLE MTU协商行为上有哪些差异，如何适配？
答案：
### iOS 与 Android 在 BLE MTU 协商行为上的差异
1. **默认 MTU 值**
- **iOS**：默认 MTU 为 **23 字节**（即 BLE 规范的最小值），除非外设主动发起 MTU 请求或 Central 端调用 `maximumWriteValueLength` 相关 API，否则不会自动协商更大的 MTU。
- **Android**：默认 MTU 为 **23 字节**，但系统在连接建立后会自动发起一次 MTU 协商（通常请求 512 字节），部分设备或 Android 版本可能直接协商到 512 字节，无需开发者手动触发。
2. **协商触发方式**
- **iOS**：**必须由 Central 端（iOS 设备）主动发起 MTU 请求**。外设（Peripheral）无法主动发起协商，只能等待 Central 端请求后响应。iOS 通过 `maximumWriteValueLength(for:)` 方法获取当前连接的实际 MTU，但实际协商需调用 `setNotifyValue` 或 `writeValue` 等操作间接触发，或通过 Core Bluetooth 内部机制自动完成（并非所有场景都会自动协商）。
- **Android**：**可由 Central 或 Peripheral 任意一方发起**。Android 作为 Central 时，通常自动发起请求；作为 Peripheral 时，可通过 `BluetoothGattServer` 的 `requestMtu` 方法主动请求。Android 的 `BluetoothGatt` 类提供了 `requestMtu(int mtu)` 方法供开发者手动调用。
3. **协商结果范围**
- **iOS**：协商后的 MTU 最大支持 **512 字节**（iOS 10+），但实际值取决于外设的支持能力。
- **Android**：协商后的 MTU 最大支持 **512 字节**（Android 5.0+），部分设备或系统版本可能支持到 1024 字节（需硬件和驱动支持）。
4. **协商时机**
- **iOS**：协商通常发生在**首次数据传输**（如写入或订阅通知）时，或开发者显式调用 `peripheral(_:didWriteValueFor:error:)` 等回调后。**不会在连接建立后立即自动协商**。
- **Android**：协商通常**在连接建立后立即自动触发**（系统默认行为），也可通过 `requestMtu` 手动触发。
### 适配建议
1. **通用最佳实践**
- **不要假设默认 MTU 为 23**：始终通过平台 API 获取实际协商后的 MTU 值。
- **分片处理大数据包**：若发送数据超过当前 MTU，需自行分片（ATT 层不支持自动分片，GATT 层需应用层处理）。
- **优先使用 512 字节 MTU**：大多数现代设备支持，可显著提升吞吐量。
2. **iOS 适配要点**
- **主动发起 MTU 协商**：在连接建立后，通过 `peripheral.setNotifyValue(true, for: characteristic)` 或 `peripheral.writeValue(data, for: characteristic, type: .withResponse)` 触发协商（iOS 会在首次写入/订阅时自动尝试协商）。
- **获取当前 MTU**：使用 `peripheral.maximumWriteValueLength(for: .withResponse)` 或 `withoutResponse` 获取实际 MTU。
- **注意响应式写入**：`withResponse` 写入时，iOS 会自动处理 MTU 协商，但 `withoutResponse` 写入需确保数据长度不超过当前 MTU。
- **外设端（Peripheral）**：iOS 外设
> 答案参考了知识库中的相关资料。
[hr]本问答由 AI 基于知识库自动生成，仅供参考。
