一、前言
圖片載入的輪子有很多了,Universal-Image-Loader, Picasso, Glide, Fresco等。
網上各種分析和對比文章很多,我們這裡就不多作介紹了。
古人云:“紙上得來終覺淺,絕知此事要躬行”。
只看分析,不動手實踐,終究印象不深。
用當下流行的“神經網路”來說,就是要通過“輸出”,形成“反饋”,才能更有效地“訓練”。
當然,大千世界,包羅永珍,我們不可能任何事情都去經歷。
能挑自己感興趣的方面探究一番,已經幸事。
圖片載入是筆者比較感興趣的,其中有不少知識和技巧值得研究探討。
話不多說,先來兩張圖暖一下氣氛:
二、 框架命名
命名是比較令人頭疼的一件事。
在反覆翻了單詞表之後,決定用Doodle作為框架的名稱。
Picasso是畫家畢加索的名字,Fresco翻譯過來是“壁畫”,比ImageLoader之類的要更有格調;
本來想起Van、Vince之類的,但想想還是不要冒犯這些巨擘了。
Doodle為塗鴉之意,除了單詞本身內涵之外,外在也很有趣,很像一個單詞:Google。
這樣的兼具有趣靈魂和好看皮囊的詞,真的不多了。
三、流程&架構
3.1 載入流程
概括來說,圖片載入包含封裝,解析,下載,解碼,變換,快取,顯示等操作。
流程圖如下:
- 封裝引數:從指定來源,到輸出結果,中間可能經歷很多流程,所以第一件事就是封裝引數,這些引數會貫穿整個過程;
- 解析路徑:圖片的來源有多種,格式也不盡相同,需要規範化;
- 讀取快取:為了減少計算,通常都會做快取;同樣的請求,從快取中取圖片(Bitmap)即可;
- 查詢檔案/下載檔案:如果是本地的檔案,直接解碼即可;如果是網路圖片,需要先下載;
- 解碼:這一步是整個過程中最複雜的步驟之一,有不少細節;
- 變換:解碼出Bitmap之後,可能還需要做一些變換處理(圓角,濾鏡等);
- 快取:得到最終bitmap之後,可以快取起來,以便下次請求時直接取結果;
- 顯示:顯示結果,可能需要做些動畫(淡入動畫,crossFade等)。
以上簡化版的流程(只是眾多路徑中的一個分支),後面我們將會看到,完善各種細節之後,會比這複雜很多。
但萬事皆由簡入繁,先簡單梳理,後續再慢慢填充,猶如繪畫,先繪輪廓,再描細節。
3.2 基本架構
解決複雜問題,思路都是相似的:分而治之。
參考MVC的思路,我們將框架劃分三層:
- Interface: 框架入口和外部介面
- Processor: 邏輯處理層
- Storage:儲存層,負責各種快取。
具體劃分如下:
-
外部介面
Doodle: 提供全域性引數配置,圖片載入入口,以及記憶體快取介面。
Config: 全域性引數配置。包括快取路徑,快取大小,圖片編碼等引數。
Request: 封裝請求引數。包括資料來源,剪裁引數,行為引數,以及目標。 -
執行單元
Dispatcher : 負責請求排程, 以及結果顯示。
Worker: 工作執行緒,非同步執行載入,解碼,轉換,儲存等。
Downloader: 負責檔案下載。
Source: 解析資料來源,提供統一的解碼介面。
Decoder: 負責具體的解碼工作。 -
儲存元件
MemoryCache: 管理Bitmap快取。
DiskCache: 圖片“結果”的磁碟快取(原圖由OkHttp快取)。
四、功能實現
上一節分析了流程和架構,接下來就是在理解流程,瞭解架構的前提下,
先分別實現關鍵功能,然後串聯起來,之後就是不斷地新增功能和完善細節。
簡而言之,就是自頂向下分解,自底向上填充。
4.1 API設計
眾多圖片載入框架中,Picasso和Glide的API是比較友好的。
Picasso.with(context)
.load(url)
.placeholder(R.drawable.loading)
.into(imageView);
複製程式碼
Glide的API和Picasso類似。
當引數較多時,構造者模式就可以搬上用場了,其鏈式API能使引數指定更加清晰,而且更加靈活(隨意組合引數)。
Doodle也用類似的API,而且為了方便理解,有些方法命名也參照Picasso和 Glide。
4.1.1 全域性引數
- Config
object Config {
internal var userAgent: String = ""
internal var diskCachePath: String = ""
internal var diskCacheCapacity: Long = 128L shl 20
internal var diskCacheMaxAge: Long = 30 * 24 * 3600 * 1000L
internal var bitmapConfig: Bitmap.Config = Bitmap.Config.ARGB_8888
// ...
fun setUserAgent(userAgent: String): Config {
this.userAgent = userAgent
return this
}
fun setDiskCachePath(path: String): Config {
this.diskCachePath = path
return this
}
// ....
}
複製程式碼
- Doodle
object Doodle {
internal lateinit var appContext: Context
fun init(context: Context) : Config {
appContext = context as? Application ?: context.applicationContext
registerActivityLifeCycle(appContext)
return Config
}
}
複製程式碼
- 框架初始化
Doodle.init(context)
.setDiskCacheCapacity(256L shl 20)
.setMemoryCacheCapacity(128L shl 20)
.setDefaultBitmapConfig(Bitmap.Config.ARGB_8888)
複製程式碼
雖然也是鏈式API,但是沒有參照Picasso那樣的構造者模式的用法(讀寫分離),因為那種寫法有點麻煩,而且不直觀。
Doodle在初始化的時候傳入context(最好傳入Application), 這樣後面請求單個圖片時,就不用像Picasso和Glide那樣用with傳context了。
4.1.2 圖片請求
載入圖片:
Doodle.load(url)
.placeholder(R.drawable.loading)
.into(topIv)
複製程式碼
實現方式和Config是類似的:
object Doodle {
// ....
fun load(path: String): Request {
return Request(path)
}
fun load(resID: Int): Request {
return Request(resID)
}
fun load(uri: Uri): Request {
return Request(uri)
}
}
複製程式碼
- Request
class Request {
internal val key: Long by lazy { MHash.hash64(toString()) }
// 圖片源
internal var uri: Uri? = null
internal var path: String
private var sourceKey: String? = null
// 圖片引數
internal var viewWidth: Int = 0
internal var viewHeight: Int = 0
// ....
// 載入行為
internal var priority = Priority.NORMAL
internal var memoryCacheStrategy= MemoryCacheStrategy.LRU
internal var diskCacheStrategy = DiskCacheStrategy.ALL
// ....
// target
internal var simpleTarget: SimpleTarget? = null
internal var targetReference: WeakReference<ImageView>? = null
internal constructor(path: String) {
if (TextUtils.isEmpty(path)) {
this.path = ""
} else {
this.path = if (path.startsWith("http") || path.contains("://")) path else "file://$path"
}
}
fun sourceKey(sourceKey: String): Request {
this.sourceKey = sourceKey
return this
}
fun into(target: ImageView?) {
if (target == null) {
return
}
targetReference = WeakReference(target)
if (noClip) {
fillSizeAndLoad(0, 0)
} else if (viewWidth > 0 && viewHeight > 0) {
fillSizeAndLoad(viewWidth, viewHeight)
}
// ...
}
private fun fillSizeAndLoad(targetWidth: Int, targetHeight: Int) {
viewWidth = targetWidth
viewHeight = targetHeight
// ...
Dispatcher.start(this)
}
override fun toString(): String {
val builder = StringBuilder()
if (!TextUtils.isEmpty(sourceKey)) {
builder.append("source:").append(sourceKey)
} else {
builder.append("path:").append(path)
}
// ....
return builder.toString()
}
}
複製程式碼
Request主要職能是封裝請求引數,引數可以大約劃分為4類:
- 1、圖片源;
- 2、解碼引數:寬高,scaleType,圖片配置(ARGB_8888, RGB_565)等;
- 3、載入行為:載入優先順序,快取策略,佔點陣圖,動畫等;
- 4、目標,ImageView或者回撥等。
其中,圖片源和解碼引數決定了最終的bitmap, 所以,我們拼接這些引數作為請求的key,這個key會用於快取的索引和任務的去重。
拼接引數後字串很長,所以需要壓縮成摘要,由於終端上的圖片數量不會太多,64bit的摘要即可(原理參考《漫談雜湊函式》)。
圖片檔案的來源,通常有網路圖片,drawable/raw資源, assets檔案,本地檔案等。
當然,嚴格來說,除了網路圖片之外,其他都是本地檔案,只是有各種形式而已。
Doodle支援三種引數, id(Int), path(String), 和Uri(常見於呼叫相機或者相簿時)。
對於有的圖片源,路徑可能會變化,比如url, 裡面可能有一些動態的引數:
val url = "http://www.xxx.com/a.jpg?t=1521551707"
複製程式碼
請求服務端的時候,其實返回的是同一張圖片。
但是如果用整個url作為請求的key的一部分,因為動態引數的原因,每次請求key都不一樣,會導致快取失效。
為此,可以將url不變的部分作為制定為圖片源的key:
val url = "http://www.xxx.com/a.jpg"
Skate.load(url + "?t=" + System.currentTimeMillis())
.sourceKey(url)
.into(testIv);
複製程式碼
有點類似Glide的StringSignature。
請求的target最常見的應該是ImageView,
此外,有時候需要單純獲取Bitmap,
或者同時獲取Bitmap和ImageView,
抑或是在當前執行緒獲取Bitmap ……
總之,有各種獲取結果的需求,這些都是設計API時需要考慮的。
4.2 快取設計
幾大圖片載入框架都實現了快取,各種文章中,有說二級快取,有說三級快取。
其實從儲存來說,可簡單地分為記憶體快取和磁碟快取;
只是同樣是記憶體/磁碟快取,也有多種形式,例如Glide的“磁碟快取”就分為“原圖快取”和“結果快取”。
4.2.1 記憶體快取
為了複用計算結果,提高使用者體驗,通常會做bitmap的快取;
而由於要限制快取的大小,需要淘汰機制(通常是LRU策略)。
Android SDK提供了LruCache類,檢視原始碼,其核心是LinkedHashMap。
為了更好地定製,這裡我們不用SDK提供的LruCache,直接用LinkedHashMap,封裝自己的LruCache。
internal class BitmapWrapper(var bitmap: Bitmap) {
var bytesCount: Int = 0
init {
this.bytesCount = Utils.getBytesCount(bitmap)
}
}
複製程式碼
internal object LruCache {
private val cache = LinkedHashMap<Long, BitmapWrapper>(16, 0.75f, true)
private var sum: Long = 0
private val minSize: Long = Runtime.getRuntime().maxMemory() / 32
@Synchronized
operator fun get(key: Long?): Bitmap? {
val wrapper = cache[key]
return wrapper?.bitmap
}
@Synchronized
fun put(key: Long, bitmap: Bitmap?) {
val capacity = Config.memoryCacheCapacity
if (bitmap == null || capacity <= 0) {
return
}
var wrapper: BitmapWrapper? = cache[key]
if (wrapper == null) {
wrapper = BitmapWrapper(bitmap)
cache[key] = wrapper
sum += wrapper.bytesCount.toLong()
if (sum > capacity) {
trimToSize(capacity * 9 / 10)
}
}
}
private fun trimToSize(size: Long) {
val iterator = cache.entries.iterator()
while (iterator.hasNext() && sum > size) {
val entry = iterator.next()
val wrapper = entry.value
WeakCache.put(entry.key, wrapper.bitmap)
iterator.remove()
sum -= wrapper.bytesCount.toLong()
}
}
}
複製程式碼
LinkedHashMap 建構函式的第三個引數:accessOrder,傳入true時, 元素會按訪問順序排列,最後訪問的在遍歷器最後端。
進行淘汰時,移除遍歷器前端的元素,直至快取總大小降低到指定大小以下。
有時候需要載入比較大的圖片,佔用記憶體較高,放到LruCache可能會“擠掉”其他一些bitmap;
或者有時候滑動列表生成大量的圖片,也有可能會“擠掉”一些bitmap。
這些被擠出LruCache的bitmap有可能很快又會被用上,但在LruCache中已經索引不到了,如果要用,需重新解碼。
值得指出的是,被擠出LruCache的bitmap,在GC時並不一定會被回收,如果bitmap還被引用,則不會被回收;
但是不管是否被回收,在LruCache中都索引不到了。
我們可以將一些可能短暫使用的大圖片,以及這些被擠出LruCache的圖片,放到弱引用的容器中。
在被回收之前,還是可以根據key去索引到bitmap。
internal object WeakCache {
private val cache = HashMap<Long, BitmapWeakReference>()
private val queue = ReferenceQueue<Bitmap>()
private class BitmapWeakReference internal constructor(
internal val key: Long,
bitmap: Bitmap,
q: ReferenceQueue<Bitmap>) : WeakReference<Bitmap>(bitmap, q)
private fun cleanQueue() {
var ref: BitmapWeakReference? = queue.poll() as BitmapWeakReference?
while (ref != null) {
cache.remove(ref.key)
ref = queue.poll() as BitmapWeakReference?
}
}
@Synchronized
operator fun get(key: Long?): Bitmap? {
cleanQueue()
val reference = cache[key]
return reference?.get()
}
@Synchronized
fun put(key: Long, bitmap: Bitmap?) {
if (bitmap != null) {
cleanQueue()
val reference = cache[key]
if (reference == null) {
cache[key] = BitmapWeakReference(key, bitmap, queue)
}
}
}
}
複製程式碼
以上實現中,BitmapWeakReference是WeakReference的子類,除了引用Bitmap的功能之外,還記錄著key, 以及關聯了ReferenceQueue;
當Bitmap被回收時,BitmapWeakReference會被放入ReferenceQueue,
我們可以遍歷ReferenceQueue,移除ReferenceQueue的同時,取出其中記錄的key, 到cache中移除對應的記錄。
利用WeakReference和ReferenceQueue的機制,索引物件的同時又不至於記憶體洩漏,類似用法在WeakHashMap和Glide原始碼中都出現過。
最後,綜合LruCache和WeakCache,統一索引:
internal object MemoryCache {
fun getBitmap(key: Long): Bitmap? {
var bitmap = LruCache[key]
if (bitmap == null) {
bitmap = WeakCache[key]
}
return bitmap
}
fun putBitmap(key: Long, bitmap: Bitmap, toWeakCache: Boolean) {
if (toWeakCache) {
WeakCache.put(key, bitmap)
} else {
LruCache.put(key, bitmap)
}
}
// ......
}
複製程式碼
宣告記憶體快取策略:
object MemoryCacheStrategy{
const val NONE = 0
const val WEAK = 1
const val LRU = 2
}
複製程式碼
NONE: 不快取到記憶體
WEAK: 快取到WeakCache
LRU:快取到LRUCache
4.2.2 磁碟快取
曲面提到,Glide有兩種磁碟快取:“原圖快取”和“結果快取”,
Doodle也仿照類似的策略,可以選擇快取原圖和結果。
原圖快取指的是Http請求下來的未經解碼的檔案;
結果快取指經過解碼,剪裁,變換等,變成最終的bitmap之後,通過**bitmap.compress()**壓縮儲存。
其中,後者通常比前者更小,而且解碼時不需要再次剪裁和變換等,所以從結果快取獲取bitmap通常要比從原圖獲取快得多。
為了儘量使得api相似,Doodle設定直接用Glide v3的快取策略定義(Glide v4有一些變化)。
object DiskCacheStrategy {
const val NONE = 0
const val SOURCE = 1
const val RESULT = 2
const val ALL = 3
}
複製程式碼
NONE: 不快取到磁碟
SOURCE: 只快取原圖
RESULT: 只快取結果
ALL: 既快取原圖,也快取結果。
Doodle的HttpClient是用的OkHttp, 所以網路快取,包括原圖的快取就交給OkHttp了,
至於本地的圖片源,本就在SD卡,只是各種形式而已,也就無所謂快取了。
結果快取,Doodle沒有用DiskLruCache, 而是自己實現了磁碟快取。
DiskLruCache是比較通用的磁碟快取解決方案,筆者覺得對於簡單地存個圖片檔案可以更精簡一些,所以自己設計了一個更專用的方案。
其實磁碟快取的管理最主要是設計記錄日誌,方案要點如下:
1、一條記錄儲存key(long)和最近訪問時間(long),一條記錄16位元組;
2、每條記錄依次排列,由於比較規整,可以根據偏移量隨機讀寫;
3、用mmap方式對映日誌檔案,以4K為單位對映。
檔案記錄之外,記憶體中還需要一個HashMap記錄key到”檔案記錄”的對映, 其中,檔案記錄物件如下:
private class JournalValue internal constructor(
internal var key: Long,
internal var accessTime: Long,
internal var fileLen: Long,
internal var offset: Int) : Comparable<JournalValue> {
// ...
}
複製程式碼
只需記錄key, 訪問時間,檔案大小,以及記錄在日誌檔案中的位置即可。
那檔名呢?檔案命名為key的十六進位制,所以可以根據key運算出檔名。
運作機制:
訪問DiskCache時,先讀取日誌檔案,填充HashMap;
後面的訪問中,只需讀取HashMap就可以知道有沒有對應的磁碟快取;
存入一個“結果檔案”則往HashMap存入記錄,同時更新日誌檔案。
這種機制其實有點像SharePreferences, 二級儲存,檔案讀一次之後接下來都是寫入。
相對而言,該方案的優點為:
1、節省空間,一頁(4K)能記錄256個檔案;
2、格式規整,解析快;
3、mmap對映,可批量記錄,自動定時寫入磁碟,降低磁碟IO消耗;
4、二級儲存,訪問速度快。
當容量超出限制需要淘汰時,根據訪問時間,先刪除最久沒被訪問的檔案;
除了實現LRU淘汰規則外,還可實現最大保留時間,刪除一些太久沒用到的圖片檔案。
雖然名為磁碟快取,其實不僅僅快取檔案,“檔案記錄”也很關鍵,二者關係猶如檔案內容和檔案的後設資料, 相輔相成。
4.3 解碼
SDK提供了BitmapFactory,提供各種API,從圖片源解碼成bitmap,但這僅是圖片解碼的最基礎的工作;
圖片解碼,前前後後要準備各種材料,留心各種細節,是圖片載入過程中最繁瑣的步驟之一。
4.3.1 解析資料來源
前面提到,圖片的來源有多種,我們需要識別圖片來源,
然後根據各自的特點提供統一的處理方法,為後續的具體解碼工作提供方便。
internal abstract class Source : Closeable {
// 魔數,提供檔案格式的資訊
internal abstract val magic: Int
// 旋轉方向,EXIF專屬資訊
internal abstract val orientation: Int
internal abstract fun decode(options: BitmapFactory.Options): Bitmap?
internal abstract fun decodeRegion(rect: Rect, options: BitmapFactory.Options): Bitmap?
internal class FileSource constructor(private val file: File) : Source() {
//...
}
internal class AssetSource(private val assetStream: AssetManager.AssetInputStream) : Source() {
//...
}
internal class StreamSource constructor(inputStream: InputStream) : Source() {
//...
}
companion object {
private const val ASSET_PREFIX = "file:///android_asset/"
private const val FILE_PREFIX = "file://"
fun valueOf(src: Any?): Source {
if (src == null) {
throw IllegalArgumentException("source is null")
}
return when (src) {
is File -> FileSource(src)
is AssetManager.AssetInputStream -> AssetSource(src)
is InputStream -> StreamSource(src)
else -> throw IllegalArgumentException("unsupported source " + src.javaClass.simpleName)
}
}
fun parse(request: Request): Source {
val path = request.path
return when {
path.startsWith("http") -> {
val builder = okhttp3.Request.Builder().url(path)
if (request.diskCacheStrategy and DiskCacheStrategy.SOURCE == 0) {
builder.cacheControl(CacheControl.Builder().noCache().noStore().build())
} else if (request.onlyIfCached) {
builder.cacheControl(CacheControl.FORCE_CACHE)
}
valueOf(Downloader.getSource(builder.build()))
}
path.startsWith(ASSET_PREFIX) -> valueOf(Doodle.appContext.assets.open(path.substring(ASSET_PREFIX.length)))
path.startsWith(FILE_PREFIX) -> valueOf(File(path.substring(FILE_PREFIX.length)))
else -> valueOf(Doodle.appContext.contentResolver.openInputStream((request.uri ?: Uri.parse(path))))
}
}
}
}
複製程式碼
以上程式碼,從資源id, path, 和Uri等形式,最終轉換成FileSource, AssetSource, StreamSource等。
- FileSource: 本地檔案
- AssetSource:asset檔案,drawable/raw資原始檔
- StreamSource:網路檔案,ContentProvider提供的圖片檔案,如相機,相簿等。
其中,網路檔案從OkHttp的網路請求獲得,如果快取了原圖, 則會獲得FileSource。
其實各種圖片源最終都可以轉化為InputStream,例如AssetInputStream其實就是InputStream的一種, 檔案也可以轉化為FileInputStream。
那為什麼區分開來呢? 這一切都要從讀取圖片頭資訊開始講。
4.3.2 預讀頭資訊
解碼過程中通常需要預讀一些頭資訊,如檔案格式,圖片解析度等,作為接下來解碼策略的引數,例如用圖片解析度來計算壓縮比例。
當inJustDecodeBounds設定為true時, BitmapFactory不會返回bitmap, 而是僅僅讀取檔案頭資訊,其中最重要的是圖片解析度。
val options = BitmapFactory.Options()
options.inJustDecodeBounds = true
BitmapFactory.decodeStream(inputStream, null, options)
複製程式碼
讀取了頭資訊,計算解碼引數之後,將inJustDecodeBounds設定為false,
再次呼叫BitmapFactory.decodeStream即可獲取所需bitmap。
可是,有的InputStream不可重置讀取位置,同時BitmapFactory.decodeStream方法要求從頭開始讀取。
那先關閉流,然後再次開啟不可以嗎? 可以,不過效率極低,尤其是網路資源時,不敢想象……
有的InputStream實現了mark(int)和reset()方法,就可以通過標記和重置支援重新讀取。
這一類InputStream會過載markSupported()方法,並返回true, 我們可以據此判斷InputStream是否支援重讀。
幸運的是AssetInputStream就支援重讀;
不幸的是FileInputStream居然不支援,OkHttp的byteStream()返回InputStream也不支援。
對於檔案,我們通過搭配RandomAccessFile和FileDescriptor來重新重讀;
而對於其他的InputStream,只能曲折一點,通過快取已讀位元組來支援重新讀取。
SDK提供的BufferedInputStream就是這樣一種思路, 通過設定一定大小的緩衝區,以滑動視窗的形式提供緩衝區內重新讀取。
遺憾的是,BufferedInputStream的mark函式需指定readlimit,緩衝區會隨著需要預讀的長度增加而擴容,但是不能超過readlimit;
若超過readlimit,則讀取失敗,從而解碼失敗。
/**
* @param readlimit the maximum limit of bytes that can be read before
* the mark position becomes invalid.
*/
public void mark(int readlimit) {
marklimit = readlimit;
markpos = pos;
}
複製程式碼
於是readlimit設定多少就成了考量的因素了。
Picasso早期版本設定64K, 結果遭到大量的反饋說解碼失敗,因為有的圖片需要預讀的長度不止64K。
從Issue的回覆看,Picasso的作者也很無奈,最終妥協地將readlimit設為MAX_INTEGER。
但即便如此,後面還是有反饋有的圖片無法預讀到圖片的大小。
筆者很幸運地遇到了這種情況,經除錯程式碼,最終發現Android 6.0的BufferedInputStream,
其skip函式的實現有問題,每次skip都會擴容,即使skip後的位置還在緩衝區內。
造成的問題是有的圖片預讀時需多次呼叫skip函式,然後緩衝區就一直double直至丟擲OutOfMemoryError……
不過Picasso最終還是把圖片載入出來了,因為其catch了Throwable, 然後重新直接解碼(不預讀大小);
雖然載入出來了,但是代價不小:只能全尺寸載入,以及前面預讀時申請的大量記憶體(雖然最終會被GC),所造成的記憶體抖動。
Glide沒有這個問題,因為Glide自己實現了類似BufferedInputStream功能的InputStream,完美地繞過了這個坑;
Doodle則是copy了Android 8.0的SDK的BufferedInputStream, 精簡程式碼,加入一些緩衝區複用的程式碼等,可以說是改裝版BufferedInputStream。
回頭看前面一節的問題,為什麼不統一用“改裝版BufferedInputStream”來解碼?
因為有的圖片預讀的長度很長,需要開闢較大的緩衝區,從這個角度看,FileSource和AssetSource更節約記憶體。
4.3.3 圖片壓縮
有時候需要顯示的bitmap比原圖的解析度小。
比方說原圖是 4096 * 4096, 如果按照ARGB_8888的配置全尺寸解碼出來,需要佔用64M的記憶體!
不過app中所需得bitmap通常會小很多, 這時就要壓縮了。
比方說需要300 * 300的bitmap, 該怎麼做呢?
網上通常的說法是設定 options.inSampleSize 來降取樣。
閱讀SDK文件,inSampleSize 需是整數,而且是2的倍數,
不是2的倍數時,會被 “be rounded down to the nearest power of 2”。
比方說前面的 4096 * 4096 的原圖,
當inSampleSize = 16時,解碼出256 * 256 的bitmap;
當inSampleSize = 8時,解碼出512 * 512 的bitmap。
即使是inSampleSize = 8,所需記憶體也只有原來的1/64(1M),效果還是很明顯的。
Picasso和Glide v3就是這麼降取樣的。
如果你發現解碼出來的圖片是300 * 300 (比如使用Picasso時呼叫了fit()函式),應該是有後續的處理(通過Matrix 和 Bitmap.createBitmap 繼續縮放)。
那能否直接解碼出300 * 300的圖片呢? 可以的。
檢視 BitmapFactory.cpp 的原始碼,其中有一段:
const int density = env->GetIntField(options, gOptions_densityFieldID);
const int targetDensity = env->GetIntField(options, gOptions_targetDensityFieldID);
const int screenDensity = env->GetIntField(options, gOptions_screenDensityFieldID);
if (density != 0 && targetDensity != 0 && density != screenDensity) {
scale = (float) targetDensity / density;
}
複製程式碼
對應BitmapFactory.Options的兩個關鍵引數:inDensity 和 inTargetDensity。
上面的例子,設定inTargetDensity=300, inDensity=4096(還要設定inScale=true), 則可解碼出300 * 300的bitmap。
額外提一下,Glide v4也換成這種壓縮策略了。
平時設計給切圖,要放對資料夾,也是這個道理。
比如設計給了144 * 144(xxhdpi) 的icon, 如果不小心放到hdpi的資源目錄下;
假如機器的dpi在320dpi ~ 480dpi之間(xxhdpi),則解碼出來的bitmap是288 * 288的解析度,;
如果剛好ImageView又是wrap_content設定的寬高,視覺上會比預期的翻了一番-_-。
言歸正傳,解碼的過程為,通過獲取圖片的原始解析度,結合Request的width和height, 以及ScaleType,
計算出最終要解碼的寬高, 設定inDensity和inTargetDensity然後decode。
當然,有時候decode出來之後還要做一些加工,比方說ScaleType為CENTER_CROP而圖片寬高又不相等,
則需要在decode之後進行裁剪,取出中間部分的畫素。
關於ScaleType,Doodle是直接獲取ImageView的ScaleType, 所以無需再特別呼叫函式指定;
當然也提供了指定ScaleType的API, 對於target不是ImageView時或許會用到。
fun scaleType(scaleType: ImageView.ScaleType)
複製程式碼
還有就是,解碼階段的壓縮是向下取樣的。
比如,如果原圖只有100 * 100, 但是ImageView是200 * 200,最終也是解碼出100 * 100的bitmap。
不過ImageView假如是CENTER_CROP或者FIX_XY等ScaleType,顯示時通常會在渲染階段自行縮放的。
如果確實就是需要200 * 200的解析度,可以在解碼後的變換(Transformation)階段處理。
4.3.4 圖片旋轉
相信不少開發都遇到拍照後圖片旋轉的問題(尤其是三星的手機)。
網上有不少關於此問題的解析,這是其中一篇:關於圖片EXIF資訊中旋轉引數Orientation的理解
Android SDK提供了ExifInterface 來獲取Exif資訊,Picasso正是用此API獲取旋轉引數的。
很可惜ExifInterface要到 API level 24 才支援通過InputStream構造物件,低於此版本,僅支援通過檔案路徑構造物件。
故此,Picasso當前版本僅在傳入引數是檔案路徑(或者檔案的Uri)時可處理旋轉問題。
Glide自己實現了頭部解析,主要是獲取檔案型別和exif旋轉資訊。
Doodle抽取了Glide的HeaderParse,並結合工程做了一些精簡和程式碼優化, 嗯, 又一個“改裝版”。
decode出bitmap之後,根據獲取的旋轉資訊,呼叫setRotate和postScale進行對應的旋轉和翻轉,即可還原正確的顯示。
4.3.5 變換
解碼出bitmap之後,有時候還需要做一些處理,如圓形剪裁,圓角,濾鏡等。
Picasso和Glide都提供了類似的API:Transformation
interface Transformation {
fun transform(source: Bitmap): Bitmap?
fun key(): String
}
複製程式碼
實現變換比較簡單,實現Transformation介面,處理source,返回處理後的bitmap即可;
當然,還要在key()返回變換的標識,通常寫變換的名稱就好,如果有引數, 需拼接上引數。
Transformation也是決定bitmap長什麼樣的因素之一,所以需要過載key(), 作為Request的key的一部分。
Transformation可以設定多個,處理順序會按照設定的先後順序執行。
Doodle預置了三個常用的Transformation。
CircleTransformation:圓形剪裁,如果寬高不相等,會先取中間部分(類似CENTER_CROP);
RoundedTransformation:圓角剪裁,可指定半徑;
ResizeTransformation:大小調整,寬高縮放到指定大小。
需要指出的一點是, Request中指定大小之後並不總是能夠解碼出指定大小的bitmap,
如果原圖解析度小於指定大小,基於向下取樣的策略,並不會主動縮放到指定的大小(前面有提到)。
若需要確定大小的bitmap, 可應用ResizeTransformation。
更多的變換,可以到glide-transformations尋找,
雖然不能直接匯入引用, 但是處理方法是類似的,改造一下就可使用-_-
4.3.6 GIF圖
GIF有靜態的,也有動態的。
BitmapFactory支援解碼GIF圖片的第一幀,所以各個圖片框架都支援GIF縮率圖。
至於GIF動圖,Picasso當前是不支援的,Glide支援,但據反饋有些GIF動圖Glide顯示不是很流暢。
Doodle本身也沒有實現GIF動圖的解碼,但是留了擴充介面,結合第三方GIF解碼庫, 可實現GIF動圖的載入和顯示。
GIF解碼庫,推薦 android-gif-drawable。
具體用法:
在App啟動時, 注入GIF解碼的實現類(實現GifDecoder 介面):
fun initApplication(context: Application) {
Doodle.init(context)
// ... 其他配置
.setGifDecoder(gifDecoder)
}
private val gifDecoder = object : GifDecoder {
override fun decode(bytes: ByteArray): Drawable {
return GifDrawable(bytes)
}
}
複製程式碼
使用時和載入到普通的ImageView沒區別,如果圖片源是GIF圖片,會自動呼叫gifDecoder進行解碼。
Doodle.load(url).into(gifImageView)
複製程式碼
當然也可以指定不需要顯示動圖, 呼叫asBitmap()方法即可。
4.3.7 圖片複用
很多文章講圖片優化時都會提到兩個點,壓縮和圖片複用。
Doodle在設計階段也考慮了圖片複用,並且也實現了,但實現後一直糾結其收益和成本-_-
- 1、正在使用的圖片不能被複用,所以要新增引用計數策略,附加程式碼很多;
- 2、即使圖片沒有被引用,根據區域性性原理,該圖片可能稍後有可能被訪問,所以也不應該馬上被複用;
- 3、大多數情況下,符合複用條件(不用一段時間,尺寸符合要求)的並不多;
- 4、佔用一些額外的計算資源。
最終,在看了帖子 picasso_vs_glide 之後,下決心移除了圖片複用的程式碼。
以下該帖子中,Picasso的作者JakeWharton 的原話:
Slight correction here: “Glide reuses bitmaps period”. Picasso does not at all. Nor do we have plans to. This is actually a performance optimization in some cases as we can retained cached images longer. It`d be nice to support both modes with programmer hints, but since ImageDecoder doesn`t even support re-use I see no point to adding it.
Doodle定位是小而美的輕量級圖片框架,過程中移除了不少價值不高的功能和複雜的實現。
有舍必有得,程式設計與生活,莫不如此。
4.4 執行緒排程
圖片獲取和解碼都是耗時的操作,需放在非同步執行;
而通常需要同時請求多張圖片,故此,執行緒排程不可或缺。
Doodle的執行緒排程依賴於筆者的另一個專案Task,
具體內容詳見:《如何實現一個執行緒排程框架》(又發了一波廣告?-_-)。
簡單的說,主要用到了Task的幾個特性:
- 1、支援優先順序;
- 2、支援生命週期(在Activity/Fragment銷燬時取消任務);
- 3、支援根據 Activity/Fragment 的顯示/隱藏動態調整優先順序;
- 4、支援任務去重。
關於任務去重,主要是以Request的key作為任務的tag, 相同tag的任務序列執行,
如此,當第一個任務完成,後面的任務讀快取即可,避免了重複計算。
對於網路圖片源的任務,則以URL作為tag, 以免重複下載。
此外,執行緒池,在UI執行緒回撥結果,在當前執行緒獲取結果等操作,都能基於Task簡單地實現。
4.5 Dispatcher
從Request,到開始解碼,從解碼完成,到顯示圖片, 之間不少零碎的處理。
把這些處理都放到一個類中,卻不知道怎麼命名了,且命名為Dispatcher吧。
都有哪些處理呢?
- 1、檢查ImageView有沒有繫結任務(啟動任務後會將Request放入ImageView的tag中),
如果有,判斷是否相同(根據請求的key), 相同且前面的任務在執行,則取消之; - 2、啟動任務前顯示佔點陣圖(如果設定了的話);
- 3、任務結束,如果任務失敗,顯示錯誤圖片;
- 4、如果載入成功且設定了過渡動畫,執行動畫;
- 5、各種target的回撥;
- 6、任務的暫停和開始。
其中,最後一點,在顯示有大量資料來源的RecycleView或者ListView時,
執行快速滑動時最好能暫停任務,停下來才恢復載入,這樣能節省很多不必要的請求。
簡而言之,Dispatcher有兩個職責:
1、橋接的作用,連線外部於內部元件(有點像主機板);
2、處理結果的反饋(如圖片的顯示)。
五、回顧
第三章梳理了流程和架構;
第四章分解了各部分功能實現;
這一章我們做一下回顧和梳理。
5.1 依賴關係
先回顧一下圖片框架的架構:
- Doodle作為框架的入口,提供全域性引數配置(Config)以及單個圖片的請求(Request);
- Request被很多類所依賴,事實上,Request貫穿了整個請求過程。
新增功能時,一般也是從Request開始,新增變數和方法,然後在後面的流程中尋找注入點,插入控制程式碼,完成功能新增。 - Dispatcher和Worker是相互依賴的關係,表現為Dispatcher發起啟動Worker, Worker將結果反饋給Dispatcher。
- Downloader給Source提供圖片檔案的InputStream, 圖片下載的具體執行為Downloader中的OkHttpClient。、
整個框架以Doodle為起點,以Worker為核心,類之間呼叫不會太深, 總體上結構還是比較緊湊的。
瞭解這幾個類,就基本上了解整個框架的構成了。
5.2 執行流
這一節,我們結合各個核心類,再次梳理一下執行流程:
上圖依然是簡化版的執行流,但弄清楚了基本流程,其他細枝末節的流程也都好理解了。
1、圖片載入流程,從框架的 Doodle.load() 開始,返回Request物件;
object Doodle {
fun load(path: String): Request {
return Request(path)
}
}
複製程式碼
2、封裝Request引數之後,以into收尾,由Dispatcher啟動請求;
class Request {
fun into(target: ImageView?)
fillSizeAndLoad(viewWidth, viewHeight)
}
private fun fillSizeAndLoad(targetWidth: Int, targetHeight: Int) {
Dispatcher.start(this)
}
}
複製程式碼
3、先嚐試從記憶體快取獲取bitmap, 無則開啟非同步請求
internal object Dispatcher {
fun start(request: Request?) {
val bitmap = MemoryCache.getBitmap(request.key)
if (bitmap == null) {
val loader = Worker(request, imageView)
loader.priority(request.priority)
.hostHash(request.hostHash)
.execute()
}
}
}
複製程式碼
4、核心的工作都在Worker中執行,包括獲取檔案(解析,下載),解碼,變換,及快取圖片等
internal class Worker(private val request: Request, imageView: ImageView?) : UITask<Void, Void, Any>() {
private var fromMemory = false
private var fromDiskCache = false
override fun doInBackground(vararg params: Void): Any? {
var bitmap: Bitmap? = null
var source: Source? = null
try {
bitmap = MemoryCache.getBitmap(key) // 檢查記憶體快取
if (bitmap == null) {
val filePath = DiskCache[key] // 檢查磁碟快取(結果快取)
fromDiskCache = !TextUtils.isEmpty(filePath)
source = if (fromDiskCache) Source.valueOf(File(filePath!!)) else Source.parse(request) // 解析
bitmap = Decoder.decode(source, request, fromDiskCache) // 解碼
bitmap = transform(request, bitmap) // 變換
if (bitmap != null) {
if (request.memoryCacheStrategy != MemoryCacheStrategy.NONE) {
val toWeakCache = request.memoryCacheStrategy == MemoryCacheStrategy.WEAK
MemoryCache.putBitmap(key, bitmap, toWeakCache) // 快取到記憶體
}
if (!fromDiskCache && request.diskCacheStrategy and DiskCacheStrategy.RESULT != 0) {
storeResult(key, bitmap) // 快取到磁碟
}
}
}
return bitmap
} catch (e: Throwable) {
LogProxy.e(TAG, e)
} finally {
Utils.closeQuietly(source)
}
return null
}
override fun onPostExecute(result: Any?) {
val imageView = target
if (imageView != null) {
imageView.tag = null
}
// 顯示結果
Dispatcher.feedback(request, imageView, result, false)
}
}
複製程式碼
以上程式碼中,有兩點需要提一下:
- Dispatcher啟動Worker之前已經檢查記憶體快取了,為什麼Worker中又檢查一次?
因為可能存在多個請求的bitmap是相同的(key所決定),只是target不同,然後Worker會序列執行這些請求;
當第一個請求結束,圖片已經放到記憶體快取了,接下來的請求可以從記憶體快取中直接獲取bitmap,無需再次解碼。 - 為什麼沒有看到Downloader下載檔案?
Downloader出現在Source.parse(request)方法中,主要是返回一個InputStream;
檔案的下載過程在發生在Decoder.decode()方法中,邊下載邊解碼。
5、迴歸Dispatcher, 重新整理ImageView
internal object Dispatcher {
fun feedback(request: Request, imageView: ImageView? ...) {
if (bitmap != null) {
imageView.setImageBitmap(bitmap)
}
}
}
複製程式碼
六、API
前面說了這麼多實現細節,那到底最終都實現了些什麼功能呢?
看有什麼功能,看介面層的三個類即可。
6.1 Doodle (框架入口)
方法 | 作用 |
---|---|
init(Context) : Config | 初始化,傳入context, 返回全域性配置 |
trimMemory(int) | 整理記憶體(LruCache),傳入ComponentCallbacks2的不同level有不同的策略 |
clearMemory() | 移除LruCache中所有bitmap |
load(String): Request | 傳入圖片路徑,返回Request |
load(int): Request | 傳入資源ID,返回Request |
load(Uri): Request | 傳入URI,返回Request |
downloadOnly(String): File? | 僅下載圖片檔案,不解碼。此方法會走網路請求,不可再UI執行緒呼叫 |
getSourceCacheFile(url: String): File? | 獲取原圖快取,無則返回null。不走網路請求,可以在UI執行緒呼叫 |
cacheBitmap(String,Bitmap,Boolean) | 快取bitmap到Doodle的MemoryCache, 相當於開放MemoryCache, 複用程式碼,統一管理。 |
getCacheBitmap(String): Bitmap? | 獲取快取在Cache中的bitmap |
pauseRequest() | 暫停往任務佇列中插入請求,對RecycleView快速滑動等場景,可呼叫此函式 |
resumeRequest() | 恢復請求 |
notifyEvent(Any, int) | 傳送頁面生命週期事件(通知頁面銷燬以取消請求等) |
6.2 Config (全域性配置)
方法 | 作用 |
---|---|
setUserAgent(String) | 設定User-Agent頭,網路請求將自動填上此Header |
setDiskCachePath(String) | 設定結果快取的儲存路徑 |
setDiskCacheCapacity(Long) | 設定結果快取的容量 |
setDiskCacheMaxAge(Long) | 設定結果快取的最大保留時間(從最近一次訪問算起),預設30天 |
setSourceCacheCapacity(Long) | 設定原圖快取的容量 |
setMemoryCacheCapacity(Long) | 設定記憶體快取的容量,預設為maxMemory的1/6 |
setCompressFormat(Bitmap.CompressFormat) | 設定結果快取的壓縮格式, 預設為PNG |
setDefaultBitmapConfig(Bitmap.Config) | 設定預設的Bitmap.Config,預設為ARGB_8888 |
setGifDecoder(GifDecoder) | 設定GIF解碼器 |
6.3 Request (圖片請求)
方法 | 作用 |
---|---|
sourceKey(String) | 設定資料來源的key url預設情況下作為Request的key的一部分,有時候url有動態的引數,使得url頻繁變化,從而無法快取。 此時可以設定sourceKey,提到path作為Request的key的一部分。 |
override(int, int) | 指定剪裁大小 並不最終bitmap等大小並不一定等於override指定的大小(優先按照 ScaleType剪裁,向下取樣), 若需確切大小的bitmap可配合ResizeTransformation實現。 |
scaleType(ImageView.ScaleType) | 指定縮放型別 如果target為ImageView則會自動從ImageView獲取。 |
memoryCacheStrategy(int) | 設定記憶體快取策略,預設LRU策略 |
diskCacheStrategy(int) | 設定磁碟快取策略,預設ALL |
noCache() | 不做任何快取,包括磁碟快取和記憶體快取 |
onlyIfCached(boolean) | 指定網路請求是否只從快取讀取(原圖快取) |
noClip() | 直接解碼,不做剪裁和壓縮 |
config(Bitmap.Config) | 指定單個請求的Bitmap.Config |
transform(Transformation) | 設定解碼後的圖片變換,可以連續呼叫(會按順序執行) |
priority(int) | 請求優先順序 |
keepOriginalDrawable() | 預設情況下請求開始會先清空ImageView之前的Drawable, 呼叫此方法後會保留之前的Drawable |
placeholder(int) | 設定佔點陣圖,在結果載入完成之前會顯示此drawable |
placeholder(Drawable) | 同上 |
error(int) | 設定載入失敗後的佔點陣圖 |
error(Drawable) | 同上 |
goneIfMiss() | 載入失敗後imageView.visibility = View.GONE |
animation(int) | 設定載入成功後的過渡動畫 |
animation(Animation) | 同上 |
fadeIn(int) | 載入成功後顯示淡入動畫 |
crossFate(int) | 這個動畫效果是原圖從透明度100到0, bitmap從0到100。 當設定placeholder且記憶體快取中沒有指定圖片時, placeholder為原圖。 如果沒有設定placeholder, 效果和fadeIn差不多。 需要注意的是,這個動畫在原圖和bitmap寬高不相等時,動畫結束時圖片會變形。 因此,慎用crossFade。 |
alwaysAnimation(Boolean) | 預設情況下僅在圖片是從磁碟或者網路載入出來時才做動畫,可通過此方法設定總是做動畫 |
asBitmap() | 當設定了GifDecoder時,預設情況下只要圖片是GIF圖片,則用GifDecoder解碼。 呼叫此方法後,只取Gif檔案第一幀,返回bitmap |
host(Any) | 參加Task的host |
cacheInterceptor(CacheInterceptor) | (原圖)快取攔截器,可自定義單個請求的快取路徑,自己管理快取,以免被LRU或者過時規則刪除 |
preLoad() | 預載入 |
get(int) : Bitmap? | 當前執行緒獲取圖片,載入時阻塞當前執行緒, 可設定timeout時間(預設3s),超時未完成則取消任務,返回null。 |
into(SimpleTarget) | 載入圖片後通過SimpleTarget回撥圖片(載入是不阻塞當前執行緒) |
into(ImageView, Callback) | 載入圖片圖片到ImageView,同時通過Callback回撥。 如果Callback中返回true, 說明已經處理該bitmap了,則Doodle不會再setBitmap到ImageView了。 |
into(ImageView?) | 載入圖片圖片到ImageView |
七、總結
本文從架構,流程等方面入手,詳細分析了圖片載入框架的各種實現細節。
從文中可以看出,實現過程大量借鑑了Glide和Picasso, 在此對Glide和Picasso的開源工作者表示敬意和感謝。
這裡就不做太詳細的對比了,這裡只比較下方法數和包大小(功能和效能不太好比較)。
框架 | 版本 | 方法數 | 包大小 |
---|---|---|---|
Glide | 4.8.0 | 3193 | 691k |
Picasso | 2.71828 | 527 | 119k |
Doodle | 1.0.8 | 419 | 100k |
Doodle先是用Java寫的,後面用Kotlin改寫,方法數從200多增加到400多,包大小從60多K增加到100K,真是作啊-_-
Picasso的版本停在2.71828(自然對數e≈2.71828, 剛開始還以為作者棄療了~)好久了,說要出Picasso 3, 但是時間過去N久了也沒見影;
從完備度和穩定性而言,Glide都要優於Picasso,畢竟一直有大量的反饋以及持續的維護。
Doodle在完備度上是不輸Picasso的,並且相對前二者有一些微創新;
但畢竟是新專案,一個人的力量有限,必然會有不足的地方。
感興趣的讀者可以參與進來,歡迎提建議和提程式碼。
專案已釋出到jcenter和github, 專案地址:https://github.com/No89757/Doodle
看多遍不如跑一遍,可以Download下來執行一下,會比看文章有更多的收穫。