1. okhttp3 源码分析
- 好处
- 拥有自动维护的socket连接池
- 拥有队列线程池
- 拥有Interceptors(拦截器)轻松处理请求与响应
- 基于Headers的缓存策略
- 流程
当我们用OkHttpClient.newCall(request)进行execute/enenqueue时，实际是将请求Call放到了Dispatcher中，okhttp使用Dispatcher进行线程分发，它有两种方法，一个是普通的同步单线程；另一种是使用了队列进行并发任务的分发(Dispatch)与回调，我们下面主要分析第二种，也就是队列这种情况，这也是okhttp能够竞争过其它库的核心功能之一 - 核心
-
OkHttp3源码分析[复用连接池]
1 . OkHttp采用Dispatcher技术，类似于Nginx，与线程池配合实现了高并发，低阻塞的运行
2 .Okhttp采用Deque作为缓存，按照入队的顺序先进先出
3 .OkHttp最出彩的地方就是在try/finally中调用了finished函数，可以主动控制等待队列的移动，而不是采用锁或者wait/notify，极大减少了编码复杂性 -
缓存机制
[图片上传失败...(image-27e217-1520731917140)]](http://upload-images.jianshu.io/upload_images/4179767-e744c843a20af892.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
-
OkHttp3源码分析[复用连接池]
- 设计模式
1 .CacheStrategy使用Factory模式进行构造
2 .Interceptor责任链模式(事件传递就是责任链机制)
Interceptor是 OkHttp 核心类，它把网络请求、缓存、透明压缩等功能都统一了起来，每一个功能都是一个 Interceptor，它们再连接成一个 Interceptor.Chain，如链条一般，分工明确，完美完成一次网络请求。
3 . Request与Response都是使用Builder模式创建
4 .ExecutorService使用单例获取线程池(标准懒汉模式)
public synchronized ExecutorService executorService() {
if (executorService == null) {
executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
}
return executorService;
}
- 注意事项(遇到的坑)
post方式不支持缓存
在获取到ResponseBody对象后,注意要复制一个新的，否则消费掉了就没了
enqueue异步执行,onResponse是在子线程中,不能直接刷新UI - 项目使用案例
okgo
2. retrofit
定义
-
流程
- 通过解析 网络请求接口的注解 配置 网络请求参数
- 通过 动态代理 生成 网络请求对象
- 通过 网络请求适配器 将 网络请求对象 进行平台适配
平台包括：Android、Rxjava、Guava和java8 - 通过 网络请求执行器 发送网络请求
- 通过 数据转换器 解析服务器返回的数据
- 通过 回调执行器 切换线程（子线程 ->>主线程）
- 用户在主线程处理返回结果
设计模式
注意事项(遇到的坑)
项目使用案例
3. Glide
-
优点
多样化媒体加载
Glide 不仅是一个图片缓存，它支持 Gif、WebP、缩略图。甚至是 Video生命周期集成
通过设置绑定生命周期，我们可以更加高效的使用Glide提供的方式进行绑定，这样可以更好的让加载图片的请求的生命周期动态管理起来高效的缓存策略
A. 支持Memory和Disk图片缓存
B. Picasso 只会缓存原始尺寸的图片，而 Glide 缓存的是多种规格，也就意味着 Glide 会根据你 ImageView 的大小来缓存相应大小的图片尺寸
C. 内存开销小
默认的 Bitmap 格式是 RGB_565 格式，而 Picasso 默认的是 ARGB_8888 格式，这个内存开销要小一半。
-
缓存策略
- 1 .
DiskCacheStrategy.NONE不做磁盘缓存 - 2 .
DiskCacheStrategy.SOURCE只缓存图像原图 - 3 .
DiskCacheStrategy.RESULT只缓存加载后的图像，即处理后最终显示时的图像 - 4 .
DiskCacheStrategy.ALL缓存所有版本的图像（默认行为）
- 1 .
只从缓存中读取，如果缓存没有，则失败.
private void retrieveFromCache(){
GlideApp.with(this)
.asBitmap()
.load(URL)
.placeholder(R.drawable.default_avatar)
.error(R.drawable.image_error)
.fallback(R.drawable.fallback_nodata)
.onlyRetrieveFromCache(true)
.into(mImageView);
}
跳过缓存. 每次都从服务端获取最新.
/**
* 跳过缓存. 每次都从服务端获取最新.
* diskCacheStrategy: 磁盘缓存
* skipMemoryCache:内存缓存
*/
private void skipCache(){
GlideApp.with(this)
.asBitmap()
.load(URL)
.diskCacheStrategy(DiskCacheStrategy.NONE)
.skipMemoryCache(true)
.into(mImageView);
}
Glide 需要缓存的 图片资源 分为两类：
原始图片（Source） ：即图片源的图片初始大小 & 分辨率
转换后的图片(Result) ：经过 尺寸缩放 和 大小压缩等处理后的图片
内存缓存：防止应用 重复将图片数据 读取到内存当中
- 只缓存转换过后的图片
// 默认开启内存缓存，用户不需要作任何设置
Glide.with(this)
.load(url)
.into(imageView);
// 可通过 API 禁用 内存缓存功能
Glide.with(this)
.load(url)
.skipMemoryCache(true) // 禁用 内存缓存
.into(imageView);
Glide的内存缓存实现是基于：LruCache 算法（Least Recently Used） & 弱引用机制
LruCache算法原理：将 最近使用的对象 用强引用的方式 存储在LinkedHashMap中 ；当缓存满时 ，将最近最少使用的对象从内存中移除
弱引用：弱引用的对象具备更短生命周期，因为 **当JVM进行垃圾回收时，一旦发现弱引用对象，都会进行回收（无论内存充足否）
硬盘缓存：防止应用 重复从网络或其他地方重复下载和读取数据
-
可缓存原始图片 & 缓存转换过后的图片，用户自行设置
image.png
image.png
image.png
image.png
with（）
得到一个RequestManager对象
根据传入with()方法的参数 将Glide图片加载的生命周期与Activity/Fragment的生命周期进行绑定，从而实现自动执行请求，暂停操作
load（）
预先创建好对图片进行一系列操作（加载、编解码、转码）的对象，并全部封装到 DrawableTypeRequest `对象中。
into（）
即获取图片资源 & 加载图片并显示
