Moshi vs Gson in android

问题:

I'm deciding on whether to use Moshi by square or Gson to serialize and deserialize model data.

one thing i always did not like about Gson is i think it uses reflection which can be slow on android? Does Moshi use reflection also?

What are some of the pros and cons of moshi vs Gson?

I see them as similar. take for example this statement that creates a 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);
    }
  }
}

and to use it register it just like in gson:

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

I guess the advantages would be the annotation being used in the typeAdapter. I'm looking to find out if there are any performance gains if I switch to Moshi.

回答1:

Moshi uses Okio to optimize a few things that Gson doesn’t.

• When reading field names, Moshi doesn’t have to allocate strings or do hash lookups.
• Moshi scans the input as a sequence of UTF-8 bytes, converting to Java chars lazily. For example, it never needs to convert integer literals to chars.

The benefits of these optimizations are particularly pronounced if you’re already using Okio streams. Users of Retrofit and OkHttp in particular benefit from Moshi.

Further discussion on the origins of Moshi are in my post, Moshi, another JSON Processor.

回答2:

According to swankjesse's comment on reddit:

I’m proud of my work on Gson, but also disappointed by some of its limitations. I wanted to address these, but not as “Gson 3.0”, in part because I no longer work at Google. Jake, Scott, Eric, and I created Moshi to address the various limitations of Gson. Here’s ten small reasons to prefer Moshi over Gson:

1. Upcoming Kotlin support.

2. Qualifiers like @HexColor int permit multiple JSON representations for a single Java type.

3. The @ToJson and @FromJson make it easy to write and test custom JSON adapters.

4. JsonAdapter.failOnUnknown() lets you reject unexpected JSON data.

5. Predictable exceptions. Moshi throws IOException on IO problems and JsonDataException on type mismatches. Gson is all over the place.

6. JsonReader.selectName() avoids unnecessary UTF-8 decoding and string allocations in the common case.

7. You’ll ship a smaller APK. Gson is 227 KiB, Moshi+Okio together are 200 KiB.

8. Moshi won’t leak implementation details of platform types into your encoded JSON. This makes me afraid of Gson: gson.toJson(SimpleTimeZone.getTimeZone("GMT"))

9. Moshi doesn’t do weird HTML escaping by default. Look at Gson’s default encoding of "12 & 5 = 4" for an example.

10. No broken Date adapter installed by default.

If you’re writing new code, I highly recommend starting with Moshi. If you’ve got an existing project with Gson, you should upgrade if that’ll be simple and not risky. Otherwise stick with Gson! I’m doing my best to make sure it stays compatible and dependable.

回答3:

As ref, this link describes migration from Gson to Moshi with some sample Kotlin code which is very straightforward.

https://medium.com/@joshuaavalon/migrate-from-gson-to-moshi-in-android-bfc9f357ff17

回答4:

From the previous link you can see that using moshi codegen will create compile time adapters to model classes, which will remove the usage of reflection in runtime

Model

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

app/build.gradle

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

Will generate a MyModelJsonAdapter class with validations to ensure the nullablility of the model properties.