Android數(shù)據(jù)庫ORM框架用法、源碼和性能比較分析
synchronized與lock 對象鎖、互斥鎖、共享鎖以及公平鎖和非公平鎖
ormlite
基于注解和反射的的方式,導(dǎo)致ormlite性能有著一定的損失(注解其實也是利用了反射的原理)
優(yōu)點：文檔較全面，社區(qū)活躍，有好的維護，使用簡單，易上手。
缺點：基于反射，效率較低
反射包括了一些動態(tài)類型，所以JVM無法對這些代碼進行優(yōu)化。因此，反射操作的效率要比那些非反射操作低得多。
GreenDao
greenDAO與上述兩種ORM框架不同，其原理不是根據(jù)反射進行數(shù)據(jù)庫的各項操作，而是一開始就人工生成業(yè)務(wù)需要的Model和DAO文件，業(yè)務(wù)中可以直接調(diào)用相應(yīng)的DAO文件進行數(shù)據(jù)庫操作，從而避免了因反射帶來的性能損耗和效率低下。
優(yōu)點：效率很高，插入和更新的速度是sqlite的2倍，加載實體的速度是ormlite的4.5倍。
文件較?。?lt;100K），占用更少的內(nèi)存 ，但是需要create Dao，操作實體靈活：支持get，update，delete等操作
另外GreenDao支持Protocol buffers協(xié)議數(shù)據(jù)的直接存儲 ，如果通過protobuf協(xié)議和服務(wù)器交互，不需要任何的映射。
缺點：
但是由于需要人工生成model和DAO文件，所以greenDAO的配置就略顯復(fù)雜。
Android Sqlite框架 GreenDao的源碼分析筆記
GreenDao源碼簡要分析
采用IdentityScope緩存key(主鍵)－model，加鎖
數(shù)據(jù)的操作緩存只有在load的時候緩存才去緩存查找是否存在，存在直接返回
Sqlite之主鍵亂序和GreenDao設(shè)計的坑
.db-journal該文件是sqlite的一個臨時的日志文件，主要用于sqlite事務(wù)回滾機制，在事務(wù)開始時產(chǎn)生，在事務(wù)結(jié)束時刪除；當程序發(fā)生崩潰或者系統(tǒng)斷電時該文件將留在磁上，以便下次程序運行時進行事務(wù)回滾。
在android采用的這種模式下，.db-journal文件是永久的留在磁盤上不會被自動清除的，如果沒有發(fā)生事務(wù)回滾那么.db-journal文件的大小為0，這樣就避免了每次生成和刪除.db-journal文件的開銷。
android 的數(shù)據(jù)庫系統(tǒng)用的是sqlite ，sqlite的每一個數(shù)據(jù)庫其實都是一個.db文件，它的同步鎖也就精確到數(shù)據(jù)庫級了，不能跟別的數(shù)據(jù)庫有表鎖，行鎖。
所以對寫實在有要求的，可以使用多個數(shù)據(jù)庫文件。[這也就是為什么IM在同步一萬個聯(lián)系人里，采用兩個數(shù)據(jù)庫的原因]
Realm
Realm是C++實現(xiàn)。當它用原生對象格式（native object format）來存儲數(shù)據(jù)時，這些對象不會帶著其語言特有的格式原封不動地存在磁盤上，而是通過C++引擎存儲在一個全局的表中。這使得Realm可以通過各種語言來訪問數(shù)據(jù)，還包括各種即時查詢。
相比關(guān)系數(shù)據(jù)庫，這種混合了對象和表的方式的優(yōu)勢在于它視圖查詢（graph query）更高效——甚至在相對老舊的智能手機上，查詢深度嵌套的對象圖也不會影響系統(tǒng)反應(yīng)速度。Realm發(fā)布的基準測試（benchmark）結(jié)果稱，在普通操作上，Realm的速度最快要達到原始的SQLite的10倍。
