是的！不要放弃你的直播 Jbu。我们在这里谈论串行通信。对于串行的东西，绝对可以/将在读取时返回-1，但仍然期望稍后有数据。问题是大多数人习惯于处理 TCP/IP，除非 TCP/IP 断开连接，否则它应该总是返回 0……然后是的，-1 是有道理的。但是，使用 Serial 时，长时间没有数据流，也没有“HTTP Keep Alive”或 TCP/IP 心跳，或者（在大多数情况下）没有硬件流控制。但是链接是物理的，并且仍然通过“铜”连接并且仍然完美地活着。
现在，如果他们所说的是正确的，即：串行应该在 -1 上关闭，那么为什么我们必须注意诸如 OnCTS、pmCarroerDetect、onDSR、onRingIndicator 等内容......哎呀，如果 0 意味着它在那里, -1 表示不是，那就搞砸所有这些检测功能！:-)
您可能面临的问题可能在其他地方。
现在，到细节：
Q：“好像只显示了第二个事件的数据的尾部，其余的都不见了。”
A：我猜你是在一个循环中，重复使用相同的 byte[] 缓冲区。第一条消息进来，还没有显示在屏幕/日志/标准输出上（因为你在循环中），然后你读取第二条消息，替换缓冲区中的第一条消息数据。再说一次，因为我猜你不会存储你读了多少，然后确保将你的存储缓冲区偏移上一个读取量。
问：“我最终更改了我的代码，以便当我得到一个事件时，我调用了 if(inputStream.available() > 0) while((aByte = read()) > -1) 来存储字节。”
A：好极了……这就是好东西。现在，您的数据缓冲区位于 IF 语句中，您的第二条消息不会破坏您的第一条消息……好吧，实际上，它可能只是第一个位置的一条大（er）消息。但现在，您将一口气读完所有内容，并保持数据完整。
C：“……比赛条件……”
A: 啊，好家伙'抓住所有的替罪羊！竞态条件... :-) 是的，这可能是竞态条件，事实上它很可能是。但是，它也可能只是 RXTX 清除标志的方式。“数据可用标志”的清除可能不会像人们预期的那样快。例如，任何人都知道 read VS readLine 与清除先前存储数据的缓冲区和重新设置事件标志之间的区别吗？我也没有。:-) 我也找不到答案……但是……让我再啰嗦几句。事件驱动编程仍然存在一些缺陷。让我给你一个我最近不得不处理的真实世界的例子。
- 我得到了一些 TCP/IP 数据，比如说 20 个字节。
- 所以我收到了接收数据的 OnEvent。
- 我什至在 20 个字节上开始我的“读取”。
- 在我读完我的 20 个字节之前……我又得到了 10 个字节。
- 然而，TCP/IP 看起来会通知我，哦，看到标志仍然是 SET，并且不会再次通知我。
- 但是，我读完了我的 20 个字节（available() 说有 20 个）...
- ...最后 10 个字节保留在 TCP/IP Q... 因为我没有收到通知。
看，通知被错过了，因为标志仍然设置......即使我已经开始读取字节。如果我完成了字节，那么标志就会被清除，并且我会收到接下来 10 个字节的通知。
与你现在正在发生的事情完全相反。
所以是的，使用 IF available() ...读取返回的数据长度。然后，如果您偏执，请设置一个计时器并再次调用 available()，如果那里仍有数据，则不读取新数据。如果 available() 返回 0（或 -1），则放松...坐等...等待下一个 OnEvent 通知。