Моші проти Гсона в android [закрито]

Я вирішую, чи використовувати Moshi за допомогою квадрата або Gson для серіалізації та десеріалізації даних моделі.

одна річ, яка мені завжди не подобалась у Gson, - це, на мою думку, використовує відображення, яке може бути повільним на андроїд? Чи використовує Моші рефлексію також?

Які плюси та мінуси Moshi проти Gson?

Я бачу їх подібними. візьмемо для прикладу це твердження, яке створює atypeAdapter:

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. Я хочу з’ясувати, чи є якісь підвищення продуктивності, якщо я перейду на Моші.

Моші використовує Okio для оптимізації кількох речей, яких Gson не робить.

• При читанні імен полів , Moshi не повинен виділяти рядки або зробити хеш - пошук.
• Моші сканує вхідні дані як послідовність байт UTF-8, ліниво перетворюючи на символи Java. Наприклад, йому ніколи не потрібно перетворювати цілочисельні літерали в символи.

Переваги цих оптимізацій особливо виражені, якщо ви вже використовуєте потоки Okio. Користувачі Модернізації та OkHttp, зокрема, отримують вигоду від Moshi.

Подальша дискусія про походження Moshi знаходиться в моєму дописі, Moshi, ще один процесор JSON .

Відповідно до коментаря swankjesse щодо reddit :

Я пишаюся своєю роботою над Gson, але також розчарований деякими його обмеженнями. Я хотів звернутися до них, але не як “Gson 3.0”, частково тому, що я більше не працюю в Google. Джейк, Скотт, Ерік і я створили Моші для вирішення різних обмежень Гсона. Ось десять невеликих причин віддати перевагу Моші перед Гсоном:

1. Майбутня підтримка Kotlin.

2. Кваліфікатори, такі як @HexColor int, дозволяють кілька представлень JSON для одного типу Java.

3. @ToJson та @FromJson спрощують написання та тестування власних адаптерів JSON.

4. JsonAdapter.failOnUnknown () дозволяє відхилити несподівані дані JSON.

5. Передбачувані винятки. Moshi кидає IOException на проблеми IO та JsonDataException на невідповідність типу. Гсон повсюди.

6. JsonReader.selectName () уникає зайвого декодування UTF-8 та розподілу рядків у загальному випадку.

7. Ви завантажите менший файл .apk. Gson - 227 КіБ, Moshi + Okio разом - 200 КіБ.

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

9. Moshi за замовчуванням не робить дивного HTML-екранування. Подивіться на приклад кодування Gson за замовчуванням "12 & 5 = 4".

10. За замовчуванням не встановлений зламаний адаптер дати.

Якщо ви пишете новий код, настійно рекомендую почати з Moshi. Якщо у вас є існуючий проект з Gson, вам слід оновити, якщо це буде просто і не ризиковано. Інакше дотримуйтесь Gson! Я докладаю максимум зусиль, щоб він залишався сумісним та надійним.

З попереднього посилання ви бачите, що використання moshi codegen створить адаптери часу компіляції до класів моделі, що вилучить використання відображення під час виконання

Модель

@JsonClass(generateAdapter = true) 
class MyModel(val blah: Blah, val blah2: Blah)

app / build.gradle

kapt "com.squareup.moshi:moshi-kotlin-codegen:$version_moshi"

Згенерує клас MyModelJsonAdapter з валідаціями, щоб забезпечити нульовість властивостей моделі.