「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 來源：簡書 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。