對比現在主流圖片框架的優勢和缺點,在實際項目中如何選擇適合自己的框架;
成都創新互聯公司專注于企業全網整合營銷推廣、網站重做改版、醴陵網站定制設計、自適應品牌網站建設、H5技術、購物商城網站建設、集團公司官網建設、成都外貿網站建設公司、高端網站制作、響應式網頁設計等建站業務,價格優惠性價比高,為醴陵等各大城市提供網站開發制作服務。
Glide、Fresco、Picasso、ImageLoader
共同優點:
以上名詞介紹
在分析他們的差異、優缺點之前,我們先了解圖片緩存通用的概念:
以上概念在不同框架之間可能不同,比如Displayer在ImageLoader中叫做ImageAware,在Picasso和Glide中叫做Target。
以上為Glide的總體設計圖。
整個庫分為RequestManager(請求管理器)、Engine(數據獲取引擎)、Fetcher(數據獲取器)、MemoryCache(內存緩存)、DiskLRUCache(本地緩存)、Transformation(圖片處理)、Encoder(編碼處理)、Registry(圖片類型以及解析器配置)、Target(目標)等模塊。
簡單流程: Glider收到加載及顯示資源任務,創建Request并將它交給RequestManager,Request啟動Engine去數據源獲取資源,得到資源后通過Transformation處理后交給Target.
Glide依賴DiskLRUCache、GifDecoder等開源庫去完成本地緩存和Gif圖片解密工作;
為Bitmap 維護一個BitmapPool對象池, 對象池的主要目的是通過減少大對象的分配以重用來提高性能!
缺點 :
①圖片質量低:因為機制不同,速度快,但是圖片的質量降低了RGB565;
②多尺寸緩存導致內存和磁盤占用多:根據ImageView大小來緩存,可能會導致一張圖片可能根據展示情況來緩存不同尺寸的幾份;
擴展理解參考:
以上為Picasso的總體設計圖。
整個庫分為Dispatcher、RequestHandler以及Downloader、PicassoDrawable等模塊。
簡單流程: Picasso收到加載顯示圖片任務后,創建Request并將它交給Dispatcher,Dispatcher分發任務到具體RequestHandler,任務通過MemoryCache及Handler(數據獲取接口)獲取圖片,圖片獲取成功后通過PicassoDrawable顯示到Target中;
上面Data的File system部分,Picasso沒有自定義本地緩存的接口,默認使用http的本地緩存,API19以上使用okhttp,一下使用UrlConnection,所以如果需要自定義本地緩存就需要自定義Downloader;
缺點 :加載速度沒有其他框架快;
特點 :只緩存一個全尺寸的圖片,根據需求的大小在壓縮轉換;
以上為Fresco的總體設計圖
整個庫分為UI:DraweeView(View控件)、Drawable(圖片數據)、DraweeController(圖片控制器)、DraweeHiierarchy(圖片體系);Core:DataSource(數據源)、ImagePipeline(圖像管道)、Producer(生產者)、ProducerFacotry(生產工廠)、Subcriber(訂閱)、Supplier(供應者)、Consumer(消費者);IO/Data:MemoryCache(內存緩存)、Network、DiskCache(磁盤緩存)、Recourse(本地資源)
簡單流程: 從上面的結構可以看出,fresco主要采用了工廠+建造者的模式實現功能,邏輯劃分比較清楚;Fresco框架整體是一個MVC模式,DrawableView---View用來顯示頂層視圖、DrawableController---Control控制加載圖片的配置 事件的分發、DrawableHierarchy---Model 用于存儲和描述圖片信息,同時也封裝了一些圖片的顯示和視圖層級的方法;ImagePipeline模塊負責從網絡、本地文件系統、本地資源加載圖片
缺點:
①框架大,影響Apk體積;
②一定的學習成本,使用比較繁瑣,需要使用內部提供的ImageView控件,使用起來比較復雜;
先上效果圖
1.為了實現圖片的放到縮小,我選擇了 PhotoView 框架用于顯示圖片。
2.使用 Glide 框架加載圖片
3.實現原理:
通過自定義View繼承FrameLayout,以PhotoView作為背景,動態添加ImageView作為點。
4.主要分析:
1)標簽隨圖片移動:通過實現PhotoView的OnMatrixChangedListener接口,監聽圖片的位置及大小,動態設置標簽的位置
2)點擊圖片任意位置,在此位置生成標簽,
3)標簽添加后,會導致布局重新測量,此時會導致已經放大的圖片回到初始的位置及大小,在onLayout方法中重新設置photoView的Matrix。
矩形框的實現原理類似,難點就是在給icon添加了移動監聽,保證icon可隨處移動
下面是源碼地址
Android模塊化設計方案系列文章:
1、 Android模塊化設計方案模型圖
2、 Android模塊化設計方案之接口API化
3、 Android模塊化設計方案之使用代理模式解耦
本篇是Android模塊化設計方案的第三篇,也是對 第一篇 中ThridLibs Proxy模塊進行說明。
很多人覺得對那些優秀的第三方依賴庫再次封裝是一件多余的事情,因為這些庫可能出自大神/大廠,或有非常高的star并且使用起來十分穩定,可以在項目中直接拿來使用。當然每個開發者都有自己的態度,我也只是根據以往的經驗,表達一下自己的看法。
作為從了解四大組件就不愁找不到工作的互聯網大時代中一路走來的Android老鳥,經歷了網路請求框架從HttpConnection到Volley再到OkHttp,也經歷了圖片加載框架從UniversalImageLoader到Picasso再到Gilde,技術的迭代隨時都會發生。讓項目架構具有良好的擴展性是在設計之初就需要考慮的東西。
那么接下來我用一個簡單的demo來演示一下如何使用代理模式對第三方框架進行解耦。
現在我們有一個名為 thirdlib 的模塊,為我們提供圖片加載功能。
第一步:我們創建了一個新的模塊 thridlibproxy ,并且該模塊依賴于 thirdlib ,我們在該模塊中創建包私有的接口ImageLoaderInterface,這個接口中把thirdlib模塊中提供的功能抽象為接口:
第二步:創建包私有的接口的實現類ImageLoaderOneImpl,類中圖片加載的業務邏輯是通過調用 thirdlib 中的ImageLoader類實現的:
第三步:我們提供一個供外部調用的ImageLoaderOneImpl接口代理類ImageLoaderProxy:
最后我們就可以通過ImageLoaderProxy中提供的loadImage方法進行圖片的加載了。
看到這里有些盆友就會問了,在第二步的時候,我們就完成了 thirdlib 的封裝工作,為什么還要有第三步?還有我寫一個單例類直接對 thirdlib 進行封裝不就行了,為什么還要抽象出接口?
原因很簡單,為的就是盡可能的滿足軟件設計七大原則中的第一個: 開閉原則 。
一個好的軟件設計,需要對拓展開放,對修改關閉。我們在設計之初就要想到,在更換圖片加載框架之后如何最大程度上滿足開閉原則。
如果直接對 thirdlib 進行封裝,是面向類的開發而不是面向接口。如果此時更換圖片加載類庫,那必然會對封裝出來的類進行大量的修改,把原來的實現替換為新的實現。
使用代理模式的好處就是,我新創建一個被代理的類ImageLoaderTwoImpl:
然后只需要對第三步中的被代理類進行替換就行了。
在想要達到相同效果的時候,最大程度的滿足了開閉原則。
我們業務層模塊也和第三方庫實現了完全的解耦,我不需要知道 thridlibproxy 是如何幫我完成圖片加載工作的,但是只要調用它提供的方法就完事兒的,這也符合軟件設計七大原則中的: 最少知道原則 。
關于為何以及怎么通過代理調用第三方依賴庫,到這里就介紹完畢了,趕快動手試試吧~
我只想說: 原則是死的,人是活的????
如果覺得有收獲的話,歡迎點贊評論以及關注~
android應用開發框架是 Application Framework. 其系統架構由5部分組成,分別是:Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。第二部分將詳細介紹這5個部分。下面自底向上分析各層。
Android架構
1、Linux Kernel
Android基于Linux 2.6提供核心系統服務,例如:安全、內存管理、進程管理、網絡堆棧、驅動模型。Linux Kernel也作為硬件和軟件之間的抽象層,它隱藏具體硬件細節而為上層提供統一的服務。 如果你學過計算機網絡知道OSI/RM,就會知道分層的好處就是使用下層提供的服務而為上層提供統一的服務,屏蔽本層及以下層的差異,當本層及以下層發生了變化不會影響到上層。也就是說各層各盡其職,各層提供固定的SAP(Service Access Point),專業點可以說是高內聚、低耦合。 如果你只是做應用開發,就不需要深入了解Linux Kernel層。
2、Android Runtime
Android包含一個核心庫的集合,提供大部分在Java編程語言核心類庫中可用的功能。每一個Android應用程序是Dalvik虛擬機中的實例,運行在他們自己的進程中。Dalvik虛擬機設計成,在一個設備可以高效地運行多個虛擬機。Dalvik虛擬機可執行文件格式是.dex,dex格式是專為Dalvik設計的一種壓縮格式,適合內存和處理器速度有限的系統。 大多數虛擬機包括JVM都是基于棧的,而Dalvik虛擬機則是基于寄存器的。兩種架構各有優劣,一般而言,基于棧的機器需要更多指令,而基于寄存器的機器指令更大。dx 是一套工具,可以將 Java .class 轉換成 .dex 格式。一個dex文件通常會有多個.class。由于dex有時必須進行最佳化,會使文件大小增加1-4倍,以ODEX結尾。 Dalvik虛擬機依賴于Linux 內核提供基本功能,如線程和底層內存管理。
3、Libraries
Android包含一個C/C++庫的集合,供Android系統的各個組件使用。這些功能通過Android的應用程序框架(application framework)暴露給開發者。下面列出一些核心庫: 系統C庫--標準C系統庫(libc)的BSD衍生,調整為基于嵌入式Linux設備 媒體庫--基于PacketVideo的OpenCORE。這些庫支持播放和錄制許多流行的音頻和視頻格式,以及靜態圖像文件,包括MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG 界面管理--管理訪問顯示子系統和無縫組合多個應用程序的二維和三維圖形層 LibWebCore--新式的Web瀏覽器引擎,驅動Android 瀏覽器和內嵌的web視圖 SGL--基本的2D圖形引擎 3D庫--基于OpenGL ES 1.0 APIs的實現。庫使用硬件3D加速或包含高度優化的3D軟件光柵 FreeType --位圖和矢量字體渲染 SQLite --所有應用程序都可以使用的強大而輕量級的關系數據庫引擎
4、Application Framework
通過提供開放的開發平臺,Android使開發者能夠編制極其豐富和新穎的應用程序。開發者可以自由地利用設備硬件優勢、訪問位置信息、運行后臺服務、設置鬧鐘、向狀態欄添加通知等等,很多很多。 開發者可以完全使用核心應用程序所使用的框架APIs。應用程序的體系結構旨在簡化組件的重用 ,任何應用程序都能發布他的功能且任何其他應用程序可以使用這些功能(需要服從框架執行的安全限制)。這一機制允許用戶替換組件。 所有的應用程序其實是一組服務和系統,包括: 視圖(View)--豐富的、可擴展的視圖集合,可用于構建一個應用程序。包括包括列表、網格、文本框、按鈕,甚至是內嵌的網頁瀏覽器 內容提供者(Content Providers)--使應用程序能訪問其他應用程序(如通訊錄)的數據,或共享自己的數據 資源管理器(Resource Manager)--提供訪問非代碼資源,如本地化字符串、圖形和布局文件 通知管理器(Notification Manager)--使所有的應用程序能夠在狀態欄顯示自定義警告 活動管理器(Activity Manager)--管理應用程序生命周期,提供通用的導航回退功能
5、Applications
Android裝配一個核心應用程序集合,包括電子郵件客戶端、SMS程序、日歷、地圖、瀏覽器、聯系人和其他設置。所有應用程序都是用Java編程語言寫的。更加豐富的應用程序有待我們去開發! 從上面我們知道Android的架構是分層的,非常清晰,分工很明確。Android本身是一套軟件堆迭(Software Stack),或稱為「軟件迭層架構」,迭層主要分成三層:操作系統、中間件、應用程序。從上面我們也看到了開源的力量,一個個熟悉的開源軟件在這里貢獻了自己的一份力量。
文章標題:android圖片加載框架,android中添加背景圖片
當前URL:http://vcdvsql.cn/article0/dsdisoo.html
成都網站建設公司_創新互聯,為您提供軟件開發、網站營銷、響應式網站、App開發、App設計、外貿網站建設
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯