Question

我的实时网络应用程序发出ajax请求以获取JSON经济数据响应。

返回的数据通常采用对象数组的形式。

由于数组通常有一个很多元素（虽然发送的数据是由服务器压缩的），为了保持响应大小最小，我保留了键在响应中很短。

例如，不使用说明，而是使用 d：，而不是使用宽度：我使用 w：等......

这样做会减小响应的大小，但在客户端，非常短的非人类可读密钥会使JavaScript代码（访问对象）的可读性降低。

唯一的解决方案似乎是重新解析响应并使用漂亮的键重建对象，或者在收到的原始对象中替换它们。但这可能会损害JavaScript代码的性能，导致更多的延迟......

是否存在更好的解决方案？

修改

正如BjörnRoberg在评论中建议我做了一个比较：

pretty-response.json 459,809 bytes short-response.json 245,881 bytes pretty-response.json.zip 28,635 bytes short-response.json.zip 26,388 bytes

因此，当服务器压缩响应时，差异实际上是微乎其微的。

但是，漂亮的响应要求服务器压缩450 KB的数据，而短响应只需240 KB。

这会影响服务器性能（还是有办法测量它）？

Answer 1

由于您正在考虑将短密钥转换回客户端的长密钥，因此您显然关注数据的带宽要求，而不是客户端的内存要求。

我已经生成了一些包含随机数据和三个键的文件（description，something和somethingElse）。我还通过sed转储数据，用d，s和e替换这些密钥。

这导致：

750K   long-keys
457K   short-keys

HTTP有support for compression，所有重要客户端都支持gzip。那么，如果我们gzip文件会发生什么：

187K   10:26 long-keys.gz
179K   10:27 short-keys.gz

它们之间几乎没有什么选择，因为gzip相当擅长压缩重复的字符串。

因此，只需使用HTTP压缩，不要担心重复数据。

gzip也是一种非常快速的算法，因此它对服务器性能的影响可以忽略不计。

Answer 2

也许你可以尝试protocol buffers，看看是否有任何区别。它被开发为比许多其他序列化格式（即XML和JSON）更快更轻。

存在共享相同目标的其他格式，但协议缓冲区（又称protobufs）是我想到的。

请参阅this answer进行比较。

Answer 3

您可以使用装饰器模式在从数组中检索时包装对象。

但是，鉴于您可能想要访问所有返回的对象（为什么要返回客户端不需要的对象？），将对象转换为对象可能不会更慢，也可能更快从数组中检索时具有较长的字段名称。

如果您要多次检索每个对象，您甚至可以通过数组并逐个替换它们，以避免重复转换它们。

所有这些选项都有性能成本，但可能并不重要。简介！

Answer 4

使用http://dean.edwards.name/packer/

从服务器压缩你的json

压缩库http://dean.edwards.name/download/#packer

您还可以通过在线查看是否减少来检查您的json尺寸

Answer 5

如果您希望您的代码可读并且仍然使用短键，则可以使用索引表示法来访问成员：

var descriptionKey = 'd';
var widthKey = 'w';

//...

var description = yourObject[descriptionKey];

JSON响应对象：“漂亮”键和更大的响应或短键以及更小的响应？

5 个答案: