Google Nearby 中的传入文件有效负载感知和 onPayloadTransferUpdate 频率

Posted

技术标签:

【中文标题】Google Nearby 中的传入文件有效负载感知和 onPayloadTransferUpdate 频率【英文标题】:Incoming File Payload awareness in Google Nearby and onPayloadTransferUpdate frequency 【发布时间】:2018-07-10 09:30:57 【问题描述】:

在一个非常简单的场景中,我通过 Nearby 在两部手机之间发送文件。

发送者简单地制作一个Payload.Type.FILE类型的Payload并将其发送给接收者

接收方方面,我想知道文件传输何时开始(接收方何时知道传入的文件)。在文档中它说明了onPayloadReceived:

根据有效负载的类型,在调用时可能已收到或未收到所有数据。使用 onPayloadTransferUpdate(String, PayloadTransferUpdate) 获取收到的数据状态的更新。

但是,onPayloadTransferUpdate 似乎仅在文件的重要部分已传输后才被调用。根据我的测试,每次附近收到至少 2^16 个字节时都会调用它。

简而言之,我想知道接收方是否可以在我的 FILE 的任何字节实际发送之前知道有效负载传输的开始,即update.getBytesTransferred() == 0

另外,为什么onPayloadTransferUpdate 每 2^16 字节被调用一次?一直都是这个尺寸吗?

【问题讨论】:

【参考方案1】:

是的,onPayloadReceived() 回调仅在收到第一个块时触发是正确的。

就像@Xlythe 提到的那样,如果您想在发送方开始传输时向接收方发送信号,您可以从发送方发送一个字节有效负载,让接收方知道一个文件即将到来。

在任何情况下,鉴于我们当前的块大小为 64k,传输开始和接收器收到第一个块之间的延迟应该是(再次,正如@Xlythe 提到的)

这不是你看到的吗?

【讨论】:

【参考方案2】:

Nearby Connections 会在字节离开设备后立即通知您(通过 onPayloadTransferUpdate),而不是在远程端收到它们后通知您。所以你看到的是预期的。延迟最多为 1 秒。

如果该延迟不可接受,请考虑发送 BYTE 有效负载作为接收方的接收确认。

至于 onPayloadTransferUpdate 中给出的大小,这是当前我们将文件分解成的块大小。不要依赖大小作为常数,因为它不能保证,我们会对其进行调整。

【讨论】:

我指的是远程端的onPayloadTransferUpdate 回调。我相信只有在远程端收到一整块后才会调用它,对吗?远程端无法知道有效载荷传输何时开始? 哦,你是对的。 onPayloadReceived 仅在第一个块之后接收。您可以在发送 FILE 有效负载之前发送 BYTE 有效负载(这也可以让您发送其他元数据,例如文件名)。

以上是关于Google Nearby 中的传入文件有效负载感知和 onPayloadTransferUpdate 频率的主要内容,如果未能解决你的问题,请参考以下文章

Google nearBy BLE 后台订阅仅适用于事件屏幕

Android NearBy API 非常慢(发现和连接约 10 秒以上)

iOS 后台扫描上的 Google Nearby API

适用于 Android 的 Google Nearby Publish 在后台

是否可以在 Android 的后台使用 Google Nearby Messages 发布消息?

Gradle 无法解析 androidx.appcompat:appcompat:1.1.0-alpha01 和 com.google.android.gms:play-services-nearby