MessageQueue:就是一个消息队列,可以添加消息,并处理消息
Hanlder内部会跟Looper进行关联,也就是说在Handler的内部可以找到Looper,找到了Looper也就找到了MessageQueue在Hanler中发送消息,其实就是先MessageQueue队列中发送消息
总结:Hanlder负责发送消息,Looper负责接收handler发送的消息,并直接把消息回传到handler自己
MessageQueue就是一个存储消息的容器
Volley框架的使用
1.Volley的get和post请求方式的使用
挑选合适的请求对象:(返回数据的类型)
StringRequest(主要请求不确定)
JsonObjectRequest(返回解析的数据是jsonObject)
JsonArrayRequest(返回解析的数据是JsonArray)
回调的使用
2.Volley的网络请求队列建立和取消队列的请求
建立全局请求队列
方面取消某个请求
3.Volley与Activity生命周期的联动
特点
可以在Activity销毁的时候,同时关闭请求
关键点
设置Tag标签,onStop()里面执行取消请求
Volley的简单的二次回调封装
请求成功请求失败的回调封装
优势
全局使用一个方式,可控,可自定义定制需求
方便灵活
OkHttp
https://blog.csdn.net/jiankeufo/article/details/54880588
1.占用储存空间
使用OkHttp需要 okio.jar (80k), okhttp.jar(330k)这2个jar包,总大小差不多400k,加上自己的封装,差不多得410k。
2.功能介绍
Square 公司开源的 OkHttp 是一个专注于连接效率的 HTTP 客户端。OkHttp 提供了对 HTTP/2 和 SPDY 的支持,并提供了连接池,GZIP 压缩和 HTTP 响应缓存功能。
3.优点
支持http请求,https请求。
支持文件下载。
使用的是HttpURLConnection,不要担心android版本的变换。(至少目前是都支持的)。
支持get,post请求。
基于Http的文件上传。
加载图片。
4.缺点
比如callback回来是在线程里面, 不能刷新UI,需要我们手动处理。
封装比较麻烦。
Volley
1.占用储存空间
使用Volley 需要Volley.jar(120k),加上自己的封装最多140k。
2.功能介绍
Volley是Goole在2013年Google I/O大会上推出了一个新的网络通信框架,它是开源的。
Volley 的特点:特别适合数据量小,通信频繁的网络操作。
3.优点
非常适合进行数据量不大,但通信频繁的网络操作。
内部分装了异步线程。
支持get,post网络请求。
图片下载。
可直接在主线程调用服务端并处理返回结果。
可以取消请求,容易扩展,面向接口编程。
4.缺点
对大文件下载 Volley的表现非常糟糕。
只支持http请求。
在BasicNetwork中判断了statusCode(statusCode < 200 || statusCode > 299),如果符合条件直
接图片加载,性能一般。
使用的是httpclient,HttpURLConnection。不过在android 6.0不支持httpclient了,如果想支持得添加org.apache.http.legacy.jar。
总结
在我们平时的项目使用volley就可以了,相对okhttp,volley非常稳定。Okhttp一般混合来用,能够胜任相对复杂的需求。如今,在AndroidStudio中,网络请求还是推荐使用Retrofit2+okhttp。
Retrofit2+okHttp3这个目前较为流行网络框架
四种常用的图片加载框架,分别是Fresco、ImageLoader、 Picasso、 Glide,包括他们各自的优缺点、使用步骤等等
http://www.jb51.net/article/100093.htm
首先看 Fresco, Fresco 是 Facebook 推出的开源图片缓存工具,主要特点包括:两个内存缓存加上 Native 缓存构成了三级缓存,支持流式,可以类似网页上模糊渐进式显示图片,对多帧动画图片支持更好,如 Gif、WebP。它的优点是其他几个框架没有的, 或者说是其他几个框架的短板。
优点:
1. 图片存储在安卓系统的匿名共享内存, 而不是虚拟机的堆内存中, 图片的中间缓冲数据也存放在本地堆内存, 所以, 应用程序有更多的内存使用, 不会因为图片加载而导致oom, 同时也减少垃圾回收器频繁调用回收 Bitmap 导致的界面卡顿, 性能更高。 2. 渐进式加载 JPEG 图片, 支持图片从模糊到清晰加载。 3. 图片可以以任意的中心点显示在 ImageView, 而不仅仅是图片的中心。 4. JPEG 图片改变大小也是在 native 进行的, 不是在虚拟机的堆内存, 同样减少 OOM。 5. 很好的支持 GIF 图片的显示。
缺点:
1. 框架较大, 影响 Apk 体积 2. 使用较繁琐
ImageLoader是比较老的框架,是github社区上star最多的一个项目,可以理解为点赞最多滴,应该是最有名的一个国内很多知名软件都用它包括淘宝京东聚划算等等。整个库分为 ImageLoaderEngine,Cache 及 ImageDownloader,ImageDecoder,BitmapDisplayer,BitmapProcessor 五大模块,其中 Cache 分为 MemoryCache 和 DiskCache 两部分。简单的讲就是 ImageLoader 收到加载及显示图片的任务,并将它交给 ImageLoaderEngine,ImageLoaderEngine 分发任务到具体线程池去执行,任务通过 Cache 及 ImageDownloader 获取图片,中间可能经过 BitmapProcessor 和 ImageDecoder 处理,最终转换为Bitmap 交给 BitmapDisplayer 在 ImageAware中显示。特点是稳定, 加载速度适中, 缺点在于不支持GIF图片加载, 使用稍微繁琐, 并且缓存机制没有和 http 的缓存很好的结合, 完全是自己的一套缓存机制。使用比较简单,这个框架的github主页上也有快速使用的步骤,基本上就是在application类里的oncreate方法(整个程序开始时运行一次)中进行一下简单的基本配置,可以根据需要自行进行设定,懒得设定的话框架也提供了一个默认的配置,调用一个方法即可。基本上是配置一些类似于:缓存类型啊,缓存上限值啊,加载图片的线程池数量啊等等。此外在页面内显示的时候还要设置一个显示配置这个配置不同于基本配置,一个项目里可以根据需要创建多个配置对象使用,这个配置就比较具体了,可以设置是否使用disk缓存(存到sd卡里一般),加载图片失败时显示的图片,默认图片,图片的色彩样式等。ImageLoader和Volley图片部分还包括其他大部分图片框架,基本上图片处理都差不多,区别仅在于部分优化了,而优化方面UIL即Universal-Image-Loader框架做的最好,配置好以后,就是简单的使用了,创建一个图片加载对象,然后一行代码搞定显示图片功能。参数一般是入你需要显示的图片url和imageview对象。
优点:
1.支持下载进度监听 2.可以在 View 滚动中暂停图片加载,通过 PauseOnScrollListener 接口可以在 View 滚动中暂停图片加载。 3.默认实现多种内存缓存算法 这几个图片缓存都可以配置缓存算法,不过 ImageLoader 默认实现了较多缓存算法,如 Size 最大先删除、使用最少先删除、最近最少使用、先进先删除、时间最长先删除等。 4.支持本地缓存文件名规则定义
4. 提供了丰富的缓存策略
内存缓存,现在我们来看Universal-Image-Loader有哪些内存缓存策略
1. 只使用的是强引用缓存 LruMemoryCache(这个类就是这个开源框架默认的内存缓存类,缓存的是bitmap的强引用,下面我会从源码上面分析这个类)
2.使用强引用和弱引用相结合的缓存有
UsingFreqLimitedMemoryCache(如果缓存的图片总量超过限定值,先删除使用频率最小的bitmap) LRULimitedMemoryCache(这个也是使用的lru算法,和LruMemoryCache不同的是,他缓存的是bitmap的弱引用) FIFOLimitedMemoryCache(先进先出的缓存策略,当超过设定值,先删除最先加入缓存的bitmap) LargestLimitedMemoryCache(当超过缓存限定值,先删除最大的bitmap对象) LimitedAgeMemoryCache(当 bitmap加入缓存中的时间超过我们设定的值,将其删除)
3.只使用弱引用缓存
WeakMemoryCache(这个类缓存bitmap的总大小没有限制,唯一不足的地方就是不稳定,缓存的图片容易被回收硬盘缓存) FileCountLimitedDiscCache(可以设定缓存图片的个数,当超过设定值,删除掉最先加入到硬盘的文件) LimitedAgeDiscCache(设定文件存活的最长时间,当超过这个值,就删除该文件) TotalSizeLimitedDiscCache(设定缓存bitmap的最大值,当超过这个值,删除最先加入到硬盘的文件) UnlimitedDiscCache(这个缓存类没有任何的限制)
Picasso 是 Square 开源的项目,且他的主导者是 JakeWharton,所以广为人知。square公司,很多知名的开源也是该公司`android-times-square,leakcanary,okhttp,retrofit`。 Picasso的使用方便, 一行代码完成加载图片并显示, 框架体积小。但是不支持 GIF, 并且它可能是想让服务器去处理图片的缩放, 它缓存的图片是未缩放的, 并且默认使用 ARGB_8888 格式缓存图片, 缓存体积大。整个库分为 Dispatcher,RequestHandler 及 Downloader,PicassoDrawable 等模块。Dispatcher 负责分发和处理 Action,包括提交、暂停、继续、取消、网络状态变化、重试等等。简单的讲就是 Picasso 收到加载及显示图片的任务,创建 Request 并将它交给 Dispatcher,Dispatcher 分发任务到具体 RequestHandler,任务通过 MemoryCache 及 Handler(数据获取接口) 获取图片,图片获取成功后通过 PicassoDrawable 显示到 Target 中。需要注意的是上面 Data 的 File system 部分,Picasso 没有自定义本地缓存的接口,默认使用 http 的本地缓存,API 9 以上使用 okhttp,以下使用 Urlconnection,所以如果需要自定义本地缓存就需要重定义 Downloader。
Picasso 优点
1.自带统计监控功能。支持图片缓存使用的监控,包括缓存命中率、已使用内存大小、节省的流量等。 2.支持优先级处理。每次任务调度前会选择优先级高的任务,比如 App 页面中 Banner 的优先级高于 Icon 时就很适用。 3.支持延迟到图片尺寸计算完成加载 4.支持飞行模式、并发线程数根据网络类型而变。 手机切换到飞行模式或网络类型变换时会自动调整线程池最大并发数,比如 wifi 最大并发为 4,4g 为 3,3g 为 2。 这里 Picasso 根据网络类型来决定最大并发数,而不是 CPU 核数。 5.“无”本地缓存。无”本地缓存,不是说没有本地缓存,而是 Picasso 自己没有实现,交给了 Square 的另外一个网络库 okhttp 去实现,这样的好处是可以通过请求 Response Header 中的 Cache-Control 及 Expired 控制图片的过期时间。
Glide可以说是 Picasso 的升级版, 有 Picasso 的优点, 并且支持 GIF 图片加载显示, 图片缓存也会自动缩放, 默认使用 RGB_565 格式缓存图片, 是 Picasso 缓存体积的一半。谷歌为我们介绍了一个名叫 Glide 的图片加载库,作者是`bumptech`。这个库被广泛的运用在google的开源项目中,包括2014年google I/O大会上发布的官方app。整个库分为 RequestManager(请求管理器),Engine(数据获取引擎)、 Fetcher(数据获取器)、MemoryCache(内存缓存)、DiskLRUCache、Transformation(图片处理)、Encoder(本地缓存存储)、Registry(图片类型及解析器配置)、Target(目标) 等模块。简单的讲就是Glide 收到加载及显示资源的任务,创建 Request 并将它交给RequestManager,Request 启动 Engine 去数据源获取资源(通过 Fetcher ),获取到后 Transformation 处理后交给 Target。Glide 依赖于 DiskLRUCache、GifDecoder 等开源库去完成本地缓存和 Gif 图片解码工作。
Glide 优点
不仅仅可以进行图片缓存还可以缓存媒体文件。Glide 不仅是一个图片缓存,它支持 Gif、WebP、缩略图。甚至是 Video,所以更该当做一个媒体缓存。 2.支持优先级处理。 3.与 Activity/Fragment 生命周期一致,支持 trimMemory。Glide 对每个 context 都保持一个 RequestManager,通过 FragmentTransaction 保持与 Activity/Fragment 生命周期一致,并且有对应的 trimMemory 接口实现可供调用。 4.支持 okhttp、Volley。Glide 默认通过 UrlConnection 获取数据,可以配合 okhttp 或是 Volley 使用。实际 ImageLoader、Picasso 也都支持 okhttp、Volley。 5.内存友好。Glide 的内存缓存有个 active 的设计,从内存缓存中取数据时,不像一般的实现用 get,而是用 remove,再将这个缓存数据放到一个 value 为软引用的 activeResources map 中,并计数引用数,在图片加载完成后进行判断,如果引用计数为空则回收掉。内存缓存更小图片,Glide 以 url、view_width、view_height、屏幕的分辨率等做为联合 key,将处理后的图片缓存在内存缓存中,而不是原始图片以节省大小与 Activity/Fragment 生命周期一致,支持 trimMemory。图片默认使用默认RGB_565 而不是 ARGB_888,虽然清晰度差些,但图片更小,也可配置到 ARGB_888。 6.Glide 可以通过 signature 或不使用本地缓存支持 url 过期
Android --- 简单实现三级缓存
为什么要进行三级缓存
三级缓存策略,最实在的意义就是减少不必要的流量消耗,增加加载速度。
三级缓存的原理
首次加载的时候通过网络加载,获取图片,然后保存到内存和SD 卡中。
之后运行APP 时,优先访问内存中的图片缓存。
如果内存没有,则加载本地SD 卡中的图片。
三级缓存:
1、网络缓存 从网络获取资源(异步加载)
2、本地缓存 从本地获取数据(File存储)
3、内存缓存 从内存获取数据(LruCache)
轻量级缓存框架——ACache(ASimpleCache)
ACache介绍:
ACache类似于SharedPreferences,但是比SharedPreferences功能更加强大,SharedPreferences只能保存一些基本数据类型、Serializable、Bundle等数据,
而Acache可以缓存如下数据:
普通的字符串、JsonObject、JsonArray、Bitmap、Drawable、序列化的java对象,和 byte数据。
主要特色:
1:轻,轻到只有一个JAVA文件。
2:可配置,可以配置缓存路径,缓存大小,缓存数量等。
3:可以设置缓存超时时间,缓存超时自动失效,并被删除。
4:支持多进程。
应用场景:
1、替换SharePreference当做配置文件
2、可以缓存网络请求数据,比如oschina的android客户端可以缓存http请求的新闻内容,缓存时间假设为1个小时,超时后自动失效,让客户端重新请求新的数据,减少客户端流量,同时减少服务器并发量。
下载链接:https://github.com/yangfuhai/ASimpleCache
框架分析:http://blog.csdn.net/zhoubin1992/article/details/46379055
Android缓存分为内存缓存和文件缓存(磁盘缓存)。在早期,各大图片缓存框架流行之前,常用的内存缓存方式是软引用(SoftReference)和弱引用(WeakReference),如大部分的使用方式:HashMap> imageCache;这种形式。从Android 2.3(Level 9)开始,垃圾回收器更倾向于回收SoftReference或WeakReference对象,这使得SoftReference和WeakReference变得不是那么实用有效。同时,到了Android 3.0(Level 11)之后,图片数据Bitmap被放置到了内存的堆区域,而堆区域的内存是由GC管理的,开发者也就不需要进行图片资源的释放工作,但这也使得图片数据的释放无法预知,增加了造成OOM的可能。因此,在Android3.1以后,Android推出了LruCache这个内存缓存类,LruCache中的对象是强引用的。