web-dev-qa-db-fra.com

Moshi vs Gson dans android

Je décide d’utiliser Moshi par carré ou Gson pour sérialiser et désérialiser les données du modèle.

une chose que je n’ai toujours pas aimée chez Gson est que je pense qu’elle utilise la réflexion qui peut être lente sur Android? Moshi utilise-t-il également la réflexion?

Quels sont certains des avantages et des inconvénients de Moshi vs Gson?

Je les vois comme similaires. Prenons par exemple cette instruction qui crée un typeAdapter:

    class CardAdapter {
  @ToJson String toJson(Card card) {
    return card.rank + card.suit.name().substring(0, 1);
  }

  @FromJson Card fromJson(String card) {
    if (card.length() != 2) throw new JsonDataException("Unknown card: " + card);

    char rank = card.charAt(0);
    switch (card.charAt(1)) {
      case 'C': return new Card(rank, Suit.CLUBS);
      case 'D': return new Card(rank, Suit.DIAMONDS);
      case 'H': return new Card(rank, Suit.HEARTS);
      case 'S': return new Card(rank, Suit.SPADES);
      default: throw new JsonDataException("unknown suit: " + card);
    }
  }
}

et pour l'utiliser, enregistrez-le comme dans gson:

Moshi moshi = new Moshi.Builder()
.add(new CardAdapter())
.build();

je suppose que les avantages seraient les annotations utilisées dans le typeAdapter. Je cherche à savoir s’il ya des gains de performance si je passe à Moshi.

androidgsondeserializationmoshi
57
j2emanue

Moshi utilise Okio pour optimiser certaines choses que Gson n’a pas.

  • Lorsque lecture des noms de champs , Moshi n’a pas à allouer de chaînes ni à effectuer de recherches de hachage.
  • Moshi analyse l'entrée sous la forme d'une séquence d'octets UTF-8, en convertissant les caractères Java caressés. Par exemple, il n'est jamais nécessaire de convertir des littéraux entiers en caractères.

Les avantages de ces optimisations sont particulièrement prononcés si vous utilisez déjà des flux Okio. Les utilisateurs de Retrofit et OkHttp bénéficient en particulier de Moshi.

Vous trouverez plus de détails sur les origines de Moshi dans mon message, Moshi, un autre processeur JSON .

75
Jesse Wilson

D'après le commentaire de swankjesse sur reddit :

Je suis fier de mon travail sur Gson, mais aussi déçu par certaines de ses limites. Je voulais aborder ces questions, mais pas en tant que "Gson 3.0", en partie parce que je ne travaille plus chez Google. Jake, Scott, Eric et moi avons créé Moshi pour répondre aux diverses limitations de Gson. Voici dix petites raisons de préférer Moshi à Gson:

  1. Prise en charge de Kotlin à venir.

  2. Des qualificateurs tels que @HexColor int autorisent plusieurs représentations JSON pour un seul type Java.

  3. @ToJson et @FromJson facilitent l'écriture et le test d'adaptateurs JSON personnalisés.

  4. JsonAdapter.failOnUnknown () vous permet de rejeter des données JSON inattendues.

  5. Exceptions prévisibles. Moshi lève IOException sur IO problèmes et JsonDataException sur des incohérences de types. Gson est partout.

  6. JsonReader.selectName () évite le décodage UTF-8 et les allocations de chaîne inutiles dans le cas habituel.

  7. Vous allez envoyer un fichier APK plus petit. Gson est 227 KiB, Moshi + Okio ensemble sont 200 KiB.

  8. Moshi ne divulguera pas les détails d’implémentation des types de plate-forme dans votre JSON codé. Cela me fait peur de Gson: gson.toJson (SimpleTimeZone.getTimeZone ("GMT"))

  9. Moshi ne fait pas l’échappement HTML étrange par défaut. Regardez le codage par défaut de Gson "12 & 5 = 4" pour un exemple.

  10. Aucun adaptateur de date brisé installé par défaut.

Si vous écrivez un nouveau code, je vous recommande fortement de commencer par Moshi. Si vous avez un projet existant avec Gson, vous devez effectuer une mise à niveau si ce sera simple et sans risque. Sinon, restez avec Gson! Je fais de mon mieux pour que ce dernier reste compatible et fiable.

12
Ahamadullah Saikat