摘要：加載圖的機(jī)制是什么，為何不會(huì)內(nèi)存泄漏自定義可拖動(dòng)的顯示高清大圖的技術(shù)博客大總結(jié)提供一個(gè)設(shè)置圖片的入口，里面去獲得圖片的真實(shí)的寬度和高度，以及初始化我們的重寫，在里面根據(jù)用戶移動(dòng)的手勢(shì)，去更新顯示區(qū)域的參數(shù)。

7.0.0.1 加載bitmap圖片的時(shí)候需要注意什么？為何bitmap容易造成OOM？如何計(jì)算Bitmap占用內(nèi)存？

7.0.0.2 如何理解recycle釋放內(nèi)存問題？圖片加載到內(nèi)存其實(shí)有兩部分?jǐn)?shù)據(jù)，這是為何？

7.0.0.3 如何在不壓縮圖片的情況下加載高清大圖？加載圖的機(jī)制是什么，為何不會(huì)內(nèi)存泄漏？

7.0.0.7 LRU算法的原理？核心思想是什么？如果緩存滿了的話，什么方法來管理移除最近最少使用的item和添加新的item？

博客筆記大匯總【15年10月到至今】，包括Java基礎(chǔ)及深入知識(shí)點(diǎn)，Android技術(shù)博客，Python學(xué)習(xí)筆記等等，還包括平時(shí)開發(fā)中遇到的bug匯總，當(dāng)然也在工作之余收集了大量的面試題，長(zhǎng)期更新維護(hù)并且修正，持續(xù)完善……開源的文件是markdown格式的！同時(shí)也開源了生活博客，從12年起，積累共計(jì)500篇[近100萬字]，將會(huì)陸續(xù)發(fā)表到網(wǎng)上，轉(zhuǎn)載請(qǐng)注明出處，謝謝！

鏈接地址：https://github.com/yangchong2...

如果覺得好，可以star一下，謝謝！當(dāng)然也歡迎提出建議，萬事起于忽微，量變引起質(zhì)變！所有的筆記將會(huì)更新到GitHub上，同時(shí)保持更新，歡迎同行提出或者push不同的看法或者筆記！

注意問題

直接加載大容量的高清Bitmap很容易出現(xiàn)顯示不完整、內(nèi)存溢出OOM的問題，所以最好按一定的采樣率將圖片縮小后再加載進(jìn)來

為減少流量消耗，可對(duì)圖片采用內(nèi)存緩存策略，又為了避免圖片占用過多內(nèi)存導(dǎo)致內(nèi)存溢出，最好以軟引用方式持有圖片

如果還需要網(wǎng)上下載圖片，注意要開子線程去做下載的耗時(shí)操作技術(shù)博客大總結(jié)

為何bitmap容易造成OOM

如何計(jì)算Bitmap占用內(nèi)存

1.1 如何計(jì)算占用內(nèi)存

如果圖片要顯示下Android設(shè)備上，ImageView最終是要加載Bitmap對(duì)象的，就要考慮單個(gè)Bitmap對(duì)象的內(nèi)存占用了，如何計(jì)算一張圖片的加載到內(nèi)存的占用呢？其實(shí)就是所有像素的內(nèi)存占用總和：

bitmap內(nèi)存大小 = 圖片長(zhǎng)度 x 圖片寬度 x 單位像素占用的字節(jié)數(shù)

起決定因素就是最后那個(gè)參數(shù)了，Bitmap"常見有2種編碼方式：ARGB_8888和RGB_565，ARGB_8888每個(gè)像素點(diǎn)4個(gè)byte，RGB_565是2個(gè)byte，一般都采用ARGB_8888這種。那么常見的1080*1920的圖片內(nèi)存占用就是：1920 x 1080 x 4 = 7.9M

1.2 上面方法計(jì)算內(nèi)存對(duì)嗎

我看到好多博客都是這樣計(jì)算的，但是這樣算對(duì)嗎？有沒有哥們?cè)囼?yàn)過這種方法正確性？我覺得看博客要對(duì)博主表示懷疑，論證別人寫的是否正確。更多詳細(xì)可以看我的GitHub：https://github.com/yangchong211

說出我的結(jié)論：上面1.1這種說法也對(duì)，但是不全對(duì)，沒有說明場(chǎng)景，同時(shí)也忽略了一個(gè)影響項(xiàng)：Density。接下來看看源代碼。

inDensity默認(rèn)為圖片所在文件夾對(duì)應(yīng)的密度；inTargetDensity為當(dāng)前系統(tǒng)密度。

加載一張本地資源圖片，那么它占用的內(nèi)存 = width height nTargetDensity/inDensity nTargetDensity/inDensity 一個(gè)像素所占的內(nèi)存。

@Nullable
public static Bitmap decodeResourceStream(@Nullable Resources res, @Nullable TypedValue value,
        @Nullable InputStream is, @Nullable Rect pad, @Nullable Options opts) {
    validate(opts);
    if (opts == null) {
        opts = new Options();
    }

    if (opts.inDensity == 0 && value != null) {
        final int density = value.density;
        if (density == TypedValue.DENSITY_DEFAULT) {
            opts.inDensity = DisplayMetrics.DENSITY_DEFAULT;
        } else if (density != TypedValue.DENSITY_NONE) {
            opts.inDensity = density;
        }
    }
    
    if (opts.inTargetDensity == 0 && res != null) {
        opts.inTargetDensity = res.getDisplayMetrics().densityDpi;
    }
    
    return decodeStream(is, pad, opts);
}

正確說法，這個(gè)注意呢？計(jì)算公式如下所示

對(duì)資源文件：width height nTargetDensity/inDensity nTargetDensity/inDensity 一個(gè)像素所占的內(nèi)存；

別的：width height 一個(gè)像素所占的內(nèi)存；

1.3 一個(gè)像素占用多大內(nèi)存技術(shù)博客大總結(jié)

Bitmap.Config用來描述圖片的像素是怎么被存儲(chǔ)的？

ARGB_8888: 每個(gè)像素4字節(jié). 共32位，默認(rèn)設(shè)置。

Alpha_8: 只保存透明度，共8位，1字節(jié)。

ARGB_4444: 共16位，2字節(jié)。

RGB_565:共16位，2字節(jié)，只存儲(chǔ)RGB值。

如何理解recycle釋放內(nèi)存問題？

在Android2.3.3(API 10)及之前的版本中，Bitmap對(duì)象與其像素?cái)?shù)據(jù)是分開存儲(chǔ)的，Bitmap對(duì)象存儲(chǔ)在Dalvik heap中，而Bitmap對(duì)象的像素?cái)?shù)據(jù)則存儲(chǔ)在Native Memory（本地內(nèi)存）中或者說Derict Memory（直接內(nèi)存）中，這使得存儲(chǔ)在Native Memory中的像素?cái)?shù)據(jù)的釋放是不可預(yù)知的，我們可以調(diào)用recycle()方法來對(duì)Native Memory中的像素?cái)?shù)據(jù)進(jìn)行釋放，前提是你可以清楚的確定Bitmap已不再使用了，如果你調(diào)用了Bitmap對(duì)象recycle()之后再將Bitmap繪制出來，就會(huì)出現(xiàn)”Canvas: trying to use a recycled bitmap”錯(cuò)誤，而在Android3.0(API 11)之后，Bitmap的像素?cái)?shù)據(jù)和Bitmap對(duì)象一起存儲(chǔ)在Dalvik heap中。

圖片加載到內(nèi)存其實(shí)有兩部分?jǐn)?shù)據(jù)，這是為何？技術(shù)博客大總結(jié)

一個(gè)圖片加載到內(nèi)存里，其實(shí)是有兩部分?jǐn)?shù)據(jù)組成，一部分是圖片的相關(guān)描述信息，另一部分就是最重要的像素信息（這部分是有byte數(shù)組組成的），android系統(tǒng)為了提高對(duì)圖片的處理效率，對(duì)于圖片的處理都是調(diào)用了底層的功能（由C語言實(shí)現(xiàn)的），也就是說一個(gè)圖片加載到內(nèi)存里后是使用兩部分的內(nèi)存區(qū)域，簡(jiǎn)單的說：一部分是java可用的內(nèi)存區(qū)，一部分是c可用的內(nèi)存區(qū)，這兩個(gè)內(nèi)存區(qū)域是不能相互直接使用的，這個(gè)bitmap對(duì)象是由java分配的，當(dāng)然不用的時(shí)候系統(tǒng)會(huì)自動(dòng)回收了，可是那個(gè)對(duì)應(yīng)的C可用的內(nèi)存區(qū)域jvm是不能直接回收的，這個(gè)只能調(diào)用底層的功能釋放。所以你要調(diào)用recycle方法來釋放那一部分內(nèi)存。

查看源碼如下所示

翻譯這段解釋：釋放bitmap內(nèi)存的時(shí)候，它會(huì)釋放和這個(gè)bitmap有關(guān)的native內(nèi)存，同時(shí)它會(huì)清理有關(guān)數(shù)據(jù)對(duì)象的引用，但是這里處理數(shù)據(jù)對(duì)象的引用，并不是立即清理數(shù)據(jù)（他并不是調(diào)用玩recycle()方法，就直接清理這個(gè)內(nèi)存，他只是給垃圾回收機(jī)制發(fā)送一個(gè)指令，讓它在bitmap沒有對(duì)象引用的時(shí)候，來進(jìn)行垃圾回收）。當(dāng)調(diào)用recycle()方法之后，這個(gè)bitmap就會(huì)被表明為“死亡狀態(tài)”。這個(gè)時(shí)候你在調(diào)用bitmap其他相關(guān)的方法，例如果get像素()或set像素()就會(huì)拋出一個(gè)異常。同時(shí)這個(gè)操作是不可逆的，所以一定百分之百確定這個(gè)bitmap在以后的場(chǎng)景下，不會(huì)被你的程序在使用到，再去調(diào)用recycle()方法。所以谷歌源碼中建議我們，可以不用去主動(dòng)調(diào)用recycle()方法，因?yàn)樵跊]有引用的情況下，我們的垃圾回收機(jī)制會(huì)主動(dòng)的清理內(nèi)存。

通過看源碼，我們會(huì)發(fā)現(xiàn)，這個(gè)方法首先將這個(gè)Bitmap的引用置為null，然后調(diào)用了nativeRecycle(mNativeBitMap)方法，這個(gè)方法很明顯是個(gè)JNI調(diào)用，會(huì)調(diào)用底層的c或者c++代碼就可以做到對(duì)該內(nèi)存的立即回收，而不需要等待那不確定啥時(shí)候會(huì)執(zhí)行的GC來回收了。

如何在不壓縮圖片的情況下加載高清大圖？

使用BitmapRegionDecoder，主要用于顯示圖片的某一塊矩形區(qū)域，如果你需要顯示某個(gè)圖片的指定區(qū)域，那么這個(gè)類非常合適。

加載圖的機(jī)制是什么，為何不會(huì)內(nèi)存泄漏？

自定義可拖動(dòng)的顯示高清大圖的View技術(shù)博客大總結(jié)

提供一個(gè)設(shè)置圖片的入口，setInputStream里面去獲得圖片的真實(shí)的寬度和高度，以及初始化我們的mDecoder

重寫onTouchEvent，在里面根據(jù)用戶移動(dòng)的手勢(shì)，去更新顯示區(qū)域的參數(shù)。在onMeasure里面為我們的顯示區(qū)域的rect賦值，大小為view的尺寸

每次更新區(qū)域參數(shù)后，調(diào)用invalidate，onDraw里面去regionDecoder.decodeRegion拿到bitmap，然后draw。

public void trimToSize(int maxSize) {
    while(true) {
        Object key;
        Object value;
        synchronized(this) {
            if (this.size < 0 || this.map.isEmpty() && this.size != 0) {
                throw new IllegalStateException(this.getClass().getName() + ".sizeOf() is reporting inconsistent results!");
            }

            if (this.size <= maxSize || this.map.isEmpty()) {
                return;
            }

            Entry toEvict = (Entry)this.map.entrySet().iterator().next();
            key = toEvict.getKey();
            value = toEvict.getValue();
            this.map.remove(key);
            //計(jì)算現(xiàn)在緩存的大小，然后減掉多余的，內(nèi)部調(diào)用的是sizeOf()方法
            this.size -= this.safeSizeOf(key, value);
            ++this.evictionCount;
        }

        //如果你想在在我們的緩存中實(shí)現(xiàn)二級(jí)緩存，可以實(shí)現(xiàn)此方法，源碼中是空方法。
        this.entryRemoved(true, key, value, (Object)null);
    }
}