「Glide」源碼解析系列
承前啟后
Engine將要加載的資源在引用緩存和內存緩存中均未命中塔拳，重任就交到了Job身上颗味。
這節(jié)就來看看有幾種Job稀并，他們的功能是什么责语！
此節(jié)涉及到的類有
EngineJob
GlideExecutor
DecodeJob
Job流程
這是Engine.load方法中吧雹，Job邏輯調用相關的代碼
梳理流程：
- 創(chuàng)建了engineJob和decodeJob對象，且engineJob為decodeJob的參數巨缘；
- key與engineJob的關聯，并存儲在jobs中
- 給engineJob加監(jiān)聽
- engineJob啟動decodeJob
能夠看出engineJob和decodeJob并不是同一級，engineJob調用decodeJob使其工作嗜愈，然后engineJob將工作狀態(tài)回調到SingleRequest。（挖了這么深莽龟，終于觸底反彈了）
EngineJob
先來看看EngineJob對象的產生
Pools.Pool的用法在「Glide」請求的生成一節(jié)中有介紹
這里通過pool復用EngineJob對象蠕嫁，通過init方法重置參數
這是EngineJob的構造參數，有沒有注意到Executor毯盈，是不是眼前一亮【線程池】
線程相關內容可以看以下Android中的線程問題回憶下剃毒。
EngineJob的Executor來自EngineJobFactory
EngineJobFactory的Executor來自Engine
Engine來自GlideBuilder，這也是為什么在「Glide」中的Engine一篇中花篇幅講Engine的起源（早期的伏筆）
看到搂赋，所有的Executor來自GlideExecutor
GlideExecutor
以newSourceExecutor為例
計算最優(yōu)線程數
注意紅藍框的區(qū)別
先生成ThreadPoolExecutor對象赘阀，作為參數生成GlideExecutor
重點：GlideExecutor采用了靜態(tài)代理模式，外部將任務交到GlideExecutor執(zhí)行脑奠，但實際的執(zhí)行者是ThreadPoolExecutor基公，優(yōu)點是統(tǒng)一了Glide中所有的Executor為GlideExecutor，達到了高內聚的目的
不清楚的可閱讀常見設計模式總結
我們知道線程池ThreadPoolExecutor的區(qū)別在于參數
重點看看DefaultThreadFactory
DefaultThreadFactory對象在初始化時傳入了一個布爾值變量preventNetworkOperations譯為阻止網絡操作
這里是生成SourceExecutor傳入的值為false捺信，不進入if邏輯
而DiskCacheExecutor傳入的是true
preventNetworkOperations參數的作用是什么
if邏輯內設置了StrictMode酌媒，不清楚的可以參考這篇文章StrictMode機制以及使用場景
效果是：有網絡請求，殺死此線程
這下再回去看看傳入的布爾值迄靠，
從DiskCache中加載資源執(zhí)行的線程秒咨，禁止網絡請求
從源加載資源執(zhí)行的線程，允許網絡請求
這是GlideExecutor中即重要有容易忽略的點
DecodeJob
有了EngineJob對象掌挚，也知道了其內部Executor的異同來看看DecodeJob
與EngineJob生成對象相同的手法：復用對象雨席、重置參數
注意到DecodeJob實現了Runnable接口，而EngineJob內有Executor
果不其然吠式，DecodeJob對象被放到了EngineJob中Executor執(zhí)行了
中途Executor的選擇跳過陡厘。。特占。
來到DecodeJob的run
Run
通過變量runReason選擇性的進入分支
stage記錄目前執(zhí)行階段糙置，currentGenerator記錄目前Generator
runGenerators方法推進stage和currentGenerator的變化，進入下一階段
在runGenerators中while一直在推進stage和currentGenerator向下一階段變化
各級緩存和源的處理都在其中
總結
Engine只是個狀態(tài)觀察者是目，實際還要回調到SingleRequest對象
實際的工作由DecodeJob做谤饭，而EngineJob負責分配DecodeJob工作所處的線程
