在Android上我们有requestMtu和onMtuChanged,这似乎意味着我们必须手动协商MTU大小,如果*和外围设备都是基于Android的(但我可能是错的,它可能会在没有我介入的情况下在连接时自动发生) ).
requestMtu的文档仅讨论写请求(无响应写)操作,并未提及通知,并且还说它是用于“连接”但不提及它是来自*还是外围.
因此,目前尚不清楚,连接的哪一方可以/应该使用requestMtu以及它如何影响通知大小和写入大小？

在iOS上,似乎没有requestMtu的直接替代品,我们只有central.maximumUpdateValueLength(因为iOS 7,我猜).它的文档(与Android相反)表示maximumUpdateValueLength仅用于通知更新,这意味着它仅在外围端有用,因为您从外围设备向中心发送通知.
但写作怎么样？如果我正在编写(再次没有响应)从中心到外设的特性,我如何知道我的批量大小以确保有效写入？

考虑到混合系统(Android / iOS*/外围设备),这一切都让人感到困惑,并且不清楚哪一方以及何时可以/应该请求/对MTU大小协商作出反应.是否有任何描述ATT MTU交换选项的文档,它们对应于真正的Android和iOS实现？

解决方法:

Asper我的理解requestMtu()应该从中心角色设备启动,因为它知道它将接收多少数据.通常,在任何客户端服务器模型中,始终是客户端告知或协商会话参数.因此,我觉得即使在BLE的情况下,同样的规则也适合.