我正在開發一個應用程式，它將生成一個可能非常大的 Json。在我的測驗中，這是 8000 行。這是因為 是一年的資料聚合，需要在 UI 中顯示詳細資訊。
例如：
"voice1": {
"sum": 24000,
"items": [
{
"price": 2000,
"description": "desc1",
"date": "2021-11-01T00:00:00.000Z",
"info": {
"Id": "85fda619bbdc40369502ec3f792ae644",
"address": "add2",
"images": {
"icon": "img.png",
"banner": null
}
}
},
{
"price": 2000,
"description": "desc1",
"date": "2021-11-01T00:00:00.000Z",
"info": {
"Id": "85fda619bbdc40369502ec3f792ae644",
"address": "add2",
"images": {
"icon": "img.png",
"banner": null
}
}
}
]
},
關鍵是我可能有 10 個聲音，并且每打幾十個專案。
我想知道您是否可以向我指出一些最佳實踐，或者您是否有一些關于它們的提示，因為我覺得這可以做得更好。
uj5u.com熱心網友回復：
對我來說，唯一顯而易見的是，您可能想要制作一個聲音串列（就像您對專案所做的那樣）而不是 voice1、voice2 等。
除此之外，它實際上只取決于您開始的資料結構（創建 json）和目標資料或代碼的結構（如果需要考慮大小，也可能是傳輸資料的方法）。如果您在任一端進行大量處理以對 json 進行編碼/解碼，則表明有一種更簡單的方法來構建資料。你能分享一些額外的背景或整個程序的例子嗎？
uj5u.com熱心網友回復：
聽起來您發現 JSON 是一種相當冗長的格式（不像 XML 那樣糟糕，但仍然非常冗長）。如果您擔心服務器客戶端之間的訊息大小，您有幾個選擇：
JSON 壓縮得相當好。您可以看到大多數令牌如何重復多次。因此，請確保在發送給客戶端之前使用 Gzip 或 Snappy。這將大大減小尺寸，但會降低充氣/放氣的性能。
另一種選擇是不使用 JSON 進行傳輸，而是使用更優化的格式。這里最好的選擇之一是Flat Buffers。它確實需要您提供要發送的資料的模式，但它是一種開銷最小的優化二進制格式。它還將大大加快您的應用程式的速度，因為它將消除對 JSON 花費大量時間的序列化/反序列化的需要。另一個流行但速度稍慢的替代方案是Protobuf。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/351617.html