讀書筆記5-數據存儲篇

本系列博文 基因而前微信高級工程師張紹文專欄 《Android開發高手課》的讀書筆記。

文章所寫內容是本人讀完的感悟,須要原文的朋友請自行購買。

存儲優化篇

Android分區

分區簡單來講就是將設備中的存儲劃分爲一些互不重疊的部分，每一個部分均可以單獨格式化，用做不一樣的目的。

• /system: 操做系統預留,用來存儲系統文件和框架的,系統升級和恢復時會擦除這一整塊分區
• /data: 用來存儲用戶數據的地方,手機上恢復出廠設置的那個操做就只會擦除這部分數據
• /cache: 系統升級或者恢復時的備用分區
• /vendor: 用來存放手機廠商對Android系統的修改
• /storge: 內置或者外置的sdcard

數據存儲須要考慮哪些要素

數據存儲就是把特定的數據結構轉化成能夠被記錄和還原的格式，這個數據格式能夠是二進制的，也能夠是 XML、JSON、Protocol Buffer 這些格式。

在選擇數據存儲的時候須要考慮的要素

數據存儲的選項

• SharedPreferences
• ContentProvider
• 文件
• 數據庫

SharedPreferences

使用場景

用於存儲一些很是簡單,輕量的數據。

優勢

• 系統支持,使用簡單
• 兼容性強

缺點

• 跨進程不安全
• 加載緩慢。SharedPreferences 文件的加載使用了異步線程，並且加載線程並無設置線程優先級，若是這個時候主線程讀取數據就須要等待文件加載線程的結束
• 全量寫入。不管是調用 commit() 仍是 apply()，即便咱們只改動其中的一個條目，都會把整個內容所有寫到文件。並且即便咱們屢次寫入同一個文件，SP 也沒有將屢次修改合併爲一次，這也是性能差的重要緣由之一。

基於以上緣由,各大公司都會有對應的一個替代的存儲方案,好比微信的MMKV

ContentProvider

使用場景

跨進程,跨應用程序之間的大數據量交互,整體來講ContentProvider的總體框架仍是不錯的,目前市面上好像也沒有什麼自研的架構替代。

須要注意的點

ContentProvider 的生命週期默認在 Application onCreate() 以前，並且都是在主線程建立的。咱們自定義的 ContentProvider 類的構造函數、靜態代碼塊、onCreate 函數都儘可能不要作耗時的操做，會拖慢啓動速度。

對象的序列化

Serializable

java原生的序列化機制,其自己是經過 ObjectInputStream 和 ObjectOutputStream 來實現的,因爲在序列化過程當中使用了大量的反射和臨時變量使得性能降低,文件體積變大。

須要注意的點

• 不被序列化的字段。類的 static 變量以及被聲明爲 transient 的字段，默認的序列化機制都會忽略該字段，不會進行序列化存儲。固然咱們也可使用進階的 writeReplace 和 readResolve 方法作自定義的序列化存儲。
• serialVersionUID。在類實現了 Serializable 接口後，咱們須要添加一個 Serial Version ID，它至關於類的版本號。這個 ID 咱們能夠顯式聲明也可讓編譯器本身計算。一般我建議顯式聲明會更加穩妥，由於隱式聲明假如類發生了一點點變化，進行反序列化都會因爲 serialVersionUID 改變而致使 InvalidClassException 異常。
• 構造方法。Serializable 的反序列默認是不會執行構造函數的，它是根據數據流中對 Object 的描述信息建立對象的。若是一些邏輯依賴構造函數，就可能會出現問題，例如一個靜態變量只在構造函數中賦值，固然咱們也能夠經過進階方法作自定義的反序列化修改。

Parcelable

主要解決Serializable性能低下的問題。

使用Parcelable比Serializable須要多添加一些自定義代碼，正是由於這些代碼,使得Parcelable在序列化的時候不須要採用大量反射這種耗時的行爲,從而提升性能。

須要注意的點

使用Parcelable進行永久存儲的話,會存在一些問題。

• 系統版本的兼容性。因爲 Parcelable 設計本意是在內存中使用的，咱們沒法保證全部 Android 版本的Parcel.cpp實現都徹底一致。若是不一樣系統版本實現有所差別，或者有廠商修改了實現，可能會存在問題。
• 數據先後兼容性。Parcelable 並無版本管理的設計，若是咱們類的版本出現升級，寫入的順序及字段類型的兼容都須要格外注意，這也帶來了很大的維護成本。

通常來講，若是須要持久化存儲的話，通常仍是不得不選擇性能更差的 Serializable 方案。

Serial

Twitter開源的Serial保留了Serializable和Parcelable的大部分優勢

數據的序列化

Serial 性能看起來還不錯，可是對象的序列化要記錄的信息仍是比較多，在操做比較頻繁的時候，對應用的影響仍是很多的，這個時候咱們能夠選擇使用數據的序列化。

JSON

優勢

• 相比對象序列化方案，速度更快，體積更小。
• 相比二進制的序列化方案，結果可讀，易於排查問題。
• 使用方便，支持跨平臺、跨語言，支持嵌套引用。

市面上可用的框架有Android自帶的JSON庫,Google的Gson,阿里的FastJson,美團的MSON

總的來講Gson的兼容性最好,數據量極大時,FastJson的性能最佳。

Protocol Buffers

二進制序列化方案,數據量龐大的時候性能優於JSON,

數據庫優化

推薦使用自帶的SQLite,Realm或者Google的LevelDB。

這部份內容在張老師文中提到的可能是線程併發,索引優化,page和緩存處理等。比較深,這裏就不提了。