一、前言

在技術面試的時候肯定都會問到使用了哪些第三方框架，為什么使用它而不用其他的。身邊朋友就有這樣的親身經歷：

面試官：你們項目中加載圖片都是用的什么框架？

面試者：Glide啊（內心竊喜）

面試官：為什么使用Glide而不用其他的？

面試者：(沉默10s)，Glide好啊，我比較喜歡。（內心不安）

面試官：…(能不能好好聊天了)

這篇博文主要就是針對平常使用到的框架做一個整理和分析其優劣。

為了從整體上進行把握，先來看看一個完整的APP整體架構。

二、APP的整體架構

從較高的層次將，一個APP的整體架構可以分為兩層：應用層和基礎框架層。

• 應用層：專注于行業領域的實現，例如金融、支付、地圖導航、社交等，它直接面向用戶，是用戶對產品的第一層感知。

• 基礎框架層：專注于技術領域的實現，提供APP公有的特性，避免重復制造輪子，它是用戶對產品的第二層感知，例如性能、穩定性等。

一個理想的APP架構，應該擁有如下特點：

• 支持跨平臺開發

• 具有清晰的層次劃分，同一層模塊間充分解耦，模塊內部符合面向對象設計六大原則

• 在功能、性能、穩定性等方面達到綜合最優

基于以上設計原則，我們可以看出APP架構圖，最上層是應用層，應用層以下都屬于基礎框架層，基礎框架層包括：組件層、基礎層和跨平臺層。

我們要討論的重點是基礎層，下面開始一步一步地闡述如何基于開源函數庫搭建屬于自己的一個基礎技術堆棧。

三、技術選型的考量點

首先要明確的是，我們選擇開源函數庫或者第三方SDK、一般需要綜合考慮一下幾個方面：

• 特性：提供的特性是否滿足項目的需求。

• 可用性：是否提供了簡潔便利的API，方便開發者集成使用。

• 性能：性能不能太差，否則項目后面性能優化會過不去，可能回出現需要替換函數庫的情況。

• 文檔：文檔應該比較齊全，且可讀性高。

• 技術支持：遇到問題或者發現BUG，是否能夠及時得到官方的技術支持是很重要的。

• 大小：引入函數庫會增加APK的大小，需要慎重抉擇。

• 方法數：如果函數庫方法數太多，積累起來會導致你的APP遇到64K問題，應該盡量避免。

四、日志記錄能力

日志記錄無論在服務端開發還是移動端開發，都是一個基礎且重要的能力，開發人員在代碼調試以及錯誤定位過程中，大多說都要依賴日志信息，一個簡潔靈活的日志記錄模塊是相當重要的。

Logger（https://github.com/orhanobut/logger） 是基于系統Log類基礎上進行的封裝，但新增了如下超贊的特性：

• 在Logcat中完美的格式化輸出，再也不用擔心和手機其他APP或者系統的日志信息相混淆了。

• 包含線程、類、方法信息，可以清楚地看到日志記錄的調用堆棧。

• 支持跳轉到源碼處。

• 支持格式化輸出JSON、XML格式信息。

Logcat截圖：

當然Logger也不是完備的，它雖然支持格式化輸出JSON、XML，但并不支持諸如List、Set、Map和數組等常見Java集合類的格式化輸出。如何解決呢？可以看下 LogUtils （https://github.com/pengwei1024/LogUtils）這個開源庫，它實現了Logger缺失的上述特性。

再者，Logger只支持輸出日志到Logcat，但項目開發中往往還存在將日志保存到磁盤上的需求，如何將兩者結合起來呢？這是可用 timber（https://github.com/JakeWharton/timber） 。

timber是JakeWharton開源的一個日志記錄庫，它的特點是可擴展的框架，開發者可以方便快捷的集成不同類型的日志記錄方式，例如，打印日志到Logcat、打印日志到文件、打印日志到網絡等，timber通過一行代碼就可以同時調用多種方式。

timber的思想很簡單，就是維護一個森林對象，它由不同類型的日志樹組合而成，例如，Logcat記錄樹、文件記錄樹、網絡記錄樹等，森林對象提供對外的接口進行日志打印。每種類型的樹都可以通過種植操作把自己添加到森林對象中，或者通過移除操作從森林對象中刪除，從而實現該類型日志記錄的開啟和關閉。

最終我們的日志記錄模塊將由timber+Logger+LogUtils組成，當然輪子找到了，輪子的兼容合并就得靠我們自己實現了，同時我們還得增加打印到文件的日志樹和打印到網絡的日志樹實現。

五、JSON解析能力

移動互聯網產品與服務器端通信的數據格式，如果沒有特殊需求的話，一般都使用JSON格式。Android系統也原生的提供了JSON解析的API，但是它的速度非常慢，而且沒有提供簡潔方便的接口來提高開發者的效率和降低出錯的可能。所以我們就開始找第三方開源庫來實現JSON解析，比較優秀的包括如下幾種。

1、gson

gosn 是Google出品的JSON解析函數庫，可以將JSON字符串反序列化對應的Java對象，或者反過來將Java對象序列化為對應的JSON字符串，免去了開發者手動通過JSONObject和JSONArray將JSON字段逐個進行解析的煩惱，也減少了出錯的可能性，增強了代碼的質量。使用gson解析時，對應的Java實體類無需使用注解進行標記，支持任意復雜Java對象包括沒有源代碼的對象。

2、jackson

jcakson 是Java語言的一個流行的JSON函數庫，在Android開發中使用時，主要包含三部分。

• jackson-core：JSON流處理核心庫。

• jackson-databind：數據綁定函數庫，實現Java對象和JSON字符串流的相互轉換。

• jackson-annotations：databind使用的注解函數庫。

由于jackson是針對Java語言通用的JSON函數庫，并沒有為Android優化定制過，因此函數保重包含很多非必要的API，相比其他的JSON函數庫，用于Android平臺會更顯著的增大最終生成的APK的體積。

3、Fastjson

Fastjson 是阿里巴巴出品的一個Java語言編寫的高性能且功能完善的JSON函數庫。它采用一種“假定有序快速匹配”的算法，把JSON Parse的性能提升到極致，號稱是目前Java語言中最快的JSON庫。Fastjson接口簡單易用，已經被廣泛使用在緩存序列化、協議交互、Web輸出、Android客戶端等多種應用場景。

由于是Java語言通用的，因此，以前在Android上使用時，Fastjson不可避免的引入了很多對于Android而言冗余的功能，從而增加了包大小，很多人使用的就是標準版的fastjson，但事實上，fastjson還存在一個專門為Android定制的版本 fastjson.android 。和標準版本相比，Android版本去掉了一些Android虛擬機dalvik不支持的功能，使得jar更小。

4、LoganSquare

LoganSquare 是近兩年崛起的快速解析和序列化JSON的Android函數庫，其底層基于jackson的streaming API，使用APT(Android Annotation Tool)實現編譯時注解，從而提高JSON解析和序列化的性能。官網上可以看到LoganSquare和gson、jackson databind的性能對比。

從性能方面看，LoganSquare是完勝gson和jackson的。如果和fastjson相比較，兩者應該是不相上下的。

再來看下jar包的大小：

• gson：232KB

• jackson：259+47+1229 = 1.5M

• Fastjson：417KB

• Fastjson.android：256KB

• LoganSquare：48+259 = 307KB

從性能和包大小綜合考慮，最終 我們會選擇Fastjson.android作為基礎技術堆棧中的JSON解析和序列化庫。

六、數據庫操作能力

無論是iOS還是Android，底層數據庫都是基于開源的SQLite實現，然后在系統層封裝成用于應用層的API。雖然直接使用系統的數據庫API性能很高，但是這些API接口并不是很方便開發者使用，一不小心就會引入Bug，而且代碼的視覺效果也不佳。為了解決這個問題，對象關系映射（ORM）框架出現了，比較好的有 ActiveAndroid，ormlite和greenDAO。

1、ActiveAndroid

ActiveAndroid 是一種Active Record風格的ORM框架，Active Record（活動目錄）是Yii,Rails等框架中對ORM實現的典型命名方式。它極大的簡化數據庫的使用，使用面向對象的方式管理數據庫，告別手寫SQL的歷史。每一個數據庫表都可以被映射為一個類，開發者只需使用類似save()或者delete()這樣的函數即可。

不過ActiveAndroid已經基本上處于維護階段了，最新的一個Release版本是在2012年發布的。

2、ormlite

ormlite 是Java平臺的一個ORM框架，支持JDBC連接、Spring和Android平臺。在Android中使用時，它包含兩部分。

• ormlite-core：核心模塊，無論在哪個平臺使用，都必須基于這個核心庫，是實現ORM映射的關鍵模塊。

• ormlite-android：基于ormlite-core封裝的針對Android平臺的適配器模塊，Android開發中主要跟這個模塊打交道。

與ActiveAndroid類似，ormlite也已經不是一個活躍的開源庫，最近一次Release版本是在2013年發布的。

3、greenDAO

greenDAO 是一個輕量級且快速的ORM框架，專門為Android高度優化和定制，它能夠支持每秒數千條記錄的CRUD操作。官網上給出一張性能對比圖：

縱軸表示每秒執行的操作數。而且greenDAO處在高度活躍中，最新Release版本是在2017年3月份發布的。

4、Realm

Realm 是一個全新的移動數據庫引擎，它既不是基于iOS平臺的Core Data，也不是基于SQLite，它擁有自己的數據庫存儲引擎，并實現了高效快速的數據庫構建操作，相比Core Data和SQLite，Realm操作要快很多，跟ORM框架相比就更不用說了。

Realm的好處如下：

• 跨平臺：Android和iOS已經是事實上的兩大移動互聯網操作系統，絕大多數應用都會支持這兩個平臺。使用Realm，Android和iOS開發者無需考慮內部數據的架構，調用Realm提供的API即可輕松完成數據的交換。

• 用法簡單：相比Core Data和SQLite所需的入門知識，Realm可以極大降低開發者的學習成本，快速實現數據庫存儲功能。

• 可視化操作：Realm為開發者提供了一個輕量級的數據庫可視化操作工具，開發者可以輕松查看數據庫中的內容，并實現簡單地插入和刪除等操作。

我們看下上述四種數據庫包大小：

• activeandroid：40KB

• greendao：100KB

• ormlite-android：57KB

• realm-android：4.2M

可以看出，前三個還是正常范圍，但Realm的大小一般項目可能無法接受。這是因為不同CPU架構平臺的 .so 文件增加了整個包的大小，由于arm平臺的so在其他平臺上面能夠以兼容模式運行的，雖然會損失性能，但是可以極大地減少函數庫占用的空間。因此，可以選擇只保留armeabi-v7a和x86兩個平臺的 .so 文件，直接刪除無用的 .so 文件，或者通過工程的build.gradle文件中增加 ndk abi 過濾，語句如下：

因此，綜合性能考慮，包大小以及開源庫的可持續發展等因素，我最終選擇greenDAO。

七、網絡通信能力

現在的APP幾乎都需要從服務器獲取數據，不可避免的需要具備網絡通信的能力，否則就是一個死界面。

1、android-async-http

Android最經典的網絡異步通信函數庫，它對Apache的HttpClient API的封裝使得開發者可以簡潔優雅地實現網絡請求和響應，并且同時支持同步和異步請求。主要特性如下：

• 支持異步HTTP請求，并在匿名回調函數中處理響應。

• 在子線程中發起HTTP請求。

• 內部采用線程池來處理并發請求。

• 通過RequestParams類實現GET/POST參數構造。

• 無需第三方庫支持即可實現Multipart文件上傳。

• 庫的大小只有60KB。

• 支持多種移動網絡環境下自動智能的請求重試機制。

• HTTP響應中實現自動的gzip解碼，實現快速請求響應。

• 內置多種形式的響應解析，有原生的字節流、String、JSON對象，甚至可以將response寫入到文件中。

• 可選的永久cookie保存，內部實現使用的是Android的SharedPreferences。

但是在6.0之后，系統對開發者隱藏了HttpClient函數庫，這顯著增大了使用android-async-http的代價。 如果鐵了心想繼續使用HttpClient，官方推薦的做法是在編譯期引入org.apache.http.legacy 這個庫，庫目錄在Android SDK目錄下的platforms\android-23\optional中找到，它的作用是確保在編譯時不會出現找不到HttpClient相關API的錯誤，在應用運行時可以不依賴這個庫，因為6.0以上的Android系統還沒有真正移除HttpClient的代碼，只不過API設置為對開發者不可見。我們查看android-async-http源碼發現，需要使用下面這個函數庫來替換之前的Apache的HttpClient。

這樣顯著的增加了APP的包的大小，如果想繼續使用android-async-http，那么你的APP需要額外增加1.1MB左右的大小。

2、OkHttp

OkHttp 是一個高效的HTTP客戶端，具有如下特性。

• 支持HTTP/2和SPDY，對同一臺主機的所有請求共享同一個socket。

• 當SPDY不可用時，使用連接池減少請求的延遲。

• 透明的GZIP壓縮減少下載數據大小。

• 緩存響應避免重復的網絡請求。

OkHttp在網絡性能很差的情況下能夠很好地工作，它能夠避免常見的網絡連接問題。如果你的HTTP服務有多個IP地址，OkHttp在第一次連接失敗是，會嘗試其他可選的地址。這對于IPv4+IPv6以及托管在冗余數據中心的服務來說是必要的。OkHttp使用現代的TLS特性（SNI,ALPN）初始化HTTP連接，當握手失敗時，會降低使用TSL1.0初始化連接。

OkHttp依賴于okio，okio作為java.io和java.nio的補充，是square公司開發的一個函數庫。okio使得開發者可以更好地訪問、存儲和處理數據。一開始是作為OkHttp的一個組件存在的，當然我們也可以單獨使用它。

使用Okhttp需要引入Jar包，包的大小為：326+66 = 392KB

3、Volley

Volley 是Google在2013年發布的用于Android平臺的網絡通信庫，能使網絡通信更快、更簡單、更健壯。Volley特別使用于數據量小等通信頻繁的場景。

Volley是為了簡化網絡任務而設計的，用于幫助開發者處理請求、加載、緩存、多線程、同步等任務。Volley設計了一個靈活的網絡棧適配器，在Android2.2及之前的版本中，Volley底層使用Apache HttpClient，在Android2.3及以上版本中，它使用HttpURLConnection來發起網絡請求，而且開發者也很容易將網絡棧切換成使用OkHttp。

4、Retrofit

確切的說，Retrofit 并不是一個完整的網絡請求函數庫，而是將REST API轉換成Java接口的一個開源函數庫，它要求服務器API接口遵循REST規范。基于注解使得代碼變得很簡潔，Retrofit默認情況下使用GSON作為JSON解析器，使用OkHttp實現網絡請求，三者通常配合使用，當然我們也可以將這兩者換成其他的函數庫。

通過以上分析，HttpURLConnection、Apache HttpClient 和 OkHttp 封裝了底層的網絡請求，而 android-async-http，Volley和Retrofit 是基于前面三者的基礎上二次開發而成。

最后看下函數庫的大小：

• android-async-http：106KB+1.1MB = 1.2MB

• OkHttp：326KB+66KB = 392KB

• Volley：94KB

• Retrofit：122KB+211KB = 333KB

八、圖片緩存和顯示能力

圖片緩存函數庫有很多非常優秀的，開發人員可以根據需求進行選擇。傳統的圖片緩存方案中設置有兩級緩存，分別是內存緩存和磁盤緩存。在Facebook推出的Fresco中，它增加了一級緩存，也就是Native緩存，這極大地降低了使用Fresco的APP出現OOM的概率。

1、BitmapFun

BitmapFun 函數庫是Android官方教程中的一個圖片加載和緩存實例，對于簡單的圖片加載需求來說，使用BitmapFun就夠了，在早期用的多，現在漸漸退出了實際項目開發的舞臺。

2、Picasso

Picasso 是著名的square公司眾多開源項目中的一個，它除了實現圖片的下載和二級緩存功能，還解決了常見的一些問題。

• 在adapter中正常的處理ImageView回收和下載的取消

• 使用盡量小的內存實現復雜的圖像變換

3、Glide

Glide 是Google推薦的用于Android平臺上的圖片加載和緩存函數庫。這個庫被廣泛應用在Google的開源項目中，Glide和Picasso有90%的相似度，只是在細節上還是存在不少區別。Glide為包含圖片的滾動列表做了盡可能流暢的優化。除了靜態圖片，Glide也支持GIF格式圖片的顯示。Glide提供了靈活的API可以讓開發者方便地替換下載圖片所用的網絡函數庫，默認情況下，它使用HttpUrlConnection作為網絡請求模塊，開發者也可以根據自己項目的實際需求靈活使用Google的Volley或者Square的OkHttp等函數庫進行替換。

4、Fresco

Fresco 是Facebook開源的功能強大的圖片加載和緩存函數庫，相比其他圖片緩存庫，Fresco最顯著的特點是具有三級緩存：兩級內存緩存和一級磁盤緩存。主要特性如下：

• 漸進式地加載JPEG圖片

• 顯示GIF和WebP動畫

• 可擴展，可自定義圖片加載和顯示

在Android 4.X和一下的系統上，將圖片放在Android內存一個特殊的區域，從而使得應用運行更流暢，同時極大減低出現OutOfMemoryError的錯誤。

5、Android-Universal-Image-Loader

Android-Universal-Image-Loader 簡稱UIL，是Android平臺老牌的圖片下載和緩存函數庫，功能強大靈活且高度可自定義，它提供一系列配置選項，并能很好地控制圖片加載和緩存的過程。使用者甚多，現在項目仍在使用。UIL也支持二級緩存，特性如下：

• 同步或異步的多線程圖片加載

• 高度可自定義：線程池、下載器、解碼器、內存和磁盤緩存、圖片顯示選項等。

• 每張圖片的顯示支持多種自定義選項：默認存根圖片、解碼選項、Bitmap處理和顯示等。

• 圖片可緩存在內存或者磁盤（設備的文件系統或者SD卡）上。

• 可實時監聽圖片加載流程，包括下載進度。

最后看下幾個庫的包大小

• BitmapFun：71KB

• Picasso：120KB

• Glide：475KB

• Fresco：47KB+93KB+93KB+10KB+3MB+62KB+8KB+111KB = 3.4MB

• Android-Universal-Image-Loader：162KB

圖片函數庫的選擇需要根據APP的具體情況而定，對于嚴重依賴圖片緩存的APP,例如壁紙類，圖片社交類APP來說，可以選擇最專業的Fresco。對于一般的APP，選擇Fresco會顯得比較重，畢竟Fresco 3.4MB的體量擺在這。

根據APP對圖片顯示和緩存的需求從低到高我們可以對以上函數庫做一個排序

BitmapFun < Picasso < Android-Universal-Image-Loader < Glide < Fresco

值得一提的是，如果你的APP計劃使用React Native進行部分模塊功能的開發的話，那么在基礎函數庫選擇方面需要考慮和React Native的依賴庫的復用，這樣可以減少引入React Native 所增加的APP的大小，可以復用的函數庫有：OkHttp，Fresco，jackson-core。