首先，先上一張圖稠屠，總體看一下峦睡，我的Android項目中用到的開源框架：
RxJava
我對它的定義是：RxJava本質(zhì)上是一個異步操作庫，是一個能讓你用極其簡潔的邏輯去處理繁瑣復雜任務的異步事件庫权埠。讓異步變得簡單榨了。
給 Android 開發(fā)者的 RxJava 詳解
RxAndroid
RxAndroid是RxJava的擴展，可以優(yōu)雅地處理異步請求攘蔽，多個線程切換跳轉(zhuǎn)龙屉。
EventBus
EventBus是一款針對Android優(yōu)化的發(fā)布/訂閱事件總線。簡化了應用程序內(nèi)各組件間满俗、組件與后臺線程間的通信叔扼。優(yōu)點是開銷小，代碼更優(yōu)雅漫雷，以及將發(fā)送者和接收者解耦。
圖片加載框架
Glide
Glide庫和Picasso庫有極大的相似性鳍咱，編碼風格也幾近相同降盹，不過Glide卻有著更為強大的功能。它在緩存處理方面有著很大的優(yōu)勢并且支持加載Gif動畫以及本地Video谤辜。Universal-ImagerLoader
Universal-ImagerLoader可以算是老牌最火的圖片加載庫了蓄坏，使用過這個開源庫的項目可以說是多的令人發(fā)指，即使到現(xiàn)在 GitHub 上他的 Star 數(shù)仍然是眾多圖片加載庫最多的丑念。
可惜的是該作者已經(jīng)停止了對該項目的維護涡戳。這就意味著以后任何的 bug 都不會修復，任何的新特性都不會再繼續(xù)開發(fā)脯倚，所以毫無疑問 UIL 不推薦在項目中使用了渔彰。Fressco
Fresco 是 Facebook 出品嵌屎，他是新一代的圖片加載庫，我們知道 Android 應用程序可用的內(nèi)存有限恍涂，經(jīng)常會因為圖片加載導致 OOM宝惰，雖然我們有各種手段去優(yōu)化，盡量減少出現(xiàn) OOM 的可能性再沧，但是永遠沒法避免尼夺，尤其某些低端手機 OOM 更是嚴重。而 Facebook 就另辟蹊徑炒瘸，既然沒法在 Java 層處理千扔，我們就在更底層的 Native 堆做手腳骑素。于是 Fresco 將圖片放到一個特別的內(nèi)存區(qū)域叫 Ashmem 區(qū)，就是屬于 Native 堆，圖片將不再占用 App 的內(nèi)存鹤树，Java 層對此無能為力，這里是屬于 C++ 的地盤贡翘，所以能大大的減少 OOM著角。Picasso
Picasso 是 Square 公司的大作，這個庫是我之前一直很喜歡的技俐，因為他不僅具備圖片加載應有盡有的強大功能乘陪，他的調(diào)用也是如此簡潔文藝：
Picasso.with(context).load("http://i.imgur.com/DvpvklR.png").into(imageView);
以上代碼就是給一個 ImageView 加載遠程圖片的一個示例，是不是很簡潔.
總結(jié)：
綜合來看雕擂，毫無疑問 Glide 與 Picasso 之間優(yōu)先推薦選擇 Glide啡邑，尤其是如果你的項目想要支持 Gif 動態(tài)圖，那更該選擇 Glide 井赌。
但是如果你的項目使用了 Square 公司的全家桶谤逼，如 Retrofit 或者 OkHttp ，那么搭配 Picasso 一起使用也不是不可仇穗，兼容性可能會更好些流部，占用體積也會少些。
對于一般的 App 使用 Fresco 未免有些大材小用了纹坐，大部分情況 Glide 都能滿足你的需求了枝冀，但是如果你的 App 中大量使用圖片，比如是類似 Instagram 一類的圖片社交 App 耘子，那么推薦使用 Fresco 果漾，雖然稍復雜，但是還是推薦使用 Fresco 谷誓，對提升你 App 的性能與體驗有不少幫助绒障，值得花時間去研究并應用到自己的 App 上來。
網(wǎng)絡請求框架
Volley
Volley 是 Google 官方出的一套小而巧的異步請求庫捍歪，該框架封裝的擴展性很強户辱，支持 HttpClient鸵钝、HttpUrlConnection，甚至支持 OkHttp.
而且 Volley 里面也封裝了 ImageLoader 焕妙，所以如果你愿意你甚至不需要使用圖片加載框架蒋伦，不過這塊功能沒有一些專門的圖片加載框架強大，對于簡單的需求可以使用焚鹊，對于稍復雜點的需求還是需要用到專門的圖片加載框架痕届。
Volley 也有缺陷，比如不支持 post 大數(shù)據(jù)末患，所以不適合上傳文件研叫。不過 Volley 設計的初衷本身也就是為頻繁的、數(shù)據(jù)量小的網(wǎng)絡請求而生璧针！OkHttp
我們知道在 Android 開發(fā)中是可以直接使用現(xiàn)成的 api 進行網(wǎng)絡請求的嚷炉，就是使用 HttpClient、HttpUrlConnection 進行操作探橱，目前 HttpClient 已經(jīng)被廢棄申屹，而 android-async-http 是基于 HttpClient 的，我想可能也是因為這個原因作者放棄維護隧膏。
而 OkHttp 是 Square 公司開源的針對 Java 和 Android 程序哗讥，封裝的一個高性能 http 請求庫，所以它的職責跟 HttpUrlConnection 是一樣的胞枕，支持 spdy杆煞、http 2.0、websocket 腐泻，支持同步决乎、異步，而且 OkHttp 又封裝了線程池派桩，封裝了數(shù)據(jù)轉(zhuǎn)換构诚，封裝了參數(shù)使用、錯誤處理等铆惑，api 使用起來更加方便唤反。可以把它理解成是一個封裝之后的類似 HttpUrlConnection 的一個東西鸭津，但是你在使用的時候仍然需要自己再做一層封裝，這樣才能像使用一個框架一樣更加順手肠缨。Retrofit
Retrofit的特點我個人認為是簡化了網(wǎng)絡請求流程逆趋，同時自己內(nèi)部對OkHtttp客戶端做了封裝，同時2.x把之前1.x版本的部分不恰當職責都轉(zhuǎn)移給OkHttp了(例如Log晒奕，目前用OkHttp的Interceptor來實現(xiàn))闻书，這樣的好處是職責清晰名斟，Retrofit做自己該做的事兒。
而且Retrofit提供不同的Json Converter實現(xiàn)（也可以自定義）魄眉，同時提供RxJava支持(返回Observable對象)砰盐，配合Jackson(或者Gson)和RxJava，再加上Dagger2坑律，你的效率至少可以提高一倍岩梳。
總結(jié)：
毫無疑問 Volley 的優(yōu)勢在于封裝的更好，而使用 OkHttp 你需要有足夠的能力再進行一次封裝晃择。而 OkHttp 的優(yōu)勢在于性能更高冀值，因為 OkHttp 基于 NIO 和 Okio ，所以性能上要比 Volley更快宫屠。
數(shù)據(jù)庫框架
Realm
數(shù)據(jù)庫Realm列疗，是用來替代sqlite的一種解決方案，它有一套自己的數(shù)據(jù)庫存儲引擎浪蹂，比sqlite更輕量級抵栈，擁有更快的速度，并且具有很多現(xiàn)代數(shù)據(jù)庫的特性坤次，比如支持JSON古劲，流式api，數(shù)據(jù)變更通知浙踢，自動數(shù)據(jù)同步,簡單身份驗證绢慢，訪問控制，事件處理洛波，最重要的是跨平臺胰舆，目前已有Java，Objective C蹬挤，Swift缚窿，React-Native，Xamarin這五種實現(xiàn)焰扳。
Realm for Android詳細教程
在Android中使用Realm作本地存儲-
GreenDao
GreenDAO是一個對象關(guān)系映射（ORM）的框架倦零，能夠提供一個接口通過操作對象的方式去操作關(guān)系型數(shù)據(jù)庫，它能夠讓你操作數(shù)據(jù)庫時更簡單吨悍、更方便扫茅。如下圖所示：
官網(wǎng)地址：http://greenrobot.org/greendao/
github：https://github.com/greenrobot/greenDAO
GreenDao 優(yōu)點：
1.性能高，號稱Android最快的關(guān)系型數(shù)據(jù)庫
2.內(nèi)存占用小
3.庫文件比較小育瓜，小于100K葫隙，編譯時間低，而且可以避免65K方法限制
4.支持數(shù)據(jù)庫加密 greendao支持SQLCipher進行數(shù)據(jù)庫加密
5.簡潔易用的API
GreenDao3.2.2的使用
Android數(shù)據(jù)存儲之GreenDao 3.0 詳解和常見錯誤解析 OrmLite
ORMLite是對象關(guān)系映射（Object Relational Mapping）數(shù)據(jù)庫的一種輕量級SQL數(shù)據(jù)庫的開發(fā)包（packages）躏仇。提供簡單易用的DAO恋脚。ORMLite官方主頁：http://ormlite.com
