Picasso 是一款老牌的圖片加載器,特別小巧,功能上雖然比不上 Glide 和 Fresco。可是通常的圖片加載需求都能知足。關鍵是 square 出品,JakeWharton 大神主導的項目,必屬精品,和自家的 OkHtttp 無縫銜接。html
分析版本: 2.5.2java
Picasso.with(this)
.load("https://www.kaochong.com/static/imgs/ic_course_logo_92e76ec.png")
.into(imageView);
複製代碼
看了幾個開源庫,都是一個套路,先用門面模式提供一個單例給外部訪問,這裏是 Picasso,其餘開源框架如 EventBus,Retrofit 都是同樣的。由於開源須要知足不少 feature 避免不了使用一堆參數,建造者模式也是很常見的,幾乎每一個開源庫必備。數組
public static Picasso with(Context context) {
if (singleton == null) {
synchronized (Picasso.class) {
if (singleton == null) {
singleton = new Builder(context).build();
}
}
}
return singleton;
}
複製代碼
接着看 load 方法:緩存
load 有 4 個重載方法:bash
load(Uri)
load(String)
load(File)
load(int)
分別對應加載不一樣的來源。 這個方法會構造一個 RequestCreator
對象並返回。這個 RequestCreator
看名字就知道,是負責建立圖片請求的。RequestCreator
和 Request
的區別在於,Request
是最終建立完成的請求,全部關於圖片的信息都在這個請求裏,包括圖片大小,圖片怎麼轉換,圖片是否有漸變更畫等等。而 RequestCreator
是一個 Request
的生產者,負責把請求參數組合而後建立成一個 Request
。網絡
Picasso.with(this).load("url").placeholder()
.resize()
.transform()
.error()
.noFade()
.networkPolicy()
.centerCrop()
.into(imageview);
複製代碼
上面這段代碼中,load()
返回的是 RequestCreator
對象,後面從 placeholder()
到 into()
都是 RequestCreator
的中的方法。直到在 into()
中才會把最終圖片請求 Request
對象構造出來處理。因此以前都是一堆參數的設置。app
以 load(String)
爲例看看內部的操做:框架
public RequestCreator load(String path) {
if (path == null) {
return new RequestCreator(this, null, 0);
}
if (path.trim().length() == 0) {
throw new IllegalArgumentException("Path must not be empty.");
}
return load(Uri.parse(path));
}
複製代碼
load(String)
其實調用的是 load(Uri)
:ide
public RequestCreator load(Uri uri) {
return new RequestCreator(this, uri, 0);
}
複製代碼
RequestCreator 的構造中,傳入了 picasso 實例,用傳入的 Uri、resourceId、默認 Bitmap 參數在內部構造一個 Request.Builder 實例,用於拼接後續參數最終 build 出一個 Request 實例。oop
RequestCreator(Picasso picasso, Uri uri, int resourceId) {
if (picasso.shutdown) {
throw new IllegalStateException(
"Picasso instance already shut down. Cannot submit new requests.");
}
this.picasso = picasso;
this.data = new Request.Builder(uri, resourceId, picasso.defaultBitmapConfig);
}
複製代碼
後面的 error()
、placeholder()
等等就很簡單了,就是把參數進行賦值修改。
關鍵的地方來了。 into 有 4 個重載方法:
into(Target)
into(RemoteViews,int,int,Notification)
into(RemoteViews,int,int[])
into(ImageView)
into(ImageView,Callback)
第 1 個用於實現了 Target 接口的對象,第 二、3 用於 RemoteView 的加載,分別用於通知和桌面小部件。4 和 5 就是咱們經常使用的方法,把圖片加載到 ImageView, 區別是 5 有回調。這 5 個流程基本是同樣,咱們就看 5 來看看加載的具體過程。
public void into(ImageView target, Callback callback) {
// 獲取加載的開始時間,納秒級別的,由於加載很快的
long started = System.nanoTime();
// 檢查是否在主線程
checkMain();
// target 不能爲空,否則無法加載
if (target == null) {
throw new IllegalArgumentException("Target must not be null.");
}
// 沒圖片就設置佔位圖
if (!data.hasImage()) {
picasso.cancelRequest(target);
if (setPlaceholder) {
setPlaceholder(target, getPlaceholderDrawable());
}
return;
}
// 若是是 fit 模式,圖片自適應控件的大小,須要等 View layout 完肯定寬和高再加載。這裏採用的是監聽 OnPreDraw 接口的方法。
if (deferred) {
// fit 模式不能指定圖片大小,和 resize 衝突
if (data.hasSize()) {
throw new IllegalStateException("Fit cannot be used with resize.");
}
int width = target.getWidth();
int height = target.getHeight();
if (width == 0 || height == 0) {
if (setPlaceholder) {
setPlaceholder(target, getPlaceholderDrawable());
}
picasso.defer(target, new DeferredRequestCreator(this, target, callback));
return;
}
data.resize(width, height);
}
// 建立出最終的 Request
Request request = createRequest(started);
// 建立 Request key 用於緩存 Request
String requestKey = createKey(request);
// 首先從內存中查找,內存中有就把這個請求取消,直接從內存加載
if (shouldReadFromMemoryCache(memoryPolicy)) {
Bitmap bitmap = picasso.quickMemoryCacheCheck(requestKey);
if (bitmap != null) {
picasso.cancelRequest(target);
setBitmap(target, picasso.context, bitmap, MEMORY, noFade, picasso.indicatorsEnabled);
if (picasso.loggingEnabled) {
log(OWNER_MAIN, VERB_COMPLETED, request.plainId(), "from " + MEMORY);
}
if (callback != null) {
callback.onSuccess();
}
return;
}
}
// 設置佔位圖
if (setPlaceholder) {
setPlaceholder(target, getPlaceholderDrawable());
}
// 構造出 Action
Action action =
new ImageViewAction(picasso, target, request, memoryPolicy, networkPolicy, errorResId,
errorDrawable, requestKey, tag, callback, noFade);
// 將 Action 入隊執行
picasso.enqueueAndSubmit(action);
}
複製代碼
into 中會檢查調用代碼是否在主線程,由於要更新 View,還有回調,確定要在主線程。而後判斷是否有圖片的源地址,若是給的是個 null,那麼直接就終止請求了。若是設置了 fit 模式(自適應 ImageView 的寬和高),fit 模式和 resize 衝突,既然自適應寬高了,確定就不能指定寬高。自適應 ImageView 的寬和高須要等待測量完成後獲得寬高再繼續請求,不然獲得的寬高是 0,Picasso 使用 ViewTreeObserver 監聽 ImageView 的 OnPreDrawListener 接口來獲取寬和高,詳細的代碼能夠看 DeferredRequestCreator
這個類。
而後建立出最終的 Request,此時的 Request 就表明了最終的圖片請求信息。而後沒有直接去請求,而是去緩存中查找,有的話就直接取消請求從內存中加載。沒有的話就建立一個 ImageViewAction
, 它是 Action
的子類。加載到不一樣的 Target 會使用不一樣的 Action。加載到 Target
使用 TargetAction
。加載到通知就使用 NotificationAction
。能夠去其餘的 into
方法中查看源碼。
Action
是一個抽象類, 內部封裝了圖片的請求信息,以及當前圖片請求的其餘參數(緩存策略,網絡策略,是否取消了請求,Tag, 是否有動畫等等)。須要子類實現 2 個方法:
// 解析圖片完成後拿到 Bitmap,子類定義如何顯示
abstract void complete(Bitmap result, VanGogh.LoadedFrom from);
// 解析發送錯誤
abstract void error(Exception e);
複製代碼
這下能夠理解它爲啥叫 Action
了,它須要子類本身處理 Bitmap。定義本身的 Action (行爲), 成功拿到 Bitmap 怎麼辦,發生錯誤了怎麼辦?
ImageViewAction 的實現很簡單,內部經過自定義 BitmapDrawable 來繪製本身的圖像,實現漸變。加載錯誤的時候就放置佔位圖。
接着看這最後一行 picasso.enqueueAndSubmit(action);
看看把 action
扔到哪去處理了。
void enqueueAndSubmit(Action action) {
Object target = action.getTarget();
if (target != null && targetToAction.get(target) != action) {
// 取消原來 target 的 action,將新的 action 存入
cancelExistingRequest(target);
targetToAction.put(target, action);
}
submit(action);
}
void submit(Action action) {
dispatcher.dispatchSubmit(action);
}
void dispatchSubmit(Action action) {
handler.sendMessage(handler.obtainMessage(REQUEST_SUBMIT, action));
}
void performSubmit(Action action, boolean dismissFailed) {
// 處理暫停的請求
if (pausedTags.contains(action.getTag())) {
pausedActions.put(action.getTarget(), action);
if (action.getPicasso().loggingEnabled) {
log(OWNER_DISPATCHER, VERB_PAUSED, action.request.logId(),
"because tag '" + action.getTag() + "' is paused");
}
return;
}
// 將 action 合併,action 的 key 是根據 Request 中圖片參數生成的,
// 這裏的意思就是若是圖片請求徹底同樣,只是 Action 不同,只須要請求一次拿到 Bitmap 就行,
// 由於圖片信息徹底相同,一個 Request 對應了對個 Action
BitmapHunter hunter = hunterMap.get(action.getKey());
if (hunter != null) {
hunter.attach(action);
return;
}
if (service.isShutdown()) {
if (action.getPicasso().loggingEnabled) {
log(OWNER_DISPATCHER, VERB_IGNORED, action.request.logId(), "because shut down");
}
return;
}
// 構造出 hunter
hunter = forRequest(action.getPicasso(), this, cache, stats, action);
// 扔給線程池執行並得到結果
hunter.future = service.submit(hunter);
// 緩存 hunter
hunterMap.put(action.getKey(), hunter);
// 是否移除請求失敗的 Action
if (dismissFailed) {
failedActions.remove(action.getTarget());
}
}
複製代碼
跟蹤能夠發現交給 Dispatcher 中的 handler 處理了。
在 performSubmit()
中重點看 forRequest()
方法構造出 BitmapHunter 實例。
static BitmapHunter forRequest(Picasso picasso, Dispatcher dispatcher, Cache cache, Stats stats, Action action) {
Request request = action.getRequest();
List<RequestHandler> requestHandlers = picasso.getRequestHandlers();
for (int i = 0, count = requestHandlers.size(); i < count; i++) {
RequestHandler requestHandler = requestHandlers.get(i);
if (requestHandler.canHandleRequest(request)) {
return new BitmapHunter(picasso, dispatcher, cache, stats, action, requestHandler);
}
}
return new BitmapHunter(picasso, dispatcher, cache, stats, action, ERRORING_HANDLER);
}
複製代碼
forRequest()
中遍歷全部的 RequestHandler。誰能處理 Action 就處理這個 Action。這是典型的責任鏈模式- 《JAVA與模式》之責任鏈模式。
在 Picasso 實例初始化的時候就把這些 RequestHandler 都加入了列表中。
Picasso(Context context, Dispatcher dispatcher, Cache cache, Listener listener,
RequestTransformer requestTransformer, List<RequestHandler> extraRequestHandlers...) {
List<RequestHandler> allRequestHandlers =
new ArrayList<RequestHandler>(builtInHandlers + extraCount);
// ResourceRequestHandler needs to be the first in the list to avoid
// forcing other RequestHandlers to perform null checks on request.uri
// to cover the (request.resourceId != 0) case.
allRequestHandlers.add(new ResourceRequestHandler(context));
if (extraRequestHandlers != null) {
allRequestHandlers.addAll(extraRequestHandlers);
}
allRequestHandlers.add(new ContactsPhotoRequestHandler(context));
allRequestHandlers.add(new MediaStoreRequestHandler(context));
allRequestHandlers.add(new ContentStreamRequestHandler(context));
allRequestHandlers.add(new AssetRequestHandler(context));
allRequestHandlers.add(new FileRequestHandler(context));
allRequestHandlers.add(new NetworkRequestHandler(dispatcher.downloader, stats));
requestHandlers = Collections.unmodifiableList(allRequestHandlers);
}
複製代碼
每一個 RequestHandler 重寫 canHandleRequest
來代表本身能處理哪一種請求。
BitmapHunter 是一個 Runnable
, 構造以後交給線程池處理。來看看 BitmapHunter 的 run()
。
@Override public void run() {
try {
updateThreadName(data);
// 解析圖片獲得 Bitmap
result = hunt();
// 由 dispatcher 分發解析圖片的結果。
if (result == null) {
dispatcher.dispatchFailed(this);
} else {
dispatcher.dispatchComplete(this);
}
} catch (Downloader.ResponseException e) {
if (!e.localCacheOnly || e.responseCode != 504) {
exception = e;
}
dispatcher.dispatchFailed(this);
} catch (NetworkRequestHandler.ContentLengthException e) {
exception = e;
dispatcher.dispatchRetry(this);
} catch (IOException e) {
exception = e;
dispatcher.dispatchRetry(this);
} catch (OutOfMemoryError e) {
StringWriter writer = new StringWriter();
stats.createSnapshot().dump(new PrintWriter(writer));
exception = new RuntimeException(writer.toString(), e);
dispatcher.dispatchFailed(this);
} catch (Exception e) {
exception = e;
dispatcher.dispatchFailed(this);
} finally {
Thread.currentThread().setName(Utils.THREAD_IDLE_NAME);
}
}
複製代碼
首先由 hunt()
方法解析出 Bitmap,再把解析後的結果交給 Dispatcher 來分發,成功了咋樣,失敗了咋樣,失敗了是否重試。Dispatcher 在 Picasso 中扮演了重要的角色,負責整個流程的調度。
看看 hunt() 是怎麼解析出 Bitmap 的。首先仍是從內存中取,每一個 RequestHandler 對象都持有了下載器,用於下載網絡圖片。網絡圖片下載完是一個流須要解析成 Bitmap,非網絡的就直接獲得一個 Bitmap。最後在處理變換操做獲得最終的 bitmap。
Bitmap hunt() throws IOException {
Bitmap bitmap = null;
// 從內存緩存中取
if (shouldReadFromMemoryCache(memoryPolicy)) {
bitmap = cache.get(key);
if (bitmap != null) {
// 統計 緩存命中
stats.dispatchCacheHit();
loadedFrom = MEMORY;
return bitmap;
}
}
data.networkPolicy = retryCount == 0 ? NetworkPolicy.OFFLINE.index : networkPolicy;
// 用下載器請求url獲得結果
RequestHandler.Result result = requestHandler.load(data, networkPolicy);
if (result != null) {
loadedFrom = result.getLoadedFrom();
exifRotation = result.getExifOrientation();
bitmap = result.getBitmap();
// 從流中解析出 Bitmap
if (bitmap == null) {
InputStream is = result.getStream();
try {
bitmap = decodeStream(is, data);
} finally {
Utils.closeQuietly(is);
}
}
}
if (bitmap != null) {
// 解碼
stats.dispatchBitmapDecoded(bitmap);
if (data.needsTransformation() || exifRotation != 0) {
// 同一時間只處理一個 bitmap
synchronized (DECODE_LOCK) {
if (data.needsMatrixTransform() || exifRotation != 0) {
bitmap = transformResult(data, bitmap, exifRotation);
}
if (data.hasCustomTransformations()) {
bitmap = applyCustomTransformations(data.transformations, bitmap);
}
}
}
}
return bitmap;
}
複製代碼
Dispatcher 內部實例化了一個 HandlerThread,全部的調度都是經過這個子線程上執行,經過這個子線程的 Handler 和 主線程的 Handler 以及線程池互相通訊。
解析圖片的獲得 Bitmap 後,Dispatcher 會調度到 dispatchComplete
,跟蹤代碼走到 performComplete
。
void performComplete(BitmapHunter hunter) {
// 是否寫入內存緩存
if (shouldWriteToMemoryCache(hunter.getMemoryPolicy())) {
cache.set(hunter.getKey(), hunter.getResult());
}
hunterMap.remove(hunter.getKey());
// 批處理 hunter
batch(hunter);
}
// 執行批處理
void performBatchComplete() {
List<BitmapHunter> copy = new ArrayList<BitmapHunter>(batch);
batch.clear();
mainThreadHandler.sendMessage(mainThreadHandler.obtainMessage(HUNTER_BATCH_COMPLETE, copy));
logBatch(copy);
}
複製代碼
最終將一批 BitmapHunter 打包一塊兒扔給主線程處理。跟蹤代碼到 Picasso
類中的主線程的 Handler, 遍歷執行 complete(hunter)
@SuppressWarnings("unchecked") List<BitmapHunter> batch = (List<BitmapHunter>) msg.obj;
//noinspection ForLoopReplaceableByForEach
for (int i = 0, n = batch.size(); i < n; i++) {
BitmapHunter hunter = batch.get(i);
hunter.picasso.complete(hunter);
}
複製代碼
complete(hunter)
中將調用 Action
的 complete
/error
方法進行最後一步把 Bitmap 顯示到 target 上,並進行相應的成功或者失敗回調。
引用一下blog.happyhls.me的圖(本身懶得畫了%>_<%),上面的流程能夠總結成:
看源碼的過程當中發現 Dispatcher 裏面一堆 handler send message,和 ActivityThread 中 H 和 AMS 通訊很像,都用 Handler 來進行通訊。Handler 真是 Android 的精髓。