「Glide」源碼解析系列
承前啟后
RequestManager上所有的Request歸RequestTracker統(tǒng)一管理
Request開始加載了延蟹，這節(jié)就來看看Request
此節(jié)涉及到的類有
SingleRequest
StateVerifier
StateVerifier
requestTracker調(diào)用了request的begin方法
最開始的兩個(gè)方法進(jìn)行狀態(tài)判斷
- assertNotCallingCallbacks：判斷request是否正在回調(diào)瞧剖，回調(diào)中調(diào)用begin則會(huì)拋出異常
回調(diào)時(shí)通過設(shè)置isCallingCallbacks標(biāo)識(shí)
- stateVerifier用來標(biāo)識(shí)此request是否是被回收的狀態(tài)
StateVerifier本身是抽象類，通過setRecycled設(shè)置是否回收標(biāo)識(shí)滤祖，判斷時(shí)調(diào)用throwIfRecycled方法，內(nèi)部進(jìn)行相應(yīng)的異常處理
SingleRequest變量stateVerifier由StateVerifier的靜態(tài)方法生成
Request開始工作的時(shí)候就會(huì)判斷當(dāng)前狀態(tài)是否正常隧魄，否則就拋異常
request對(duì)象是放在FactoryPools中的赴魁，復(fù)用在所難免。那request對(duì)象是在什么時(shí)候重置的狀態(tài)呢空厌？
代碼中可以看出庐船，request在從池子中取出時(shí)，就重置了狀態(tài)嘲更。
單獨(dú)拿出StateVerifier來講筐钟，不是源碼有很多技巧，而是這種設(shè)計(jì)模式：抽出專門的類來進(jìn)行對(duì)象狀態(tài)的管理赋朦，降低了耦合性篓冲，提高了類功能的專一性
model
狀態(tài)正常，流程繼續(xù)
當(dāng)model為null便回調(diào)onLoadFailed宠哄，那model是什么
涉過千山萬水壹将，終于找到了。外部通過load方法傳入的對(duì)象
類型有：Bitmap毛嫉、Drawable诽俯、String、Uri承粤、File暴区、Integer、URL辛臊、byte等
到此大概有個(gè)概念仙粱，load的為要加載的原始資源如上一行所列，as的是加載資源后要轉(zhuǎn)換的類型如asDrawable彻舰，model在此就充當(dāng)了原始資源伐割，如網(wǎng)絡(luò)圖片URL候味、圖片流byte、資源圖片id等
status
有了model隔心，繼續(xù)往下走
status是request當(dāng)前的狀態(tài)標(biāo)識(shí)白群，在request的初始化的時(shí)候status = Status.PENDING
最終都會(huì)進(jìn)入onSizeReady方法
修改了status = Status.RUNNING，engine.load就結(jié)束了
返回到begin方法
剛修改的status = Status.RUNNING济炎，派上了用場
回調(diào)target.onLoadStarted川抡，并將占位圖回調(diào)回去
誒？须尚？
status = Status.RUNNING表示request正在工作把碌獭！耐床！那
請求的圖片呢密幔？問什么沒有網(wǎng)絡(luò)請求獲取圖片流？裁剪圖片撩轰？等一系列加載圖片的步驟呢胯甩？
哪里漏掉了？
這里面做了什么堪嫂？下節(jié)繼續(xù)
總結(jié)
RequestTracker啟動(dòng)了request對(duì)象
request對(duì)象將更加詳細(xì)的請求參數(shù)匯總偎箫，并load進(jìn)engine
這里request對(duì)象主要起到記錄加載過程中所處的階段
