在 Android 中如果遇到需要長期把持的資料，會有三種方案可以選擇

• SharedPeference ：適合簡單、清量的 key-value 資料，例如 用戶ID、上一次登入時間這種
• File ：適合儲存複雜的格式，例如圖片、文章等等
• SQLite ：相信各位對 SQL 應該多少都有一點了解，那 SQLite 是一種在手機裏面很常見的 SQL ，主打輕量，和一般 SQL 用法大同小異，適合儲存比較複雜的結構化資料，例如部門成員或是圖片的路徑等等

沒有說誰好誰爛，只有適不適合的問題，例如不會希望把比較複雜的結構化資料存在 SharedPeference ，而會希望用 SQL 或是 Json File 的方式處理掉

接下來就一一介紹

SharedPreference

SharedPreference 通常會存在 /data/data/[app packageName]/shared_prefs/ 之下

那他的優點有

• xml檔案的儲存方式
• key-value 結構
• value 只會儲存小量的資料
• 無法儲存太複雜的行別,支援型別有：Boolean、Float、Integer、Long、String
• 每個 App 獨立擁有自己的 SharedPerferecne

File

File 的話就很直觀是檔案，不論是 圖片、影片、PDF、下載的APK 等等，都會是以 File 的型式儲存

講到 File 的儲存就要補充一下 Android 的 Storage ，在 Android 下， Storage 也分為三種，分別是

• Internal Storage
• Primary External Storage
• Secondary External Storage

Internal Storage

Internal Storage 是只要目前 App 能夠存取的區域，其他 App 或是使用者都不能直接接觸到的空間，路徑通常會是 data/data/[app packageName]

裏面會包含像是 App 的 Config 、SharedPreference 、SQLite 等等。因為這個空間每個 App 都會有一個，因此站在 Android OS 的角度，就不會劃分太多的空間給某個 App ，只會是比較重要的檔案才會存在這個空間裏面，其他比較大型的檔案就會希望存在 External Storage

另外因為這個空間只專屬給對應的 App 持有，因此當使用者把 App 刪掉時，這個空間裏面的資料自然就會跟著被回收掉

Primary External Storage

Primary External Storage 是 OS 從裝置的 Storage 劃分出來的一個區塊，專門儲存從 App 中產出的圖片、影片、音檔等等，在這個空間的檔案也是可以提供給其他程式做使用

例如拍照軟體會把照片存到相簿，而修圖軟體可以到相簿中取得照片修圖，修完的圖可以在存回相簿中，讓其他程式去取用

另外需要注意的一點是在 App 要使用 External Storage 的檔案時，需要先取得 External Storage Permission 才能夠存取喔

Secondary External Storage

因為手機以前的儲存空間都不大，因此人手一張 16G 的 SD 卡，才能在上學的時候偷偷聽音樂或看影片，那外接儲存空間都算是 Secondary External Storage， 目前很多手機容量越來越大再加上雲端空間就非常夠用，因此手機中也漸漸拿掉 SD card 插槽了（ 時代的眼淚...

SQLite

可能有些人會想說資料不都可以打 API 送到後端的 Database 做處理嗎？幹嘛在放一套資料在手機裏面，這樣不會很佔空間嗎？

其實這樣的看法對也不對，的確如果只是把 App 都做一種資料呈獻的手段，那其實 App 本身不需要握有太多數據，需要在打 API 去拿或是打 API 把生成出來的資料傳回去即可，但畢竟有些 App 是要考慮到使用者隱私或是要做到離線模式都能夠使用的，例如有些通訊軟體即使在沒有網路的狀態下，還是能看到一部份過去的聊天紀錄，這些可能就會是透過 SQLite 的方式暫且儲存起來，並且如果使用者在離線狀態下持續的發送訊息，那麼這些訊息會先 hold 在 SQLite 裏面，等到連上網路的時候在跟後端 Server 做 Sync ，因此手機裡面有 SQLite 還是非常重要的

那麼 SQLite 主要的優點就如同以下列出來的

• Android 內建支援，不需要安裝
• 每個 App 都有自己的 SQLite ，不能互相存取，具有隔離性
• 用法上和其他 Relational SQL Service 大同小異
• 儲存結構化數據

但 SQLite 因為追求小而巧，因此有省略掉一些部份，造成令人詬病的問題，例如

• 使用錯誤的 Column name 編寫了一個 SQL 查詢，但在編譯時無法發現，必須等到 Runtime 才會報錯
• 如果 SQLite 的架構做了修改，那就要手動更新受影響的 SQL 資料
• 需要使用大量樣板代碼（ Boilerplate Code ）在 SQL 和 POJO 之間進行轉換

因為以上的問題，因此 Google 在 I/O 2018 的時候發表 Andorid Jetpack 時，在 Jetpack 中推出了 Google 官方支援的 SQL ORM - Room ，Room 改正了幾項問題

• 編譯時會驗證 SQL 是否正確
• Room 將 SQLite 映射到 POJO ，而沒有使用樣板代碼
• Room 支援 SQL Migration
• 可以與 LiveData 、RxJava 等等強大的工具一起使用

看到這邊是不是很想要學 Room 了呢？

總結

總結一下今天的部份，今天是複習 Android 中三種資料儲存的方案，以及 Internal Storage 與 External Storage 的差別，並且在介紹 SQLite 的時候也順勢帶到了明天會介紹的 Room
那下面這張圖是 Google 給出的一張比較圖，幾乎所有上面提到的東西，這張圖都有概刮到，可以在看完上面在服用這張圖會更有感覺喔

如果內容有任何問題或錯誤，歡迎提出與指教

Reference

• https://medium.com/mindorks/using-room-database-android-jetpack-675a89a0e942
• https://developer.android.com/reference/androidx/core/content/FileProvider