android - 在实践中协商 Android 和 iOS 中央/外设上的蓝牙 LE ATT MTU

Question

在 Android 上我们有 requestMtu 和 onMtuChanged，这似乎意味着我们必须手动协商 MTU 大小，如果中央设备和外围设备都是基于 Android 的(但我可能错了，它也可能在没有我干预的情况下在连接时自动发生)。requestMtu 的文档只讨论了写请求(write without response)操作，没有提到通知，还说它是为了“连接”，但没有提到它是来自中央还是外围。因此，不清楚连接的哪一侧可以/应该使用 requestMtu 以及它如何影响通知大小和写入大小？

在 iOS 上，似乎没有 requestMtu 的直接替代品，我们只有 central.maximumUpdateValueLength(我猜是从 iOS 7 开始)。它的文档(与 Android 文档相反)说 maximumUpdateValueLength 仅用于通知更新，这意味着它仅在外围设备端有用，因为您将通知从外围设备发送到中央设备。但是写入呢？如果我正在(再次没有响应)从中央到外围设备的特征写入，我如何知道我的批量大小以确保高效写入？

考虑到混合系统(Android/iOS 中央/外设)，一切都会变得困惑，并且完全不清楚哪一方以及何时可以/应该请求/响应 MTU 大小协商。 是否有任何文档描述 ATT MTU 交换选项，这些选项对应于真实的 Android 和 iOS 实现？

Answer 1

根据我的理解，requestMtu() 应该从中央角色设备启动，因为它知道要传输和接收多少数据。通常，在任何客户端服务器模型中，总是由客户端告知或协商 session 参数。因此，我觉得即使在 BLE 的情况下，同样的规则也适用。