目錄

• 一、前言
• 二、APP的整體架構(gòu)
• 三、技術(shù)選型的考量點(diǎn)
• 四、日志記錄能力
• 五、JSON解析能力
• • 1、gson
  • 2、jackson
  • 3、Fastjson
  • 4、LoganSquare
• 六、數(shù)據(jù)庫操作能力
• • 1、ActiveAndroid
  • 2、ormlite
  • 3、greenDAO
  • 4、Realm
• 七、網(wǎng)絡(luò)通信能力
• • 1、android-async-http
  • 2、OkHttp
  • 3、Volley
  • 4、Retrofit
• 八、圖片緩存和顯示能力
• • 1、BitmapFun
  • 2、Picasso
  • 3、Glide
  • 4、Fresco
  • 5、Android-Universal-Image-Loader

一、前言

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

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

面試者：Glide啊（內(nèi)心竊喜）

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

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

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

這篇博文主要就是針對(duì)平常使用到的框架做一個(gè)整理和分析其優(yōu)劣。

為了從整體上進(jìn)行把握，先來看看一個(gè)完整的APP整體架構(gòu)。

二、APP的整體架構(gòu)

從較高的層次將，一個(gè)APP的整體架構(gòu)可以分為兩層：應(yīng)用層和基礎(chǔ)框架層。

• 應(yīng)用層：專注于行業(yè)領(lǐng)域的實(shí)現(xiàn)，例如金融、支付、地圖導(dǎo)航、社交等，它直接面向用戶，是用戶對(duì)產(chǎn)品的第一層感知。

• 基礎(chǔ)框架層：專注于技術(shù)領(lǐng)域的實(shí)現(xiàn)，提供APP公有的特性，避免重復(fù)制造輪子，它是用戶對(duì)產(chǎn)品的第二層感知，例如性能、穩(wěn)定性等。

一個(gè)理想的APP架構(gòu)，應(yīng)該擁有如下特點(diǎn)：

• 支持跨平臺(tái)開發(fā)

• 具有清晰的層次劃分，同一層模塊間充分解耦，模塊內(nèi)部符合面向?qū)ο笤O(shè)計(jì)六大原則

• 在功能、性能、穩(wěn)定性等方面達(dá)到綜合最優(yōu)

基于以上設(shè)計(jì)原則，我們可以看出APP架構(gòu)圖，最上層是應(yīng)用層，應(yīng)用層以下都屬于基礎(chǔ)框架層，基礎(chǔ)框架層包括：組件層、基礎(chǔ)層和跨平臺(tái)層。

我們要討論的重點(diǎn)是基礎(chǔ)層，下面開始一步一步地闡述如何基于開源函數(shù)庫搭建屬于自己的一個(gè)基礎(chǔ)技術(shù)堆棧。

三、技術(shù)選型的考量點(diǎn)

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

• 特性：提供的特性是否滿足項(xiàng)目的需求。

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

• 性能：性能不能太差，否則項(xiàng)目后面性能優(yōu)化會(huì)過不去，可能回出現(xiàn)需要替換函數(shù)庫的情況。

• 文檔：文檔應(yīng)該比較齊全，且可讀性高。

• 技術(shù)支持：遇到問題或者發(fā)現(xiàn)BUG，是否能夠及時(shí)得到官方的技術(shù)支持是很重要的。

• 大小：引入函數(shù)庫會(huì)增加APK的大小，需要慎重抉擇。

• 方法數(shù)：如果函數(shù)庫方法數(shù)太多，積累起來會(huì)導(dǎo)致你的APP遇到64K問題，應(yīng)該盡量避免。

四、日志記錄能力

日志記錄無論在服務(wù)端開發(fā)還是移動(dòng)端開發(fā)，都是一個(gè)基礎(chǔ)且重要的能力，開發(fā)人員在代碼調(diào)試以及錯(cuò)誤定位過程中，大多說都要依賴日志信息，一個(gè)簡潔靈活的日志記錄模塊是相當(dāng)重要的。

Logger（https://github.com/orhanobut/logger） 是基于系統(tǒng)Log類基礎(chǔ)上進(jìn)行的封裝，但新增了如下超贊的特性：

• 在Logcat中完美的格式化輸出，再也不用擔(dān)心和手機(jī)其他APP或者系統(tǒng)的日志信息相混淆了。

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

• 支持跳轉(zhuǎn)到源碼處。

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

Logcat截圖：

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

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

timber是JakeWharton開源的一個(gè)日志記錄庫，它的特點(diǎn)是可擴(kuò)展的框架，開發(fā)者可以方便快捷的集成不同類型的日志記錄方式，例如，打印日志到Logcat、打印日志到文件、打印日志到網(wǎng)絡(luò)等，timber通過一行代碼就可以同時(shí)調(diào)用多種方式。

timber的思想很簡單，就是維護(hù)一個(gè)森林對(duì)象，它由不同類型的日志樹組合而成，例如，Logcat記錄樹、文件記錄樹、網(wǎng)絡(luò)記錄樹等，森林對(duì)象提供對(duì)外的接口進(jìn)行日志打印。每種類型的樹都可以通過種植操作把自己添加到森林對(duì)象中，或者通過移除操作從森林對(duì)象中刪除，從而實(shí)現(xiàn)該類型日志記錄的開啟和關(guān)閉。

最終我們的日志記錄模塊將由timber+Logger+LogUtils組成，當(dāng)然輪子找到了，輪子的兼容合并就得靠我們自己實(shí)現(xiàn)了，同時(shí)我們還得增加打印到文件的日志樹和打印到網(wǎng)絡(luò)的日志樹實(shí)現(xiàn)。

五、JSON解析能力

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

1、gson

gosn 是Google出品的JSON解析函數(shù)庫，可以將JSON字符串反序列化對(duì)應(yīng)的Java對(duì)象，或者反過來將Java對(duì)象序列化為對(duì)應(yīng)的JSON字符串，免去了開發(fā)者手動(dòng)通過JSONObject和JSONArray將JSON字段逐個(gè)進(jìn)行解析的煩惱，也減少了出錯(cuò)的可能性，增強(qiáng)了代碼的質(zhì)量。使用gson解析時(shí)，對(duì)應(yīng)的Java實(shí)體類無需使用注解進(jìn)行標(biāo)記，支持任意復(fù)雜Java對(duì)象包括沒有源代碼的對(duì)象。

2、jackson

jcakson 是Java語言的一個(gè)流行的JSON函數(shù)庫，在Android開發(fā)中使用時(shí)，主要包含三部分。

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

• jackson-databind：數(shù)據(jù)綁定函數(shù)庫，實(shí)現(xiàn)Java對(duì)象和JSON字符串流的相互轉(zhuǎn)換。

• jackson-annotations：databind使用的注解函數(shù)庫。

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

3、Fastjson

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

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

4、LoganSquare

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

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

再來看下jar包的大小：

• gson：232KB

• jackson：259+47+1229 = 1.5M

• Fastjson：417KB

• Fastjson.android：256KB

• LoganSquare：48+259 = 307KB

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

六、數(shù)據(jù)庫操作能力

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

1、ActiveAndroid

ActiveAndroid 是一種Active Record風(fēng)格的ORM框架，Active Record（活動(dòng)目錄）是Yii,Rails等框架中對(duì)ORM實(shí)現(xiàn)的典型命名方式。它極大的簡化數(shù)據(jù)庫的使用，使用面向?qū)ο蟮姆绞焦芾頂?shù)據(jù)庫，告別手寫SQL的歷史。每一個(gè)數(shù)據(jù)庫表都可以被映射為一個(gè)類，開發(fā)者只需使用類似save()或者delete()這樣的函數(shù)即可。

不過ActiveAndroid已經(jīng)基本上處于維護(hù)階段了，最新的一個(gè)Release版本是在2012年發(fā)布的。

2、ormlite

ormlite 是Java平臺(tái)的一個(gè)ORM框架，支持JDBC連接、Spring和Android平臺(tái)。在Android中使用時(shí)，它包含兩部分。

• ormlite-core：核心模塊，無論在哪個(gè)平臺(tái)使用，都必須基于這個(gè)核心庫，是實(shí)現(xiàn)ORM映射的關(guān)鍵模塊。

• ormlite-android：基于ormlite-core封裝的針對(duì)Android平臺(tái)的適配器模塊，Android開發(fā)中主要跟這個(gè)模塊打交道。

與ActiveAndroid類似，ormlite也已經(jīng)不是一個(gè)活躍的開源庫，最近一次Release版本是在2013年發(fā)布的。

3、greenDAO

greenDAO 是一個(gè)輕量級(jí)且快速的ORM框架，專門為Android高度優(yōu)化和定制，它能夠支持每秒數(shù)千條記錄的CRUD操作。官網(wǎng)上給出一張性能對(duì)比圖：

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

4、Realm

Realm 是一個(gè)全新的移動(dòng)數(shù)據(jù)庫引擎，它既不是基于iOS平臺(tái)的Core Data，也不是基于SQLite，它擁有自己的數(shù)據(jù)庫存儲(chǔ)引擎，并實(shí)現(xiàn)了高效快速的數(shù)據(jù)庫構(gòu)建操作，相比Core Data和SQLite，Realm操作要快很多，跟ORM框架相比就更不用說了。

Realm的好處如下：

• 跨平臺(tái)：Android和iOS已經(jīng)是事實(shí)上的兩大移動(dòng)互聯(lián)網(wǎng)操作系統(tǒng)，絕大多數(shù)應(yīng)用都會(huì)支持這兩個(gè)平臺(tái)。使用Realm，Android和iOS開發(fā)者無需考慮內(nèi)部數(shù)據(jù)的架構(gòu)，調(diào)用Realm提供的API即可輕松完成數(shù)據(jù)的交換。

• 用法簡單：相比Core Data和SQLite所需的入門知識(shí)，Realm可以極大降低開發(fā)者的學(xué)習(xí)成本，快速實(shí)現(xiàn)數(shù)據(jù)庫存儲(chǔ)功能。

• 可視化操作：Realm為開發(fā)者提供了一個(gè)輕量級(jí)的數(shù)據(jù)庫可視化操作工具，開發(fā)者可以輕松查看數(shù)據(jù)庫中的內(nèi)容，并實(shí)現(xiàn)簡單地插入和刪除等操作。

我們看下上述四種數(shù)據(jù)庫包大小：

• activeandroid：40KB

• greendao：100KB

• ormlite-android：57KB

• realm-android：4.2M

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

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

七、網(wǎng)絡(luò)通信能力

現(xiàn)在的APP幾乎都需要從服務(wù)器獲取數(shù)據(jù)，不可避免的需要具備網(wǎng)絡(luò)通信的能力，否則就是一個(gè)死界面。

1、android-async-http

Android最經(jīng)典的網(wǎng)絡(luò)異步通信函數(shù)庫，它對(duì)Apache的HttpClient API的封裝使得開發(fā)者可以簡潔優(yōu)雅地實(shí)現(xiàn)網(wǎng)絡(luò)請(qǐng)求和響應(yīng)，并且同時(shí)支持同步和異步請(qǐng)求。主要特性如下：

• 支持異步HTTP請(qǐng)求，并在匿名回調(diào)函數(shù)中處理響應(yīng)。

• 在子線程中發(fā)起HTTP請(qǐng)求。

• 內(nèi)部采用線程池來處理并發(fā)請(qǐng)求。

• 通過RequestParams類實(shí)現(xiàn)GET/POST參數(shù)構(gòu)造。

• 無需第三方庫支持即可實(shí)現(xiàn)Multipart文件上傳。

• 庫的大小只有60KB。

• 支持多種移動(dòng)網(wǎng)絡(luò)環(huán)境下自動(dòng)智能的請(qǐng)求重試機(jī)制。

• HTTP響應(yīng)中實(shí)現(xiàn)自動(dòng)的gzip解碼，實(shí)現(xiàn)快速請(qǐng)求響應(yīng)。

• 內(nèi)置多種形式的響應(yīng)解析，有原生的字節(jié)流、String、JSON對(duì)象，甚至可以將response寫入到文件中。

• 可選的永久cookie保存，內(nèi)部實(shí)現(xiàn)使用的是Android的SharedPreferences。

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

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

2、OkHttp

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

• 支持HTTP/2和SPDY，對(duì)同一臺(tái)主機(jī)的所有請(qǐng)求共享同一個(gè)socket。

• 當(dāng)SPDY不可用時(shí)，使用連接池減少請(qǐng)求的延遲。

• 透明的GZIP壓縮減少下載數(shù)據(jù)大小。

• 緩存響應(yīng)避免重復(fù)的網(wǎng)絡(luò)請(qǐng)求。

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

OkHttp依賴于okio，okio作為java.io和java.nio的補(bǔ)充，是square公司開發(fā)的一個(gè)函數(shù)庫。okio使得開發(fā)者可以更好地訪問、存儲(chǔ)和處理數(shù)據(jù)。一開始是作為OkHttp的一個(gè)組件存在的，當(dāng)然我們也可以單獨(dú)使用它。

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

3、Volley

Volley 是Google在2013年發(fā)布的用于Android平臺(tái)的網(wǎng)絡(luò)通信庫，能使網(wǎng)絡(luò)通信更快、更簡單、更健壯。Volley特別使用于數(shù)據(jù)量小等通信頻繁的場(chǎng)景。

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

4、Retrofit

確切的說，Retrofit 并不是一個(gè)完整的網(wǎng)絡(luò)請(qǐng)求函數(shù)庫，而是將REST API轉(zhuǎn)換成Java接口的一個(gè)開源函數(shù)庫，它要求服務(wù)器API接口遵循REST規(guī)范?；谧⒔馐沟么a變得很簡潔，Retrofit默認(rèn)情況下使用GSON作為JSON解析器，使用OkHttp實(shí)現(xiàn)網(wǎng)絡(luò)請(qǐng)求，三者通常配合使用，當(dāng)然我們也可以將這兩者換成其他的函數(shù)庫。

通過以上分析，HttpURLConnection、Apache HttpClient 和 OkHttp 封裝了底層的網(wǎng)絡(luò)請(qǐng)求，而 android-async-http，Volley和Retrofit 是基于前面三者的基礎(chǔ)上二次開發(fā)而成。

最后看下函數(shù)庫的大小：

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

• OkHttp：326KB+66KB = 392KB

• Volley：94KB

• Retrofit：122KB+211KB = 333KB

八、圖片緩存和顯示能力

圖片緩存函數(shù)庫有很多非常優(yōu)秀的，開發(fā)人員可以根據(jù)需求進(jìn)行選擇。傳統(tǒng)的圖片緩存方案中設(shè)置有兩級(jí)緩存，分別是內(nèi)存緩存和磁盤緩存。在Facebook推出的Fresco中，它增加了一級(jí)緩存，也就是Native緩存，這極大地降低了使用Fresco的APP出現(xiàn)OOM的概率。

1、BitmapFun

BitmapFun 函數(shù)庫是Android官方教程中的一個(gè)圖片加載和緩存實(shí)例，對(duì)于簡單的圖片加載需求來說，使用BitmapFun就夠了，在早期用的多，現(xiàn)在漸漸退出了實(shí)際項(xiàng)目開發(fā)的舞臺(tái)。

2、Picasso

Picasso 是著名的square公司眾多開源項(xiàng)目中的一個(gè)，它除了實(shí)現(xiàn)圖片的下載和二級(jí)緩存功能，還解決了常見的一些問題。

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

• 使用盡量小的內(nèi)存實(shí)現(xiàn)復(fù)雜的圖像變換

3、Glide

Glide 是Google推薦的用于Android平臺(tái)上的圖片加載和緩存函數(shù)庫。這個(gè)庫被廣泛應(yīng)用在Google的開源項(xiàng)目中，Glide和Picasso有90%的相似度，只是在細(xì)節(jié)上還是存在不少區(qū)別。Glide為包含圖片的滾動(dòng)列表做了盡可能流暢的優(yōu)化。除了靜態(tài)圖片，Glide也支持GIF格式圖片的顯示。Glide提供了靈活的API可以讓開發(fā)者方便地替換下載圖片所用的網(wǎng)絡(luò)函數(shù)庫，默認(rèn)情況下，它使用HttpUrlConnection作為網(wǎng)絡(luò)請(qǐng)求模塊，開發(fā)者也可以根據(jù)自己項(xiàng)目的實(shí)際需求靈活使用Google的Volley或者Square的OkHttp等函數(shù)庫進(jìn)行替換。

4、Fresco

Fresco 是Facebook開源的功能強(qiáng)大的圖片加載和緩存函數(shù)庫，相比其他圖片緩存庫，Fresco最顯著的特點(diǎn)是具有三級(jí)緩存：兩級(jí)內(nèi)存緩存和一級(jí)磁盤緩存。主要特性如下：

• 漸進(jìn)式地加載JPEG圖片

• 顯示GIF和WebP動(dòng)畫

• 可擴(kuò)展，可自定義圖片加載和顯示

在Android 4.X和一下的系統(tǒng)上，將圖片放在Android內(nèi)存一個(gè)特殊的區(qū)域，從而使得應(yīng)用運(yùn)行更流暢，同時(shí)極大減低出現(xiàn)OutOfMemoryError的錯(cuò)誤。

5、Android-Universal-Image-Loader

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

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

• 高度可自定義：線程池、下載器、解碼器、內(nèi)存和磁盤緩存、圖片顯示選項(xiàng)等。

• 每張圖片的顯示支持多種自定義選項(xiàng)：默認(rèn)存根圖片、解碼選項(xiàng)、Bitmap處理和顯示等。

• 圖片可緩存在內(nèi)存或者磁盤（設(shè)備的文件系統(tǒng)或者SD卡）上。

• 可實(shí)時(shí)監(jiān)聽圖片加載流程，包括下載進(jìn)度。

最后看下幾個(gè)庫的包大小

• BitmapFun：71KB

• Picasso：120KB

• Glide：475KB

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

• Android-Universal-Image-Loader：162KB

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

根據(jù)APP對(duì)圖片顯示和緩存的需求從低到高我們可以對(duì)以上函數(shù)庫做一個(gè)排序

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

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

總結(jié)

以上是生活随笔為你收集整理的Android 开源框架选择的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。