這次來面試的是一個有著5年工作經驗的小夥，擷取了一段對話如下：

> 面試官：我看你寫到Glide，為什麼用Glide，而不選擇其它圖片載入框架？  
> 小夥：Glide 使用簡單，鏈式呼叫，很方便，一直用這個。  
> 面試官：有看過它的原始碼嗎？跟其它圖片框架相比有哪些優勢？  
> 小夥：沒有，只是在專案中使用而已~  
> 面試官：假如現在不讓你用開源庫，需要你自己寫一個圖片載入框架，你會考慮哪些方面的問題，說說大概的思路。  
> 小夥：額~，壓縮吧。  
> 面試官：還有嗎？  
> 小夥：額~，這個沒寫過。

說到圖片載入框架，大家最熟悉的莫過於Glide了，但我卻不推薦簡歷上寫熟悉Glide，除非你熟讀它的原始碼，或者參與Glide的開發和維護。

在一般面試中，遇到圖片載入問題的頻率一般不會太低，只是問法會有一些差異，例如：

*   簡歷上寫Glide，那麼會問一下Glide的設計，以及跟其它同類框架的對比 ；
*   假如讓你寫一個圖片載入框架，說說思路；
*   給一個圖片載入的場景，比如網路載入一張或多張大圖，你會怎麼做；

帶著問題進入正文~

一、談談Glide
---------

### 1.1 Glide 使用有多簡單？

Glide由於其口碑好，很多開發者直接在專案中使用，使用方法相當簡單

1、新增依賴：

```
implementation 'com.github.bumptech.glide:glide:4.10.0'
annotationProcessor 'com.github.bumptech.glide:compiler:4.10.0'

```

2、新增網路許可權

```
<uses-permission android:name="android.permission.INTERNET"></uses-permission>

```

3、一句程式碼載入圖片到ImageView

```
Glide.with(this).load(imgUrl).into(mIv1);

```

進階一點的用法，引數設定

```
RequestOptions options = new RequestOptions()
            .placeholder(R.drawable.ic_launcher_background)
            .error(R.mipmap.ic_launcher)
            .diskCacheStrategy(DiskCacheStrategy.NONE)
    		.override(200, 100);
    
Glide.with(this)
            .load(imgUrl)
            .apply(options)
            .into(mIv2);

```

使用Glide載入圖片如此簡單，這讓很多開發者省下自己處理圖片的時間，圖片載入工作全部交給Glide來就完事，同時，很容易就把圖片處理的相關知識點忘掉。

### 1.2 為什麼用Glide？

從前段時間面試的情況，我發現了這個現象：簡歷上寫熟悉Glide的，基本都是熟悉使用方法，很多3年-6年工作經驗，除了說Glide使用方便，不清楚Glide跟其他圖片框架如**Fresco**的對比有哪些優缺點。

首先，當下流行的圖片載入框架有那麼幾個，可以拿 Glide 跟[Fresco](https://link.juejin.cn/?target=https%3A%2F%2Fgithub.com%2Ffacebook%2Ffresco "https://github.com/facebook/fresco")對比，例如這些：

**Glide：**

*   多種圖片格式的快取，適用於更多的內容表現形式（如Gif、WebP、縮圖、Video）
*   生命週期整合（根據Activity或者Fragment的生命週期管理圖片載入請求）
*   高效處理Bitmap（bitmap的複用和主動回收，減少系統回收壓力）
*   高效的快取策略，靈活（Picasso只會快取原始尺寸的圖片，Glide快取的是多種規格），載入速度快且記憶體開銷小（預設Bitmap格式的不同，使得記憶體開銷是Picasso的一半）

**Fresco：**

*   最大的優勢在於5.0以下(最低2.3)的bitmap載入。在5.0以下系統，Fresco將圖片放到一個特別的記憶體區域(Ashmem區)
*   大大減少OOM（在更底層的Native層對OOM進行處理，圖片將不再佔用App的記憶體）
*   適用於需要高效能載入大量圖片的場景

對於一般App來說，Glide完全夠用，而對於圖片需求比較大的App，為了防止載入大量圖片導致OOM，Fresco 會更合適一些。並不是說用Glide會導致OOM，Glide預設用的記憶體快取是LruCache，記憶體不會一直往上漲。

二、假如讓你自己寫個圖片載入框架，你會考慮哪些問題？
--------------------------

首先，梳理一下必要的圖片載入框架的需求：

*   非同步載入：執行緒池
*   切換執行緒：Handler，沒有爭議吧
*   快取：LruCache、DiskLruCache
*   防止OOM：軟引用、LruCache、圖片壓縮、Bitmap畫素儲存位置
*   記憶體洩露：注意ImageView的正確引用，生命週期管理
*   列表滑動載入的問題：載入錯亂、隊滿任務過多問題

當然，還有一些不是必要的需求，例如載入動畫等。

### 2.1 非同步載入：

執行緒池，多少個？

快取一般有三級，記憶體快取、硬碟、網路。

由於網路會阻塞，所以讀記憶體和硬碟可以放在一個執行緒池，網路需要另外一個執行緒池，網路也可以採用Okhttp內建的執行緒池。

讀硬碟和讀網路需要放在不同的執行緒池中處理，所以用兩個執行緒池比較合適。

Glide 必然也需要多個執行緒池，看下原始碼是不是這樣

```
public final class GlideBuilder {
  ...
  private GlideExecutor sourceExecutor; //載入原始檔的執行緒池，包括網路載入
  private GlideExecutor diskCacheExecutor; //載入硬碟快取的執行緒池
  ...
  private GlideExecutor animationExecutor; //動畫執行緒池

```

Glide使用了三個執行緒池，不考慮動畫的話就是兩個。

### 2.2 切換執行緒：

圖片非同步載入成功，需要在主執行緒去更新ImageView，

**無論是RxJava、EventBus，還是Glide，只要是想從子執行緒切換到Android主執行緒，都離不開Handler。**

看下Glide 相關原始碼：

```
    class EngineJob<r> implements DecodeJob.Callback<r>,Poolable {
	  private static final EngineResourceFactory DEFAULT_FACTORY = new EngineResourceFactory();
	  //建立Handler
	  private static final Handler MAIN_THREAD_HANDLER =
	      new Handler(Looper.getMainLooper(), new MainThreadCallback());

```

> 問RxJava是完全用Java語言寫的，那怎麼實現從子執行緒切換到Android主執行緒的？ 依然有很多3-6年的開發答不上來這個很基礎的問題，而且只要是這個問題回答不出來的，接下來有關於原理的問題，基本都答不上來。
> 
> 有不少工作了很多年的Android開發不知道**鴻洋、郭霖、玉剛說**，不知道掘金是個啥玩意，內心估計會想是不是還有叫掘銀掘鐵的（我不知道有沒有）。
> 
> 我想表達的是，幹這一行，真的是需要有對技術的熱情，不斷學習，**不怕別人比你優秀，就怕比你優秀的人比你還努力，而你卻不知道**。

### 2.3 快取

我們常說的圖片三級快取：記憶體快取、硬碟快取、網路。

#### 2.3.1 記憶體快取

一般都是用`LruCache`

Glide 預設記憶體快取用的也是LruCache，只不過並沒有用Android SDK中的LruCache，不過內部同樣是基於LinkHashMap，所以原理是一樣的。

```
// -> GlideBuilder#build
if (memoryCache == null) {
  memoryCache = new LruResourceCache(memorySizeCalculator.getMemoryCacheSize());
}

```

既然說到LruCache ，必須要了解一下LruCache的特點和原始碼：

**為什麼用LruCache？**

LruCache 採用**最近最少使用演算法**，設定一個快取大小，當快取達到這個大小之後，會將最老的資料移除，避免圖片佔用記憶體過大導致OOM。

##### LruCache 原始碼分析

```
    public class LruCache<k v=""> {
	// 資料最終存在 LinkedHashMap 中
    private final LinkedHashMap<k v=""> map;
	...
	public LruCache(int maxSize) {
        if (maxSize <= 0) {
            throw new IllegalArgumentException("maxSize <= 0");
        }
        this.maxSize = maxSize;
		// 建立一個LinkedHashMap，accessOrder 傳true
        this.map = new LinkedHashMap<k v="">(0, 0.75f, true);
    }
    ...

```

LruCache 構造方法裡建立一個**LinkedHashMap**，accessOrder 引數傳true，表示按照訪問順序排序，資料儲存基於LinkedHashMap。

先看看LinkedHashMap 的原理吧

LinkedHashMap 繼承 HashMap，在 HashMap 的基礎上進行擴充套件，put 方法並沒有重寫，說明**LinkedHashMap遵循HashMap的陣列加連結串列的結構**，

![HashMap](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/11/3/16e3183d92d1997d~tplv-t2oaga2asx-watermark.image)

LinkedHashMap重寫了 **createEntry** 方法。

看下HashMap 的 createEntry 方法

```
void createEntry(int hash, K key, V value, int bucketIndex) {
    HashMapEntry<k> e = table[bucketIndex];
    table[bucketIndex] = new HashMapEntry<>(hash, key, value, e);
    size++;
}

```

**HashMap的陣列裡面放的是`HashMapEntry` 物件**

看下LinkedHashMap 的 createEntry方法

```
void createEntry(int hash, K key, V value, int bucketIndex) {
    HashMapEntry<k> old = table[bucketIndex];
    LinkedHashMapEntry<k> e = new LinkedHashMapEntry<>(hash, key, value, old);
    table[bucketIndex] = e; //陣列的新增
    e.addBefore(header);  //處理連結串列
    size++;
}

```

**LinkedHashMap的陣列裡面放的是`LinkedHashMapEntry`物件**

**LinkedHashMapEntry**

```
private static class LinkedHashMapEntry<k> extends HashMapEntry<k> {
    // These fields comprise the doubly linked list used for iteration.
    LinkedHashMapEntry<k> before, after; //雙向連結串列

private void remove() {
        before.after = after;
        after.before = before;
    }

private void addBefore(LinkedHashMapEntry<k> existingEntry) {
        after  = existingEntry;
        before = existingEntry.before;
        before.after = this;
        after.before = this;
    }

```

**LinkedHashMapEntry繼承 HashMapEntry，新增before和after變數，所以是一個雙向連結串列結構，還新增了`addBefore`和`remove` 方法，用於新增和刪除連結串列節點。**

**LinkedHashMapEntry#addBefore**  
將一個資料新增到Header的前面

```
private void addBefore(LinkedHashMapEntry<k> existingEntry) {
        after  = existingEntry;
        before = existingEntry.before;
        before.after = this;
        after.before = this;
}

```

existingEntry 傳的都是連結串列頭header，將一個節點新增到header節點前面，只需要移動連結串列指標即可，新增新資料都是放在連結串列頭header 的before位置，**連結串列頭節點header的before是最新訪問的資料，header的after則是最舊的資料。**

再看下**LinkedHashMapEntry#remove**

```
private void remove() {
        before.after = after;
        after.before = before;
    }

```

連結串列節點的移除比較簡單，改變指標指向即可。

再看下**LinkHashMap的put 方法**

```
public final V put(K key, V value) {
    
    V previous;
    synchronized (this) {
        putCount++;
        //size增加
        size += safeSizeOf(key, value);
        // 1、linkHashMap的put方法
        previous = map.put(key, value);
        if (previous != null) {
            //如果有舊的值，會覆蓋，所以大小要減掉
            size -= safeSizeOf(key, previous);
        }
    }

trimToSize(maxSize);
    return previous;
}

```

LinkedHashMap 結構可以用這種圖表示

![LinkedHashMap](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/11/3/16e3183d9e907230~tplv-t2oaga2asx-watermark.image)

LinkHashMap 的 put方法和get方法最後會呼叫`trimToSize`方法，**LruCache 重寫`trimToSize`方法，判斷記憶體如果超過一定大小，則移除最老的資料**

**LruCache#trimToSize，移除最老的資料**

```
public void trimToSize(int maxSize) {
    while (true) {
        K key;
        V value;
        synchronized (this) {
            
            //大小沒有超出，不處理
            if (size <= maxSize) {
                break;
            }

//超出大小，移除最老的資料
            Map.Entry<k v=""> toEvict = map.eldest();
            if (toEvict == null) {
                break;
            }

key = toEvict.getKey();
            value = toEvict.getValue();
            map.remove(key);
            //這個大小的計算，safeSizeOf 預設返回1；
            size -= safeSizeOf(key, value);
            evictionCount++;
        }

entryRemoved(true, key, value, null);
    }
}

```

對LinkHashMap 還不是很理解的話可以參考：  
[圖解LinkedHashMap原理](https://link.juejin.cn/?target=https%3A%2F%2Fwww.jianshu.com%2Fp%2F8f4f58b4b8ab "https://www.jianshu.com/p/8f4f58b4b8ab")

LruCache小結：

*   **LinkHashMap 繼承HashMap，在 HashMap的基礎上，新增了雙向連結串列結構，每次訪問資料的時候，會更新被訪問的資料的連結串列指標，具體就是先在連結串列中刪除該節點，然後新增到連結串列頭header之前，這樣就保證了連結串列頭header節點之前的資料都是最近訪問的（從連結串列中刪除並不是真的刪除資料，只是移動連結串列指標，資料本身在map中的位置是不變的）。**
*   **LruCache 內部用LinkHashMap存取資料，在雙向連結串列保證資料新舊順序的前提下，設定一個最大記憶體，往裡面put資料的時候，當資料達到最大記憶體的時候，將最老的資料移除掉，保證記憶體不超過設定的最大值。**

#### 2.3.2 磁碟快取 DiskLruCache

依賴：

> implementation 'com.jakewharton:disklrucache:2.0.2'

DiskLruCache 跟 LruCache 實現思路是差不多的，一樣是設定一個總大小，每次往硬碟寫檔案，總大小超過閾值，就會將舊的檔案刪除。簡單看下remove操作：

```
	// DiskLruCache 內部也是用LinkedHashMap
	private final LinkedHashMap<string entry=""> lruEntries =
      	new LinkedHashMap<string entry="">(0, 0.75f, true);
	...

public synchronized boolean remove(String key) throws IOException {
	    checkNotClosed();
	    validateKey(key);
	    Entry entry = lruEntries.get(key);
	    if (entry == null || entry.currentEditor != null) {
	      return false;
	    }
	
            //一個key可能對應多個value，hash衝突的情況
	    for (int i = 0; i < valueCount; i++) {
	      File file = entry.getCleanFile(i);
            //透過 file.delete() 刪除快取檔案，刪除失敗則拋異常
	      if (file.exists() && !file.delete()) {
	        throw new IOException("failed to delete " + file);
	      }
	      size -= entry.lengths[i];
	      entry.lengths[i] = 0;
	    }
	    ...
	    return true;
  }

```

可以看到 DiskLruCache 同樣是利用LinkHashMap的特點，只不過陣列裡面存的 Entry 有點變化，Editor 用於操作檔案。

```
private final class Entry {
    private final String key;

private final long[] lengths;

private boolean readable;

private Editor currentEditor;

private long sequenceNumber;
	...
}

```

### 2.4 防止OOM

載入圖片非常重要的一點是需要防止OOM，上面的LruCache快取大小設定，可以有效防止OOM，但是當圖片需求比較大，可能需要設定一個比較大的快取，這樣的話發生OOM的機率就提高了，那應該探索其它防止OOM的方法。

##### 方法1：軟引用

回顧一下Java的四大引用：

*   強引用： 普通變數都屬於強引用，比如 `private Context context;`
*   軟應用： SoftReference，在發生OOM之前，垃圾回收器會回收SoftReference引用的物件。
*   弱引用： WeakReference，發生GC的時候，垃圾回收器會回收WeakReference中的物件。
*   虛引用： 隨時會被回收，沒有使用場景。

怎麼理解強引用：

> 強引用物件的回收時機依賴垃圾回收演算法，我們常說的可達性分析演算法，當Activity銷燬的時候，Activity會跟GCRoot斷開，至於GCRoot是誰？這裡可以大膽猜想，Activity物件的建立是在ActivityThread中，ActivityThread要回撥Activity的各個生命週期，肯定是持有Activity引用的，那麼這個GCRoot可以認為就是ActivityThread，當Activity 執行onDestroy的時候，ActivityThread 就會斷開跟這個Activity的聯絡，Activity到GCRoot不可達，所以會被垃圾回收器標記為可回收物件。

軟引用的設計就是應用於會發生OOM的場景，大記憶體物件如Bitmap，可以透過 SoftReference 修飾，防止大物件造成OOM，看下這段程式碼

```
    private static LruCache<string softreference="">> mLruCache = new LruCache<string softreference="">>(10 * 1024){
        @Override
        protected int sizeOf(String key, SoftReference<bitmap> value) {
            //預設返回1，這裡應該返回Bitmap佔用的記憶體大小，單位：K

//Bitmap被回收了，大小是0
            if (value.get() == null){
                return 0;
            }
            return value.get().getByteCount() /1024;
        }
    };

```

LruCache裡存的是軟引用物件，那麼當記憶體不足的時候，Bitmap會被回收，也就是說透過SoftReference修飾的Bitmap就不會導致OOM。

當然，這段程式碼存在一些問題，Bitmap被回收的時候，LruCache剩餘的大小應該重新計算，可以寫個方法，當Bitmap取出來是空的時候，LruCache清理一下，重新計算剩餘記憶體；

還有另一個問題，就是記憶體不足時軟引用中的Bitmap被回收的時候，這個LruCache就形同虛設，相當於記憶體快取失效了，必然出現效率問題。

##### 方法2：onLowMemory

**當記憶體不足的時候，Activity、Fragment會呼叫`onLowMemory`方法，可以在這個方法裡去清除快取，Glide使用的就是這一種方式來防止OOM。**

```
//Glide
public void onLowMemory() {
    clearMemory();
}

public void clearMemory() {
    // Engine asserts this anyway when removing resources, fail faster and consistently
    Util.assertMainThread();
    // memory cache needs to be cleared before bitmap pool to clear re-pooled Bitmaps too. See #687.
    memoryCache.clearMemory();
    bitmapPool.clearMemory();
    arrayPool.clearMemory();
  }

```

##### 方法3：從Bitmap 畫素儲存位置考慮

我們知道，系統為每個程式，也就是每個虛擬機器分配的記憶體是有限的，早期的16M、32M，現在100+M，  
虛擬機器的記憶體劃分主要有5部分：

*   虛擬機器棧
*   本地方法棧
*   程式計數器
*   方法區
*   堆

而物件的分配一般都是在堆中，堆是JVM中最大的一塊記憶體，OOM一般都是發生在堆中。

Bitmap 之所以佔記憶體大不是因為物件本身大，而是因為Bitmap的畫素資料， **Bitmap的畫素資料大小 = 寬 \* 高 \* 1畫素佔用的記憶體。**

1畫素佔用的記憶體是多少？不同格式的Bitmap對應的畫素佔用記憶體是不同的，具體是多少呢？  
在Fresco中看到如下定義程式碼

```
  /**
   * Bytes per pixel definitions
   */
  public static final int ALPHA_8_BYTES_PER_PIXEL = 1;
  public static final int ARGB_4444_BYTES_PER_PIXEL = 2;
  public static final int ARGB_8888_BYTES_PER_PIXEL = 4;
  public static final int RGB_565_BYTES_PER_PIXEL = 2;
  public static final int RGBA_F16_BYTES_PER_PIXEL = 8;

```

如果Bitmap使用 `RGB_565` 格式，則1畫素佔用 2 byte，`ARGB_8888` 格式則佔4 byte。  
**在選擇圖片載入框架的時候，可以將記憶體佔用這一方面考慮進去，更少的記憶體佔用意味著發生OOM的機率越低。** Glide記憶體開銷是Picasso的一半，就是因為預設Bitmap格式不同。

至於寬高，是指Bitmap的寬高，怎麼計算的呢？看`BitmapFactory.Options` 的 outWidth

```
/**
     * The resulting width of the bitmap. If {@link #inJustDecodeBounds} is
     * set to false, this will be width of the output bitmap after any
     * scaling is applied. If true, it will be the width of the input image
     * without any accounting for scaling.
     *
     * <p>outWidth will be set to -1 if there is an error trying to decode.</p>
     */
    public int outWidth;

```

看註釋的意思，如果 `BitmapFactory.Options` 中指定 `inJustDecodeBounds` 為true，則為原圖寬高，如果是false，則是縮放後的寬高。**所以我們一般可以透過壓縮來減小Bitmap畫素佔用記憶體**。

扯遠了，上面分析了Bitmap畫素資料大小的計算，只是說明Bitmap畫素資料為什麼那麼大。**那是否可以讓畫素資料不放在java堆中，而是放在native堆中呢**？據說Android 3.0到8.0 之間Bitmap畫素資料存在Java堆，而8.0之後畫素資料存到native堆中，是不是真的？看下原始碼就知道了~

###### 8.0 Bitmap

java層建立Bitmap方法

```
    public static Bitmap createBitmap(@Nullable DisplayMetrics display, int width, int height,
            @NonNull Config config, boolean hasAlpha, @NonNull ColorSpace colorSpace) {
        ...
        Bitmap bm;
        ...
        if (config != Config.ARGB_8888 || colorSpace == ColorSpace.get(ColorSpace.Named.SRGB)) {
            //最終都是透過native方法建立
            bm = nativeCreate(null, 0, width, width, height, config.nativeInt, true, null, null);
        } else {
            bm = nativeCreate(null, 0, width, width, height, config.nativeInt, true,
                    d50.getTransform(), parameters);
        }

...
        return bm;
    }

```

Bitmap 的建立是透過native方法 `nativeCreate`

對應原始碼 [8.0.0\_r4/xref/frameworks/base/core/jni/android/graphics/Bitmap.cpp](https://link.juejin.cn/?target=https%3A%2F%2Fwww.androidos.net.cn%2Fandroid%2F8.0.0_r4%2Fxref%2Fframeworks%2Fbase%2Fcore%2Fjni%2Fandroid%2Fgraphics%2FBitmap.cpp "https://www.androidos.net.cn/android/8.0.0_r4/xref/frameworks/base/core/jni/android/graphics/Bitmap.cpp")

```
//Bitmap.cpp
static const JNINativeMethod gBitmapMethods[] = {
    {   "nativeCreate",             "([IIIIIIZ[FLandroid/graphics/ColorSpace$Rgb$TransferParameters;)Landroid/graphics/Bitmap;",
        (void*)Bitmap_creator },
...

```

JNI動態註冊，nativeCreate 方法 對應 `Bitmap_creator`；

```
//Bitmap.cpp
static jobject Bitmap_creator(JNIEnv* env, jobject, jintArray jColors,
                              jint offset, jint stride, jint width, jint height,
                              jint configHandle, jboolean isMutable,
                              jfloatArray xyzD50, jobject transferParameters) {
    ...
    //1. 申請堆記憶體，建立native層Bitmap
    sk_sp<bitmap> nativeBitmap = Bitmap::allocateHeapBitmap(&bitmap, NULL);
    if (!nativeBitmap) {
        return NULL;
    }

...
    //2.建立java層Bitmap
    return createBitmap(env, nativeBitmap.release(), getPremulBitmapCreateFlags(isMutable));
}

```

主要兩個步驟：

1.  申請記憶體，建立native層Bitmap，看下`allocateHeapBitmap`方法

```
//
static sk_sp<bitmap> allocateHeapBitmap(size_t size, const SkImageInfo& info, size_t rowBytes,
        SkColorTable* ctable) {
    // calloc 是c++ 的申請記憶體函式
    void* addr = calloc(size, 1);
    if (!addr) {
        return nullptr;
    }
    return sk_sp<bitmap>(new Bitmap(addr, size, info, rowBytes, ctable));
}

```

可以看到透過c++的 `calloc` 函式申請了一塊記憶體空間，然後建立native層Bitmap物件，把記憶體地址傳過去，也就是native層的Bitmap資料（畫素資料）是存在native堆中。

2.  建立java 層Bitmap

```
//Bitmap.cpp
jobject createBitmap(JNIEnv* env, Bitmap* bitmap,
        int bitmapCreateFlags, jbyteArray ninePatchChunk, jobject ninePatchInsets,
        int density) {
    ...
    BitmapWrapper* bitmapWrapper = new BitmapWrapper(bitmap);
     //透過JNI回撥Java層，呼叫java層的Bitmap構造方法
    jobject obj = env->NewObject(gBitmap_class, gBitmap_constructorMethodID,
            reinterpret_cast<jlong>(bitmapWrapper), bitmap->width(), bitmap->height(), density,
            isMutable, isPremultiplied, ninePatchChunk, ninePatchInsets);

...
    return obj;
}

```

env->NewObject，透過JNI建立Java層Bitmap物件，`gBitmap_class，gBitmap_constructorMethodID`這些變數是什麼意思，看下面這個方法，對應java層的Bitmap的類名和構造方法。

```
//Bitmap.cpp
int register_android_graphics_Bitmap(JNIEnv* env)
{
    gBitmap_class = MakeGlobalRefOrDie(env, FindClassOrDie(env, "android/graphics/Bitmap"));
    gBitmap_nativePtr = GetFieldIDOrDie(env, gBitmap_class, "mNativePtr", "J");
    gBitmap_constructorMethodID = GetMethodIDOrDie(env, gBitmap_class, "<init>", "(JIIIZZ[BLandroid/graphics/NinePatch$InsetStruct;)V");
    gBitmap_reinitMethodID = GetMethodIDOrDie(env, gBitmap_class, "reinit", "(IIZ)V");
    gBitmap_getAllocationByteCountMethodID = GetMethodIDOrDie(env, gBitmap_class, "getAllocationByteCount", "()I");
    return android::RegisterMethodsOrDie(env, "android/graphics/Bitmap", gBitmapMethods,
                                         NELEM(gBitmapMethods));
}

```

8.0 的Bitmap建立就兩個點：

1.  建立native層Bitmap，在native堆申請記憶體。
2.  透過JNI建立java層Bitmap物件，這個物件在java堆中分配記憶體。

畫素資料是存在native層Bitmap，也就是證明8.0的Bitmap畫素資料存在native堆中。

###### 7.0 Bitmap

直接看native層的方法，

```
//JNI動態註冊
static const JNINativeMethod gBitmapMethods[] = {
    {   "nativeCreate",             "([IIIIIIZ)Landroid/graphics/Bitmap;",
        (void*)Bitmap_creator },
...

static jobject Bitmap_creator(JNIEnv* env, jobject, jintArray jColors,
                              jint offset, jint stride, jint width, jint height,
                              jint configHandle, jboolean isMutable) {
    ... 
    //1.透過這個方法來建立native層Bitmap
    Bitmap* nativeBitmap = GraphicsJNI::allocateJavaPixelRef(env, &bitmap, NULL);
    ...

return GraphicsJNI::createBitmap(env, nativeBitmap,
            getPremulBitmapCreateFlags(isMutable));
}

```

native層Bitmap 建立是透過`GraphicsJNI::allocateJavaPixelRef`，看看裡面是怎麼分配的， GraphicsJNI 的實現類是[Graphics.cpp](https://link.juejin.cn/?target=https%3A%2F%2Fwww.androidos.net.cn%2Fandroid%2F7.0.0_r31%2Fxref%2Fframeworks%2Fbase%2Fcore%2Fjni%2Fandroid%2Fgraphics%2FGraphics.cpp "https://www.androidos.net.cn/android/7.0.0_r31/xref/frameworks/base/core/jni/android/graphics/Graphics.cpp")

```
android::Bitmap* GraphicsJNI::allocateJavaPixelRef(JNIEnv* env, SkBitmap* bitmap,
                                             SkColorTable* ctable) {
    const SkImageInfo& info = bitmap->info();
    
    size_t size;
    //計算需要的空間大小
    if (!computeAllocationSize(*bitmap, &size)) {
        return NULL;
    }

// we must respect the rowBytes value already set on the bitmap instead of
    // attempting to compute our own.
    const size_t rowBytes = bitmap->rowBytes();
    // 1. 建立一個陣列，透過JNI在java層建立的
    jbyteArray arrayObj = (jbyteArray) env->CallObjectMethod(gVMRuntime,
                                                             gVMRuntime_newNonMovableArray,
                                                             gByte_class, size);
    ...
    // 2. 獲取建立的陣列的地址
    jbyte* addr = (jbyte*) env->CallLongMethod(gVMRuntime, gVMRuntime_addressOf, arrayObj);
    ...
    //3. 建立Bitmap，傳這個地址
    android::Bitmap* wrapper = new android::Bitmap(env, arrayObj, (void*) addr,
            info, rowBytes, ctable);
    wrapper->getSkBitmap(bitmap);
    // since we're already allocated, we lockPixels right away
    // HeapAllocator behaves this way too
    bitmap->lockPixels();

return wrapper;
}

```

可以看到，7.0 畫素記憶體的分配是這樣的：

1.  透過JNI呼叫java層建立一個陣列
2.  然後建立native層Bitmap，把陣列的地址傳進去。

由此說明，7.0 的Bitmap畫素資料是放在java堆的。

當然，3.0 以下Bitmap畫素記憶體據說也是放在native堆的，但是需要手動釋放native層的Bitmap，也就是需要手動呼叫recycle方法，native層記憶體才會被回收。這個大家可以自己去看原始碼驗證。

###### native層Bitmap 回收問題

Java層的Bitmap物件由垃圾回收器自動回收，而native層Bitmap印象中我們是不需要手動回收的，原始碼中如何處理的呢？

記得有個面試題是這樣的：

> 說說final、finally、finalize 的關係

三者除了長得像，其實沒有半毛錢關係，final、finally大家都用的比較多，而 `finalize` 用的少，或者沒用過，`finalize` 是 Object 類的一個方法，註釋是這樣的：

```
/**
     * Called by the garbage collector on an object when garbage collection
     * determines that there are no more references to the object.
     * A subclass overrides the {@code finalize} method to dispose of
     * system resources or to perform other cleanup.
     * <p>
     ...**/
  protected void finalize() throws Throwable { }

```

意思是說，垃圾回收器確認這個物件沒有其它地方引用到它的時候，會呼叫這個物件的`finalize`方法，子類可以重寫這個方法，做一些釋放資源的操作。

**在6.0以前，Bitmap 就是透過這個finalize 方法來釋放native層物件的。** [6.0 Bitmap.java](https://link.juejin.cn/?target=https%3A%2F%2Fwww.androidos.net.cn%2Fandroid%2F6.0.1_r16%2Fxref%2Fframeworks%2Fbase%2Fgraphics%2Fjava%2Fandroid%2Fgraphics%2FBitmap.java "https://www.androidos.net.cn/android/6.0.1_r16/xref/frameworks/base/graphics/java/android/graphics/Bitmap.java")

```
Bitmap(long nativeBitmap, byte[] buffer, int width, int height, int density,
            boolean isMutable, boolean requestPremultiplied,
            byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets) {
        ...
        mNativePtr = nativeBitmap;
        //1.建立 BitmapFinalizer
        mFinalizer = new BitmapFinalizer(nativeBitmap);
        int nativeAllocationByteCount = (buffer == null ? getByteCount() : 0);
        mFinalizer.setNativeAllocationByteCount(nativeAllocationByteCount);
}

private static class BitmapFinalizer {
        private long mNativeBitmap;

// Native memory allocated for the duration of the Bitmap,
        // if pixel data allocated into native memory, instead of java byte[]
        private int mNativeAllocationByteCount;

BitmapFinalizer(long nativeBitmap) {
            mNativeBitmap = nativeBitmap;
        }

public void setNativeAllocationByteCount(int nativeByteCount) {
            if (mNativeAllocationByteCount != 0) {
                VMRuntime.getRuntime().registerNativeFree(mNativeAllocationByteCount);
            }
            mNativeAllocationByteCount = nativeByteCount;
            if (mNativeAllocationByteCount != 0) {
                VMRuntime.getRuntime().registerNativeAllocation(mNativeAllocationByteCount);
            }
        }

@Override
        public void finalize() {
            try {
                super.finalize();
            } catch (Throwable t) {
                // Ignore
            } finally {
                //2.就是這裡了，
                setNativeAllocationByteCount(0);
                nativeDestructor(mNativeBitmap);
                mNativeBitmap = 0;
            }
        }
    }

```

在Bitmap構造方法建立了一個 `BitmapFinalizer`類，重寫finalize 方法，在java層Bitmap被回收的時候，BitmapFinalizer 物件也會被回收，finalize 方法肯定會被呼叫，在裡面釋放native層Bitmap物件。

6.0 之後做了一些變化，BitmapFinalizer 沒有了，被NativeAllocationRegistry取代。

例如 8.0 Bitmap構造方法

```
    Bitmap(long nativeBitmap, int width, int height, int density,
            boolean isMutable, boolean requestPremultiplied,
            byte[] ninePatchChunk, NinePatch.InsetStruct ninePatchInsets) {
       
        ...
        mNativePtr = nativeBitmap;
        long nativeSize = NATIVE_ALLOCATION_SIZE + getAllocationByteCount();
        //  建立NativeAllocationRegistry這個類，呼叫registerNativeAllocation 方法
        NativeAllocationRegistry registry = new NativeAllocationRegistry(
            Bitmap.class.getClassLoader(), nativeGetNativeFinalizer(), nativeSize);
        registry.registerNativeAllocation(this, nativeBitmap);
    }

```

NativeAllocationRegistry 就不分析了， **不管是BitmapFinalizer 還是NativeAllocationRegistry，目的都是在java層Bitmap被回收的時候，將native層Bitmap物件也回收掉。** 一般情況下我們無需手動呼叫recycle方法，由GC去盤它即可。

上面分析了Bitmap畫素儲存位置，我們知道，Android 8.0 之後Bitmap畫素記憶體放在native堆，Bitmap導致OOM的問題基本不會在8.0以上裝置出現了（沒有記憶體洩漏的情況下），那8.0 以下裝置怎麼辦？趕緊升級或換手機吧~

![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/11/3/16e3183d9ec9fa30~tplv-t2oaga2asx-watermark.image)

我們換手機當然沒問題，但是並不是所有人都能跟上Android系統更新的步伐，所以，問題還是要解決~

Fresco 之所以能跟Glide 正面交鋒，必然有其獨特之處，文中開頭列出 Fresco 的優點是：“在5.0以下(最低2.3)系統，Fresco將圖片放到一個特別的記憶體區域(Ashmem區)” 這個Ashmem區是一塊匿名共享記憶體，Fresco 將Bitmap畫素放到共享記憶體去了，共享記憶體是屬於native堆記憶體。

Fresco 關鍵原始碼在 `PlatformDecoderFactory` 這個類

```
public class PlatformDecoderFactory {

/**
   * Provide the implementation of the PlatformDecoder for the current platform using the provided
   * PoolFactory
   *
   * @param poolFactory The PoolFactory
   * @return The PlatformDecoder implementation
   */
  public static PlatformDecoder buildPlatformDecoder(
      PoolFactory poolFactory, boolean gingerbreadDecoderEnabled) {
    //8.0 以上用 OreoDecoder 這個解碼器
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
      int maxNumThreads = poolFactory.getFlexByteArrayPoolMaxNumThreads();
      return new OreoDecoder(
          poolFactory.getBitmapPool(), maxNumThreads, new Pools.SynchronizedPool<>(maxNumThreads));
    } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
      //大於5.0小於8.0用 ArtDecoder 解碼器
      int maxNumThreads = poolFactory.getFlexByteArrayPoolMaxNumThreads();
      return new ArtDecoder(
          poolFactory.getBitmapPool(), maxNumThreads, new Pools.SynchronizedPool<>(maxNumThreads));
    } else {
      if (gingerbreadDecoderEnabled && Build.VERSION.SDK_INT < Build.VERSION_CODES.KITKAT) {
        //小於4.4 用 GingerbreadPurgeableDecoder 解碼器
        return new GingerbreadPurgeableDecoder();
      } else {
        //這個就是4.4到5.0 用的解碼器了
        return new KitKatPurgeableDecoder(poolFactory.getFlexByteArrayPool());
      }
    }
  }
}

```

8.0 先不看了，看一下 4.4 以下是怎麼得到Bitmap的，看下`GingerbreadPurgeableDecoder`這個類有個獲取Bitmap的方法

```
//GingerbreadPurgeableDecoder
private Bitmap decodeFileDescriptorAsPurgeable(
      CloseableReference<pooledbytebuffer> bytesRef,
      int inputLength,
      byte[] suffix,
      BitmapFactory.Options options) {
    //  MemoryFile ：匿名共享記憶體
    MemoryFile memoryFile = null;
    try {
      //將圖片資料複製到匿名共享記憶體
      memoryFile = copyToMemoryFile(bytesRef, inputLength, suffix);
      FileDescriptor fd = getMemoryFileDescriptor(memoryFile);
      if (mWebpBitmapFactory != null) {
        // 建立Bitmap，Fresco自己寫了一套建立Bitmap方法
        Bitmap bitmap = mWebpBitmapFactory.decodeFileDescriptor(fd, null, options);
        return Preconditions.checkNotNull(bitmap, "BitmapFactory returned null");
      } else {
        throw new IllegalStateException("WebpBitmapFactory is null");
      }
    } 
  }

```

捋一捋，4.4以下，Fresco 使用匿名共享記憶體來儲存Bitmap資料，首先將圖片資料複製到匿名共享記憶體中，然後使用Fresco自己寫的載入Bitmap的方法。

Fresco對不同Android版本使用不同的方式去載入Bitmap，至於4.4-5.0，5.0-8.0，8.0 以上，對應另外三個解碼器，大家可以從`PlatformDecoderFactory` 這個類入手，自己去分析，思考為什麼不同平臺要分這麼多個解碼器，8.0 以下都用匿名共享記憶體不好嗎？期待你在評論區跟大家分享~

### 2.5 ImageView 記憶體洩露

> 曾經在Vivo駐場開發，帶有頭像功能的頁面被測出記憶體洩漏，原因是SDK中有個載入網路頭像的方法，持有ImageView引用導致的。

當然，修改也比較簡單粗暴，**將ImageView用WeakReference修飾**就完事了。

事實上，這種方式雖然解決了記憶體洩露問題，但是並不完美，例如在介面退出的時候，我們除了希望ImageView被回收，同時希望載入圖片的任務可以取消，隊未執行的任務可以移除。

Glide的做法是監聽生命週期回撥，看 `RequestManager` 這個類

```
public void onDestroy() {
    targetTracker.onDestroy();
    for (Target> target : targetTracker.getAll()) {
      //清理任務
      clear(target);
    }
    targetTracker.clear();
    requestTracker.clearRequests();
    lifecycle.removeListener(this);
    lifecycle.removeListener(connectivityMonitor);
    mainHandler.removeCallbacks(addSelfToLifecycle);
    glide.unregisterRequestManager(this);
  }

```

在Activity/fragment 銷燬的時候，取消圖片載入任務，細節大家可以自己去看原始碼。

### 2.6 列表載入問題

#### 圖片錯亂

由於RecyclerView或者LIstView的複用機制，網路載入圖片開始的時候ImageView是第一個item的，載入成功之後ImageView由於複用可能跑到第10個item去了，在第10個item顯示第一個item的圖片肯定是錯的。

常規的做法是給ImageView設定tag，tag一般是圖片地址，更新ImageView之前判斷tag是否跟url一致。

當然，可以在item從列表消失的時候，取消對應的圖片載入任務。要考慮放在圖片載入框架做還是放在UI做比較合適。

#### 執行緒池任務過多

列表滑動，會有很多圖片請求，如果是第一次進入，沒有快取，那麼佇列會有很多工在等待。所以在請求網路圖片之前，需要判斷佇列中是否已經存在該任務，存在則不加到佇列去。

總結
--

本文透過Glide開題，分析一個圖片載入框架必要的需求，以及各個需求涉及到哪些技術和原理。

*   非同步載入：最少兩個執行緒池
*   切換到主執行緒：Handler
*   快取：LruCache、DiskLruCache，涉及到LinkHashMap原理
*   防止OOM：軟引用、LruCache、圖片壓縮沒展開講、Bitmap畫素儲存位置原始碼分析、Fresco部分原始碼分析
*   記憶體洩露：注意ImageView的正確引用，生命週期管理
*   列表滑動載入的問題：載入錯亂用tag、隊滿任務存在則不新增</pooledbytebuffer></p></init></jlong></bitmap></bitmap></bitmap></bitmap></string></string></string></string></k></k></k></k></k></k></k></k></k></k></k></k></r></r>

面試官：簡歷上最好不要寫Glide，不是問原始碼那麼簡單

相關文章