前言
圖片加載框架Picasso相信大家都已經用過很多次了，對它們的使用方法也早就熟稔於心了，那麼本文就Picasso的源碼進行剖析，學習設計者的優秀的代碼設計理念和方法。
幾個重要的類
在源碼解析開始之前，筆者認爲有必要對Picasso的幾個重要的類進行簡單梳理，以便於後面遇到這些組件的時候可以馬上知道它的作用是什麼。
1、OkHttp3Downloader
Picasso藉助該類來下載圖片，並把圖片緩存在磁盤空間上。實際上，它用的是OkHttp3這個網絡通信庫來完成下載任務。我們看看它的構造方法：
public OkHttp3Downloader(final Context context) {
this(Utils.createDefaultCacheDir(context));
}
public OkHttp3Downloader(final File cacheDir) {
this(cacheDir, Utils.calculateDiskCacheSize(cacheDir));
}
public OkHttp3Downloader(final File cacheDir, final long maxSize) {
this(new OkHttpClient.Builder().cache(new Cache(cacheDir, maxSize)).build());
sharedClient = false;
}
public OkHttp3Downloader(OkHttpClient client) {
this.client = client;
this.cache = client.cache();
}
通過Utils.createDefaultCacheDir(context)方法來創建緩存文件夾，通過Utils.calculateDiskCacheSize(cacheDir)來確定磁盤緩存空間的大小。由此我們可以知道，Picasso利用了OkHttp3的下載機制來緩存圖片，並且磁盤緩存的大小也是可以配置的，默認實現是可用空間的2%且不少於5MB.
2、LruCache
如果說OkHttp3Downloader實現了磁盤緩存，那麼LruCache則是實現了內存緩存。內存緩存的意義在於避免圖片過多地堆積在內存中而導致OOM。這裏使用的是Lru算法(Least recently used,最近最少使用算法)，該算法可以使得經常使用的圖片駐留於內存中，避免了反覆從磁盤加載圖片而導致內存抖動的問題。
3、PicassoExecutorService
這個實際上是一個線程池，它的主要作用就在於把下載任務分配到各個子線程中去執行。
class PicassoExecutorService extends ThreadPoolExecutor {
private static final int DEFAULT_THREAD_COUNT = 3;
PicassoExecutorService() {
super(DEFAULT_THREAD_COUNT, DEFAULT_THREAD_COUNT, 0, TimeUnit.MILLISECONDS,
new PriorityBlockingQueue<Runnable>(), new Utils.PicassoThreadFactory());
}
}
從構造方法可以看出，該線程池的默認實現是3個核心線程且最大線程數不超過3條。也就是說，默認情況下Picasso在下載圖片的時候，最大的同時下載數量是3。但實際上，核心線程和最大線程數是會隨着設備的網絡狀態而改變的，比如WIFI狀態下是4條核心線程，而4G狀態下是3條核心線程，以此類推。
4、Dispatcher
顧名思義，該類是一個調度器，負責分發、調度和處理Picasso產生的各種事件。在這個調度器內，需要關注的分別是dispatcherThread和handler這兩個成員變量。可以先看一下Dispatcher的構造方法：
Dispatcher(Context context, ExecutorService service, Handler mainThreadHandler,
Downloader downloader, Cache cache, Stats stats) {
this.dispatcherThread = new DispatcherThread();
this.dispatcherThread.start();
this.handler = new DispatcherHandler(dispatcherThread.getLooper(), this);
//省略...
}
其中，DispatcherThread繼承自Thread，是一條子線程；而DispatcherHandler則繼承自Handler，熟悉Handler的同學，肯定知道這是用於處理線程間通信的常見方法。由此可知，Dispatcher這個調度器的主要工作都是在DispatcherThread這條線程內完成，而線程切換的任務則是DispatcherHandler來完成。
5、Request
Request封裝了有關一次圖片請求的所有信息，比如圖片的url、圖片的變換策略等，這些都是不可更改的信息。舉個例子來說，Picasso.get().load(url).centerCrop().rotate(15).into(imageview);上面的調用鏈，Request會封裝centerCrop、rotate等信息。與Request相關的是RequestCreator，它可以看作是一個建造器，配置了圖片請求的信息。
6、RequestHandler
上面說到Picasso將圖片請求封裝成了一個Request，而處理Request的組件則是RequestHandler，因爲圖片的請求是多種多樣的，有的是提供了一個URL從網絡獲取圖片；有的則是提供了一個resourceId，從本地加載圖片，不同的請求會有不同的加載方式。因此Picasso提供了多個RequestHandler來應對不同的情況，用戶也可以自定義RequestHandler來實現自己的需求，只需要重寫canHandleRequest方法和load方法，如下所示：
public abstract class RequestHandler {
public abstract boolean canHandleRequest(Request data);
@Nullable public abstract Result load(Request request, int networkPolicy) throws IOException;
}
由此看出，Picasso在處理不同的圖片請求的時候，將不同請求的實現方式放在了所對應的handler去實現，這樣便實現了圖片請求和處理請求的解耦合，這樣用戶自行拓展以適應不同場景下的圖片加載需求。
加載圖片流程的詳細分析
1、Picasso.get()
該方法的調用是一切流程的起點，通過該方法我們可以獲取一個Picasso的實例。在Picasso以前的版本，我們是通過Picasso.with(context)的方式來獲取實例的，這限制了我們只能在有上下文context的環境下使用Picasso。我們來看看這個方法的實現以及探究下爲什麼新版本的Picasso不用context這個參數了。
//代碼清單：Picasso#get()
public static Picasso get() {
if (singleton == null) { //第一次判空
synchronized (Picasso.class) {
if (singleton == null) { //上鎖後的第二次判空
if (PicassoProvider.context == null) { //確保有context
throw new IllegalStateException("context == null");
}
singleton = new Builder(PicassoProvider.context).build();
}
}
}
return singleton;
}
從上面的代碼，我們可以看出Picasso使用了DCL(double check lock)形式的單例模式，確保全局只有一個Picasso對象。同時我們注意到context對象是由PicassoProvider.context來提供的，顯然PicassoProvider是一個ContentProvider，是Android的四大組件之一，通過它也是可以獲取到我們應用的上下文環境的。Picasso通過這樣形式的改動，使得Picasso可以適應更多不同的環境，比如在沒有context的條件下僅僅利用Picasso進行圖片的預下載。
1-1、Picasso實例的構造
Picasso實例的構造是通過構造器模式來進行創建的，Picasso.get()方法獲取的是默認配置的Picasso實例，我們也可以通過Picasso.Builder來靈活配置適合我們需求的Picasso實例。我們來看看Picasso.Builder.build()方法，看它是怎樣創建一個實例的：
//代碼清單1-1：Picasso.Builder#build()
public Picasso build() {
Context context = this.context;
if (downloader == null) {
downloader = new OkHttp3Downloader(context);
}
if (cache == null) {
cache = new LruCache(context);
}
if (service == null) {
service = new PicassoExecutorService();
}
if (transformer == null) {
transformer = RequestTransformer.IDENTITY;
}
Stats stats = new Stats(cache);
Dispatcher dispatcher = new Dispatcher(context, service, HANDLER, downloader, cache, stats);
return new Picasso(context, dispatcher, cache, listener, transformer, requestHandlers, stats,
defaultBitmapConfig, indicatorsEnabled, loggingEnabled);
}
顯然，這裏實例化了上面提到的幾個重要組件，如downloader、cache、service、dispatcher等，它們都在Picasso的工作過程中起着重要作用。在Picasso構造方法的內部，還初始化了一系列的RequestHandler，例如ResourceRequestHandler、NetworkRequestHandler等，這些Handler根據不同形式的圖片請求來執行相應的邏輯。
2、Picasso#load(String)
通過Picasso.get()獲取到Picasso對象後，我們接下來就會通過load的一系列重載方法來確定圖片的來源，可以是uri、file或者string等。我們選取其中一個load方法來看看源碼：
//代碼清單2：Picasso#load(string)
public RequestCreator load(@Nullable Uri uri) {
return new RequestCreator(this, uri, 0);
}
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);
}
這裏創建了RequestCreator，前面提到過Picasso將圖片的來源url、圖片的placeholder、圖片的變換操作等一系列信息封裝到了Request內，而RequestCreator就相當於是Request的一個構造器。
2-1、RequestCreator的相關方法
以上獲取到了RequestCreator實例，通常我們接下來的做法是對這一次的圖片請求配置各種功能，舉個例子來說：Picasso.get().load(url).placeholder(resId)是我們常見的一種調用，這樣給圖片設置了佔位圖。實際上，RequestCreator的一系列方法都是將用戶的操作暫存在RequestCreator的成員變量內部，等到用戶調用into(imageview)方法時，再把所有參數填充到Request。
3、PicassoCreator#into(imageview)
在確定圖片的相關操作後，我們最後會調用into方法，也即是：Picasso.get().load(url).placeholder(placeholderResid).into(target);前面的一切工作都是準備工作(獲取Picasso實例，設置圖片來源以及設置圖片的操作)，接下來就是Picasso將這些操作完成並顯示在target上的過程，我們來詳細分析這個過程。先來看into方法的源碼：
//代碼清單3：PicassoCreator#into()
public void into(ImageView target, Callback callback) {
long started = System.nanoTime();
checkMain(); //確保在主線程調用該方法
if (target == null) {
throw new IllegalArgumentException("Target must not be null.");
}
//如果圖片的uri爲null，則取消請求，然後設置佔位圖
if (!data.hasImage()) {
picasso.cancelRequest(target);
if (setPlaceholder) {
setPlaceholder(target, getPlaceholderDrawable());
}
return;
}
//如果調用了RequestCreator#fit()方法，那麼deferred會被設置爲true
//這是因爲fit()方法需要適應ImageView的大小，必須等到ImageView的layout過程完畢才能fit()
//因此，這裏實際上是推遲了圖片的加載過程，即Picasso#defer()
if (deferred) {
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 = createRequest(started); //根據RequestCreator的參數來創建一個Request
String requestKey = createKey(request); //創建與該Request對應的一個Key
//如果內存緩存可用，那麼直接從內存緩存獲取Request對應的Bitmap，並取消請求
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);
picasso.enqueueAndSubmit(action); //排隊，等待調度
}
簡單來說，into方法所做的工作主要是生成一個Request，並且封裝成一個Action，最後通過picasso.enqueueAndSubmit(action)把該動作排隊等待執行。最後會調用到Dispatcher#submit方法。
4、Dispatcher#submit(Action)
void dispatchSubmit(Action action) {
handler.sendMessage(handler.obtainMessage(REQUEST_SUBMIT, action));
}
顯然，這裏通過DispatcherHandler發送了一個submit消息，那麼根據前面所述，這個消息將會被投遞到DispatcherThread線程。根據Handler的相關知識，該消息會在handler的handleMessage方法得到處理，即：
//Dispatcher.DispatcherHandler#handleMessage
private static class DispatcherHandler extends Handler {
//...
@Override
public void handleMessage(final Message msg) {
switch (msg.what) {
case REQUEST_SUBMIT: {
Action action = (Action) msg.obj;
dispatcher.performSubmit(action);
break;
}
//...
}
}
4-1、Dispatcher#performSubmit(action)
此時，線程已經被切換到了DispatcherThread，接着調用了performSubmit方法。因此我們可以知道，Dispatcher起到了排隊、分發請求、處理請求結果的作用。但實際上請求的處理過程，比如從url上下載圖片等都是放到線程池去實現的。我們先來看performSubmit方法如下：
//代碼清單4-1：Dispatcher#performSubmit(action)
void performSubmit(Action action, boolean dismissFailed) {
//省略...
hunter = forRequest(action.getPicasso(), this, cache, stats, action);
hunter.future = service.submit(hunter);
hunterMap.put(action.getKey(), hunter);
}
//BitmapHunter#forRequest
static BitmapHunter forRequest(Picasso picasso, Dispatcher dispatcher, Cache cache, Stats stats,
Action action) {
Request request = action.getRequest();
List<RequestHandler> requestHandlers = picasso.getRequestHandlers();
//找到一個可以處理該Request的RequestHandler
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);
}
從上面的代碼可以看出，先是生成了一個BitmapHunter，這個類的作用顧名思義，就是獲取Bitmap，它是一個Runnable，它內部根據Request的不同類型來確定不同的獲取方法(實際上是RequestHandler在起作用)。
緊接着，調用了service.submit(hunter)方法，這裏的service實際上就是PicassoExecutorService線程池，將BitmapHunter這個runnable投遞進了線程池，如果線程池有空閒的線程那麼就會執行這個runnable，否則阻塞等待。最終，如果runnable獲得執行的機會，它的run()方法會被調用。
5、BitmapHunter#run()
那麼代碼運行到這裏，線程又切換到了PicassoExecutorService內的某一條線程。也就是說，加載圖片的工作是在這些子線程內執行的。我們來看看run()：
//代碼清單5：BitmapHunter#run
@Override public void run() {
try {
updateThreadName(data);
//獲取result
result = hunt();
if (result == null) {
//如果加載失敗，則分發失敗事件
dispatcher.dispatchFailed(this);
} else {
//如果加載成功，則分發成功事件
dispatcher.dispatchComplete(this);
}
}
//省略異常狀態的處理...
}
代碼的邏輯很簡單，hunt()是加載細節，如果加載失敗就由Dispatcher分發失敗事件，反之分發成功事件。
5-1、BitmapHunter#hunt()
接着，我們來探索一下hunt方法的實現方式，首先查看源碼如下：
//代碼清單5-1：BitmapHunter#hunt()
Bitmap hunt() throws IOException {
Bitmap bitmap = null;
//從內存緩存讀取bitmap，如果命中則添加計數
if (shouldReadFromMemoryCache(memoryPolicy)) {
bitmap = cache.get(key);
if (bitmap != null) {
stats.dispatchCacheHit();
loadedFrom = MEMORY;
if (picasso.loggingEnabled) {
log(OWNER_HUNTER, VERB_DECODED, data.logId(), "from cache");
}
return bitmap;
}
}
networkPolicy = retryCount == 0 ? NetworkPolicy.OFFLINE.index : networkPolicy;
//利用requestHandler解析圖片請求
RequestHandler.Result result = requestHandler.load(data, networkPolicy);
if (result != null) {
loadedFrom = result.getLoadedFrom();
exifOrientation = result.getExifOrientation();
bitmap = result.getBitmap();
// If there was no Bitmap then we need to decode it from the stream.
// 如果bitmap爲空，那麼從stream讀取字節流解析成bitmap
if (bitmap == null) {
Source source = result.getSource();
try {
bitmap = decodeStream(source, data);
} finally {
try {
//noinspection ConstantConditions If bitmap is null then source is guranteed non-null.
source.close();
} catch (IOException ignored) {
}
}
}
}
if (bitmap != null) {
//省略部分代碼...
//對Bitmap進行轉換操作，Transformation是一個自定義的轉換操作
if (data.needsTransformation() || exifOrientation != 0) {
synchronized (DECODE_LOCK) {
if (data.needsMatrixTransform() || exifOrientation != 0) {
bitmap = transformResult(data, bitmap, exifOrientation);
}
if (data.hasCustomTransformations()) {
bitmap = applyCustomTransformations(data.transformations, bitmap);
}
}
}
}
return bitmap;
}
總的流程可以概括爲：先從內存緩存獲取，如果沒有則交給對應的RequestHandler來進行圖片的加載，不同的請求對應了不同的加載方式，這裏暫不深究。在獲得一個Bitmap對象後，便對這個位圖進行了一系列的轉換操作，比如圖片自身的寬高和目標寬高不一致時要進行縮放，或者用戶設置了centerCrop的標誌位，那麼圖片就要保持寬高比列居中顯示。這些操作是利用Matrix和Bitmap.createBitmap來完成的。同時Picasso允許用戶自定義轉換器Transformation來對圖片進行個性化的修改，例如添加水印。具體的加載過程和轉換過程，本文暫不進行深究。
那麼，當hunt()方法執行完畢之後，會返回bitmap對象，我們順着代碼清單5往下走，下面就調用了dispatcher.dispatchComplete(this)方法，與上面出現過的dispatcher.dispatchSubmit一樣，把這個事件交給了Dispatcher去分發和處理。我們自然而然就會想到，這裏會進行線程的切換，從PicassoExecutorService線程池的某一條線程切換到了DispatcherThread。最終，在DispatcherHandler#handleMessage處理這個完成事件。
6、Dispatcher#performComplete(BitmapHunter)
代碼會運行到這個方法，我們直接來看源碼：
void performComplete(BitmapHunter hunter) {
//如果條件允許，那麼把該bitmap緩存到內存
if (shouldWriteToMemoryCache(hunter.getMemoryPolicy())) {
cache.set(hunter.getKey(), hunter.getResult());
}
hunterMap.remove(hunter.getKey()); //從map移除這個已完成的hunter
batch(hunter); //進行批處理
}
private void batch(BitmapHunter hunter) {
if (hunter.isCancelled()) {
return;
}
if (hunter.result != null) {
hunter.result.prepareToDraw();
}
batch.add(hunter); //添加到batch列表內
if (!handler.hasMessages(HUNTER_DELAY_NEXT_BATCH)) {
handler.sendEmptyMessageDelayed(HUNTER_DELAY_NEXT_BATCH, BATCH_DELAY);
}
}
從上面源碼可以看出，該hunter會被添加到一個batch的列表內，同時延遲發送一個HUNTER_DELAY_NEXT_BATCH消息，這意味着，第一個hunter完成後，會被添加到batch列表，然後延遲200ms發送batch消息。此時如果有別的hunter到達，也會被一一添加到batch列表，直到一開始的batch消息得到處理。這裏利用了批處理的思想，在200ms的等待時間內，會暫存多個hunter請求，時間到了之後便切換到主線程進行UI的顯示，這樣就不用頻繁地進行線程切換，可以提升UI顯示的流暢性。
7、Dispatcher#performBatchComplete
最後，在DispatcherThread會處理HUNTER_DELAY_NEXT_BATCH消息，我們來看該代碼：
void performBatchComplete() {
List<BitmapHunter> copy = new ArrayList<>(batch);
batch.clear();
mainThreadHandler.sendMessage(mainThreadHandler.obtainMessage(HUNTER_BATCH_COMPLETE, copy));
logBatch(copy);
}
這裏的mainThreadHandler是持有主線程Looper的handler，它發送的消息都會在主線程得到處理。實際上，它是在Dispatcher實例化的時候由Picasso傳遞進來的，那麼它的源碼可以在Picasso類中找到：
static final Handler HANDLER = new Handler(Looper.getMainLooper()) {
@Override public void handleMessage(Message msg) {
switch (msg.what) {
case HUNTER_BATCH_COMPLETE: {
@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);
}
break;
}
}
};
此時，線程環境已經由DispatcherThread切換到了UI Thread.在主線程內，逐個遍歷batch列表，對裏面的每一個hunter進行最後的收尾工作，把bitmap填充到imageview上。
8-1、Picasso#complete
下面就是收尾工作，我們直接看源碼：
//代碼清單8-1：Picasso#complete
void complete(BitmapHunter hunter) {
//獲取hunter所含有的Action
Action single = hunter.getAction();
//hunter可能對應多個Action，對同一圖片的同一操作的多個請求會保存在一個hunter內
//避免不必要的重複加載步驟。
List<Action> joined = hunter.getActions();
boolean hasMultiple = joined != null && !joined.isEmpty();
boolean shouldDeliver = single != null || hasMultiple;
if (!shouldDeliver) {
return;
}
Uri uri = hunter.getData().uri;
Exception exception = hunter.getException();
Bitmap result = hunter.getResult();
LoadedFrom from = hunter.getLoadedFrom();
if (single != null) {
deliverAction(result, from, single, exception);
}
if (hasMultiple) {
//noinspection ForLoopReplaceableByForEach
for (int i = 0, n = joined.size(); i < n; i++) {
Action join = joined.get(i);
deliverAction(result, from, join, exception);
}
}
if (listener != null && exception != null) {
listener.onImageLoadFailed(this, uri, exception);
}
}
這裏對hunter內的所有Action進行遍歷操作，每一個Action都有自己要設置的imageview對象。對每一個Action，進一步調用了deliverAction方法。
8-2、Picasso#deliverAction
//代碼清單8-2：Picasso#deliverAction
private void deliverAction(Bitmap result, LoadedFrom from, Action action, Exception e) {
//省略...
if (result != null) {
action.complete(result, from);
} else {
action.error(e);
}
這裏的Action是ImageViewAction實例，因此最後會調用ImageViewAction#complete()方法。實際上，用戶完全可以繼承Action來實現不同的需求。默認實現的ImageViewAction是爲了把圖片填充到ImageView.
8-3、ImageViewAction#complete
@Override public void complete(Bitmap result, Picasso.LoadedFrom from) {
if (result == null) {
throw new AssertionError(
String.format("Attempted to complete action with no result!\n%s", this));
}
ImageView target = this.target.get();
if (target == null) {
return;
}
Context context = picasso.context;
boolean indicatorsEnabled = picasso.indicatorsEnabled;
PicassoDrawable.setBitmap(target, context, result, from, noFade, indicatorsEnabled);
if (callback != null) {
callback.onSuccess();
}
}
代碼出現了新的一個類PicassoDrawable，它繼承自BitmapDrawable，那麼到現在就很清楚了，Picasso是以Drawable的形式把圖片設置進ImageView的，通過這樣的形式，Picasso可以最後在圖片上添加一些信息。比如，開啓了Debug模式後，所加載的圖片的右下角會有不同顏色的角標來表示圖片的來源(網絡、內存或磁盤)，這個功能的實現就是藉助於BitmapDrawable.draw方法在畫布上添加額外的信息。
8-4、PicassoDrawable#setBitmap
static void setBitmap(ImageView target, Context context, Bitmap bitmap,
Picasso.LoadedFrom loadedFrom, boolean noFade, boolean debugging) {
Drawable placeholder = target.getDrawable();
if (placeholder instanceof Animatable) {
((Animatable) placeholder).stop();
}
PicassoDrawable drawable =
new PicassoDrawable(context, bitmap, placeholder, loadedFrom, noFade, debugging);
target.setImageDrawable(drawable); //最後的最後，把drawable設置進imageview上
}
上面生成了PicassoDrawable，這裏不但傳遞了bitmap，也轉遞了loadedFrom信息，用於debug模式下判斷圖片來源。最後，調用了ImageView的方法設置了圖片。
至此，Picasso加載圖片的一次完整流程便完成了。
小結
縱觀整個Picasso的加載圖片的流程，其中涉及了多次的線程切換以及多個組件的協同工作，爲了方便讀者的理解，筆者繪製了整體的流程圖並標註出了線程切換的時機，讀者可以結合流程圖來梳理一下上面的源碼解析。
思路借鑑
經過上面的源碼學習，我們可以發現Picasso有很多優秀的設計思想值得我們去學習。
1、單例模式
對於全局只需要一個實例的庫來說，應該設計爲單例模式。這種庫往往承擔了繁重的工作，並且開銷不小，如果系統內存在多個實例，那麼就會造成額外的開銷。比如Picasso的線程池默認有多條子線程，如果Picasso不是單例模式的，那麼就會有頻繁創建線程池、回收線程池的操作，這完全是沒有必要的。只要設計爲單例模式，全局提供統一的入口方法，這樣不但節省了內存的消耗，同時也有利於馬上定位到問題所在。
2、模塊化設計
當一個系統實現的功能比較複雜的時候，我們可以利用模塊化的思想抽離出一個個子模塊，這些子模塊可以獨立成一個單獨的子系統，也可以相互配合以實現整個系統的功能。Picasso也是這樣設計的，它的子模塊包括downloader、cache和stats等子模塊，每一個子模塊負責不同的功能，相互之間沒有聯繫，極大程度上消除了類之間的耦合關係，修改一個模塊也不會影響到另一模塊的正常工作。
因此，我們在設計一個庫或者系統的時候，可以考慮將庫的功能分成不同的子模塊，各個模塊各司其職，儘量降低代碼的耦合度。
3、多態和可拓展性
多態是面向對象編程的三大特性之一，多態簡單地說就是父類類型的變量可以引用子類的實例，這樣的好處在於子類可以靈活多變適應不同的場景的同時也遵循了一定規則的約束。Picasso的Downloader就是一個例子，它是一個接口，默認的實現是OkHttp3Downloader，它允許用戶自己實現Downloader接口，並在Picasso的構造器中添加這樣一個自定義的下載器。這是模塊化和多態的結合，下載器是一個可以替換的模塊，用戶只需要遵循某些約定即可。除此之外，還有RequestHandler，它作爲一個抽象類，僅定義了需要實現的幾個方法，具體不同圖像的加載方式由不同的RequestHandler去實現。
在代碼中運用了多態的思想後，這意味着我們的代碼是可拓展的，可以適應未來可能出現的不同需求。我們可以將庫的某一模塊定義爲抽象類或者接口，具體的實現可以根據具體需求而定。
4、批處理思想
批處理思想是指等請求聚集到一定數量或者經過一段時間後再一起處理的思想。如果請求涉及到了跨線程處理甚至跨進程處理，並且請求的數量在短時間內是密集的，那麼如果對於每一個單一請求都進行一次線程間/進程間通信，顯然這會頻繁地切換線程造成很大的開銷。如果利用了批處理思想，那麼每隔一段時間處理一批請求，只需要切換一次線程。Picasso在處理完BitmapHunter後就是利用了批處理思想，等待200ms後再切換到UI線程進行UI的顯示。
在實時性要求不高的場景下(延遲200ms後展示圖片，完全可以接受)，我們可以善於利用批處理思想，降低切換線程/進程帶來的性能開銷。
好了，本文到這裏就結束了，最後感謝閱讀到這裏的你~