Moshi vs Gson in android [closed]

Answer 1

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.

Answer 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.

Answer 3

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.