「Glide」中的Job

「Glide」源码解析系列

• 「Glide」一切的开始
• 「Glide」目标的肯定
• 「Glide」中的跟踪者
• 「Glide」请求的生成
• 「Glide」请求的开始
• 「Glide」中的Engine
• 「Glide」中的Job

承前启后

 

Engine

Engine将要加载的资源在引用缓存和内存缓存中均未命中，重任就交到了Job身上。

这节就来看看有几种Job，他们的功能是什么！

此节涉及到的类有
EngineJob
GlideExecutor
DecodeJob

Job流程

这是Engine.load方法中，Job逻辑调用相关的代码

 

Engine.load

梳理流程：

• 建立了engineJob和decodeJob对象，且engineJob为decodeJob的参数；
• key与engineJob的关联，并存储在jobs中
• 给engineJob加监听
• engineJob启动decodeJob

可以看出engineJob和decodeJob并非同一级，engineJob调用decodeJob使其工做，而后engineJob将工做状态回调到SingleRequest。（挖了这么深，终于触底反弹了）

EngineJob

先来看看EngineJob对象的产生

 

Engine

Pools.Pool的用法在「Glide」请求的生成一节中有介绍

这里经过pool复用EngineJob对象，经过init方法重置参数

 

EngineJob

这是EngineJob的构造参数，有没有注意到Executor，是否是眼前一亮【线程池】

线程相关内容能够看如下Android中的线程问题回忆下。

 

Engine

EngineJob的Executor来自EngineJobFactory

EngineJobFactory的Executor来自Engine

Engine来自GlideBuilder，这也是为何在「Glide」中的Engine一篇中花篇幅讲Engine的起源（早期的伏笔）

 

GlideBuilder

看到，全部的Executor来自GlideExecutor

GlideExecutor

以newSourceExecutor为例

 

image.png

计算最优线程数

 

GlideExecutor

 

GlideExecutor

注意红蓝框的区别

先生成ThreadPoolExecutor对象，做为参数生成GlideExecutor

 

GlideExecutor

重点：GlideExecutor采用了静态代理模式，外部将任务交到GlideExecutor执行，但实际的执行者是ThreadPoolExecutor，优势是统一了Glide中全部的Executor为GlideExecutor，达到了高内聚的目的

不清楚的可阅读常见设计模式总结

咱们知道线程池ThreadPoolExecutor的区别在于参数

 

GlideExecutor

重点看看DefaultThreadFactory

 

GlideExecutor

DefaultThreadFactory对象在初始化时传入了一个布尔值变量preventNetworkOperations译为阻止网络操做

这里是生成SourceExecutor传入的值为false，不进入if逻辑

而DiskCacheExecutor传入的是true

 

GlideExecutor

preventNetworkOperations参数的做用是什么

if逻辑内设置了StrictMode，不清楚的能够参考这篇文章StrictMode机制以及使用场景

 

GlideExecutor

效果是：有网络请求，杀死此线程

这下再回去看看传入的布尔值，

 

GlideExecutor

从DiskCache中加载资源执行的线程，禁止网络请求

 

GlideExecutor

从源加载资源执行的线程，容许网络请求

这是GlideExecutor中即重要有容易忽略的点

DecodeJob

有了EngineJob对象，也知道了其内部Executor的异同来看看DecodeJob

 

Engine

 

Engine

与EngineJob生成对象相同的手法：复用对象、重置参数

 

DecodeJob

注意到DecodeJob实现了Runnable接口，而EngineJob内有Executor

 

EngineJob

果不其然，DecodeJob对象被放到了EngineJob中Executor执行了

中途Executor的选择跳过。。。

来到DecodeJob的run

Run

 

DecodeJob

 

DecodeJob

经过变量runReason选择性的进入分支

stage记录目前执行阶段，currentGenerator记录目前Generator

runGenerators方法推动stage和currentGenerator的变化，进入下一阶段

 

DecodeJob

在runGenerators中while一直在推动stage和currentGenerator向下一阶段变化

 

最主要到几个阶段

各级缓存和源的处理都在其中

总结

Engine只是个状态观察者，实际还要回调到SingleRequest对象

实际的工做由DecodeJob作，而EngineJob负责分配DecodeJob工做所处的线程

做者：s1991721 连接：https://www.jianshu.com/p/5170ac35cae6 来源：简书 著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。