转载出处:
注:此系列基于Gson 2.4。
你真的会用Gson吗?Gson使用指南(一)
本篇文章的主要内容:
- Gson的基本用法
- 属性重命名
@SerializedName
注解的使用 - Gson中使用泛型
一、Gson的基本用法
Gson提供了fromJson()
和toJson()
两个直接用于解析和生成的方法,前者实现反序列化,后者实现了序列化。同时每个方法都提供了重载方法,我常用的总共有5个。
基本数据类型的解析
|
|
注:不知道你是否注意到了第2、3行有什么不一样没
基本数据类型的生成
|
|
POJO类的生成与解析
|
|
生成JSON:
|
|
解析JSON:
|
|
二、属性重命名 @SerializedName 注解的使用
从上面POJO的生成与解析可以看出json的字段和值是的名称和类型是一一对应的,但也有一定容错机制(如第一个例子第3行将字符串的99.99转成double型,你可别告诉我都是字符串啊),但有时候也会出现一些不和谐的情况,如:
期望的json格式
|
|
实际
|
|
这对于使用PHP作为后台开发语言时很常见的情况,php和js在命名时一般采用下划线风格,而Java中一般采用的驼峰法,让后台的哥们改吧 前端和后台都不爽,但要自己使用下划线风格时我会感到不适应,怎么办?难到没有两全齐美的方法么?
我们知道Gson在序列化和反序列化时需要使用反射,说到反射就不得不想到注解,一般各类库都将注解放到annotations
包下,打开源码在com.google.gson
包下果然有一个annotations
,里面有一个SerializedName
的注解类,这应该就是我们要找的。
那么对于json中email_address
这个属性对应POJO的属性则变成:
|
|
这样的话,很好的保留了前端、后台、Android/java各自的命名习惯。
你以为这样就完了么?
如果接中设计不严谨或者其它地方可以重用该类,其它字段都一样,就emailAddress
字段不一样,比如有下面三种情况那怎么?重新写一个?
|
|
|
|
|
|
为POJO字段提供备选属性名SerializedName
注解提供了两个属性,上面用到了其中一个,别外还有一个属性alternate
,接收一个String数组。
注:alternate
需要2.4版本
|
|
当上面的三个属性(email_address、email、emailAddress)都中出现任意一个时均可以得到正确的结果。
注:当多种情况同时出时,以最后一个出现的值为准。
|
|
三、Gson中使用泛型
上面了解的JSON中的Number、boolean、Object和String,现在说一下Array。
例:JSON字符串数组
|
|
当我们要通过Gson解析这个json时,一般有两种方式:使用数组,使用List。而List对于增删都是比较方便的,所以实际使用是还是List比较多。
数组比较简单
|
|
但对于List将上面的代码中的 String[].class
直接改为 List<String>.class
是行不通的。对于Java来说List<String>
和List<User>
这俩个的字节码文件只一个那就是List.class
,这是Java泛型使用时要注意的问题 泛型擦除。
为了解决的上面的问题,Gson为我们提供了TypeToken
来实现对泛型的支持,所以当我们希望使用将以上的数据解析为List<String>
时需要这样写。
|
|
注:TypeToken
的构造方法是protected
修饰的,所以上面才会写成new TypeToken<List<String>>() {}.getType()
而不是 new TypeToken<List<String>>().getType()
泛型解析对接口POJO的设计影响
泛型的引入可以减少无关的代码,如我现在所在公司接口返回的数据分为两类:
|
|
|
|
我们真正需要的data
所包含的数据,而code
只使用一次,message
则几乎不用。如果Gson不支持泛型或不知道Gson支持泛型的同学一定会这么定义POJO。
|
|
当其它接口的时候又重新定义一个XXResponse
将data
的类型改成XX,很明显code
,和message
被重复定义了多次,通过泛型的话我们可以将code
和message
字段抽取到一个Result
的类中,这样我们只需要编写data
字段所对应的POJO即可,更专注于我们的业务逻辑。如:
|
|
那么对于data
字段是User
时则可以写为 Result<User>
,当是个列表的时候为 Result<List<User>>
,其它同理。
PS:嫌每次 new TypeToken<Result<XXX>
和 new TypeToken<Result<List<XXX>>
太麻烦, 想进一步封装? 查看我的另一篇博客: 《搞定Gson泛型封装》
结语
本文主要通过代码向各位读者讲解了Gson的基本用法,以后还会更新更多更高级的用法,如果你还不熟悉 注解和泛型 那么你要多多努力啦。
如果你有其它的想了解的内容(不限于Gson)请给我留言评论,水平有限,欢迎拍砖。
4月6日补充
有说看不懂Result那段怎么个简化法,下面给个两个完整的例子,User和List
没有引入泛型之前时写法:
|
|
上面有两个类UserResult
和UserListResult
,有两个字段重复,一两个接口就算了,如果有上百个怎么办?不得累死?所以引入泛型。
|
|
看出区别了么?引入了泛型之后虽然要多写一句话用于获取泛型信息,但是返回值类型很直观,也少定义了很多无关类。
你真的会用Gson吗?Gson使用指南(二)
本次的主要内容:
- Gson的流式反序列化
- Gson的流式序列化
- 使用GsonBuilder导出null值、格式化输出、日期时间及其它小功能
一、Gson的流式反序列化
自动方式
Gson提供了
fromJson()
和toJson()
两个直接用于解析和生成的方法,前者实现反序列化,后者实现了序列化。同时每个方法都提供了重载方法,我常用的总共有5个。
这是我在上一篇文章开头说的,但我到最后也一直没有是哪5个,这次我给列出来之后,你就知道这次讲的是哪个了。
|
|
好了,本节结束!
看第2、4行,Reader懂了吧
手动方式
手动的方式就是使用stream
包下的JsonReader
类来手动实现反序列化,和Android中使用pull解析XML是比较类似的。
|
|
其实自动方式最终都是通过JsonReader
来实现的,如果第一个参数是String
类型,那么Gson会创建一个StringReader
转换成流操作。
Gson流式解析
二、Gson的流式序列化
自动方式
Gson.toJson方法列表
所以啊,学会利用IDE的自动完成是多么重要这下知道了吧!
可以看出用红框选中的部分就是我们要找的东西。
提示:PrintStream
(System.out) 、StringBuilder
、StringBuffer
和*Writer
都实现了Appendable
接口。
|
|
手动方式
|
|
提示:除了beginObject
、endObject
还有beginArray
和endArray
,两者可以相互嵌套,注意配对即可。beginArray
后不可以调用name
方法,同样beginObject
后在调用value
之前必须要调用name
方法。
三、 使用GsonBuilder导出null值、格式化输出、日期时间
一般情况下Gson
类提供的 API已经能满足大部分的使用场景,但我们需要更多更特殊、更强大的功能时,这时候就引入一个新的类 GsonBuilder
。
GsonBuilder
从名上也能知道是用于构建Gson实例的一个类,要想改变Gson默认的设置必须使用该类配置Gson。
GsonBuilder用法
|
|
Gson在默认情况下是不动导出值null
的键的,如:
|
|
|
|
可以看出,email
字段是没有在json中出现的,当我们在调试是、需要导出完整的json串时或API接中要求没有值必须用Null时,就会比较有用。
使用方法:
|
|
格式化输出、日期时间及其它:
这些都比较简单就不一一分开写了。
|
|
注意:内部类(Inner Class)和嵌套类(Nested Class)的区别
这次文章就到这里,欢迎提问互动,如有不对的地方请指正。
你真的会用Gson吗?Gson使用指南(三)
本次的主要内容:
- 字段过滤的几种方法
- 基于
@Expose
注解 - 基于版本
- 基于访问修饰符
- 基于策略(作者最常用)
- 基于
- POJO与JSON的字段映射规则
一、字段过滤的几种方法
字段过滤Gson中比较常用的技巧,特别是在Android中,在处理业务逻辑时可能需要在设置的POJO中加入一些字段,但显然在序列化的过程中是不需要的,并且如果序列化还可能带来一个问题就是 循环引用 ,那么在用Gson序列化之前为不防止这样的事件情发生,你不得不作另外的处理。
以一个商品分类Category
为例。
|
|
一个大分类,可以有很多小分类,那么显然我们在设计Category
类时Category
本身既可以是大分类,也可以是小分类。
|
|
但是为了处理业务,我们还需要在子分类中保存父分类,最终会变成下面的情况
|
|
但是上面的parent
字段是因业务需要增加的,那么在序列化是并不需要,所以在序列化时就必须将其排除,那么在Gson
中如何排除符合条件的字段呢?下面提供4种方法,大家可根据需要自行选择合适的方式。
基于@Expose注解
@Expose提供了两个属性,且都有默认值,开发者可以根据需要设置不同的值。
@Expose
@Expose 注解从名字上就可以看出是暴露的意思,所以该注解是用于对处暴露字段的。可是我们以前用Gson的时候也没有@Expose 注解还是不正确的序列化为JSON了么?是的,所以该注解在使用new Gson()
时是不会发生作用。毕竟最常用的API要最简单,所以该注解必须和GsonBuilder
配合使用。
使用方法: 简单说来就是需要导出的字段上加上@Expose 注解,不导出的字段不加。注意是不导出的不加。
|
|
注:根据上面的图片可以得出,所有值为true
的属性都是可以不写的。
拿上面的例子来说就是
|
|
在使用Gson时也不能只是简单的new Gson()
了。
|
|
基于版本
Gson在对基于版本的字段导出提供了两个注解 @Since
和 @Until
,和GsonBuilder.setVersion(Double)
配合使用。@Since
和 @Until
都接收一个Double
值。
Since和Until注解
使用方法:当前版本(GsonBuilder中设置的版本) 大于等于Since的值时该字段导出,小于Until的值时该该字段导出。
|
|
注:当一个字段被同时注解时,需两者同时满足条件。
基于访问修饰符
什么是修饰符? public
、static
、final
、private
、protected
这些就是,所以这种方式也是比较特殊的。
使用方式:
|
|
使用GsonBuilder.excludeFieldsWithModifiers
构建gson,支持int
形的可变参数,值由java.lang.reflect.Modifier
提供,下面的程序排除了privateField
、 finalField
和staticField
三个字段。
|
|
到此为止,Gson提供的所有注解就还有一个@JsonAdapter
没有介绍了,而@JsonAdapter
将和TypeAdapter
将作为该系列第4篇也是最后一篇文章的主要内容。
基于策略(自定义规则)
上面介绍的了3种排除字段的方法,说实话我除了@Expose以外,其它的都是只在Demo用上过,用得最多的就是马上要介绍的自定义规则,好处是功能强大、灵活,缺点是相比其它3种方法稍麻烦一点,但也仅仅只是想对其它3种稍麻烦一点而已。
基于策略是利用Gson提供的ExclusionStrategy
接口,同样需要使用GsonBuilder
,相关API 2个,分别是addSerializationExclusionStrategy
和addDeserializationExclusionStrategy
分别针对序列化和反序化时。这里以序列化为例。
例如:
|
|
有没有很强大?
二、 POJO与JSON的字段映射规则
之前在你真的会用Gson吗?Gson使用指南(二) 属性重命名时 介绍了@SerializedName
这个注解的使用,本节的内容与上一次差不多的,但既然叫映射规则那么说的自然是有规律的情况。
还是之前User的例子,已经去除所有注解:
|
|
GsonBuilder
提供了FieldNamingStrategy
接口和setFieldNamingPolicy
和setFieldNamingStrategy
两个方法。
默认实现GsonBuilder.setFieldNamingPolicy
方法与Gson提供的另一个枚举类FieldNamingPolicy
配合使用,该枚举类提供了5种实现方式分别为:
FieldNamingPolicy | 结果(仅输出emailAddress字段) |
---|---|
IDENTITY | {“emailAddress”:”ikidou@example.com”} |
LOWER_CASE_WITH_DASHES | {“email-address”:”ikidou@example.com”} |
LOWER_CASE_WITH_UNDERSCORES | {“email_address”:”ikidou@example.com”} |
UPPER_CAMEL_CASE | {“EmailAddress”:”ikidou@example.com”} |
UPPER_CAMEL_CASE_WITH_SPACES | {“Email Address”:”ikidou@example.com”} |
自定义实现GsonBuilder.setFieldNamingStrategy
方法需要与Gson提供的FieldNamingStrategy
接口配合使用,用于实现将POJO的字段与JSON的字段相对应。上面的FieldNamingPolicy
实际上也实现了FieldNamingStrategy
接口,也就是说FieldNamingPolicy
也可以使用setFieldNamingStrategy
方法。
用法:
|
|
注意: @SerializedName
注解拥有最高优先级,在加有@SerializedName
注解的字段上FieldNamingStrategy
不生效!
你真的会用Gson吗?Gson使用指南(四)
本次文章的主要内容:
- TypeAdapter
- JsonSerializer与JsonDeserializer
- TypeAdapterFactory
- @JsonAdapter注解
- TypeAdapter与 JsonSerializer、JsonDeserializer对比
- TypeAdapter实例
- 结语
- 后期预告
一、TypeAdapter
TypeAdapter
是Gson自2.0(源码注释上说的是2.1)开始版本提供的一个抽象类,用于接管某种类型的序列化和反序列化过程,包含两个注要方法 write(JsonWriter,T)
和 read(JsonReader)
其它的方法都是final
方法并最终调用这两个抽象方法。
|
|
注意:TypeAdapter 以及 JsonSerializer 和 JsonDeserializer 都需要与 GsonBuilder.registerTypeAdapter
示或GsonBuilder.registerTypeHierarchyAdapter
配合使用,下面将不再重复说明。
使用示例:
|
|
UserTypeAdapter的定义:
|
|
当我们为User.class
注册了 TypeAdapter
之后,只要是操作User.class
那些之前介绍的@SerializedName
、FieldNamingStrategy
、Since
、Until
、Expos
通通都黯然失色,失去了效果,只会调用我们实现的UserTypeAdapter.write(JsonWriter, User)
方法,我想怎么写就怎么写。
再说一个场景,在该系列的第一篇文章就说到了Gson有一定的容错机制,比如将字符串 "24"
转成int 的24
,但如果有些情况下给你返了个空字符串怎么办(有人给我评论问到这个问题)?虽然这是服务器端的问题,但这里我们只是做一个示范。
int型会出错是吧,根据我们上面介绍的,我注册一个TypeAdapter 把 序列化和反序列化的过程接管不就行了?
|
|
注:测试空串的时候一定是"\"\""
而不是""
,""
代表的是没有json串,"\"\""
才代表json里的""
。
你说这一接管就要管两样好麻烦呀,我明明只想管序列化(或反列化)的过程的,另一个过程我并不关心,难道没有其它更简单的方法么? 当然有!就是接下来要介绍的 JsonSerializer与JsonDeserializer。
二、JsonSerializer与JsonDeserializer
JsonSerializer
和JsonDeserializer
不用像TypeAdapter
一样,必须要实现序列化和反序列化的过程,你可以据需要选择,如只接管序列化的过程就用 JsonSerializer
,只接管反序列化的过程就用 JsonDeserializer
,如上面的需求可以用下面的代码。
|
|
下面是所有数字都转成序列化为字符串的例子
|
|
注:registerTypeAdapter
必须使用包装类型,所以int.class
,long.class
,float.class
和double.class
是行不通的。同时不能使用父类来替上面的子类型,这也是为什么要分别注册而不直接使用Number.class
的原因。
上面特别说明了registerTypeAdapter
不行,那就是有其它方法可行咯?当然!换成registerTypeHierarchyAdapter 就可以使用Number.class
而不用一个一个的当独注册啦!
registerTypeAdapter与registerTypeHierarchyAdapter的区别:
registerTypeAdapter | registerTypeHierarchyAdapter | |
---|---|---|
支持泛型 | 是 | 否 |
支持继承 | 否 | 是 |
注:如果一个被序列化的对象本身就带有泛型,且注册了相应的TypeAdapter
,那么必须调用Gson.toJson(Object,Type)
,明确告诉Gson对象的类型。
|
|
三、TypeAdapterFactory
TypeAdapterFactory,见名知意,用于创建TypeAdapter的工厂类,通过对比Type
,确定有没有对应的TypeAdapter
,没有就返回null,与GsonBuilder.registerTypeAdapterFactory
配合使用。
|
|
四、@JsonAdapter注解
JsonAdapter
相较之前介绍的SerializedName
、FieldNamingStrategy
、Since
、Until
、Expos
这几个注解都是比较特殊的,其它的几个都是用在POJO的字段上,而这一个是用在POJO类上的,接收一个参数,且必须是TypeAdpater
,JsonSerializer
或JsonDeserializer
这三个其中之一。
上面说JsonSerializer
和JsonDeserializer
都要配合GsonBuilder.registerTypeAdapter
使用,但每次使用都要注册也太麻烦了,JsonAdapter
就是为了解决这个痛点的。
使用方法(以User为例):
|
|
使用时不用再使用 GsonBuilder
去注册UserTypeAdapter
了。
注:@JsonAdapter
仅支持 TypeAdapter
或TypeAdapterFactory
|
|
注意:JsonAdapter
的优先级比GsonBuilder.registerTypeAdapter
的优先级更高。
五、TypeAdapter与 JsonSerializer、JsonDeserializer对比
TypeAdapter | JsonSerializer、JsonDeserializer | |
---|---|---|
引入版本 | 2.0 | 1.x |
Stream API | 支持 | 不支持*,需要提前生成JsonElement |
内存占用 | 小 | 比TypeAdapter 大 |
效率 | 高 | 比TypeAdapter 低 |
作用范围 | 序列化 和 反序列化 | 序列化 或 反序列化 |
六、TypeAdapter实例
注:这里的TypeAdapter泛指TypeAdapter
、JsonSerializer
和JsonDeserializer
。
这里的TypeAdapter 上面讲了一个自动将 字符串形式的数值转换成int型时可能出现 空字符串的问题,下面介绍一个其它读者的需求:
服务器返回的数据中data字段类型不固定,比如请求成功data是一个List,不成功的时候是String类型,这样前端在使用泛型解析的时候,怎么去处理呢?
其实这个问题的原因主要由服务器端造成的,接口设计时没有没有保证数据的一致性,正确的数据返回姿势:同一个接口任何情况下不得改变返回类型,要么就不要返,要么就返空值,如null、[],{}。
但这里还是给出解决方案:
方案一:
|
|
方案二:
|
|
要注意的点:
- 必须使用
registerTypeHierarchyAdapter
方法,不然对List的子类无效,但如果POJO中都是使用List,那么可以使用registerTypeAdapter
。 - 对于是数组的情况,需要创建一个新的Gson,不可以直接使用context,不然gson又会调我们自定义的
JsonDeserializer
造成递归调用,方案二没有重新创建Gson,那么就需要提取出List中E的类型,然后分别反序列化适合为E手动注册了TypeAdaper的情况。 - 从效率上推荐方案二,免去重新实例化Gson和注册其它TypeAdapter的过程。
结语
Gson系列总算是完成了,感觉写得越来越差了,我怕我写得太啰嗦,也不能总是大片大片的贴代码,所以可能有的地方写得并不详细,排版也不美观,但都些都不重点,重点是Gson里我们能用上的都一一介绍一遍,只要你确确实实把我这几篇文章上的内容都学会的话,以后Gson上的任何问题都不再是问题,当然可能很多内容对于实际的开发中用的并不多,但下次有什么疑难杂症就难不倒你了。
本系列不提供Demo源码,最重要的是自己实验。
写一篇文章还是要花不少时间和精力,要写示例、调式、组织语言、码字等等,加上关注的人在慢慢的增加的同时既给了我动力也给我不少压力,如有纰漏或者更好的例子都可以和我交流。