在Android和iOS中央/外围设备上协商蓝牙LE ATT MTU

在Android上，我们有

requestMtu

和

onMtuChanged

，这似乎意味着，如果中央和外围设备都是基于Android的，我们必须手动协商MTU的大小（但我可能错了，这可能是在连接时也会自动发生，而无需我的干预）。

requestMtu

的文档只讨论了写请求（写而不响应）操作，没有提到通知，还说它是用于“连接”，但没有提到它是从中央还是外围端来的。 因此，不清楚连接的哪一侧可以/应该使用

requestMtu

，以及它如何影响通知大小和写入大小？

在iOS上，似乎没有直接的替代方法可以替代

requestMtu

，我们只有

central.maximumUpdateValueLength

（我想是从iOS 7开始）。它的文档（与Android文档相反）说

maximumUpdateValueLength

仅用于通知更新，这意味着它仅在外围设备端有用，因为您可以从外围设备向中央设备发送通知。 但是写呢？如果我正在对从中央到外围的特征进行写入（同样没有响应），如何知道批大小以确保高效写入？

---

考虑到混合系统（Android/iOS central/peripheral），这一切都会变得混乱，而且根本不清楚哪一方以及何时可以/应该请求/响应MTU大小协商是否有任何文档描述ATT MTU交换选项，这些选项对应于真正的Android和iOS实现？

据我所知，应该从中央角色设备启动

requestMtu（）

，因为它知道要传输和接收多少数据。通常，在任何客户机-服务器模型中，总是由客户机告知或协商会话参数。因此，我觉得即使在BLE的情况下，同样的规则也适用。

根据BLE标准，双方可以交换MTU。当设备充当客户端和服务器时，相同的MTU适用于两者。

谢谢，这很有意义。造成这种混乱的主要原因是，iOS似乎没有记录在案的方法来确定central将传输多少数据，而且也没有明确定义MTU是否以及如何影响写入和/或通知。我在苹果论坛上没有收到任何回复。我想，我得通过反复试验才能找到答案。