2012-05-30 54 views
3

我無法選擇SQLite和SharedPreferences。在SharedPreferences中存儲「JSON.stringify」數據不好嗎?

我可以使用

JSON.parse(SharedPreferences.getString("data","qweqwe"); 

s.putString(key,JSON.stringify(JSONObject)); 

或者SQLite中創建一個新的,大的類來存儲我的(文本)數據。 (PS:JSON。*是我自己的班級)

什麼會更快,更好?

我知道SharedPreferences是針對大量結構化數據的「鍵值」數據SQLite。但在我的情況下存儲在SP中的JSON格式的數據和按鍵訪問會更容易。主要問題 - 它會更慢還是更快?優點和缺點?

+2

期待來自社區的意見,因爲我腦子裏有同樣的問題。 – dotty

+0

@dotty我的推理。關於SQLite:我需要創建新的類,我從URL獲得JSON數據,並且使用SQLite,我需要編寫兩倍的代碼來使用這些數據。關於SharedPreferences:我從URL加載數據,s.putString這個數據沒有任何操作,我使用JSON.parse我只能:JSON.parse(s.getString(「jsdata」,「qweqwe」)。equals(「qweqwe 「)?JSON.get(url):s.getString(」jsdata「,」qweqwe「))和一些用這些數據更新/操作的函數。 –

回答

2

我想到了這一點,並有一些練習。

因此,使用SQLite(在我的情況下)更好的是在SharedPreferences中使用JSON格式的字符串,因爲我只能從表中更新一兩行。隨着SharedPreferences我必須:

  1. 使用new JSONObject(sharedPreferences.getString("json_string","qweqwe");
  2. 一些操作與對象
  3. 編輯我的SharedPreferences。
  4. 調味你的口味
  5. 把我的JSONObject()。toString()方法返回到SharedPreferences。就這些。

恕我直言,這是更復雜的設備。 因爲它不能被調整

如果我不需要更新個別部分的數據,我寧願使用SharedPreferences,因爲對於靜態數據,我不需要更新,速度更快。

1

到目前爲止,我已經在幾個項目中使用了這種方法,沒有任何問題。但是使用SQLite數據庫肯定有幾個優點;特別是SQLite的版本/升級功能,以及強大的SQL查詢語言。如果您需要將數據遷移到新的存儲結構,則SQLite框架中的升級和onUpgrade回調會非常有用。

如果您保持簡單,JSON中的首選項可以非常快速且非常易於實現。在安全性方面,首選項比數據庫稍微更「暴露」,因爲它們只是存儲在xml中,但最終SQLite數據庫的數據庫文件以相同的方式存儲,並且在入侵期間也可以讀取。

我還沒有使用JSON/SharedPreferences的任何性能問題,但我也沒有做任何分析來測試這一點。我的想法是保持代碼簡單並且不會過早優化 - 如果出現性能問題,請在此時進行分析。

最終,我會說,以這種方式使用SharedPreferences本質上沒有任何問題。

2

一方面,這是一個稍微主觀的問題(而不是最適合的stackoverflow)。另一方面,從字面上看你的問題標題,客觀答案是「不,它不是不好」。

然而,這種推理有點主觀,因爲它取決於情況。

SharedPreferences類實際上是存儲在應用程序私有(內部)存儲中的文件的包裝器/幫助程序 - 據我瞭解,它是一個XML文件。基於這個事實,再次問自己......「在XML文件中保存JSON格式的字符串不好嗎?」?

當你在你的問題commen提到,使用SQLite數據庫將意味着編寫額外的代碼,而中SharedPreferences的優點是優先考慮文件是入店按名稱按任意延伸Context包括ApplicationActivity和Android類Service

+0

在desc我寫了更客觀的問題。 :)例如什麼更快? –

+0

@anony_root:恐怕我沒有任何更快的基準,而且這還是有點微不足道的,需要進行適當的測試。以任何一種方式保存單個簡短的JSON字符串可能只有幾毫秒的差異。保存數百(或數千)的長字符串可能會花費大量不同的時間。如果你有簡單的需求,那麼'SharedPreferences'可能是一種方法,因爲功能是內置於所有基於'Context'的類。 – Squonk

相關問題