OkHttp Http2 音频流，我可以控制发送的字节数吗？答案

【问题标题】：OkHttp Http2 Audio stream, Can I control sent bytes?OkHttp Http2 音频流，我可以控制发送的字节数吗？
【发布时间】：2021-09-16 19:48:52
【问题描述】：

我正在尝试使用 OkHttp 发送音频流，下面是 here 的示例，但问题是，如果我使用管道，我无法控制字节如何发送到服务器，这会导致音频中断，因为服务器对字节流很敏感。

监听端口我看到使用 Pipe 我发送了错误的块大小预期：

4, 626, 4、 1255, 4、 1091，

现实： 1460, 1460, 1460, 2109, 1460

有没有办法使用PipeBody 来控制数据的发送方式？尝试在sink.write(data) 之间添加Thread.sleep 和flush()，但没有看到任何变化。

【问题讨论】：

标签： android okhttp http2

【解决方案1】：

您需要在接受管道数据并在 HTTP 请求上发送的代码中更频繁地刷新。

替换这个：

@Override public void writeTo(BufferedSink sink) throws IOException {
  sink.writeAll(pipe.source());
}

有了这个：

@Override public void writeTo(BufferedSink sink) throws IOException {
  sink.writeAllFrequentFlush(pipe.source());
}

然后编写一个随时刷新的函数。这个是从 Okio writeAll 函数派生的。

fun BufferedSink.writeAllFrequentFlush(source: Source): Long {
  var totalBytesRead = 0L
  while (true) {
    val readCount: Long = source.read(buffer, 8192L)
    if (readCount == -1L) break
    totalBytesRead += readCount
    emit()
  }
  return totalBytesRead
}

【讨论】：

感谢您的回答，但在我的情况下似乎没有什么不同，导致块大小与以前大致相同：162、6636、1460、6605、1460、6549、1460跨度>
在生产端尝试频繁刷新？
感谢您的建议，但遗憾的是这是不可能的。
为什么不呢？看起来这是你的问题！
这两个数据示例（预期和现实）来自同一个生产端实现，唯一的区别是在“预期”情况下使用套接字，而在“现实”情况下使用带有管道的 OkHttp，基本上我得到了很好的数据，但它没有得到正确的写入。