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