使用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=0)

把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 = 0)

@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=0)
TestBean2(name=null, age=0)
TestBean2(name=, age=0)
TestBean2(name=, age=0)

看起来好了很多，只有 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。另外，kotlin官方也提供了自己的解析库，它更考虑了kotlin本身的全部特性，这个库是kotlinx.serialization。JakeWharton也为之增加了对应的retrofit converter：retrofit2-kotlinx-serialization-converter。

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

我的思考

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

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

我是飞机酱，如果您喜欢我的文章，可以关注我~

编程之路，道阻且长。唯，路漫漫其修远兮，吾将上下而求索。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 204,445评论 6赞 478
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,889评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 151,047评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,760评论 1赞 276
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,745评论 5赞 367
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,638评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,011评论 3赞 398
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,669评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,923评论 1赞 299
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,655评论 2赞 321
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,740评论 1赞 330
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,406评论 4赞 320
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,995评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,961评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,023评论 2赞 350
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,483评论 2赞 342