关于在使用gson解析json时建模与规范冲突的问题

Android中为什么提倡使用gson开源库而非Android自带的json库(其实就是org.json开源库)?
从我个人的角度认为使用gson不仅仅是简洁的API非常迷人, 更主要的是很容易形成面向对象的风格, 不是说org.json就不能形成这种风格, 而是思维方式不易转变, 就像使用c语言写成面向对象风格的代码是完全可能的, 比较成功的如gtk+, 但是一般普通初中级的程序员要形成这样的思维方式不太容易.
使用gson最好的做法是服务端和客户端沟通后建模, 模型就是json的内容和格式, 虽然gson支持使用Object.class作为解析依据(此时将产生一个有序Map<String, Object>子类)也还OK, 但是根据json格式建一个类是通常的做法, json格式有变化改起来也方便.

使用gson的缺点是需要额外加入接近100k的jar包, 而且根据json格式建的类需要声明不能被proguard混淆, 因为gson是基于反射, 所以有可能也可能没有(我曾经因怀疑为什么Google没有使用自己的gson库而使用org.json, 做过两者的测试, 几乎没有毫秒级别的差异)性能的薛微损耗, 但是我认为比起这点损耗, 更为重要的是一个项目使用低廉的成本做稳健的事, 暂时跑一下话题:

(一个低风险的系统是由很多成熟细节的做法堆砌成的, 首先这些细枝末节如果不追究, 扩散的领域大了, 就是整体的下降, 且不好改正与维护, 一个较为富有经验的程序员相对而言比初出茅庐的程序员要握有更为成熟的做法, 但是这样的人多了, 成本相对也高, 有没有什么能规范出的成熟做法, 使得初出茅庐的程序员也能少走坑, 还能给项目减少不成熟的做法带来的风险呢, 本人从去年开始一直致力于这一方面, 虽然才疏学浅没能琢磨出更大的道理, 但是发现使用正确的编码风格(不是书写规范), 比如像eclipse一开始就考虑的"一切皆插件"的风格(这个例子还是不太合适, 这有点可能是架构思想)的早期确立是很重要的, 并使用鼓励和惩罚作为持续改进的必要依据坚持下去, 也可以采用风格一致成熟的第三方库推进这个事, 特别是有效的注解所带来的清晰风格和检查机制, 有时是大有裨益的)

现在主要谈一下相关的一个问题:
如果使用gson建模, 因为是反射, 需要保证字段名和json格式中的键保持一致, 因为json格式尤其书写要求, Android有其成员属性的命名约定, 服务端可能又是另一套编码规范, 而且有可能还有照顾到iOS的命名风格, 这样有可能为将就非Android阵营导致无法遵守Android的命名约定, 这个我觉得从两个方面考虑:
(1)区分类和结构体, 正常的情况下在json对应类里做方法逻辑的可能性不高, 换句话说, 它更像一个数据载体(我称为结构体或实体类), 而不是通过任何服务的类, 这种情况下是否遵守Android对属性的命名约定, 我觉得也可以(见第二条)也可不必, 对于一个通过服务的类而言, 如果需要公开属性, 那使用javabean的风格, 私有化属性, 提供getter-setter是很必要的, 因为说不定哪天就需要加锁权限校验等等, 对于承载数据的结构体类, 我倾向于不做javabean, 而是公开属性本身, 如果能做出不可变类那就更好些, 类似的, 如果像我一样将类本身分成结构体, 功能服务, 委托代理, 辅助等等区分对待的话, 不和谐的声音也能接受, 因为书写不会影响风险, 而且书写风格和书写语义是否表达清楚是两回事;
(2)使用@serializedname告诉gson那些键名, 还是使用Android的命名约定 ;