Vaut-il la peine d'essayer de réduire la taille de JSON?

Je suis soumettre relativement beaucoup de données depuis une application mobile (jusqu'à 1000 objets JSON), que je devrais normalement coder comme ceci:

[{
    id: 12,
    score: 34,
    interval: 5678,
    sub: 9012
}, {
    id: ...
}, ...]

J'ai pu faire la charge utile plus petits en présentant un tableau de tableaux à la place:

[[12, 34, 5678, 9012], [...], ...]

pour économiser de l'espace sur les noms de propriété, et de recréer les objets sur le serveur (comme le schéma est fixe, ou, au moins, c'est un contrat entre le serveur et le client).

La charge utile ensuite soumis à un POST demande, le plus probable au cours d'une connexion 3G (ou pourrait être, wifi).

Il regarde comme je suis en économisant de la bande passante en utilisant les tableaux imbriqués, mais je ne suis pas sûr qu'il est perceptible lorsque gzip est appliqué, et je ne suis pas sûr de savoir comment précisément et objectivement mesurer la différence.

D'autre part, les tableaux imbriqués ne pas sentir comme une bonne idée: ils sont de moins en moins lisible et donc plus difficile à repérer des erreurs pendant le débogage. Aussi, puisque nous sommes le rinçage de la lisibilité dans les toilettes, nous avons pu aplatir un peu le tableau, puisque chaque tableau enfant a un nombre fixe d'éléments, le serveur pourrait juste le couper en tranches et de reconstruire les objets.

Tout autre matériel de lecture sur ce sujet est très apprécié.

source d'informationauteur Attila O.

  1. 12

    JSONH, aka hpack, https://github.com/WebReflection/JSONH fait quelque chose de très similaire à votre exemple:

    [{
    id: 12,
    score: 34,
    interval: 5678,
    sub: 9012
}, {
    id: 98,
    score: 76,
    interval: 5432,
    sub: 1098
}, ...]

    Serait à son tour tenu:

    [["id","score","interval","sub"],12,34,5678,9012,98,76,5432,1098,...]
  2. 9

    JSON est destinée pour des raisons de lisibilité. Vous pourriez avoir un format intermédiaire, si vous êtes inquiet au sujet de l'espace. Créer un sérialiser/désérialiser fonction qui prend un fichier JSON et crée un binaire compressé le stockage de vos données de manière compacte que est raisonnable, alors lisez ce format à l'autre bout de la ligne.

    Voir: http://en.wikipedia.org/wiki/Json
    Première phrase: "JSON...est un poids léger à base de texte standard ouvert conçu pour être lisible par l'échange de données."

    Essentiellement, mon point est que l'homme serait toujours voir le JSON, et les machines sont principalement voir le binaire. Vous obtenez le meilleur des deux mondes: la lisibilité et la petite de transfert de données (au prix d'une petite quantité de calcul).

  3. 6

    Gzip va remplacer le récurrents parties de votre message avec des petites références à leur première occurrence. L'algorithme est assez "idiot", mais pour ce genre de données répétitives, il est grand. Je pense que vous ne verrez pas une diminution notable dans plus de-the-wire parce que la taille de votre objet "structure" est envoyé qu'une seule fois.

    Vous pouvez à peu près le tester en compression des deux échantillons JSONs. Ou en capturant un HTTP-demande à l'aide de Fiddler. Il peut afficher l'compressé et non compressé tailles.

  4. 6

    Depuis que vous utilisez ce sur un appareil mobile (que vous mentionnez 3G), vous pourriez effectivement envie de se soucier de la taille, pas de lisibilité. Par ailleurs, avez-vous souvent s'attendre à lire ce qui est transmis sur le fil?

    C'est une suggestion pour une autre forme.

    ProtoBuf est une option. Google utilise en interne, et il y a un ProtoBuf de "compilateur", qui peut lire .proto fichiers (contenant une description du message) et de générer des Java/C++/Python sérialiseurs/deserializers, qui utilisent une forme binaire pour la transmission sur le fil. Il vous suffit d'utiliser les classes générées sur les deux extrémités, et l'oublier à quoi ressemble l'objet au moment de leur transmission sur le réseau. Il y a aussi un Obj-C port maintenu à l'externe.

    Voici une comparaison de ProtoBuf sur XMLsur la ProtoBuf site (je sais XML n'est pas ce que vous utilisez, encore).

    Enfin, voici une Tutoriel Python.

  5. 4

    Bien que est une vieille question, je voudrais mettre quelques mots.

    Dans mon expérience, les grandes différences dans le json brutes de taille, montant très peu après la compression. Je préfère garder lisible par l'homme.

    Réel le nombre de cas: un fichier json de 1,29 MO et la version optimisée de 145KB, lors de la compression, où de 32 ko et 9 KO.

    Sauf dans des conditions extrêmes, je pense que ce genre de différences sont negligibles et le coût de la lisibilité est énorme.

    Un:

    {
  "Code": "FCEB97B6",
  "Date": "\/Date(1437706800000)\/",
  "TotalQuantity": 1,
  "Items": [
    {
      "CapsulesQuantity": 0,
      "Quantity": 1,
      "CurrentItem": {
        "ItemId": "SHIELD_AXA",
        "Order": 30,
        "GroupId": "G_MODS",
        "TypeId": "T_SHIELDS",
        "Level": 0,
        "Rarity": "R4",
        "UniqueId": null,
        "Name": "AXA Shield"
      }
    }
  ],
  "FormattedDate": "2015-Jul.-24"
}

    B:

    {
  "fDate": "2016-Mar.-01",
  "totCaps": 9,
  "totIts": 14,
  "rDays": 1,
  "avg": "1,56",
  "cells": {
    "00": {
      "30": 1
    },
    "03": {
      "30": 1
    },
    "08": {
      "25": 1
    },
    "09": {
      "26": 3
    },
    "12": {
      "39": 1
    },
    "14": {
      "33": 1
    },
    "17": {
      "40": 3
    },
    "19": {
      "41": 2
    },
    "20": {
      "41": 1
    }
  }
}

    Ce sont des fragments de deux fichiers.