Android源码分析计划

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:https://img.haomeiwen.com/i4179767/e744c843a20af892.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
• 设计模式
  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 缓存所有版本的图像（默认行为）

只从缓存中读取，如果缓存没有，则失败.

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（）

即获取图片资源 & 加载图片并显示