这篇文章给大家分享的是有关android中使用JSONObject时需要注意避免什么问题的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
问题现象
在 Android 业务同步的逻辑代码中，使用到了 JSONObject 来解析服务端的 JSON 数据。同时本地因为业务新增需求的缘故，在本地数据库中使用 JSONObject 缓存了包括水位等同步相关的信息，其中，水位值是 Long 型。但近期发现同步过程中下一次同步时，传递给服务器的水位并不是上一次服务器返回的新水位，而是相差一些。以 301028292893495297L 为例，服务器返回这个水位之后，下次客户端上传的水位是 301028292893495296L，差值为 -1。
问题排查
通过反复排查代码逻辑，发现水位从服务端返回到下次请求之间，只经过了以下转换：
认真阅读代码不难发现，Long 型的水位值保存在 JSON 对象中的时候被转成了 String 型，而在读取的时候又当作是 Long 型来处理。所以就会有精度缺失的问题吗?马上参考 JSONObject 的文档：
认真阅读代码不难发现，Long 型的水位值保存在 JSON 对象中的时候转成了 String 型，而在读取的时候又当作是 Long 型来处理。因此会有精度缺失的问题，参见如下 JSONObject 的文档：
由此可见，在读取 JSON 对象的某个值时，如果原先是 String 型，读取的时候当作是 Long 型，是会将 String 型通过 Double 进行解析的，所以在值超过 2^52 时会有精度缺失的问题。于是，遇到的问题就可以解释了。以下是 Double 的存储格式规范：
其中，Double 和 Long 的精度测试代码很简单(输入参数可以提供例如 301028292893495297L 这样超过 2^52 的 long 值，会发现其返回值不为 0)：
也就是说，在读取 JSON 对象的某个值时，如果原先是 String 型，读取的时候当作是 Long 型，是会将 String 型通过 Double 进行解析的，所以在值超过 2^52 时会有精度缺失的问题。
另外，关于 JSON 对象中的值是 Long 型还是 String 型，其实比较容易被忽略。如果JSON 对象在使用 String 表示的时候，该值对应处有引号就是 String 型，否则就是其他类型。看如下的 2 个测试用例就一目了然：
Double 和 Long 的精度测试代码很简单(输入参数可以提供例如 301028292893495297L 这样超过 2^52 的 long 值)：
知道了问题的根源，修复就一目了然了，在水位保存在 JSONObject 对象中时，应该当作 Long 型而不是 String 型来保存;亦或者在读取的时候也当作是 String 型，然后通过 Long.valueOf 等接口进行解析。
另外，关于 JSON 对象中的值是 Long 型还是 String 型，其实比较容易被忽略。如果JSON 对象在使用 String 表示的时候，该值对应处有引号就是 String 型。看如下的试用例就一目了然了：
类似的问题在网上随意一搜，其实有许多人遇坑了，比如这个。
所以，尽管不能说这个库的设计是很失败的，但肯定不算是一个设计良好的库。因为你无法直接从 API 名称看出其内在的潜在逻辑，容易导致使用者使用不当。因此，经验教训就是：使用第三方库的时候，能看 API 文档就看 API 文档，切不可望文生义。当然，这个问题可能也仅限在 Android 中较老的代码模块，毕竟新的代码都会使用 GSON 等类库进行 JSON 对象操作，也就不容易出现这样的不易发现的问题了。
当然，单就这个问题来看，其实是在新增业务逻辑的时候，没有正确使用 JSONObject 对象的接口，Long 型的值不应当看成是 String 型进行保存而又当成是 Long 型来读取，如果保存和读取的接口保持对应，也就不会出现问题了。不管怎么说，该问题的教训是在使用 JSONObject 相关接口时要倍加小心谨慎。
备注：Github 上***的 JSON-Java 库没有这个问题，可以放心使用。
问题解决
知道了问题的根源，修复就一目了然了，在水位保存在 JSON 对象中时，应该当作 Long 型而不是 String 型来保存;或者在读取的时候也当作是 String 型，然后通过 Long.valueOf 等接口进行解析。
感谢各位的阅读！关于“android中使用JSONObject时需要注意避免什么问题”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
