這篇文章給大家分享的是有關(guān)android中使用JSONObject時需要注意避免什么問題的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

創(chuàng)新互聯(lián)長期為1000+客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為大冶企業(yè)提供專業(yè)的成都做網(wǎng)站、成都網(wǎng)站建設(shè)，大冶網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

問題現(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)換：

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

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

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

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

也就是說，在讀取 JSON 對象的某個值時，如果原先是 String 型，讀取的時候當作是 Long 型，是會將 String 型通過 Double  進行解析的，所以在值超過 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)該當作 Long 型而不是 String  型來保存;亦或者在讀取的時候也當作是 String 型，然后通過 Long.valueOf 等接口進行解析。

另外，關(guān)于 JSON 對象中的值是 Long 型還是 String 型，其實比較容易被忽略。如果JSON 對象在使用 String  表示的時候，該值對應(yīng)處有引號就是 String 型?？慈缦碌脑囉美鸵荒苛巳涣耍?/p>

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

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

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

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

問題解決

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

感謝各位的閱讀！關(guān)于“android中使用JSONObject時需要注意避免什么問題”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！