2016 Top 10 Android Library

過去的 2016 年，開源社區異常活躍，很多個人與公司爭相開源自己的項目，讓人眼花繚亂，然而有些項目只是曇花一現，有些項目卻持久創造價值，為開發者提供了極大的便利，這些終究由時間來判斷。今天，我就來整理一篇，我個人認為的 2016 年對 Android 開發有巨大幫助的，甚至改變了 Android 開發方式的開源庫，但是，僅限個人認為，不具有任何權威性。

1. RxJava

地址：ReactiveX/RxJava

2016 年 Android 界最火的莫過於 RxJava 了，如果你還不知道 RxJava，你所在公司，或者你所在的項目還沒有使用 RxJava，那真的是有點 out 了，RxJava 不僅大大簡化了代碼，甚至可以說改變了我們的開發方式。

RxJava 是一種函數式、響應式的非同步操作庫，它讓你的代碼更加簡潔，真正的讓你的代碼寫到爽！由於 RxJava 用過的都說好，基於此，GitHub 上衍生了一堆比如 RxAndroid、RxBus、RxPermission 等之類的開源庫，足以說明它的影響力。

關於 RxJava 的文章網上一大堆，它的使用方法與好處我就不多說了，請自行去搜索了解，總之，身為 Android 開發者，到現在你還不知道 RxJava，簡直了！

2. Retrofit

地址：square/retrofit

如果有人問我，Android 界最好用的網路請求庫是什麼？在之前可能會有人回答 android-async-http、Volley、OkHttp（準確說，OkHttp 是一個 http 請求客戶端） 之類的，但是 16 年過後，我會告訴你 Retrofit 是最好用的網路請求庫。

Retrofit 完全 RESTful 風格的 api 網路請求庫，解耦更徹底，源碼設計超多的設計模式，值得大家學習，另外擴展性非常好，支持各種配置來滿足你的需求，最最重要的是，如果你的項目使用了 RxJava，那麼 Retrofit 可以完美結合，我只能說 Prefect！再次驗證了那句話：Square 出品，必屬精品！

3. EventBus

地址：greenrobot/EventBus

試想這麼一個場景，在 A 頁面打開 B 頁面，然後 B 頁面打開了 C 頁面，C 頁面又打開了 D 頁面，而且還需要傳遞參數，在 D 頁面修改了一些信息，然後這些信息更新之後，A、B、C 頁面很可能都需要對應的進行數據更新，碰到這種需求該怎麼處理？

有人說用 startActivityForResult()，你可以試下，有多麼難處理，還有人想到用廣播，這個當然可以，因為廣播是全局的，主要進行註冊都可以通知到每一個頁面，但是我很不喜歡用廣播，每次用廣播都要走那一套流程，很麻煩，而且很重。

而如果你知道 Eventbus，那麼一切都非常的簡單。

EventBus 是一個事件管理平台，以事件驅動的方式來簡化事件傳遞邏輯，可以把它想像成輕量級的 BroadcastReceiver，不過，EventBus 並不是 16 年才開始進入大眾視野的，很早就開源了，只是這個庫太實用了，時至今日，它仍然很火，使用起來非常方便。

值得注意的是：EventBus 固然好用，但是不要過度使用，因為一旦你的代碼大量使用 EventBus，會致使代碼可讀性稍差，而且出了問題不太好定位。所以建議只在特定的場景使用，切莫貪杯！

4. Glide、Fresco

圖片載入可能跟網路請求一樣，基本是所有 App 開發必備的功能，選擇一款成熟穩定的圖片載入庫重要性不言而喻，目前主流的圖片載入有 Picasso、Glide、Fresco，Glide 是 Google 員工基於 Picasso 基礎上進行開發的，所以自然各方面比 Picasso 更有優勢，而且支持 Gif，所以推薦大家優先選擇 Glide 庫，官方地址：

bumptech/glide

如果你的項目需要大量使用圖片，比如是類似 Instagram 一類的圖片社交 App ，那麼推薦使用 Fresco。Fresco 是 Facebook 作品，關於內存的佔用優化更好，但是同時包也更大，門檻也更高，初級工程師不建議使用。官方地址：

facebook/fresco

這兩款圖片載入庫，基本算是在 16 年使用最多，被認可最高的兩個圖片載入庫了。

5. LeakCanary

地址：square/leakcanary

開發者最關心的除了完成功能外，其次就是會不會造成內存泄露了，其實檢測內存泄露在 Java 領域有很多種方法與工具，但是針對 Android 都不夠方便，而良心公司 Square 開源了一款針對 Android 平台的內存泄露檢測工具 LeakCanary，集成簡單，使用方便，平時測試的過程中就自動記錄了內存泄露的位置，甚至幫你定位到代碼級別，強烈推薦。

6. ButterKnife

地址：JakeWharton/butterknife

我想應該沒有人沒聽過這個庫了吧？ButterKnife 是 Android 之神 JakeWharton 的大作，已經開源了很長時間，然而在 2016 年它的使用熱度依然不減，它可以讓你避免無休止的 findViewById() 代碼，具體用法我就不多說了，使用起來比較簡單。

7. Realm

地址：Realm: Create reactive mobile apps in a fraction of the time

說到 Realm 不得不提到一個 ORM 的概念。何為 ORM 呢？ORM 是 Object Relation Mapping 的縮寫，翻譯過來就是對象關係映射。這是相對於資料庫的，我們知道 Android 中使用的資料庫是 SQLite，而且 Android SDK 自帶操作資料庫的介面，而實際我們在使用的過程往往需要把查詢的數據轉換到一個 Java Object，也就是所謂的 Model，比如一般是這樣：

操作起來是不是很麻煩？而且可讀性超差，而有了 ORM 我們寫代碼可能會是類似這樣：

查詢數據是這樣：

是不是非常方便？代碼寫起來更像是面向對象，而不是一個個的裸寫 SQL 了，這就是所謂的 ORM。

而 Android 界的 ORM 框架有很多，比如 GreenDao、SugarORM、ActiveAndroid 等等，但是我推薦大家的 ORM 框架以上都不是，是叫做 Realm。

Realm 是一種面向移動端的新型輕量資料庫，而且是開源的，跟 SQLite 完全不一樣，性能上秒殺 SQLite，支持 Java、Android、iOS 各平台，我們在實際項目中採用過，體驗下來各方面都很不錯，所以推薦大家嘗試下 Realm。

8. Dagger 2

地址：google/dagger

依賴注入的概念估計大家都聽過，不理解的不妨搜索了解下，Android 領域比較著名的依賴注入庫莫過於 Dagger 了，基於註解，使用起來異常方便。

Dagger 起初是 Square 開源的，後來 Google 在此技術上進行了改進與優化，去除了反射，編譯時進行依賴注入，性能上有大幅提升，取名 Dagger 2，Square 之前開源的 Dagger 已不建議使用。其實之前大家對 Dagger 的關注程度沒有那麼高，一般都是屬於中、高級工程師才會關注使用，但是 16 年 Android 的架構被提上日程，各種 MVP、MVVM、Clean 架構等討論的較多，而 Dagger 作為承載這些架構重要的一環被越來越多的開發者使用，所以 16 年我們看到 Dagger 的身影越來越多，所以，Dagger 被我列為 16 年還算是比較火，比較實用的 Top 10 Android Library。

9. android-architecture

地址：googlesamples/android-architecture

上面說了，16 年 Android 架構被越來越多的開發者關注，國內外關於架構的探討比較活躍，大家熟知的 MVC、MVP、MVVM、Clean 等，就在大家爭執哪個更好，Android 開發到底該怎樣架構的時候，Google 開源了一個 Android 架構的官方指導，涉及 mvp、mvp-loaders、databinding、mvp-clean、mvp-dagger、mvp-contentproviders、mvp-rxjava 等，分別在各自指定的分支下，有非常大的參考意義，可以算是 Android 界的一大步。

10. awesome-android-ui

地址：wasabeef/awesome-android-ui

Android 開發中除了我們以上用到的各種實用庫之外，我們往往還會涉及到各種 UI 效果的實現，對於移動開發，界面開發其中是很重要的一環，而 16 年針對 Android 開發有人開源整理了這麼一個庫，裡面網羅了所有你見過的、沒見過的各種 UI 效果，涉及 Material、Layout、Button、List、ViewPager、Dialog、Menu、Parallax、Progress 等等，而且有相對應的截圖、gif 展示，以後應對設計師各種效果的時候有很大的參考幫助作用。

以上就是我總結的，我個人認為的，在 2016 年的 Android 開發中，比較實用的、對你的開發有很大幫助的一些 Android Library，除了對你們的開發效率有提升之外，還能夠了解其原理，閱讀其優秀源碼，參考其代碼設計，是絕佳的一份學習資料，希望每個人在 2017 年都能在技術上取得很大進步！

本文原創發佈於微信公眾號 「googdev」，不止技術分享，還有更多扯淡，關注請慎重！

推薦閱讀：