Моши против Гссона в андроиде

Я принимаю решение о том, следует ли использовать Moshi by square или Gson для сериализации и десериализации данных модели.

Одна вещь, которую мне всегда не нравилась в Gson, я думаю, что она использует отражение, которое может замедлить работу на Android. Моши также использует отражение?

Каковы некоторые из плюсов и минусов moshi vs Gson?

Я вижу их похожими. возьмите, например, это утверждение, которое создает 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);
    }
  }
}

и использовать его, зарегистрируйте его точно так же, как в gson:

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

Я предполагаю, что преимуществами будет аннотация, используемая в typeAdapter. Я хочу узнать, есть ли какие-либо улучшения в производительности, если я переключусь на Моши.

Ответы

Ответ 1

Моши использует Okio для оптимизации нескольких вещей, которые не делает Gson.

  • Когда имена полей чтения, Moshi не должен выделять строки или делать хеш-поиск.
  • Moshi сканирует вход как последовательность байтов UTF-8, лениво переходя к символам Java. Например, ему никогда не нужно преобразовывать целые литералы в символы.

Преимущества этих оптимизаций особенно заметны, если вы уже используете потоки Okio. Пользователи Retrofit и OkHttp в частности из Моши.

Дальнейшая дискуссия о происхождении Moshi находится в моем посте, Моши, другой JSON-процессор.

Ответ 2

Согласно комментарию swankjesse на Reddit:

Я горжусь своей работой над Gson, но также разочарован некоторыми ее ограничениями. Я хотел обратиться к ним, но не к "Gson 3.0", отчасти потому, что я больше не работаю в Google. Джейк, Скотт, Эрик и я создали Моши, чтобы устранить различные ограничения Gson. Вот десять небольших причин, чтобы предпочесть Моши Гсону:

  1. Предстоящая поддержка Kotlin.

  2. Спецификаторы, такие как @HexColor int, допускают несколько представлений JSON для одного типа Java.

  3. @ToJson и @FromJson облегчают написание и тестирование пользовательских адаптеров JSON.

  4. JsonAdapter.failOnUnknown() позволяет отклонять неожиданные данные JSON.

  5. Предсказуемые исключения. Moshi создает IOException при проблемах ввода-вывода и JsonDataException при несовпадении типов. Гсон повсюду.

  6. JsonReader.selectName() позволяет избежать ненужного декодирования UTF-8 и выделения строк в общем случае.

  7. Вы отправите меньший APK. Гсон - 227 КиБ, Моши + Окио вместе - 200 КиБ.

  8. Moshi не пропустит детали реализации типов платформ в ваш кодированный JSON. Это заставляет меня бояться Gson: gson.toJson(SimpleTimeZone.getTimeZone("GMT"))

  9. По умолчанию Moshi не выполняет странное экранирование HTML. Посмотрите на кодировку Gsons по умолчанию "12 & 5 = 4" для примера.

  10. По умолчанию не установлен сломанный адаптер даты.

Если вы пишете новый код, я настоятельно рекомендую начать с Moshi. Если у вас есть существующий проект с Gson, вам следует обновить его, если это будет просто и не рискованно. В противном случае придерживаться Gson! Я делаю все возможное, чтобы убедиться, что он остается совместимым и надежным.