[[177050]]

鮑協(xié)浩，小米MIUI部門， MIUI基礎(chǔ)應(yīng)用組通訊錄開發(fā)負(fù)責(zé)人。

問題現(xiàn)象

在 Android 業(yè)務(wù)同步的邏輯代碼中，使用到了 JSONObject 來解析服務(wù)端的 JSON 數(shù)據(jù)。同時本地因為業(yè)務(wù)新增需求的緣故，在本地數(shù)據(jù)庫中使用 JSONObject 緩存了包括水位等同步相關(guān)的信息，其中，水位值是 Long 型。但近期發(fā)現(xiàn)同步過程中下一次同步時，傳遞給服務(wù)器的水位并不是上一次服務(wù)器返回的新水位，而是相差一些。以 301028292893495297L 為例，服務(wù)器返回這個水位之后，下次客戶端上傳的水位是 301028292893495296L，差值為 -1。

問題排查

通過反復(fù)排查代碼邏輯，發(fā)現(xiàn)水位從服務(wù)端返回到下次請求之間，只經(jīng)過了以下轉(zhuǎn)換：

認(rèn)真閱讀代碼不難發(fā)現(xiàn)，Long 型的水位值保存在 JSON 對象中的時候被轉(zhuǎn)成了 String 型，而在讀取的時候又當(dāng)作是 Long 型來處理。所以就會有精度缺失的問題嗎?馬上參考 JSONObject 的文檔：

認(rèn)真閱讀代碼不難發(fā)現(xiàn)，Long 型的水位值保存在 JSON 對象中的時候轉(zhuǎn)成了 String 型，而在讀取的時候又當(dāng)作是 Long 型來處理。因此會有精度缺失的問題，參見如下 JSONObject 的文檔：

由此可見，在讀取 JSON 對象的某個值時，如果原先是 String 型，讀取的時候當(dāng)作是 Long 型，是會將 String 型通過 Double 進(jìn)行解析的，所以在值超過 2^52 時會有精度缺失的問題。于是，遇到的問題就可以解釋了。以下是 Double 的存儲格式規(guī)范：

其中，Double 和 Long 的精度測試代碼很簡單(輸入?yún)?shù)可以提供例如 301028292893495297L 這樣超過 2^52 的 long 值，會發(fā)現(xiàn)其返回值不為 0)：

也就是說，在讀取 JSON 對象的某個值時，如果原先是 String 型，讀取的時候當(dāng)作是 Long 型，是會將 String 型通過 Double 進(jìn)行解析的，所以在值超過 2^52 時會有精度缺失的問題。

另外，關(guān)于 JSON 對象中的值是 Long 型還是 String 型，其實比較容易被忽略。如果JSON 對象在使用 String 表示的時候，該值對應(yīng)處有引號就是 String 型，否則就是其他類型?？慈缦碌?2 個測試用例就一目了然：

Double 和 Long 的精度測試代碼很簡單(輸入?yún)?shù)可以提供例如 301028292893495297L 這樣超過 2^52 的 long 值)：

知道了問題的根源，修復(fù)就一目了然了，在水位保存在 JSONObject 對象中時，應(yīng)該當(dāng)作 Long 型而不是 String 型來保存;亦或者在讀取的時候也當(dāng)作是 String 型，然后通過 Long.valueOf 等接口進(jìn)行解析。

另外，關(guān)于 JSON 對象中的值是 Long 型還是 String 型，其實比較容易被忽略。如果JSON 對象在使用 String 表示的時候，該值對應(yīng)處有引號就是 String 型。看如下的試用例就一目了然了：

類似的問題在網(wǎng)上隨意一搜，其實有許多人遇坑了，比如這個。

所以，盡管不能說這個庫的設(shè)計是很失敗的，但肯定不算是一個設(shè)計良好的庫。因為你無法直接從 API 名稱看出其內(nèi)在的潛在邏輯，容易導(dǎo)致使用者使用不當(dāng)。因此，經(jīng)驗教訓(xùn)就是：使用第三方庫的時候，能看 API 文檔就看 API 文檔，切不可望文生義。當(dāng)然，這個問題可能也僅限在 Android 中較老的代碼模塊，畢竟新的代碼都會使用 GSON 等類庫進(jìn)行 JSON 對象操作，也就不容易出現(xiàn)這樣的不易發(fā)現(xiàn)的問題了。

當(dāng)然，單就這個問題來看，其實是在新增業(yè)務(wù)邏輯的時候，沒有正確使用 JSONObject 對象的接口，Long 型的值不應(yīng)當(dāng)看成是 String 型進(jìn)行保存而又當(dāng)成是 Long 型來讀取，如果保存和讀取的接口保持對應(yīng)，也就不會出現(xiàn)問題了。不管怎么說，該問題的教訓(xùn)是在使用 JSONObject 相關(guān)接口時要倍加小心謹(jǐn)慎。

備注：Github 上***的 JSON-Java 庫沒有這個問題，可以放心使用。

問題解決

知道了問題的根源，修復(fù)就一目了然了，在水位保存在 JSON 對象中時，應(yīng)該當(dāng)作 Long 型而不是 String 型來保存;或者在讀取的時候也當(dāng)作是 String 型，然后通過 Long.valueOf 等接口進(jìn)行解析。

問題后話

類似的問題在網(wǎng)上隨意一搜，其實有許多人遇坑了，比如這個。所以，盡管不能說這個庫的設(shè)計是很失敗的，但肯定不算是一個設(shè)計良好的庫。因為你無法直接從 API 名稱看出內(nèi)在的潛在邏輯，導(dǎo)致使用不當(dāng)。因此，經(jīng)驗教訓(xùn)就是：使用第三方庫的時候，能看 API 文檔就看 API 文檔，切不可望文生義。

當(dāng)然，Github 上***的 JSON-Java 庫是沒有這個問題的。

【本文是51CTO專欄“小米開放平臺”的原創(chuàng)文章，“小米開放平臺”微信公眾號：xiaomideveloper】