GWT 是否有效地序列化 java.lang.Longs？

Question

我通过 GWT RPC 机制在客户端和服务器之间来回发送对象 ID。 id 以长整型（8 字节）形式从数据存储区中出来。我认为我所有的 id 都只需要 4 个字节，但是可能发生一些随机的事情，给我一个 5 字节（或其他）值。

GWT 是否会聪明地将这些值打包在某种可变长度编码中，从而平均节省空间？我可以指定它在某个地方这样做吗？或者我应该编写自己的代码将长整型复制为整数并注意那些特殊情况？

谢谢~

Answer 1

如 GWT 文档中所述。

long：JavaScript没有64位整型，因此long需要特别考虑。在 GWT 1.5 之前，long 类型只是简单地映射到 64 位 JavaScript 浮点值的整数范围，从而使 long 变量的实际范围小于完整的 64 位。从 GWT 1.5 开始，长原语被模拟为一对 32 位整数，并在整个 64 位范围内可靠地工作。模拟溢出以匹配预期行为。有一些注意事项。由于底层模拟，大量使用长操作会对性能产生影响。此外，长原语不能在 JSNI 代码中使用，因为它们不是本机 JavaScript 数字类型。

如果你的 id 可以容纳在一个整数中，那么你的情况可能会更好。否则，如果您使用 DTO，请将 ids 设为双精度，这实际上存在于 Javascript 中。

Answer 2

GWT 对负载为 256 字节或更大的响应使用 gzip 压缩。如果您的响应中有很多零字节，那么这应该很有效。

来自RemoteServiceServlet.shouldCompressResponse：

确定是否响应
给定的 servlet 请求应该或应该
不是 GZIP 压缩的。这个方法是
仅在以下情况下调用
请求者接受 GZIP 编码。

此实现当前返回
true 如果响应字符串是
估计字节长度长于
256 字节。子类可以重写
这个逻辑。

因此，服务器首先检查请求者（通常是浏览器）是否接受 GZIP 编码。在内部，java.util。使用 zip.GZIPOutputStream - 请参阅 RPCServerUtils。在客户端，浏览器的工作是解压缩 gzip 压缩的有效负载 - 因为这是在本机代码中完成的，应该相当快。