Protostuff序列化时的注意事项

 Android Dalvik JVM 实现中的坑 

但是且慢， 这样的代码在Server端代码做Junit Test的时候， 和Android 本地的代码Test的时候做本地的Java 对象的序列化到字符串， 再反序列化回Object 都没有什么问题， 但是联调的时候出问题了， 无论怎么调试Android 客户端使用这个代码逻辑去反序列化都不能成功。开始我们怀疑是Http 协议传输的时候， 字符编码的问题， 并在这个上面打转了大半天的时间。 后来突然发现这个是Android JVM 实现中的一个坑。 也或者说ProtostuffRuntime 的没考虑到的Case。  在解释这个问题之前， 我们先看看ProtostuffRuntime 如何生成运行期的protobuf Schema的。 也就是RuntimeSchema.getSchema(typeClass)这里， 到底发生了什么。 它的基本流程是：

1.  获取当前typeClass 的所有Super Class2. 对SuperClass 调用 getDeclaredFields 方法获取Field 列表， 并做一些过滤( 比如transient 修饰的字段是需要过滤的)， 把这些Field 列表中field按顺序以 这样的键值对的形式放到HashMap中

3. 重复第二部， 从最根的SuperClass 一直做到当前的typeClass。

4. 然后根据HashMap进行编译出protobuf 的Schema。

我们发现问题出在第二步， Android 下getDeclaredFields 方法返回的Field 列表顺序和我们在类里面定义的不一样。 它是做过字母排序的。 我们知道Protobuf 的序列化中所需要的Schema 是对类下面的Field顺序强依赖的。而在我们的Server端的调式中， 我们发现我们的Field顺序是和我们在类中定义的是一样的。

StackOverflow 上也有类似的讨论, JDK 1.6 以上这个顺序才保证是和类定义中的顺序是一致的， 而在早期版本中这个顺序是没保证的， 是根据各JDK 的实现自己做的。 也就是说 ProtostuffRuntime  其实只能保证在JDK1.6 以上能正确运行。 更别说Android这样的非正统的JVM 系统了。
问题找到了， 那怎么解决呢？

 

4. 定制RuntimeSchema的生成逻辑

 

   这里要做的事情是需要把Android 的上最终push 到hashMap  中的顺序保证和Java 类中定义的顺序一样就可以了。 好吧， 这个只有借助Annotation了。

Java代码  

1.  @Retention(RetentionPolicy.RUNTIME)  
2. @Target({ ElementType.FIELD })  
3. public @interface FieldOrder {  
4.     public int order() default 0;  
5. }  

我们定义个这样的Annotation， 然后改写

 

Java代码  

1. static void fill(Map<String,java.lang.reflect.Field> fieldMap, Class<?> typeClass)  
2.   {  
3.       if(Object.class!=typeClass.getSuperclass())  
4.           fill(fieldMap, typeClass.getSuperclass());  
5.       List<java.lang.reflect.Field> fieldList = new ArrayList<java.lang.reflect.Field>();  
6.   
7.   
8.   
9.       for(java.lang.reflect.Field f : typeClass.getDeclaredFields())  
10.       {  
11.           int mod = f.getModifiers();  
12.           if(!Modifier.isStatic(mod) && !Modifier.isTransient(mod))  
13.               fieldList.add(f);  
14.   
15.       }  
16.   
17.       final String className = typeClass.getName();  
18.   
19.       Collections.sort(fieldList, new java.util.Comparator<java.lang.reflect.Field>(){  
20.   
21.           public int compare(java.lang.reflect.Field lField, java.lang.reflect.Field rField){  
22.   
23.               if(lField.getAnnotation(FieldOrder.class) == null || rField.getAnnotation(FieldOrder.class)==null)  
24.                    throw new RuntimeException("Class " + className + " " +  lField.getName() + " or " + rField.getName() + " not set order.");  
25.               return lField.getAnnotation(FieldOrder.class).order() - rField.getAnnotation(FieldOrder.class).order();  
26.   
27.           }  
28.       });  
29.   
30.       for(java.lang.reflect.Field f: fieldList){  
31.           fieldMap.put(f.getName(), f);  
32.       }  
33.   
34.   }  

 

上面的实例代码中Collections.sort改写后添加的逻辑， 也就是根据Annotation， 在使用field 列表put 到FieldMap 之前最一次根据Annotation 定义的顺序进行一次排序。

Java代码  

1. public class SearchObject {  
2.   
3.     @FieldOrder(order = 1 ) private int currentPage;  
4.   
5.     @FieldOrder(order = 2 ) private int pageSize;  
6.   
7. ....  

5. 反思Protobuf的应用场景

 

我们知道Protobuf 对兼容字段差异的兼容可以做到的是， 如果有一个Bean　Class　有１０个字段序列化方S方和反序列化方DS　方的字段， 假如有Bean　Class　在某一边做了升级，　添加了第１１　个field，　如果这第１１　个field　在field　列表的末尾，　那么是没问 题的。　如果在中间添加这个字段，　那将会导致在另一边无法做反序列化。

从上面第三节里面， 我们看Protobuf的生成Protobuf Schema的流程我们知道， 假如有个类ClassA　extends SuperClassA

如果ClassA 中有FieldA1, FieldA2. SuperClassA 中有FieldsSA1， FieldsSA2。 那么最终编译到Schema 中的顺序会是

FieldsSA1， FieldsSA2, FieldA1, FieldA2.    如果我们对SuperClassA上新增FieldSA3， 那么顺序会是  FieldsSA1， FieldsSA2, FieldsSA2, FieldA1, FieldA2. 如果另外一端因为Class 未升级， 那么编译的顺序还是FieldsSA1， FieldsSA2, FieldA1, FieldA2. 那么将会导致无法正确反序列化。

用一句话总结就是， 如果Super Class中新增字段了， 必须两端程序同时升级。 而如果在子类中新增字段， 并且增加在字段列表中的最后一个， 那么是不需要另外一端跟着升级的。


这里我们可以看到protobuf 的运行高效性所带来的一些问题。 相应的这类问题是不会存在在使用Json 格式转换服务上。