原文链接：新一代Json解析库Moshi使用及原理解析

推荐理由

硬伤：Gson无法解析设置Kotlin默认参数
全新JsonAdapter
解析效率高
报空异常（即是优点也是缺点）

概述

Moshi是Square公司在2015年6月开源的有关Json的反序列化及序列化的框架，说到Json，大家应该很快想到Gson，FastJson以及Jackson等著名的开源框架，那为什么还需要Moshi呢？这个主要是由于Kotlin的缘故，我们知道前面说到的几大解析库主要是针对Java解析Json的，当然他们也支持Kotlin，但是Moshi天生对Kotlin友好，而且对Java的解析也毫不逊色，所以不管是在Java跟Kotlin的混编还是在纯Kotlin项目中，Moshi表现都很出色。在Java当中，Gson是官方推荐的反序列化及序列化Json框架，同样在Kotlin中，也有官方的库kotlinx.serialization，下面简称KS，这个库在kotlinx中，是单独拿出来了，跟kotlinx.coroutines一样，接下来我们拿官方库Gson以及Kotlin的官方库KS来做个对比，看看彼此的特点。

性能对比

在性能对比之前，我们先简单对比下这几种解析框架的解析方式

	Method	支持语言	自定义解析
Gson	反射	Java/Kotlin	TypeAdapter
Moshi	反射/注解	Java/Kotlin	JsonAdapter
KS	编译插件	Kotlin	KSerializer

通过上表可以看出，Gson跟Moshi都支持反射解析，KS不支持，而且KS只支持Kotlin，三种解析方式都支持自定义解析器，其中在Kotlin解析时，Moshi支持自动生成JsonAdapter，Gson跟KS需要手动编写，同时的KS可以跨平台，但是KS对于Gradle的版本要求比较高，需要4.7及以上。

在测试的时候，需要注意几点

用真机：尽量别用模拟器，不同的解析框架在同样的模拟器上面差距太大，远超ms级，会给测试带来误差
最优解：也就是说我们在选择Json框架测试的时候，一定要选择该框架的最优解，也就是兼顾开发效率跟解析效率，虽然Gson的TypeAdapter不需要反射，但是它需要手动去编写代码，开发效率较低，所以我们用来对比的是Gson的反射，Moshi的注解以及KS的编译插件解析。

我们主要比较两点：速度跟稳定性

速度

这里用豆瓣的API进行测试，Api的地址是api.douban.com/v2/movie/to…，这个是返回豆瓣电影评分排名前250的电影，不过这个API做了限流，每次最多返回100条，所以我强求了2次，然后把2次的Json叠加在一起，共200条数据以便于测试，说句题外话，豆瓣在返回的图片格式全部用了webp，确实很优秀。然后我们就要开始测试了，在测试的时候不管是反序列化还是序列化，我都只测试了一套Json，然后单个框架测试了10次取平均值，注意是在没有缓存字节码的情况下，也就是首次解析。原因在于这些开源库的底层实现都是反射，所以他们会缓存字节码，导致第二次解析相同的类，速度都超快，因为只需要赋值，当然你可能会说，一套Json的结果是不是不太靠谱，在本次测试中是很靠谱的，首先是我的Json数据量大，而且嵌套层级多，第二是因为他们底层的实现不同，在数据量大的时候这个差异会被放大地很明显，一会儿看数据大家就知道了。

Moshi VS Gson(Java)

Test Code

 fun testGsonJava() {val json = JsonUtils.getJson("douban.json", this)val deserialstart = System.currentTimeMillis()val doubanBean = Gson().fromJson(json, DoubanBean::class.java)val deserizalend = System.currentTimeMillis()val deserialConsume = deserizalend - deserialstartval serialstart = System.currentTimeMillis()val seriJson = Gson().toJson(doubanBean)val serizalend = System.currentTimeMillis()val serialConsume = serizalend - serialstart}fun testMoshiJava() {val json = JsonUtils.getJson("douban.json", this)val jsonAdapter = Moshi.Builder().build().adapter(DoubanBean::class.java)val deserialstart = System.currentTimeMillis()val douban = jsonAdapter.fromJson(json)val deserizalend = System.currentTimeMillis()val deserialConsume = deserizalend - deserialstartval serialstart = System.currentTimeMillis()val seriJson = jsonAdapter.toJson(douban)val serizalend = System.currentTimeMillis()val serialConsume = serizalend - serialstart}
复制代码

Test Result

	Moshi	Gson
Serialization(ms)	24/24/23/23/25	60/60/59/59/60
Deserialization(ms)	66/65/65/65/67	73/79/72/75/74

Moshi VS GSon VS KS(Kotlin)

Test Code

 fun testGsonKotlin() {val json = JsonUtils.getJson("douban.json", this)val deserialstart = System.currentTimeMillis()val doubanBean = Gson().fromJson(json, DoubanBean::class.javaObjectType)val deserizalend = System.currentTimeMillis()val deserialConsume = deserizalend - deserialstartval serialstart = System.currentTimeMillis()val seriJson = Gson().toJson(doubanBean)val serizalend = System.currentTimeMillis()val serialConsume = serizalend - serialstart}fun testMoshiKotlin() {val json = JsonUtils.getJson("douban.json", this)val moshi = Moshi.Builder().add(KotlinJsonAdapterFactory()).build()val jsonAdapter = moshi.adapter(DoubanBean::class.java)val deserialstart = System.currentTimeMillis()val douban = jsonAdapter.fromJson(json)val deserizalend = System.currentTimeMillis()val deserialConsume = deserizalend - deserialstartval serialstart = System.currentTimeMillis()val seriJson = jsonAdapter.toJson(douban)val serizalend = System.currentTimeMillis()val serialConsume = serizalend - serialstart}fun testKotlinXSerialize() {val json = JsonUtils.getJson("douban.json", this)val start = System.currentTimeMillis()val douban = JSON.parse(DoubanBean.serializer(), json)val end = System.currentTimeMillis()val consume = end - startval serialstart = System.currentTimeMillis()val seriJson = JSON.stringify(DoubanBean.serializer(), douban)val serizalend = System.currentTimeMillis()val serialConsume = serizalend - serialstart}
复制代码

Test Result

	Moshi	Gson	KS
Serialization(ms)	23/27/23/24/27	91/85/85/86/86	38/37/36/43/37
Deserialization(ms)	74/74/73/74/73	93/93/94/89/92	73/72/73/77/71

小结

由于Moshi底层的IO操作采用的是Okio，所以在序列化的时候性能优于Gson及KS以及其它框架，这个是很好理解的，在反序列化的过程中，我们看到Moshi的解析效率跟Kotlin的官方序列化工具基本持平，但是稍快于Gson，本次测试中没有把Moshi创建Adapter的时间计算在内，因为他是可以单独创建作为一个单例，跟解析保持相互独立，跟前面提到的最优解保持一致。

稳定性

稳定性主要包含两个方面：默认值和空安全

默认值

我们知道，在Java的解析过程中，如果在Json中缺少某个字段，我们的Bean对象原有的值保持不变，但是由于Gson无法识别Kotlin的构造函数，导致默认值会失效，下面举个例子：

@Serializable
data class Chinese(@Optional val age: Int = 0, @Optional val country: String? = "China") {@Optionalprivate val hobby: String = "travel"
}fun main(args: Array<String>) {val gsonBean = Gson().fromJson("""{"age":4}""", Chinese::class.javaObjectType)val moshi = Moshi.Builder().add(KotlinJsonAdapterFactory()).build()val adapter = moshi.adapter(Chinese::class.java)val moshiBean = adapter.fromJson("""{"age":4}""")val kxBean = JSON.parse(Chinese.serializer(), """{"age":4}""")}
复制代码

我们解析上述数据，发现Gson解析到的gsonBean对象中的country及hobby这两个字段都是null，但是Moshi跟KX反序列化后的对象country跟hobby都是我们给予的默认值，这个问题Gson在解析Java的时候是没有的，但是在Kotlin中就失效了。原因可以从Gson的源码中得到答案，在采用反射解析的时候，Gson构造对象实例时调用的是默认无参构造方法，所以没有默认值也就不足为奇了。那么hobby为什么也没有，因为在Gson并不知道什么是数据类，所以他依然不认识hobby。

空安全

在Java中，我们可以用注解@Nullable和NotNull来标记一个变量或者方法参数是否可空，但是加注解比较麻烦，所以我们很多时候都不会去加注解，一般都是在使用的时候进行非空判断，所以Java代码在调用解析后的Bean对象的时候都需要进行非空判断，Kotlin在这种情况下进行了完善，可以在定义的时候指定对象是否可空，这样在使用非空对象的时候就无需进行判断了，但是如果针对一个方法的参数是非空的，你传入了一个空值，编译就会报错，那么同样的道理，如果我们在定义Data类的时候，如果指定了一个字段为非空类型，那么如果Json数据里面这个字段为Null就应该报错，下面看看三个框架的实现逻辑

@Serializable
data class Chinese(@Optional val age: Int = 0, @Optional val country: String? = "China") {@Optionalprivate val hobby: String = "travel"
}
fun main(args: Array<String>) {val gsonBean = Gson().fromJson("""{"age":null}""", Chinese::class.javaObjectType)val moshi = Moshi.Builder().add(KotlinJsonAdapterFactory()).build()val adapter = moshi.adapter(Chinese::class.java)val moshiBean = adapter.fromJson("""{"age":null}""")val kxBean = JSON.parse(Chinese.serializer(), """{"age":null}""")
}
复制代码

测试的时候发现Moshi跟KS都报错了，但是Gson是正常的，按照Kotlin的语法这个是不合理的，我们是需要报错的，因为age字段是不可空的，而这里却传了一个空参数，所以Gson在这里的处理是有问题的。原因我们之前说过，虽然Kotlin最终被编译成的字节码也是运行在JVM上的，但是Gson反射的时候无法区分Java跟Kotlin，所以还是按照Java的解析规则去解析的，因为Json的key为Null在Java中是正常的，即使这在Kotlin中已经无法执行。

结论

针对上面的测试，下面根据项目的实际使用情况总结一下

混编项目：使用Moshi，兼顾Java跟Kotlin
Java项目：建议使用Gson，如果反序列化需求比较多，建议使用Moshi，因为它内置Okio
Kotlin项目：跨平台的话，使用KS；非跨平台，如果仅仅是反序列化，Moshi跟KS均可，如果序列化较多，使用Moshi

基本用法之Java

Dependency

implementation 'com.squareup.moshi:moshi:1.8.0'
复制代码

Bean

String json = ...;
Moshi moshi = new Moshi.Builder().build();
JsonAdapter<Bean> jsonAdapter = moshi.adapter(Bean.class);
//Deserialize
Bean bean = jsonAdapter.fromJson(json);
//Serialize
String json = jsonAdapter.toJson(bean);
复制代码

List

Moshi moshi = new Moshi.Builder().build();
Type listOfCardsType = Types.newParameterizedType(List.class, Bean.class);
JsonAdapter<List<Bean>> jsonAdapter = moshi.adapter(listOfCardsType);
//Deserialize
List<Bean> beans = jsonAdapter.fromJson(json);
//Serialize
String json = jsonAdapter.fromJson(json);
复制代码

Map

Moshi moshi = new Moshi.Builder().build();
ParameterizedType newMapType = Types.newParameterizedType(Map.class, String.class, Integer.class);
JsonAdapter<Map<String,Integer>> jsonAdapter = moshi.adapter(newMapType);
//Deserialize
Map<String,Integer> beans = jsonAdapter.fromJson(json);
//Serialize
String json = jsonAdapter.fromJson(json);
复制代码

Others

@json：Key转换
transitent：跳过该字段不解析

public final class Bean {@Json(name = "lucky number") int luckyNumber;@Json(name = "objec") int data;@Json(name = "toatl_price") String totolPrice;private transient int total;//jump the field
}
复制代码

基本用法之Kotlin

相对于Java只能通过反射进行解析，针对Kotlin，Moshi提供了两种解析方式，一种是通过Reflection，一种是通过Codegen本质上是通过注解处理器，你可以采用其中的一种，也可以两种都使用，下面分别介绍下这两种解析方式

Dependency

implementation 'com.squareup.moshi:moshi-kotlin:1.8.0'
复制代码

Reflection

Data类

data class ConfigBean(var isGood: Boolean = false,var title: String = "",var type: CustomType = CustomType.DEFAULT
)
复制代码

开始解析

val moshi = Moshi.Builder().add(KotlinJsonAdapterFactory()).build()
复制代码

这种方式会引入Kotlin-Reflect的Jar包，大概有2.5M。

Codegen

上面提到了Reflection，会导致APK体积增大，所以Moshi还提供了另外一种解析方式，就是注解，Moshi的官方叫法叫做Codegen，因为是采用注解生成的，所以除了添加Moshi的Kotlin依赖之外，还需要加上kapt

kapt 'com.squareup.moshi:moshi-kotlin-codegen:1.8.0'
复制代码

改造Data类

给我们的数据类增加JsonClass注解

@JsonClass(generateAdapter = true)
data class ConfigBean(var isGood: Boolean = false,var title: String = "",var type: CustomType = CustomType.DEFAULT
)
复制代码

这样的话，Moshi会在编译期生成我们需要的JsonAdapter，然后通过JsonReader遍历的方式去解析Json数据，这种方式不仅仅不依赖于反射，而且速度快于Kotlin。

这种通过注解生成的Adpter，不需要进行注册，Moshi会通过注解自动帮我们注册到Factory里面，这里就不贴代码了，大家可以去看下官方文档，Read the Fucking Source Code。

高级用法(JsonAdapter)

JsonAdapter是Moshi有别于Gson，FastJson的最大特点，顾名思义，这是一个Json的转换器，他的主要作用在于将拿到的Json数据转换成任意你想要的类型，Moshi内置了很多JsonAdapter，有如下这些：

Built-in Type Adapters

Map：MapJsonAdapter
Enums：EnumJsonAdapter
Arrays：ArrayJsonAdapter
Object：ObjectJsonAdapter
String：位于StandardJsonAdapters，采用匿名内部类实现
Primitives (int, float, char,boolean) ：基本数据类型的Adapter都在StandardJsonAdapters里面，采用匿名内部类实现

Custom Type Adapters

对于一些比较简单规范的数据，使用Moshi内置的JsonAdapter已经完全能够Cover住，但是由于Json只支持基本数据类型传输，所以很多时候不能满足业务上需要，举个例子：

{
"type": 2,
"isGood": 1
"title": "TW9zaGkgaXMgZmxleGlibGU="
}
复制代码

这是一个很普通的Json，包含了3个字段，我们如果按照服务端返回的字段来定义解析的Bean，显然是可以完全解析的，但是我们在实际调用的时候，这些数据并不是很干净，我们还需要处理一下：

type：Int类型，我需要Enum，我得定义一个Enum的转换类，去将Int转换成Enum
isGood：Int类型，我需要Boolean，所以我用的时候还得将Int转成Boolean
title：String类型，这个字段是加密过的，可能是通过AES或者RSA加密，这里我们为了方便测试，只是用Base64对Moshi is flexible对进行encode。

对于客户端的同学来说，好像没毛病，以前都是这么干的，如果这种不干净的Json少点还好，多了之后就很头疼，每个在用的时候都需要转一遍，很多时候我这么干的时候都觉得浪费时间，而今天有了Moshi之后，我们只需要针对需要转换的类型定义对应的JsonAdapter，达到一次定义，一劳永逸的效果，Moshi针对常见的数据类型已经定义了Adapter，但是内置的Adapter现在已经不能满足我们的需求了，所以我们需要自定义JsonAdapter。

实体定义

class ConfigBean {public CustomType type;public Boolean isGood;public String title;
}
复制代码

此处我们定义的数据类型不是根据服务器返回的Json数据，而是定义的我们业务需要的格式，那么最终是通过JsonAdapter转换器来完成这个转换，下面开始自定义JsonAdapter。

Int->Enum

CustomType

enum CustomType {DEFAULT(0, "DEFAULT"), BAD(1, "BAD"), NORMAL(2, "NORMAL"), GOOD(3, "NORMAL");public int type;public String content;CustomType(int type, String content) {this.type = type;this.content = content;}
}
复制代码

TypeAdapter

定义一个TypeAdapter继承自JsonAdapter，传入对应的泛型，会自动帮我们复写fromJson跟toJson两个方法

public class TypeAdapter  {@FromJsonpublic CustomType fromJson(int value) throws IOException {CustomType type = CustomType.DEFAULT;switch (value) {case 1:type = CustomType.BAD;break;case 2:type = CustomType.NORMAL;break;case 3:type = CustomType.GOOD;break;}return type;}@ToJsonpublic Integer toJson(CustomType value)  {return value != null ? value.type : 0;}
}复制代码

至此已经完成Type的转换，接下来我们再以title举个例子，别的基本上都是照葫芦画瓢，没什么难度

StringDecode

TitleAdapter

public class TitleAdapter {@FromJsonpublic String fromJson(String value) {byte[] decode = Base64.getDecoder().decode(value);return new String(decode);}@ToJsonpublic String toJson(String value) {return new String(Base64.getEncoder().encode(value.getBytes()));}
}
复制代码

Int->Boolean

BooleanAdapter

public class BooleanAdapter {@FromJsonpublic Boolean fromJson(int value) {return value == 1;}@ToJsonpublic Integer toJson(Boolean value) {return value ? 1 : 0;}
}复制代码

Adapter测试

下面我们来测试一下

  String json = "{\n" + "\"type\": 2,\n" + "\"isGood\": 1,\n"+ "\"title\": \"TW9zaGkgaXMgZmxleGlibGU=\"\n"+ "}";Moshi moshi = new Moshi.Builder().add(new TypeAdapter()).add(new TitleAdapter()).add(new BooleanAdapter()).build();JsonAdapter<ConfigBean> jsonAdapter = moshi.adapter(ConfigBean.class);ConfigBean cofig = jsonAdapter.fromJson(json);System.out.println("=========Deserialize ========");System.out.println(cofig);String cofigJson = jsonAdapter.toJson(cofig);System.out.println("=========serialize ========");System.out.println(cofigJson);
复制代码

打印Log

=========Deserialize ========
ConfigBean{type=CustomType{type=2, content='NORMAL'}, isGood=true, title='Moshi is flexible'}
=========serialize ========
{"isGood":1,"title":"TW9zaGkgaXMgZmxleGlibGU=","type":2}
复制代码

符合我们预期的结果，并且我们在开发的时候，只需要将Moshi设置成单例的，一次性将所有的Adapter全部add进去，就可以一劳永逸，然后愉快地进行开发了。

源码解析

Moshi底层采用了Okio进行优化，但是上层的JsonReader，JsonWriter等代码是直接从Gson借鉴过来的，所以不再过多分析，主要是就Moshi的两大特性JsonAdapter以及Kotlin的Codegen解析重点分析一下。

Builder

   Moshi moshi = new Moshi.Builder().add(new BooleanAdapter()).build();
复制代码

Moshi是通过Builder模式进行构建的，支持添加多个JsonAdapter，下面先看看Builder源码

public static final class Builder {
//存储所有Adapter的创建方式，如果没有添加自定义Adapter，则为空
final List<JsonAdapter.Factory> factories = new ArrayList<>();
//添加自定义Adapter，并返回自身
public Builder add(Object adapter) {return add(AdapterMethodsFactory.get(adapter));}
//添加JsonAdapter的创建方法到factories里，并返回自身
public Builder add(JsonAdapter.Factory factory) {factories.add(factory);return this;}
//添加JsonAdapter的创建方法集合到factories里，并返回自身
public Builder addAll(List<JsonAdapter.Factory> factories) {this.factories.addAll(factories);return this;}//通过Type添加Adapter的创建方法，并返回自身
public <T> Builder add(final Type type, final JsonAdapter<T> jsonAdapter) {return add(new JsonAdapter.Factory() {@Override public @Nullable JsonAdapter<?> create(Type targetType, Set<? extends Annotation> annotations, Moshi moshi) { return annotations.isEmpty() && Util.typesMatch(type, targetType) ? jsonAdapter : null;}});}
//创建一个Moshi的实例
public Moshi build() {return new Moshi(this);}}
复制代码

通过源码发现Builder保存了所有自定义Adapter的创建方式，然后调用Builder的build方式创建了一个Moshi的实例，下面看一下Moshi的源码。

Moshi

构造方法

  Moshi(Builder builder) {List<JsonAdapter.Factory> factories = new ArrayList<>(builder.factories.size() + BUILT_IN_FACTORIES.size());factories.addAll(builder.factories);factories.addAll(BUILT_IN_FACTORIES);this.factories = Collections.unmodifiableList(factories);}
复制代码

构造方法里面创建了factories，然后加入了Builder中的factories，然后又增加了一个BUILT_IN_FACTORIES，我们应该也能猜到这个就是Moshi内置的JsonAdapter，点进去看一下

BUILT_IN_FACTORIES

 static final List<JsonAdapter.Factory> BUILT_IN_FACTORIES = new ArrayList<>(5);static {BUILT_IN_FACTORIES.add(StandardJsonAdapters.FACTORY);BUILT_IN_FACTORIES.add(CollectionJsonAdapter.FACTORY);BUILT_IN_FACTORIES.add(MapJsonAdapter.FACTORY);BUILT_IN_FACTORIES.add(ArrayJsonAdapter.FACTORY);BUILT_IN_FACTORIES.add(ClassJsonAdapter.FACTORY);}
复制代码

BUILT_IN_FACTORIES这里面提前用一个静态代码块加入了所有内置的JsonAdapter

JsonAdapter

JsonAdapter<ConfigBean> jsonAdapter = moshi.adapter(ConfigBean.class);
复制代码

不管是我们自定义的JsonAdapter还是Moshi内置的JsonAdapter，最终都是为我们的解析服务的，所以最终所有的JsonAdapter最终汇聚成JsonAdapter,我们看看是怎么生成的，跟一下Moshi的adapter方法，发现最终调用的是下面的方法

public <T> JsonAdapter<T> adapter(Type type, Set<? extends Annotation> annotations,@Nullable String fieldName) {type = canonicalize(type);// 如果有对应的缓存，那么直接返回缓存Object cacheKey = cacheKey(type, annotations);synchronized (adapterCache) {JsonAdapter<?> result = adapterCache.get(cacheKey);if (result != null) return (JsonAdapter<T>) result;}boolean success = false;JsonAdapter<T> adapterFromCall = lookupChain.push(type, fieldName, cacheKey);try {if (adapterFromCall != null)return adapterFromCall;// 遍历Factories，直到命中泛型T的Adapterfor (int i = 0, size = factories.size(); i < size; i++) {JsonAdapter<T> result = (JsonAdapter<T>) factories.get(i).create(type, annotations, this);if (result == null) continue;lookupChain.adapterFound(result);success = true;return result;}} }
复制代码

最开始看到这里，我比较奇怪，不太确定我的Config命中了哪一个JsonAdapter，最终通过断点追踪，发现是命中了ClassJsonAdapter，既然命中了他，那么我们就看一下他的具体实现

ClassJsonAdapter

构造方法

final class ClassJsonAdapter<T> extends JsonAdapter<T> {public static final JsonAdapter.Factory FACTORY = new JsonAdapter.Factory() {@Override public @Nullable JsonAdapter<?> create(Type type, Set<? extends Annotation> annotations, Moshi moshi) {//省略了很多异常判断代码Class<?> rawType = Types.getRawType(type);//获取Class的所有类型ClassFactory<Object> classFactory = ClassFactory.get(rawType);Map<String, FieldBinding<?>> fields = new TreeMap<>();for (Type t = type; t != Object.class; t = Types.getGenericSuperclass(t)) {//创建Moshi跟Filed的绑定关系，便于解析后赋值createFieldBindings(moshi, t, fields);}return new ClassJsonAdapter<>(classFactory, fields).nullSafe();}
}
复制代码

当我们拿到一个JsonAdapter的时候，基本上所有的构建都已经完成，此时可以进行Deserialize 或者Serialize 操作，先看下Deserialize 也就是fromjson方法

JsonReader&JsonWriter

对于Java的解析，Moshi并没有在传输效率上进行显著的提升，只是底层的IO操作采用的是Okio，Moshi的创新在于灵活性上面，也就是JsonAdapter，而且Moshi的官方文档上面也提到了

Moshi uses the same streaming and binding mechanisms as Gson. If you’re a Gson user you’ll find Moshi works similarly. If you try Moshi and don’t love it, you can even migrate to Gson without much violence!

所以这里的JsonReader跟JsonWriter说白了都是从Gson那里直接拷过来的，就是这么坦诚，不过Moshi也不是全部都是拿来主义，站在Gson 的肩膀上，Moshi的JsonAdapter更加灵活，并且可以采用注解自动生成。

fromjson

ConfigBean cofig = jsonAdapter.fromJson(json);
复制代码

这个方法先是调用了父类JsonAdapter的fromJson方法

 public abstract  T fromJson(JsonReader reader) throws IOException;public final  T fromJson(BufferedSource source) throws IOException {return fromJson(JsonReader.of(source));}public final  T fromJson(String string) throws IOException {JsonReader reader = JsonReader.of(new Buffer().writeUtf8(string));T result = fromJson(reader);return result;复制代码

我们发现fromJson是个重载方法，既可以传String也可以传BufferedSource，不过最终调用的都是fromJson(JsonReader reader)这个方法，BufferedSource是Okio的一个类，因为Moshi底层的IO采用的是Okio，但是我们发现参数为JsonReader的这个方法是抽象方法，所以具体的实现是是在ClassJsonAdapter里面,。

 @Override public T fromJson(JsonReader reader) throws IOException {T  result = classFactory.newInstance();try {reader.beginObject();while (reader.hasNext()) {int index = reader.selectName(options);//如果不是Key，直接跳过if (index == -1) {reader.skipName();reader.skipValue();continue;}//解析赋值fieldsArray[index].read(reader, result);}reader.endObject();return result;} catch (IllegalAccessException e) {throw new AssertionError();}}//递归调用，直到最后
void read(JsonReader reader, Object value) throws IOException, IllegalAccessException {T fieldValue = adapter.fromJson(reader);field.set(value, fieldValue);}
复制代码

toJson

String cofigJson = jsonAdapter.toJson(cofig);
复制代码

跟fromJson一样，先是调用的JsonAdapter的toJson方法

 public abstract void toJson(JsonWriter writer,  T value) throws IOException;public final void toJson(BufferedSink sink, T value) throws IOException {JsonWriter writer = JsonWriter.of(sink);toJson(writer, value);}public final String toJson( T value) {Buffer buffer = new Buffer();try {toJson(buffer, value);} catch (IOException e) {throw new AssertionError(e); // No I/O writing to a Buffer.}return buffer.readUtf8();}
复制代码

不管传入的是泛型T还是BufferedSink，最终调用的toJson(JsonWriter writer)，然后返回了buffer.readUtf8()。我们继续看一下子类的具体实现

@Override public void toJson(JsonWriter writer, T value) throws IOException {try {writer.beginObject();for (FieldBinding<?> fieldBinding : fieldsArray) {writer.name(fieldBinding.name);//将fieldsArray的值依次写入writer里面fieldBinding.write(writer, value);}writer.endObject();} catch (IllegalAccessException e) {throw new AssertionError();}}
复制代码

Codegen

Moshi’s Kotlin codegen support is an annotation processor. It generates a small and fast adapter for each of your Kotlin classes at compile time. Enable it by annotating each class that you want to encode as JSON:

所谓Codegen，也就是我们上文提到的Annotation，在编译期间生成对应的JsonAdapter，我们看一下先加一下注解，看看Kotlin帮我们自动生成的注解跟我们自定义的注解有什么区别，rebuild一下项目：

CustomType

@JsonClass(generateAdapter = true)
data class CustomType(var type: Int, var content: String)
复制代码

我们来看一下对应生成的JsonAdapter

CustomTypeJsonAdapter

这个类方法很多，我们重点看一下formJson跟toJson

override fun fromJson(reader: JsonReader): CustomType {private val options: JsonReader.Options = JsonReader.Options.of("type", "content", "age")var type: Int? = nullvar content: String? = nullreader.beginObject()while (reader.hasNext()) {when (reader.selectName(options)) {//按照变量的定义顺序依次赋值0 -> type = intAdapter.fromJson(reader) 1 -> content = stringAdapter.fromJson(reader) -1 -> {reader.skipName()reader.skipValue()}}}reader.endObject()//不通过反射，直接创建对象，传入解析的Valuevar result = CustomType(type = type ,content = content )return result}override fun toJson(writer: JsonWriter, value: CustomType?) {writer.beginObject()writer.name("type")//写入typeintAdapter.toJson(writer, value.type)writer.name("content")//写入contentstringAdapter.toJson(writer, value.content)writer.endObject()}
复制代码

在看这段代码之前，我开始很奇怪Moshi为什么在遍历JsonReader的时候要通过Int类型的变量来判断，而不是通过JsonReader的Name来解析，因为一般拿到一个JsonReader之后，我们都是下面这种写法：

 override fun fromJson(reader: JsonReader): CustomType {var type: Int? = nullvar content: String? = nullreader.beginObject()while (reader.hasNext()) {when (reader.nextName()) {//按照变量的定义顺序依次赋值"type" -> type = reader.nextInt()"content" -> content = reader.nextString() else -> {reader.skipValue()}}}reader.endObject()//不通过反射，直接创建对象，传入解析的Valuevar result = CustomType(type = type ,content = content )return result}
//省略toJson
复制代码

相比于我们自己写的代码，Moshi生成的注解中的代码是把Json的key提取出来了，放到一个Options里面去了，在放的同时也自然生成了一个index，可能这里不太好理解，为什么要转成int呢，这样的话效率反而不是更低了么，因为刚开始创建对象的时候需要转一次，读取key的时候也要转一次，这样还不如直接用String来的快，下面我们跟一下源码，看看selectName里面的具体实现

 /*** If the next token is a {@linkplain Token#NAME property name} that's in {@code options}, this* consumes it and returns its index. Otherwise this returns -1 and no name is consumed.*/
@CheckReturnValue
public abstract int selectName(Options options) throws IOException;
复制代码

通过注释我们可以看到selectName的注释，我们传入一个Options，返回一个索引，这个索引也就是我们之前放进去的key的索引，这样会提高解析效率么，直观看起来好像是多此一举，直接把这个Key的名字给我就好了么，为什么还要换成0跟1，可读性反而贬低了。如果你的key只重复一次，那么转不转成index都是一样的，因为从二进制流到string需要一个decode，如果我们解析的是一个列表，那么同一个key会被decode多次，decode需要时间也需要空间，所以当我们解析无重复的key的时候，换成index跟不换是一样的，效率差不多，但是当我们解析List的时候，换成Index的时候对于相同的Key我们只需要decode一次，这个在解析列表的时候效率会大大提升。

ConfigBean

@JsonClass(generateAdapter = true)
data class ConfigBean(var isGood: Boolean ,var title: String ,var type: CustomType)
复制代码

ConfigBeanJsonAdapter

override fun fromJson(reader: JsonReader): ConfigBean {var isGood: Boolean? = nullvar title: String? = nullvar type: CustomType? = nullreader.beginObject()while (reader.hasNext()) {when (reader.selectName(options)) {0 -> isGood = booleanAdapter.fromJson(reader) 1 -> title = stringAdapter.fromJson(reader) 2 -> type = customTypeAdapter.fromJson(reader)-1 -> {reader.skipName()reader.skipValue()}}}reader.endObject()var result = ConfigBean(isGood = isGood ,title = title ,type = typereturn result
}override fun toJson(writer: JsonWriter, value: ConfigBean?) {writer.beginObject()writer.name("isGood")booleanAdapter.toJson(writer, value.isGood)writer.name("title")stringAdapter.toJson(writer, value.title)writer.name("type")customTypeAdapter.toJson(writer, value.type)writer.endObject()
}
复制代码

通过查看生成的CustomTypeJsonAdapter以及ConfigBeanJsonAdapter，我们发现通过Codegen生成也就是注解的方式，跟反射对比一下，会发现有如下优点：

效率高：直接创建对象，无需反射
APK体积小：无需引入Kotlin-reflect的Jar包

注意事项

在进行kotlin解析的时候不管是采用Reflect还是Codegen，都必须保证类型一致，也就是父类跟子类必须是Java或者kotlin，因为两种解析方式，最终都是通过ClassType来进行解析的，同时在使用Codegen解析的时候必须保证Koltin的类型是internal或者public的。

总结

Moshi整个用法跟源码看下来，其实并不是很复杂，但是针对Java跟Kotlin的解析增加了灵活的JsonAdapter，并且在Kotlin中可以自动生成，虽然Gson跟KS也都支持自定义解析，但是赋值需要手动编写，开发效率较低。不过Moshi也有些缺点，对于Kotlin的Null类型的支持并不友好，这样会在Kotlin解析的时候如果对于一个不可空的字段变成了Null就会直接抛异常，感觉不太友好，应该给个默认值或者直接置空比较好一些，还有就是对默认值的支持，如果Json出现了Null类型，那么解析到对应的字段依然会被赋值成Null，跟之前的Gson一样，不过从最新官方的commit已经有人提了issue跟MR，来给非空类型的字段遇到Json数据对应的Key为Null的时候给予一个默认值，应该会在1.9.0中进行更新，大家可以关注一下。

Gson替代方案Moshi使用教程相关推荐

gson 解析json_Gson示例教程解析JSON
gson 解析json Welcome to Gson Example Tutorial. In last post we looked at the Java JSON API and you ca ...
JSON教程（非常详细）
之前写过有关C语言JSON库:[C语言开源库]在Clion上使用开源库cJSON; JSON和XML的对比:JSON vs XML,为什么JSON更好? 下面就好好来了解一下JSON. 文章目录 JS ...
jqgrid mvc_将JQGrid与Spring MVC和Gson集成
jqgrid mvc 我在一个单页面应用程序上工作,我想在使用Spring MVC的应用程序的一部分中使用网格功能. 自从我上次使用JQGrid以来已经有一段时间了,找到让我起床所需的信息有点困难. ...
将JQGrid与Spring MVC和Gson集成
我在一个单页面应用程序上工作,我想在使用Spring MVC的应用程序的一部分中使用网格功能. 自从我上次使用JQGrid以来已经有一段时间了,找到让我起床所需的信息有点困难. 在这篇文章中,我想整理 ...
Oracle 使用GSON库解析复杂json串
在前文中讲到了如何使用JSON标准库解析json串,参考: Oracle解析复杂json的方法(转) 现补充一篇使用GSON库在Oracle中解析复杂json的方法. GSON串的使用教程参考官方文档 ...
HowToDoInJava 其它教程 2 · 翻译完毕
原文:HowToDoInJava 协议:CC BY-NC-SA 4.0 欢迎任何人参与和完善:一个人可以走的很快,但是一群人却可以走的更远. ApacheCN 学习资源目录 JMS 教程 JMS 教 ...
新一代Json解析库Moshi使用及原理解析
概述 Moshi是Square公司在2015年6月开源的有关Json的反序列化及序列化的框架,说到Json,大家应该很快想到Gson,FastJson以及Jackson等著名的开源框架,那为什么还需要 ...
深度对比Jackson和Fastjson，最终我还是选择了...
点击关注公众号,Java干货及时送达来源:cnblogs.com/larva-zhh/p/11544317.html 为什么要替换fastjson 框架选型替换fastjson Deseriali ...
手动构建磁贴服务器（16.04.2 LTS）
转载: https://switch2osm.org/manually-building-a-tile-server-16-04-2-lts/ 本页介绍如何安装,设置和配置操作您自己的磁贴服务器所需的 ...

Gson替代方案Moshi使用教程

概述