Android搭建屬于自己的技術(shù)堆棧和App架構(gòu)
來源：原創(chuàng) 時(shí)間：2017-10-17 瀏覽：0 次
一、目錄
前語
APP的全體架構(gòu)
技能選型的考量點(diǎn)
日志記載才能
JSON解析才能
數(shù)據(jù)庫操作才能
網(wǎng)絡(luò)通訊才能
圖片緩存和顯現(xiàn)才能
二、前語
在技能面試的時(shí)分必定都會(huì)問到運(yùn)用了哪些第三方結(jié)構(gòu)，為什么運(yùn)用它而不必其他的。身邊朋友就有這樣的親身經(jīng)歷：
面試官：你們項(xiàng)目中加載圖片都是用的什么結(jié)構(gòu)？
面試者：Glide?。ㄐ睦锔`喜）
面試官：為什么運(yùn)用Glide而不必其他的？
面試者：(緘默沉靜10s)，Glide好啊，我比較喜愛。（心里不安）
面試官：......(能不能好好談天了)
這篇博文首要就是針對(duì)往常運(yùn)用到的結(jié)構(gòu)做一個(gè)收拾和剖析其好壞。
為了從全體上進(jìn)行掌握，先來看看一個(gè)完好的APP全體架構(gòu)
三、APP的全體架構(gòu)
從較高的層次將，一個(gè)APP的全體架構(gòu)能夠分為兩層，即運(yùn)用層和根底結(jié)構(gòu)層。
運(yùn)用層專心于職業(yè)范疇的完結(jié)，例如金融、付出、地圖導(dǎo)航、交際等，它直接面向用戶，是用戶對(duì)產(chǎn)品的第一層感知。
根底結(jié)構(gòu)層專心于技能范疇的完結(jié)，供給APP公有的特性，防止重復(fù)制作輪子，它是用戶對(duì)產(chǎn)品的第二層感知，例如功用、穩(wěn)定性等。
一個(gè)抱負(fù)的APP架構(gòu)，應(yīng)該具有如下特色
支撐跨渠道開發(fā)
具有明晰的層次區(qū)分，同一層模塊間充分化耦，模塊內(nèi)部契合面向目標(biāo)規(guī)劃六大準(zhǔn)則
在功用、功用、穩(wěn)定性等方面到達(dá)歸納最優(yōu)
依據(jù)以上規(guī)劃準(zhǔn)則，我們能夠看出APP架構(gòu)圖，最上層是運(yùn)用層，運(yùn)用層以下都?xì)w于根底結(jié)構(gòu)層，根底結(jié)構(gòu)層包含：組件層、根底層和跨渠道層。
我們要評(píng)論的重點(diǎn)是根底層，下面開端一步一步地論述怎么依據(jù)開源函數(shù)庫建立歸于自己的一個(gè)根底技能倉庫。
四、技能選型的考量點(diǎn)
首先要清晰的是，我們挑選開源函數(shù)庫或許第三方SDK、一般需求歸納考慮一下幾個(gè)方面
特性：供給的特性是否滿意項(xiàng)目的需求
可用性，是否供給了簡(jiǎn)練便當(dāng)?shù)腁PI，便利開發(fā)者集成運(yùn)用。
功用：功用不能太差，不然項(xiàng)目后邊功用優(yōu)化會(huì)過不去，可能回呈現(xiàn)需求替換函數(shù)庫的狀況。
文檔：文檔應(yīng)該比較完全，且可讀性高。
技能支撐：遇到問題或許發(fā)現(xiàn)BUG，是否能夠及時(shí)得到官方的技能支撐是很重要的
巨細(xì)：引進(jìn)函數(shù)庫會(huì)添加APK的巨細(xì)，需求穩(wěn)重挑選
辦法數(shù)：如果函數(shù)庫辦法數(shù)太多，堆集起來會(huì)導(dǎo)致你的APP遇到64K問題，應(yīng)該盡量防止
五、日志記載才能
日志記載不管在效勞端開發(fā)仍是移動(dòng)端開發(fā)，都是一個(gè)根底且重要的才能，開發(fā)人員在代碼調(diào)試以及過錯(cuò)定位進(jìn)程中，大多說都要依靠日志信息，一個(gè)簡(jiǎn)練靈敏的日志記載模塊是適當(dāng)重要的。
Logger（https://github.com/orhanobut/logger） 是依據(jù)體系Log類根底上進(jìn)行的封裝，但新增了如下超贊的特性。
在Logcat中完美的格局化輸出，再也不必憂慮和手機(jī)其他APP或許體系的日志信息相混雜了
包含線程、類、辦法信息，能夠清楚地看到日志記載的調(diào)用倉庫
支撐跳轉(zhuǎn)到源碼處
支撐格局化輸出JSON、XML格局信息
Logcat截圖
當(dāng)然Logger也不是齊備的，它盡管支撐格局化輸出JSON、XML，但并不支撐比如List、Set、Map和數(shù)組等常見Java調(diào)集類的格局化輸出。怎么處理呢？能夠看下LogUtils （https://github.com/pengwei1024/LogUtils）這個(gè)開源庫，它完結(jié)了Logger缺失的上述特性。
再者，Logger只支撐輸出日志到Logcat，但項(xiàng)目開發(fā)中往往還存在將日志保存到磁盤上的需求，怎么將兩者結(jié)合起來呢？這是可用timber（https://github.com/JakeWharton/timber） 。
timber是JakeWharton開源的一個(gè)日志記載庫，它的特色是可擴(kuò)展的結(jié)構(gòu)，開發(fā)者能夠便利快捷的集成不同類型的日志記載方法，例如，打印日志到Logcat、打印日志到文件、打印日志到網(wǎng)絡(luò)等，timber經(jīng)過一行代碼就能夠一起調(diào)用多種方法。
timber的思維很簡(jiǎn)略，就是保護(hù)一個(gè)森林目標(biāo)，它由不同類型的日志樹組合而成，例如，Logcat記載樹、文件記載樹、網(wǎng)絡(luò)記載樹等，森林目標(biāo)供給對(duì)外的接口進(jìn)行日志打印。每種類型的樹都能夠經(jīng)過栽培操作把自己添加到森林目標(biāo)中，或許經(jīng)過移除操作從森林目標(biāo)中刪去，然后完結(jié)該類型日志記載的敞開和封閉。
終究我們的日志記載模塊將由timber+Logger+LogUtils組成，當(dāng)然輪子找到了，輪子的兼容兼并就得靠我們自己完結(jié)了，一起我們還得添加打印到文件的日志樹和打印到網(wǎng)絡(luò)的日志樹完結(jié)。
六、JSON解析才能
移動(dòng)互聯(lián)網(wǎng)產(chǎn)品與效勞器端通訊的數(shù)據(jù)格局，如果沒有特別需求的話，一般都運(yùn)用JSON格局。Android體系也原生的供給了JSON解析的API，可是它的速度十分慢，并且沒有供給簡(jiǎn)練便利的接口來進(jìn)步開發(fā)者的功率和下降犯錯(cuò)的可能。所以我們就開端找第三方開源庫來完結(jié)JSON解析，比較優(yōu)異的包含如下幾種。
gson
gosn是Google出品的JSON解析函數(shù)庫，能夠?qū)SON字符串反序列化對(duì)應(yīng)的Java目標(biāo)，或許反過來將Java目標(biāo)序列化為對(duì)應(yīng)的JSON字符串，免去了開發(fā)者手動(dòng)經(jīng)過JSONObject和JSONArray將JSON字段逐一進(jìn)行解析的煩惱，也削減了犯錯(cuò)的可能性，增強(qiáng)了代碼的質(zhì)量。運(yùn)用gson解析時(shí)，對(duì)應(yīng)的Java實(shí)體類無需運(yùn)用注解進(jìn)行符號(hào)，支撐恣意雜亂Java目標(biāo)包含沒有源代碼的目標(biāo)。
jackson
jcakson是Java言語的一個(gè)盛行的JSON函數(shù)庫，在Android開發(fā)中運(yùn)用時(shí)，首要包含三部分。
jackson-core：JSON流處理中心庫
jackson-databind：數(shù)據(jù)綁定函數(shù)庫，完結(jié)Java目標(biāo)和JSON字符串流的彼此改換。
jackson-annotations：databind運(yùn)用的注解函數(shù)庫
由于jackson是針對(duì)Java言語通用的JSON函數(shù)庫，并沒有為Android優(yōu)化定制過，因而函數(shù)珍重包含許多非必要的API，比較其他的JSON函數(shù)庫，用于Android渠道會(huì)更明顯的增大終究生成的APK的體積。
Fastjson
Fastjson是阿里巴巴出品的一個(gè)Java言語編寫的高功用且功用完善的JSON函數(shù)庫。它選用一種“假定有序快速匹配”的算法，把JSON Parse的功用提升到極致，號(hào)稱是現(xiàn)在Java言語中最快的JSON庫。Fastjson接口簡(jiǎn)略易用，現(xiàn)已被廣泛運(yùn)用在緩存序列化、協(xié)議交互、Web輸出、Android客戶端等多種運(yùn)用場(chǎng)景。
由于是Java言語通用的，因而，曾經(jīng)在Android上運(yùn)用時(shí)，F(xiàn)astjson不行防止的引進(jìn)了許多關(guān)于Android而言冗余的功用，然后添加了包巨細(xì)，許多人運(yùn)用的就是標(biāo)準(zhǔn)版的fastjson，但事實(shí)上，fastjson還存在一個(gè)專門為Android定制的版別---fastjson.android 。和標(biāo)準(zhǔn)版別比較，Android版別去掉了一些Android虛擬機(jī)dalvik不支撐的功用，使得jar更小。
LoganSquare
LoganSquare是近兩年興起的快速解析和序列化JSON的Android函數(shù)庫，其底層依據(jù)jackson的streaming API，運(yùn)用APT(Android Annotation Tool)完結(jié)編譯時(shí)注解，然后進(jìn)步JSON解析和序列化的功用。官網(wǎng)上能夠看到LoganSquare和gson、jackson databind的功用比照。
從功用方面看，LoganSquare是完勝gson和jackson的。如果和fastjson比較較，兩者應(yīng)該是平起平坐的。
再來看下jar包的巨細(xì)
gson：232KB
jackson：259+47+1229 = 1.5M
Fastjson：417KB
Fastjson.android：256KB
LoganSquare：48+259 = 307KB
從功用和包巨細(xì)歸納考慮，終究我們會(huì)挑選Fastjson.android作為根底技能倉庫中的JSON解析和序列化庫。
七、數(shù)據(jù)庫操作才能
不管是iOS仍是Android，底層數(shù)據(jù)庫都是依據(jù)開源的SQLite完結(jié)，然后在體系層封裝成用于運(yùn)用層的API。盡管直接運(yùn)用體系的數(shù)據(jù)庫API功用很高，可是這些API接口并不是很便利開發(fā)者運(yùn)用，一不小心就會(huì)引進(jìn)Bug，并且代碼的視覺效果也欠安。為了處理這個(gè)問題，目標(biāo)聯(lián)系映射（ORM）結(jié)構(gòu)呈現(xiàn)了，比較好的有ActiveAndroid，ormlite和greenDAO。
ActiveAndroid
ActiveAndroid是一種Active Record風(fēng)格的ORM結(jié)構(gòu)，Active Record（活動(dòng)目錄）是Yii,Rails等結(jié)構(gòu)中對(duì)ORM完結(jié)的典型命名方法。它極大的簡(jiǎn)化數(shù)據(jù)庫的運(yùn)用，運(yùn)用面向目標(biāo)的方法辦理數(shù)據(jù)庫，離別手寫SQL的前史。每一個(gè)數(shù)據(jù)庫表都能夠被映射為一個(gè)類，開發(fā)者只需運(yùn)用類似save()或許delete()這樣的函數(shù)即可。
不過ActiveAndroid現(xiàn)已基本上處于保護(hù)階段了，最新的一個(gè)Release版別是在2012年發(fā)布的。
ormlite
ormlite是Java渠道的一個(gè)ORM結(jié)構(gòu)，支撐JDBC銜接、Spring和Android渠道。在Android中運(yùn)用時(shí)，它包含兩部分。
ormlite-core：中心模塊，不管在哪個(gè)渠道運(yùn)用，都必須依據(jù)這個(gè)中心庫，是完結(jié)ORM映射的要害模塊。
ormlite-android：依據(jù)ormlite-core封裝的針對(duì)Android渠道的適配器模塊，Android開發(fā)中首要跟這個(gè)模塊打交道。
與ActiveAndroid類似，ormlite也現(xiàn)已不是一個(gè)活潑的開源庫，最近一次Release版別是在2013年發(fā)布的。
greenDAO
greenDAO是一個(gè)輕量級(jí)且快速的ORM結(jié)構(gòu)，專門為Android高度優(yōu)化和定制，它能夠支撐每秒數(shù)千條記載的CRUD操作。官網(wǎng)上給出一張功用比照?qǐng)D
縱軸表明每秒履行的操作數(shù)。并且greenDAO處在高度活潑中，最新Release版別是在2017年3月份發(fā)布的。
Realm
Realm是一個(gè)全新的移動(dòng)數(shù)據(jù)庫引擎，它既不是依據(jù)iOS渠道的Core Data，也不是依據(jù)SQLite，它具有自己的數(shù)據(jù)庫存儲(chǔ)引擎，并完結(jié)了高效快速的數(shù)據(jù)庫構(gòu)建操作，比較Core Data和SQLite，Realm操作要快許多，跟ORM結(jié)構(gòu)比較就更不必說了。
Realm的優(yōu)點(diǎn)如下：
跨渠道：Android和iOS現(xiàn)已是事實(shí)上的兩大移動(dòng)互聯(lián)網(wǎng)操作體系，絕大多數(shù)運(yùn)用都會(huì)支撐這兩個(gè)渠道。運(yùn)用Realm，Android和iOS開發(fā)者無需考慮內(nèi)部數(shù)據(jù)的架構(gòu)，調(diào)用Realm供給的API即可輕松完結(jié)數(shù)據(jù)的交流。
用法簡(jiǎn)略：比較Core Data和SQLite所需的入門常識(shí)，Realm能夠極大下降開發(fā)者的學(xué)習(xí)本錢，快速完結(jié)數(shù)據(jù)庫存儲(chǔ)功用。
可視化操作：Realm為開發(fā)者供給了一個(gè)輕量級(jí)的數(shù)據(jù)庫可視化操作東西，開發(fā)者能夠輕松檢查數(shù)據(jù)庫中的內(nèi)容，并完結(jié)簡(jiǎn)略地刺進(jìn)和刪去等操作。
我們看下上述四種數(shù)據(jù)庫包巨細(xì)。
activeandroid：40KB
greendao：100KB
ormlite-android：57KB
realm-android：4.2M
能夠看出，前三個(gè)仍是正常規(guī)模，但Realm的巨細(xì)一般項(xiàng)目可能無法承受。這是由于不同CPU架構(gòu)渠道的 .so 文件添加了整個(gè)包的巨細(xì)，由于arm渠道的so在其他渠道上面能夠以兼容形式運(yùn)轉(zhuǎn)的，盡管會(huì)丟失功用，可是能夠極大地削減函數(shù)庫占用的空間。因而，能夠挑選只保存armeabi-v7a和x86兩個(gè)渠道的 .so 文件，直接刪去無用的 .so 文件，或許經(jīng)過工程的build.gradle文件中添加 ndk abi 過濾，句子如下：
因而，歸納功用考慮，包巨細(xì)以及開源庫的可持續(xù)發(fā)展等要素，我終究挑選greenDAO。
八、網(wǎng)絡(luò)通訊才能
現(xiàn)在的APP簡(jiǎn)直都需求從效勞器獲取數(shù)據(jù)，不行防止的需求具有網(wǎng)絡(luò)通訊的才能，不然就是一個(gè)死界面。
android-async-http
Android最經(jīng)典的網(wǎng)絡(luò)異步通訊函數(shù)庫，它對(duì)Apache的HttpClient API的封裝使得開發(fā)者能夠簡(jiǎn)練高雅地完結(jié)網(wǎng)絡(luò)懇求和呼應(yīng)，并且一起支撐同步和異步懇求。首要特性如下：
支撐異步HTTP懇求，并在匿名回調(diào)函數(shù)中處理呼應(yīng)
在子線程中建議HTTP懇求
內(nèi)部選用線程池來處理并發(fā)懇求
經(jīng)過RequestParams類完結(jié)GET/POST參數(shù)結(jié)構(gòu)
無需第三方庫支撐即可完結(jié)Multipart文件上傳
庫的巨細(xì)只要60KB
支撐多種移動(dòng)網(wǎng)絡(luò)環(huán)境下主動(dòng)智能的懇求重試機(jī)制
HTTP呼應(yīng)中完結(jié)主動(dòng)的gzip解碼，完結(jié)快速懇求呼應(yīng)
內(nèi)置多種形式的呼應(yīng)解析，有原生的字節(jié)省、String、JSON目標(biāo)，乃至能夠?qū)esponse寫入到文件中。
可選的永久cookie保存，內(nèi)部完結(jié)運(yùn)用的是Android的SharedPreferences。
可是在6.0之后，體系對(duì)開發(fā)者躲藏了HttpClient函數(shù)庫，這明顯增大了運(yùn)用android-async-http的價(jià)值。 如果鐵了心想持續(xù)運(yùn)用HttpClient，官方引薦的做法是在編譯期引進(jìn)org.apache.http.legacy 這個(gè)庫，庫目錄在Android SDK目錄下的platformsndroid-23optional中找到，它的作用是保證在編譯時(shí)不會(huì)呈現(xiàn)找不到HttpClient相關(guān)API的過錯(cuò)，在運(yùn)用運(yùn)轉(zhuǎn)時(shí)能夠不依靠這個(gè)庫，由于6.0以上的Android體系還沒有真實(shí)移除HttpClient的代碼，只不過API設(shè)置為對(duì)開發(fā)者不行見。我們檢查android-async-http源碼發(fā)現(xiàn)，需求運(yùn)用下面這個(gè)函數(shù)庫來替換之前的Apache的HttpClient。
這樣明顯的添加了APP的包的巨細(xì)，如果想持續(xù)運(yùn)用android-async-http，那么你的APP需求額定添加1.1MB左右的巨細(xì)。
OkHttp
OkHttp是一個(gè)高效的HTTP客戶端，具有如下特性。
支撐HTTP/2和SPDY，對(duì)同一臺(tái)主機(jī)的一切懇求同享同一個(gè)socket。
當(dāng)SPDY不行用時(shí)，運(yùn)用銜接池削減懇求的推遲。
通明的GZIP緊縮削減下載數(shù)據(jù)巨細(xì)
緩存呼應(yīng)防止重復(fù)的網(wǎng)絡(luò)懇求
OkHttp在網(wǎng)絡(luò)功用很差的狀況下能夠很好地作業(yè)，它能夠防止常見的網(wǎng)絡(luò)銜接問題。如果你的HTTP效勞有多個(gè)IP地址，OkHttp在第一次銜接失利是，會(huì)測(cè)驗(yàn)其他可選的地址。這關(guān)于IPv4+IPv6以及保管在冗余數(shù)據(jù)中心的效勞來說是必要的。OkHttp運(yùn)用現(xiàn)代的TLS特性（SNI,ALPN）初始化HTTP銜接，當(dāng)握手失利時(shí)，會(huì)下降運(yùn)用TSL1.0初始化銜接。
OkHttp依靠于okio，okio作為java.io和java.nio的彌補(bǔ)，是square公司開發(fā)的一個(gè)函數(shù)庫。okio使得開發(fā)者能夠更好地拜訪、存儲(chǔ)和處理數(shù)據(jù)。一開端是作為OkHttp的一個(gè)組件存在的，當(dāng)然我們也能夠獨(dú)自運(yùn)用它。
運(yùn)用Okhttp需求引進(jìn)Jar包，包的巨細(xì)為：
326+66 = 392KB
Volley
Volley是Google在2013年發(fā)布的用于Android渠道的網(wǎng)絡(luò)通訊庫，能使網(wǎng)絡(luò)通訊更快、更簡(jiǎn)略、更強(qiáng)健。Volley特別運(yùn)用于數(shù)據(jù)量小等通訊頻頻的場(chǎng)景。
Volley是為了簡(jiǎn)化網(wǎng)絡(luò)使命而規(guī)劃的，用于協(xié)助開發(fā)者處理懇求、加載、緩存、多線程、同步等使命。Volley規(guī)劃了一個(gè)靈敏的網(wǎng)絡(luò)棧適配器，在Android2.2及之前的版別中，Volley底層運(yùn)用Apache HttpClient，在Android2.3及以上版別中，它運(yùn)用HttpURLConnection來建議網(wǎng)絡(luò)懇求，并且開發(fā)者也很簡(jiǎn)略將網(wǎng)絡(luò)棧切換成運(yùn)用OkHttp。
Retrofit
確切的說，Retrofit并不是一個(gè)完好的網(wǎng)絡(luò)懇求函數(shù)庫，而是將REST API改換成Java接口的一個(gè)開源函數(shù)庫，它要求效勞器API接口遵從REST標(biāo)準(zhǔn)。依據(jù)注解使得代碼變得很簡(jiǎn)練，Retrofit默許狀況下運(yùn)用GSON作為JSON解析器，運(yùn)用OkHttp完結(jié)網(wǎng)絡(luò)懇求，三者一般合作運(yùn)用，當(dāng)然我們也能夠?qū)⑦@兩者換成其他的函數(shù)庫。
經(jīng)過以上剖析，HttpURLConnection、Apache HttpClient 和OkHttp封裝了底層的網(wǎng)絡(luò)懇求，而android-async-http，Volley和Retrofit是依據(jù)前面三者的根底上二次開發(fā)而成。
最終看下函數(shù)庫的巨細(xì)
android-async-http：106KB+1.1MB = 1.2MB
OkHttp：326KB+66KB = 392KB
Volley：94KB
Retrofit：122KB+211KB = 333KB
九、網(wǎng)絡(luò)通訊才能
圖片緩存函數(shù)庫有許多十分優(yōu)異的，開發(fā)人員能夠依據(jù)需求進(jìn)行挑選。傳統(tǒng)的圖片緩存方案中設(shè)置有兩級(jí)緩存，分別是內(nèi)存緩存和磁盤緩存。在Facebook推出的Fresco中，它添加了一級(jí)緩存，也就是Native緩存，這極大地下降了運(yùn)用Fresco的APP呈現(xiàn)OOM的概率。
BitmapFun
BitmapFun函數(shù)庫是Android官方教程中的一個(gè)圖片加載和緩存實(shí)例，關(guān)于簡(jiǎn)略的圖片加載需求來說，運(yùn)用BitmapFun就夠了，在前期用的多，現(xiàn)在逐漸退出了實(shí)踐項(xiàng)目開發(fā)的舞臺(tái)。
Picasso
Picasso是聞名的square公司很多開源項(xiàng)目中的一個(gè)，它除了完結(jié)圖片的下載和二級(jí)緩存功用，還處理了常見的一些問題。
在adapter中正常的處理ImageView收回和下載的撤銷
運(yùn)用盡量小的內(nèi)存完結(jié)雜亂的圖畫改換
Glide
Glide是Google引薦的用于Android渠道上的圖片加載和緩存函數(shù)庫。這個(gè)庫被廣泛運(yùn)用在Google的開源項(xiàng)目中，Glide和Picasso有90%的類似度，只是在細(xì)節(jié)上仍是存在不少差異。Glide為包含圖片的翻滾列表做了盡可能流通的優(yōu)化。除了靜態(tài)圖片，Glide也支撐GIF格局圖片的顯現(xiàn)。Glide供給了靈敏的API能夠讓開發(fā)者便利地替換下載圖片所用的網(wǎng)絡(luò)函數(shù)庫，默許狀況下，它運(yùn)用HttpUrlConnection作為網(wǎng)絡(luò)懇求模塊，開發(fā)者也能夠依據(jù)自己項(xiàng)目的實(shí)踐需求靈敏運(yùn)用Google的Volley或許Square的OkHttp等函數(shù)庫進(jìn)行替換。
Fresco
Fresco是Facebook開源的功用強(qiáng)大的圖片加載和緩存函數(shù)庫，比較其他圖片緩存庫，F(xiàn)resco最明顯的特色是具有三級(jí)緩存：兩級(jí)內(nèi)存緩存和一級(jí)磁盤緩存。首要特性如下：
漸進(jìn)式地加載JPEG圖片
顯現(xiàn)GIF和WebP動(dòng)畫
可擴(kuò)展，可自定義圖片加載和顯現(xiàn)
在Android 4.X和一下的體系上，將圖片放在Android內(nèi)存一個(gè)特別的區(qū)域，然后使得運(yùn)用運(yùn)轉(zhuǎn)更流通，一起極大減低呈現(xiàn)OutOfMemoryError的過錯(cuò)。
Android-Universal-Image-Loader
Android-Universal-Image-Loader簡(jiǎn)稱UIL，是Android渠道老牌的圖片下載和緩存函數(shù)庫，功用強(qiáng)大靈敏且高度可自定義，它供給一系列裝備選項(xiàng)，并能很好地操控圖片加載和緩存的進(jìn)程。運(yùn)用者甚多，現(xiàn)在項(xiàng)目仍在運(yùn)用。UIL也支撐二級(jí)緩存，特性如下：
同步或異步的多線程圖片加載
高度可自定義：線程池、下載器、解碼器、內(nèi)存和磁盤緩存、圖片顯現(xiàn)選項(xiàng)等。
每張圖片的顯現(xiàn)支撐多種自定義選項(xiàng)：默許存根圖片、解碼選項(xiàng)、Bitmap處理和顯現(xiàn)等。
圖片可緩存在內(nèi)存或許磁盤（設(shè)備的文件體系或許SD卡）上。
可實(shí)時(shí)監(jiān)聽圖片加載流程，包含下載進(jìn)展。
最終看下幾個(gè)庫的包巨細(xì)
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的具體狀況而定，關(guān)于嚴(yán)峻依靠圖片緩存的APP,例如壁紙類，圖片交際類APP來說，能夠挑選最專業(yè)的Fresco。關(guān)于一般的APP，挑選Fresco會(huì)顯得比較重，究竟Fresco 3.4MB的體量擺在這。
依據(jù)APP對(duì)圖片顯現(xiàn)和緩存的需求從低到高我們能夠?qū)σ陨虾瘮?shù)庫做一個(gè)排序
BitmapFun < Picasso < Android-Universal-Image-Loader < Glide < Fresco
值得一提的是，如果你的APP方案運(yùn)用React Native進(jìn)行部分模塊功用的開發(fā)的話，那么在根底函數(shù)庫挑選方面需求考慮和React Native的依靠庫的復(fù)用，這樣能夠削減引進(jìn)React Native 所添加的APP的巨細(xì)，能夠復(fù)用的函數(shù)庫有：OkHttp，F(xiàn)resco,jackson-core.
