Android圖片框架對比

對比現(xiàn)在主流圖片框架的優(yōu)勢和缺點(diǎn)，在實(shí)際項(xiàng)目中如何選擇適合自己的框架；

成都創(chuàng)新互聯(lián)公司專注于企業(yè)全網(wǎng)整合營銷推廣、網(wǎng)站重做改版、醴陵網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5技術(shù)、購物商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為醴陵等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

Glide、Fresco、Picasso、ImageLoader

共同優(yōu)點(diǎn)：

以上名詞介紹

在分析他們的差異、優(yōu)缺點(diǎn)之前，我們先了解圖片緩存通用的概念：

以上概念在不同框架之間可能不同，比如Displayer在ImageLoader中叫做ImageAware,在Picasso和Glide中叫做Target。

以上為Glide的總體設(shè)計(jì)圖。

整個(gè)庫分為RequestManager（請求管理器）、Engine（數(shù)據(jù)獲取引擎）、Fetcher(數(shù)據(jù)獲取器)、MemoryCache（內(nèi)存緩存）、DiskLRUCache（本地緩存）、Transformation(圖片處理)、Encoder（編碼處理）、Registry(圖片類型以及解析器配置)、Target(目標(biāo))等模塊。

簡單流程： Glider收到加載及顯示資源任務(wù)，創(chuàng)建Request并將它交給RequestManager,Request啟動(dòng)Engine去數(shù)據(jù)源獲取資源，得到資源后通過Transformation處理后交給Target.

Glide依賴DiskLRUCache、GifDecoder等開源庫去完成本地緩存和Gif圖片解密工作；

為Bitmap 維護(hù)一個(gè)BitmapPool對象池, 對象池的主要目的是通過減少大對象的分配以重用來提高性能!

缺點(diǎn) ：

①圖片質(zhì)量低：因?yàn)闄C(jī)制不同，速度快，但是圖片的質(zhì)量降低了RGB565;

②多尺寸緩存導(dǎo)致內(nèi)存和磁盤占用多：根據(jù)ImageView大小來緩存，可能會(huì)導(dǎo)致一張圖片可能根據(jù)展示情況來緩存不同尺寸的幾份；

擴(kuò)展理解參考：

以上為Picasso的總體設(shè)計(jì)圖。

整個(gè)庫分為Dispatcher、RequestHandler以及Downloader、PicassoDrawable等模塊。

簡單流程： Picasso收到加載顯示圖片任務(wù)后，創(chuàng)建Request并將它交給Dispatcher，Dispatcher分發(fā)任務(wù)到具體RequestHandler，任務(wù)通過MemoryCache及Handler(數(shù)據(jù)獲取接口)獲取圖片，圖片獲取成功后通過PicassoDrawable顯示到Target中；

上面Data的File system部分，Picasso沒有自定義本地緩存的接口，默認(rèn)使用http的本地緩存，API19以上使用okhttp,一下使用UrlConnection，所以如果需要自定義本地緩存就需要自定義Downloader;

缺點(diǎn) ：加載速度沒有其他框架快；

特點(diǎn) ：只緩存一個(gè)全尺寸的圖片，根據(jù)需求的大小在壓縮轉(zhuǎn)換；

以上為Fresco的總體設(shè)計(jì)圖

整個(gè)庫分為UI:DraweeView(View控件)、Drawable（圖片數(shù)據(jù)）、DraweeController（圖片控制器）、DraweeHiierarchy（圖片體系）；Core:DataSource（數(shù)據(jù)源）、ImagePipeline（圖像管道）、Producer（生產(chǎn)者）、ProducerFacotry(生產(chǎn)工廠)、Subcriber(訂閱)、Supplier(供應(yīng)者)、Consumer（消費(fèi)者）；IO/Data:MemoryCache(內(nèi)存緩存)、Network、DiskCache(磁盤緩存)、Recourse（本地資源）

簡單流程： 從上面的結(jié)構(gòu)可以看出，fresco主要采用了工廠+建造者的模式實(shí)現(xiàn)功能，邏輯劃分比較清楚；Fresco框架整體是一個(gè)MVC模式，DrawableView---View用來顯示頂層視圖、DrawableController---Control控制加載圖片的配置 事件的分發(fā)、DrawableHierarchy---Model 用于存儲和描述圖片信息，同時(shí)也封裝了一些圖片的顯示和視圖層級的方法；ImagePipeline模塊負(fù)責(zé)從網(wǎng)絡(luò)、本地文件系統(tǒng)、本地資源加載圖片

缺點(diǎn)：

①框架大，影響Apk體積；

②一定的學(xué)習(xí)成本，使用比較繁瑣，需要使用內(nèi)部提供的ImageView控件,使用起來比較復(fù)雜；

Android圖片標(biāo)記（打標(biāo)簽、支持圖片放大縮小）

先上效果圖

1.為了實(shí)現(xiàn)圖片的放到縮小，我選擇了 PhotoView 框架用于顯示圖片。

2.使用 Glide 框架加載圖片

3.實(shí)現(xiàn)原理：

通過自定義View繼承FrameLayout，以PhotoView作為背景，動(dòng)態(tài)添加ImageView作為點(diǎn)。

4.主要分析：

1）標(biāo)簽隨圖片移動(dòng)：通過實(shí)現(xiàn)PhotoView的OnMatrixChangedListener接口，監(jiān)聽圖片的位置及大小，動(dòng)態(tài)設(shè)置標(biāo)簽的位置

2）點(diǎn)擊圖片任意位置，在此位置生成標(biāo)簽，

3）標(biāo)簽添加后，會(huì)導(dǎo)致布局重新測量，此時(shí)會(huì)導(dǎo)致已經(jīng)放大的圖片回到初始的位置及大小，在onLayout方法中重新設(shè)置photoView的Matrix。

矩形框的實(shí)現(xiàn)原理類似，難點(diǎn)就是在給icon添加了移動(dòng)監(jiān)聽，保證icon可隨處移動(dòng)

下面是源碼地址

Android模塊化設(shè)計(jì)方案之使用代理模式解耦

Android模塊化設(shè)計(jì)方案系列文章：

1、 Android模塊化設(shè)計(jì)方案模型圖

2、 Android模塊化設(shè)計(jì)方案之接口API化

3、 Android模塊化設(shè)計(jì)方案之使用代理模式解耦

本篇是Android模塊化設(shè)計(jì)方案的第三篇，也是對 第一篇 中ThridLibs Proxy模塊進(jìn)行說明。

很多人覺得對那些優(yōu)秀的第三方依賴庫再次封裝是一件多余的事情，因?yàn)檫@些庫可能出自大神/大廠，或有非常高的star并且使用起來十分穩(wěn)定，可以在項(xiàng)目中直接拿來使用。當(dāng)然每個(gè)開發(fā)者都有自己的態(tài)度，我也只是根據(jù)以往的經(jīng)驗(yàn)，表達(dá)一下自己的看法。

作為從了解四大組件就不愁找不到工作的互聯(lián)網(wǎng)大時(shí)代中一路走來的Android老鳥，經(jīng)歷了網(wǎng)路請求框架從HttpConnection到Volley再到OkHttp，也經(jīng)歷了圖片加載框架從UniversalImageLoader到Picasso再到Gilde，技術(shù)的迭代隨時(shí)都會(huì)發(fā)生。讓項(xiàng)目架構(gòu)具有良好的擴(kuò)展性是在設(shè)計(jì)之初就需要考慮的東西。

那么接下來我用一個(gè)簡單的demo來演示一下如何使用代理模式對第三方框架進(jìn)行解耦。

現(xiàn)在我們有一個(gè)名為 thirdlib 的模塊，為我們提供圖片加載功能。

第一步：我們創(chuàng)建了一個(gè)新的模塊 thridlibproxy ，并且該模塊依賴于 thirdlib ，我們在該模塊中創(chuàng)建包私有的接口ImageLoaderInterface，這個(gè)接口中把thirdlib模塊中提供的功能抽象為接口：

第二步：創(chuàng)建包私有的接口的實(shí)現(xiàn)類ImageLoaderOneImpl，類中圖片加載的業(yè)務(wù)邏輯是通過調(diào)用 thirdlib 中的ImageLoader類實(shí)現(xiàn)的：

第三步：我們提供一個(gè)供外部調(diào)用的ImageLoaderOneImpl接口代理類ImageLoaderProxy：

最后我們就可以通過ImageLoaderProxy中提供的loadImage方法進(jìn)行圖片的加載了。

看到這里有些盆友就會(huì)問了，在第二步的時(shí)候，我們就完成了 thirdlib 的封裝工作，為什么還要有第三步？還有我寫一個(gè)單例類直接對 thirdlib 進(jìn)行封裝不就行了，為什么還要抽象出接口？

原因很簡單，為的就是盡可能的滿足軟件設(shè)計(jì)七大原則中的第一個(gè)： 開閉原則 。

一個(gè)好的軟件設(shè)計(jì)，需要對拓展開放，對修改關(guān)閉。我們在設(shè)計(jì)之初就要想到，在更換圖片加載框架之后如何最大程度上滿足開閉原則。

如果直接對 thirdlib 進(jìn)行封裝，是面向類的開發(fā)而不是面向接口。如果此時(shí)更換圖片加載類庫，那必然會(huì)對封裝出來的類進(jìn)行大量的修改，把原來的實(shí)現(xiàn)替換為新的實(shí)現(xiàn)。

使用代理模式的好處就是，我新創(chuàng)建一個(gè)被代理的類ImageLoaderTwoImpl：

然后只需要對第三步中的被代理類進(jìn)行替換就行了。

在想要達(dá)到相同效果的時(shí)候，最大程度的滿足了開閉原則。

我們業(yè)務(wù)層模塊也和第三方庫實(shí)現(xiàn)了完全的解耦，我不需要知道 thridlibproxy 是如何幫我完成圖片加載工作的，但是只要調(diào)用它提供的方法就完事兒的，這也符合軟件設(shè)計(jì)七大原則中的： 最少知道原則 。

關(guān)于為何以及怎么通過代理調(diào)用第三方依賴庫，到這里就介紹完畢了，趕快動(dòng)手試試吧~

我只想說： 原則是死的，人是活的????

如果覺得有收獲的話，歡迎點(diǎn)贊評論以及關(guān)注~

android開發(fā)一般都使用什么框架

android應(yīng)用開發(fā)框架是 Application Framework. 其系統(tǒng)架構(gòu)由5部分組成，分別是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。第二部分將詳細(xì)介紹這5個(gè)部分。下面自底向上分析各層。

Android架構(gòu)

1、Linux Kernel

Android基于Linux 2.6提供核心系統(tǒng)服務(wù)，例如：安全、內(nèi)存管理、進(jìn)程管理、網(wǎng)絡(luò)堆棧、驅(qū)動(dòng)模型。Linux Kernel也作為硬件和軟件之間的抽象層，它隱藏具體硬件細(xì)節(jié)而為上層提供統(tǒng)一的服務(wù)。 如果你學(xué)過計(jì)算機(jī)網(wǎng)絡(luò)知道OSI/RM，就會(huì)知道分層的好處就是使用下層提供的服務(wù)而為上層提供統(tǒng)一的服務(wù)，屏蔽本層及以下層的差異，當(dāng)本層及以下層發(fā)生了變化不會(huì)影響到上層。也就是說各層各盡其職，各層提供固定的SAP（Service Access Point），專業(yè)點(diǎn)可以說是高內(nèi)聚、低耦合。 如果你只是做應(yīng)用開發(fā)，就不需要深入了解Linux Kernel層。

2、Android Runtime

Android包含一個(gè)核心庫的集合，提供大部分在Java編程語言核心類庫中可用的功能。每一個(gè)Android應(yīng)用程序是Dalvik虛擬機(jī)中的實(shí)例，運(yùn)行在他們自己的進(jìn)程中。Dalvik虛擬機(jī)設(shè)計(jì)成，在一個(gè)設(shè)備可以高效地運(yùn)行多個(gè)虛擬機(jī)。Dalvik虛擬機(jī)可執(zhí)行文件格式是.dex，dex格式是專為Dalvik設(shè)計(jì)的一種壓縮格式，適合內(nèi)存和處理器速度有限的系統(tǒng)。 大多數(shù)虛擬機(jī)包括JVM都是基于棧的，而Dalvik虛擬機(jī)則是基于寄存器的。兩種架構(gòu)各有優(yōu)劣，一般而言，基于棧的機(jī)器需要更多指令，而基于寄存器的機(jī)器指令更大。dx 是一套工具，可以將 Java .class 轉(zhuǎn)換成 .dex 格式。一個(gè)dex文件通常會(huì)有多個(gè).class。由于dex有時(shí)必須進(jìn)行最佳化，會(huì)使文件大小增加1-4倍，以O(shè)DEX結(jié)尾。 Dalvik虛擬機(jī)依賴于Linux 內(nèi)核提供基本功能，如線程和底層內(nèi)存管理。

3、Libraries

Android包含一個(gè)C/C++庫的集合，供Android系統(tǒng)的各個(gè)組件使用。這些功能通過Android的應(yīng)用程序框架（application framework）暴露給開發(fā)者。下面列出一些核心庫： 系統(tǒng)C庫--標(biāo)準(zhǔn)C系統(tǒng)庫（libc）的BSD衍生，調(diào)整為基于嵌入式Linux設(shè)備 媒體庫--基于PacketVideo的OpenCORE。這些庫支持播放和錄制許多流行的音頻和視頻格式，以及靜態(tài)圖像文件，包括MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG 界面管理--管理訪問顯示子系統(tǒng)和無縫組合多個(gè)應(yīng)用程序的二維和三維圖形層 LibWebCore--新式的Web瀏覽器引擎,驅(qū)動(dòng)Android 瀏覽器和內(nèi)嵌的web視圖 SGL--基本的2D圖形引擎 3D庫--基于OpenGL ES 1.0 APIs的實(shí)現(xiàn)。庫使用硬件3D加速或包含高度優(yōu)化的3D軟件光柵 FreeType --位圖和矢量字體渲染 SQLite --所有應(yīng)用程序都可以使用的強(qiáng)大而輕量級的關(guān)系數(shù)據(jù)庫引擎

4、Application Framework

通過提供開放的開發(fā)平臺，Android使開發(fā)者能夠編制極其豐富和新穎的應(yīng)用程序。開發(fā)者可以自由地利用設(shè)備硬件優(yōu)勢、訪問位置信息、運(yùn)行后臺服務(wù)、設(shè)置鬧鐘、向狀態(tài)欄添加通知等等，很多很多。 開發(fā)者可以完全使用核心應(yīng)用程序所使用的框架APIs。應(yīng)用程序的體系結(jié)構(gòu)旨在簡化組件的重用 ，任何應(yīng)用程序都能發(fā)布他的功能且任何其他應(yīng)用程序可以使用這些功能（需要服從框架執(zhí)行的安全限制）。這一機(jī)制允許用戶替換組件。 所有的應(yīng)用程序其實(shí)是一組服務(wù)和系統(tǒng)，包括： 視圖（View）--豐富的、可擴(kuò)展的視圖集合，可用于構(gòu)建一個(gè)應(yīng)用程序。包括包括列表、網(wǎng)格、文本框、按鈕，甚至是內(nèi)嵌的網(wǎng)頁瀏覽器 內(nèi)容提供者（Content Providers）--使應(yīng)用程序能訪問其他應(yīng)用程序（如通訊錄）的數(shù)據(jù)，或共享自己的數(shù)據(jù) 資源管理器（Resource Manager）--提供訪問非代碼資源，如本地化字符串、圖形和布局文件 通知管理器（Notification Manager）--使所有的應(yīng)用程序能夠在狀態(tài)欄顯示自定義警告 活動(dòng)管理器（Activity Manager）--管理應(yīng)用程序生命周期,提供通用的導(dǎo)航回退功能

5、Applications

Android裝配一個(gè)核心應(yīng)用程序集合，包括電子郵件客戶端、SMS程序、日歷、地圖、瀏覽器、聯(lián)系人和其他設(shè)置。所有應(yīng)用程序都是用Java編程語言寫的。更加豐富的應(yīng)用程序有待我們?nèi)ラ_發(fā)！ 從上面我們知道Android的架構(gòu)是分層的，非常清晰，分工很明確。Android本身是一套軟件堆迭(Software Stack)，或稱為「軟件迭層架構(gòu)」，迭層主要分成三層：操作系統(tǒng)、中間件、應(yīng)用程序。從上面我們也看到了開源的力量，一個(gè)個(gè)熟悉的開源軟件在這里貢獻(xiàn)了自己的一份力量。

文章標(biāo)題：android圖片加載框架,android中添加背景圖片
當(dāng)前URL：http://www.chinadenli.net/article0/dsdisoo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、網(wǎng)站營銷、響應(yīng)式網(wǎng)站、App開發(fā)、App設(shè)計(jì)、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)