使用Gson解析data class引发的一点思考

Gson是Android解析Json的老牌子了,它的使用和原理也被大家研究的极其透彻了,可以说这是一个相当成熟的库。但是伴随kotlin的普及,有一个问题也越发明显地暴露了出来。

kotlin里有一个 data class 的概念,倒不是什么“黑科技”的东西,但是确实相当好用,它会自动生成hashcode、equals以及toString等方法,都是对于一个bean来说很重要的方法。但是这么好用的东西在和gson一起使用时就出现了一点意外。让我们看下边的例子:

// 定义
data class TestBean(
    val name: String,
    val age: Int
)

// 数据
val json = """
            {"name":null,"age":null}
        """.trimIndent()

// 解析
val bean = gson.fromJson(json, TestBean::class.java)

// 输出
TestBean(name=null, age=)

把json换成 {} 或 {"name":null} 或 {"age":null},甚至 {"age":0} 都不会影响输出结果。也就是说,当gson解析data class时,kotlin的null-safe失效了。

其实这个问题不是data class造成的,问题主要在null-safe,只是data class和gson打交道最多而已。当然也不能怪gson,谁让gson火起来的时候kotlin还没多少知名度呢。

追溯问题产生原因

遇到问题自然要追踪源码了,想必很多人这样试过,最终都会定位到 ReflectiveTypeAdapterFactory.java 这个类中。为了节约大家的时间,这里把相关的部分贴出来:

public final class ReflectiveTypeAdapterFactory implements TypeAdapterFactory {
  // ...

  @Override public <T> TypeAdapter<T> create(Gson gson, final TypeToken<T> type) {
    // ...
    ObjectConstructor<T> constructor = constructorConstructor.get(type);
    return new Adapter<T>(constructor, getBoundFields(gson, type, raw));
  }

  private ReflectiveTypeAdapterFactory.BoundField createBoundField(
      final Gson context, final Field field, final String name,
      final TypeToken<?> fieldType, boolean serialize, boolean deserialize) {
    // ...

    return new ReflectiveTypeAdapterFactory.BoundField(name, serialize, deserialize) {
      // ...
      @Override void read(JsonReader reader, Object value)
          throws IOException, IllegalAccessException {
        Object fieldValue = typeAdapter.read(reader);
        if (fieldValue != null || !isPrimitive) {
          field.set(value, fieldValue);
        }
      }
    };
  }

  // ...

  public static final class Adapter<T> extends TypeAdapter<T> {
    // ...

    @Override public T read(JsonReader in) throws IOException {
      if (in.peek() == JsonToken.NULL) {
        in.nextNull();
        return null;
      }

      T instance = constructor.construct();

      try {
        in.beginObject();
        while (in.hasNext()) {
          String name = in.nextName();
          BoundField field = boundFields.get(name);
          if (field == null || !field.deserialized) {
            in.skipValue();
          } else {
            field.read(in, instance);
          }
        }
      } 
      // ...
      return instance;
    }

  }
}

这里有两处需要我们关注,第一处就是 T instance = constructor.construct(); 这个 constructor 是一个 ObjectConstructor 对象,在 ConstructorConstructor 类里可以找到它的实现:

public final class ConstructorConstructor {
  // ...

  public <T> ObjectConstructor<T> get(TypeToken<T> typeToken) {
    final Type type = typeToken.getType();
    final Class<? super T> rawType = typeToken.getRawType();

    // first try an instance creator

    @SuppressWarnings("unchecked") // types must agree
    final InstanceCreator<T> typeCreator = (InstanceCreator<T>) instanceCreators.get(type);
    if (typeCreator != null) {
      return new ObjectConstructor<T>() {
        @Override public T construct() {
          return typeCreator.createInstance(type);
        }
      };
    }

    // ...

    ObjectConstructor<T> defaultConstructor = newDefaultConstructor(rawType);
    if (defaultConstructor != null) {
      return defaultConstructor;
    }

    ObjectConstructor<T> defaultImplementation = newDefaultImplementationConstructor(type, rawType);
    if (defaultImplementation != null) {
      return defaultImplementation;
    }

    // finally try unsafe
    return newUnsafeAllocator(type, rawType);
  }

Gson 实例化对象分为四种情况:

  1. 使用我们自定义的 InstanceCreator,可以在初始化时加入它;
  2. 使用默认构造器,也就是无参构造函数;
  3. 如果是 Collection 或 Map,则返回对应的对象;
  4. 使用 UnSafe。

自定义 InstanceCreator 不现实,在这个问题上有多少 data class,就得准备多少 InstanceCreator。Collection 或 Map 也排除了,我们要处理的是对象。也就是说只有方式 2 和 4 可用,我们没有提供默认构造器,所以 Gson 使用了 UnSafe 这种手段。我们这里不追究 UnSafe 是什么,只要确认使用手机号转让地图UnSafe,就会产生上述结果就好了,不过有一句必须注意,它不会走我们的构造器

第二处需要注意的就是为什么 String 被赋值为 null,但 Int 没有问题?这个玄机就在 createBoundField 方法里,我们再贴一遍:

private ReflectiveTypeAdapterFactory.BoundField createBoundField(
      final Gson context, final Field field, final String name,
      final TypeToken<?> fieldType, boolean serialize, boolean deserialize) {
    // ...

    return new ReflectiveTypeAdapterFactory.BoundField(name, serialize, deserialize) {
      // ...
      @Override void read(JsonReader reader, Object value)
          throws IOException, IllegalAccessException {
        Object fieldValue = typeAdapter.read(reader);
        // 如果有值,或者不是 Primitive 类型,就赋值
        if (fieldValue != null || !isPrimitive) {
          field.set(value, fieldValue);
        }
      }
    };
  }

if (fieldValue != null || !isPrimitive) 在这里起了很大作用,像 int、char、boolean 以及对应的包装类等都属于基本类型,条件不成立所以不会赋值,但字符串和普通对象不是基本类型,于是就发生了一开始我们看到的现象。

如何解决

现在是解决问题的时候了,一个自然的想法是避免 UnSafe,只要提供默认构造器即可。让我们试试看:

data class TestBean2(val name : String = "", val age : Int = )

@Test
fun deserializeWithDefaultConstructor() {
    val json1 = """
        {}
    """.trimIndent()
    val bean1 = gson.fromJson(json1, TestBean2::class.java)
    println(bean1)

    val json2 = """
        {"name":null}
    """.trimIndent()
    val bean2 = gson.fromJson(json2, TestBean2::class.java)
    println(bean2)

    val json3 = """
        {"age":null}
    """.trimIndent()
    val bean3 = gson.fromJson(json3, TestBean2::class.java)
    println(bean3)

    val json4 = """
        {"age":0}
    """.trimIndent()
    val bean4 = gson.fromJson(json4, TestBean2::class.java)
    println(bean4)
}

输出的结果是这样的:

TestBean2(name=, age=)
TestBean2(name=null, age=)
TestBean2(name=, age=)
TestBean2(name=, age=)

看起来好了很多,只有 json 返回了 name=null 才会出现问题,这说明我们解决了问题一,但没解决问题二。gson正确地拿到了对象,随后又把 null 赋值给了 name,而且是用反射强行赋值的。如何解决问题二,反而成为了关键。

使用默认构造器是比较常见的解决方式,但当json显式返回null时该问题依然存在,所以还需要进一步处理。

既然使用默认值不管用,那么声明所有字段为可空 ? 类型就可以很简单地规避这个问题。但还需要考虑另一个问题:fail-fast,也就是快速失败。Json里的数据也许大部分是可空的,但总有几个字段是不可空的,这是由业务本身决定的,例如一个用户的uid明显不能为空。而使用可空参数就可能让一个空的uid“混”进来,在后续操作中引发一连串的错误。当然使用默认参数也有同样的问题。

在可空参数的基础上,提供一个不可空的getter可以有效地避免以上问题,例如对data class做以下处理:

data class TestBean3(
    @SerializedName("name")
    private val _name: String?,
    val age: Int
) {
    val name: String
        get() = _name ?: "" // 返回默认值或者抛出异常
}

这是一个行之有效的方案,也是我认为当代码库和gson深度耦合后较好的解决方案,虽不能在解析时就发现问题,但也比使用之后出问题强的多。只不过这样一来比较繁琐,二来每个 bean 都会比原来大一些。

除此之外,square出品的moshi还提供了两种不同的思路,一种是使用kotlin-reflection,kotlin的反射和java不太一致,你需要依赖一个至少2.5M的jar文件,而且反射的性能肯定差一些。另一种方案是在编译时为每个data class生成TypeAdapter。要参考这两种方案,可以查看moshi的源码,地址是:moshi[1]。另外,kotlin官方也提供了自己的解析库,它更考虑了kotlin本身的全部特性,这个库是kotlinx.serialization[2]。JakeWharton也为之增加了对应的retrofit converter:retrofit2-kotlinx-serialization-converter[3]

也就是说,如果可以摆脱gson,使用moshi或serialization在kotlin编程时可以获得更好的体验。若要使用gson,要么按照上述方式使用两个变量实现非空校验,要么参考moshi的做法自己写一套gson的实现。(其实是重复造*了,若无必要不建议这样操作==!)

我的思考

gson是谷歌出品的解析库,kotlin又是谷歌力推的开发语言,中间出现这样的不相容问题的确出乎所料,但作为开发者应当总有自己的应对之法。现在的项目大多使用Retrofit进行网络请求,json的转换也是通过ConverterFactory完成的,其他需要手动解析json的地方也可以作简单的封装,而不是随用随创建Gson对象,因此项目本身对gson的依赖并不强烈。如果项目和gson发生了深度耦合,就应该考虑下自己写代码时是不是太随意了一些?

另外一点是将data class全部声明为可空 ? 类型只能算是一种临时方案,因为问题的根源在gson不兼容kotlin特性,而不是data class出现了问题。解决问题应该从根源出发,而不是破坏其余部分的结构,造成问题范围扩大,也是设计代码时应该遵守的原则之一。

上一篇:Gson toJson()的使用


下一篇:Java(26):GSON - JsonParser对响应数据解析的封装