一張png格式的圖片在內(nèi)存中占據(jù)的大小，如果要優(yōu)化，可以從哪些方向著手？

本文已授權(quán)陌陌公眾號(hào)（紅陽(yáng)）獨(dú)家發(fā)布

最近封裝了一個(gè)高斯模糊組件，正好整理了與圖片相關(guān)的理論基礎(chǔ)。 那么，這次我就來(lái)說(shuō)說(shuō)如何估算一張圖片在顯存中的大小。 如果你想優(yōu)化的話，可以從什么方向入手。

問(wèn)問(wèn)題

在閱讀本文之前，我們先思考幾個(gè)問(wèn)題：

Q1：一張png格式的圖片，圖片文件大小為55.8KB，那么加載到顯存中時(shí)占用的大小是多少？

Q2：為什么有時(shí)同一個(gè)應(yīng)用程序，應(yīng)用程序中相同的界面，界面上相同的圖片，但在不同設(shè)備上的內(nèi)存消耗不同？

Q3：圖片占用顯存大小的公式：圖片幀率*每像素像素大小，這些說(shuō)法是否正確或嚴(yán)謹(jǐn)？

Q4：優(yōu)化圖片顯存大小可以從哪些方向入手？

文本

在開(kāi)發(fā)中，經(jīng)常需要對(duì)圖片進(jìn)行優(yōu)化，因?yàn)閳D片很容易耗盡顯存。 這樣，你就需要知道一張圖片的大小是如何估算的，以及加載到顯存中時(shí)占用了多少空間？

先看一張圖：

這是一張普通的png圖片，我們來(lái)看看它的具體信息：

圖片的幀率為1080*452，而我們?cè)诠P記本上聽(tīng)到的png圖片大小只有55.8KB，那么問(wèn)題來(lái)了：

我們看到一張大小為55.8KB的png圖片，它在顯存中是否也占用了55.8KB的大小呢？

澄清這一點(diǎn)非常重要，因?yàn)槲矣龅竭^(guò)有人說(shuō)我的一張圖片只有幾KB，雖然界面上顯示了幾百?gòu)垐D片，但為什么顯存占用這么高？

因此，我們需要明確一個(gè)概念：我們?cè)诠P記本上看到的png格式或者jpg格式的圖片，png（jpg）只是這張圖片的容器，它們通過(guò)相應(yīng)的壓縮算法對(duì)原圖的每張圖片進(jìn)行壓縮。 將像素信息轉(zhuǎn)換為另一種數(shù)據(jù)格式表示，從而達(dá)到壓縮的目的，減小圖像文件的大小。

而當(dāng)我們通過(guò)代碼將這張圖片加載到顯存中時(shí)，會(huì)先解析圖片文件本身的數(shù)據(jù)格式，然后還原為位圖，即對(duì)象，其大小取決于圖片文件的數(shù)據(jù)格式像素和幀速率提高。

因此，png或jpg格式的圖片大小與加載到顯存中的這張圖片所占用的大小完全不同。 你不能說(shuō)我的jpg圖片只有10KB，所以它只占用10KB的顯存空間，這是錯(cuò)誤的。

那么，如何估算一張圖片占用的顯存空間呢？

最后附上一篇大師文章很詳細(xì)，有興趣可以看一下。 我在這里不會(huì)說(shuō)得那么專業(yè)，但我會(huì)根據(jù)我的粗略了解告訴你。

圖像內(nèi)存大小

網(wǎng)上很多文章都會(huì)介紹估算一張圖片占用顯存大小的公式：碼率*每個(gè)像素的大小。

這句話是對(duì)是錯(cuò)，我只是覺(jué)得不結(jié)合場(chǎng)景直接表達(dá)是不嚴(yán)謹(jǐn)?shù)摹?/p>

在原生操作中，有些場(chǎng)景下，圖片加載到顯存時(shí)的幀率會(huì)經(jīng)過(guò)一層換算，所以雖然最終的圖片大小估算公式仍然是幀率*像素大小，但此時(shí)的幀率它不再是圖片本身的幀率。

我們來(lái)做一個(gè)實(shí)驗(yàn)，從以下幾個(gè)考慮因素相互結(jié)合的場(chǎng)景中加載同一張圖片，看看它占用了多少顯存空間：

測(cè)試代碼模板如下：

private void loadResImage(ImageView imageView) {
	BitmapFactory.Options options = new BitmapFactory.Options();
	Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.weixin, options);
    //Bitmap bitmap = BitmapFactory.decodeFile("mnt/sdcard/weixin.png", options);
	imageView.setImageBitmap(bitmap);
	Log.i("!!!!!!", "bitmap：ByteCount = " + bitmap.getByteCount() + ":::bitmap：AllocationByteCount = " + bitmap.getAllocationByteCount());
	Log.i("!!!!!!", "width:" + bitmap.getWidth() + ":::height:" + bitmap.getHeight());
	Log.i("!!!!!!", "inDensity:" + options.inDensity + ":::inTargetDensity:" + options.inTargetDensity);
	Log.i("!!!!!!", "imageview.width:" + imageView.getWidth() + ":::imageview.height:" + 	imageView.getHeight());
}

ps：這里提一下，可以使用()方法獲取當(dāng)前圖像占用的顯存大小。 其實(shí)api19之后還有另外一種方法，只不過(guò)復(fù)用時(shí)獲取的大小含義也發(fā)生了變化。 這個(gè)特殊場(chǎng)景就不詳細(xì)說(shuō)了。 說(shuō)，有興趣的話，自己去看看吧。 總之，我們知道，在大多數(shù)場(chǎng)景下，我們可以通過(guò)()復(fù)制圖片所占用的顯存大小來(lái)驗(yàn)證我們的實(shí)驗(yàn)。

圖片為上圖：一張png格式的圖片，幀率為1080*452，圖片文件本身大小為56KB

序列號(hào)前提內(nèi)存大小

圖片位于res/，設(shè)備dpi=240，設(shè)備1dp=1.5px，控制寬高=50dp

(4.19MB)

圖片位于res/，設(shè)備dpi=240，設(shè)備1dp=1.5px，控制寬高=500dp

(4.19MB)

圖片位于res/-hdpi，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.86MB)

圖片位于res/-xhdpi，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.05MB)

圖片位于res/-xhdpi，設(shè)備dpi=160，設(shè)備1dp=1px

(476.7KB)

圖片位于res/-hdpi，設(shè)備dpi=160，設(shè)備1dp=1px

(846.5KB)

圖片位于res/，設(shè)備dpi=160，設(shè)備1dp=1px

(1.86MB)

圖片位于c盤，設(shè)備dpi=160，設(shè)備1dp=1px

(1.86MB)

圖片位于c盤，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.86MB)

看看是否是同一張圖片，但是在不同的場(chǎng)景下，占用的顯存大小可能會(huì)不一樣，這個(gè)后面會(huì)分析。 上述場(chǎng)景中，列出了不同的圖片來(lái)源、不同的設(shè)備、不同的顯示控件大小。 我們繼續(xù)看一個(gè)場(chǎng)景：同一張圖片，保存為不同格式的文件（不是重命名，可以用ps）；

圖片：jpg格式的圖片，碼率為1080*452，圖片文件本身大小為85.2KB

ps：還是和上一張圖一樣，只是保存為jpg格式

序號(hào)前提顯存大小比較對(duì)象

10

圖片位于res/，設(shè)備dpi=240，設(shè)備1dp=1.5px

(4.19MB)

序列號(hào)1

11

圖片位于res/-hdpi，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.86MB)

序列號(hào)3

12

圖片位于res/-xhdpi，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.05MB)

序列號(hào)4

13

圖片位于c盤，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.86MB)

9號(hào)

對(duì)于這里列出的幾個(gè)場(chǎng)景，每行的末尾還寫有每個(gè)場(chǎng)景比較的實(shí)驗(yàn)對(duì)象的序號(hào)。 你可以對(duì)比確認(rèn)一下，發(fā)現(xiàn)數(shù)據(jù)是否一樣，所以這里可以得到一點(diǎn)推論：

圖片的不同格式：png或jpg似乎對(duì)圖片占用顯存的大小沒(méi)有影響

好，我們開(kāi)始分析這類實(shí)驗(yàn)數(shù)據(jù)：

首先如果根據(jù)圖片大小的估算公式為：幀率*像素大小

所以，這張圖片的大小應(yīng)該按照這個(gè)公式：1080*452*4B=≈1.86MB

ps：這里像素大小是按4B估算的，因?yàn)椴恢付〞r(shí)系統(tǒng)默認(rèn)為像素?cái)?shù)據(jù)格式，其他格式如下：

上面的實(shí)驗(yàn)中應(yīng)該是這個(gè)大小，那為什么會(huì)出現(xiàn)一些其他大小的數(shù)據(jù)呢？ 那么，讓我們一一分解：

分析點(diǎn)1

我們先看一下數(shù)字1和2的實(shí)驗(yàn)。 三者之間的區(qū)別僅在于圖片中顯示的空間大小。 之所以做這個(gè)測(cè)試，是因?yàn)橛腥苏J(rèn)為圖片占用顯存的大小與界面上顯示的圖片大小有關(guān)。 顯示控件越大，占用的視頻內(nèi)存就越多。 事實(shí)上，這些認(rèn)識(shí)都是錯(cuò)誤的。

想想看，圖片在繪制到控件上之前必須先加載到顯存中，所以當(dāng)圖片需要申請(qǐng)顯存空間時(shí)，它不知道此時(shí)要顯示的控件的大小，怎么可能控件大小影響圖片占用 至于顯存空間，除非提前通知，否則會(huì)自動(dòng)參與圖片加載過(guò)程。

分析點(diǎn)2

我們看一下序號(hào)2、3、4的實(shí)驗(yàn)nc10 內(nèi)存，這三個(gè)的區(qū)別在于圖片在res中的資源目錄不同。 當(dāng)圖片放在res中不同的目錄下時(shí)，為什么最終圖片加載到顯存中所占用的大小不同呢？

如果你看一下.()的源碼，你會(huì)發(fā)現(xiàn)，系統(tǒng)在加載res目錄下的資源圖片時(shí)，會(huì)根據(jù)圖片存放的目錄不同，進(jìn)行碼率轉(zhuǎn)換，轉(zhuǎn)換后的碼率會(huì)根據(jù)圖片的大小進(jìn)行轉(zhuǎn)換。規(guī)則是：

新圖片的高度=原圖片的高度*（設(shè)備的dpi/目錄對(duì)應(yīng)的dpi）

新圖片的長(zhǎng)度=原圖片的長(zhǎng)度*（設(shè)備的dpi/目錄對(duì)應(yīng)的dpi）

目錄名與dpi的對(duì)應(yīng)關(guān)系如下，無(wú)后綴對(duì)應(yīng)：

那么，我們來(lái)看看實(shí)驗(yàn)號(hào)2，根據(jù)上面的理論，我們來(lái)估算一下這張圖片的顯存大?。?/p>

轉(zhuǎn)換后幀率：1080*(240/160)*452*(240/160)=1620*678

事實(shí)上，此時(shí)的幀率并不是原始圖像的幀率。 經(jīng)過(guò)一層轉(zhuǎn)換，最終估算出圖像大?。?/p>

1620*678*4B=≈4.19MB

現(xiàn)在你知道序列號(hào)2的實(shí)驗(yàn)結(jié)果是怎么來(lái)的了吧。 同理，序號(hào)3資源的目標(biāo)是240對(duì)應(yīng)的hdpi，而設(shè)備的dpi也是240，所以轉(zhuǎn)換后的幀率依然是原圖本身，結(jié)果也是1.86MB。

總結(jié)：

位于res中不同資源目錄的圖像，在加載到顯存時(shí)，會(huì)先進(jìn)行碼率轉(zhuǎn)換，然后估算大小。 轉(zhuǎn)換的影響是由設(shè)備的dpi和不同的資源目錄引起的。

分析點(diǎn)3

根據(jù)分析點(diǎn)2的理論，看序號(hào)5、6、7的實(shí)驗(yàn)，這三個(gè)實(shí)驗(yàn)似乎是用來(lái)和序號(hào)2、3、4的實(shí)驗(yàn)進(jìn)行比較的，這是我們可以從這6個(gè)實(shí)驗(yàn)中得到。 推論是：

因此，可能會(huì)出現(xiàn)這樣的情況，同一個(gè)app，但是運(yùn)行在不同dpi的設(shè)備上，同樣的界面，但是內(nèi)存消耗可能會(huì)不同。

為什么我們?nèi)匀徽f(shuō)可能會(huì)有所不同？ 根據(jù)前面的理論，如果圖像相同，目錄相同，但dpi設(shè)備不同，那么幀率轉(zhuǎn)換可能不同，顯存消耗也一定不同。 為什么要用“可能性”這些詞呢？

emmm，繼續(xù)看下面的分析點(diǎn)。

分析點(diǎn)4

序號(hào)8和9的實(shí)驗(yàn)，雖然我想驗(yàn)證只有圖片來(lái)源為res時(shí)是否會(huì)有碼率轉(zhuǎn)換，但結(jié)果也證明了當(dāng)圖片在C盤、SD卡或者目錄下時(shí)、網(wǎng)上還是網(wǎng)上（雖然網(wǎng)上的圖片最終都是下載到c盤的），只要不在res目錄下，此類圖片占用顯存大小的估算公式是原圖碼率*像素大小。

當(dāng)然，如果有時(shí)間看一下源碼，確實(shí)只有()方法會(huì)根據(jù)里面的dpi來(lái)轉(zhuǎn)換碼率，其他()則不會(huì)。

那么，為什么在上一節(jié)中，非常重要的是要解釋一下，雖然同一個(gè)應(yīng)用程序運(yùn)行在不同 dpi 設(shè)備上，但相同的界面可能會(huì)消耗不同的顯存。 為什么這里用了這么多“可能”這個(gè)詞？

對(duì)啊，大家想想吧。 顯然，根據(jù)我們整理的理論，估算圖像內(nèi)存大小的公式為：碼率*像素大小。 之后，如果圖片的來(lái)源在res中，則需要注意圖片放置的資源目錄，以及設(shè)備本身的dpi值，因?yàn)橄到y(tǒng)在res中取資源圖片，所以會(huì)根據(jù)這兩點(diǎn)進(jìn)行幀率轉(zhuǎn)換。 這樣的話，圖片的顯存大小一定不一樣吧？

emmm，這個(gè)就看你自己的動(dòng)機(jī)了。 如果你開(kāi)發(fā)一個(gè)app，圖片的相關(guān)操作都是經(jīng)過(guò)操作的，所以上面的問(wèn)題可以用肯定的說(shuō)法來(lái)代替。 但現(xiàn)在還是有那么多自己寫的強(qiáng)大的圖片開(kāi)源庫(kù)，而且不同的圖片開(kāi)源庫(kù)內(nèi)部的圖片加載處理、緩存策略、復(fù)用策略也不同。

因此，如果使用某個(gè)圖像開(kāi)源庫(kù)，加載一張圖片到顯存會(huì)占用多少空間，就需要深入該圖像開(kāi)源庫(kù)分析其處理。

由于基本上所有的圖像開(kāi)源庫(kù)都會(huì)對(duì)圖像操作進(jìn)行優(yōu)化，所以下面我們繼續(xù)講圖像優(yōu)化。

圖像優(yōu)化

有了上面的理論基礎(chǔ)，現(xiàn)在我們來(lái)思考一下，如果圖片占用顯存空間太大，需要優(yōu)化，可以入手一些方向，就更有趣了。

圖像搶占顯存大小的公式為：幀率*像素大小，但在某些場(chǎng)景下，例如圖像來(lái)源為res，最終圖像的碼率可能不是原始圖像的幀率，但歸根結(jié)底，對(duì)于計(jì)算機(jī)而言，確實(shí)是按照這個(gè)公式來(lái)估算的。

因此，如果只從圖像本身考慮優(yōu)化，只有兩個(gè)方向：

不僅僅考慮圖片本身，其他方面可以是顯存警告時(shí)自動(dòng)清除、圖片弱引用等操作。

減小像素大小

第二個(gè)方向非常容易操作。 雖然系統(tǒng)默認(rèn)采用該格式進(jìn)行處理，但每個(gè)像素都會(huì)占用4B大小。 改變這種格式自然會(huì)增加圖像占用的顯存大小。

一般都會(huì)換成某種格式，但是前者不支持透明度，所以這個(gè)方案不通用，要看你app中圖片的透明度要求，其實(shí)也可以緩存，但是會(huì)增加質(zhì)量。

因?yàn)榛径际鞘褂脠D像開(kāi)源庫(kù)，所以這里介紹一下圖像開(kāi)源庫(kù)的一些處理方法：

//fresco，默認(rèn)使用ARGB_8888
Fresco.initialize(context, ImagePipelineConfig.newBuilder(context).setBitmapsConfig(Bitmap.Config.RGB_565).build());

//Glide，不同版本nc10 內(nèi)存，不同像素格式

班級(jí) {

@Override  
public void applyOptions(Context context, GlideBuilder builder) {  
    builder.setDecodeFormat(DecodeFormat.PREFER_ARGB_8888);  
}  
@Override  
public void registerComponents(Context context, Glide glide) {  
}  

//定義為.xml上的元數(shù)據(jù)

"com..lab..":value=""/>

//，默認(rèn)

.with(.()).load(url).(..).into();

上面的代碼摘自網(wǎng)上，其正確性應(yīng)該是可信的。 尚未得到證實(shí)。 如果有興趣可以去相關(guān)源碼確認(rèn)一下。

增加比特率

如果能夠讓系統(tǒng)在加載圖片時(shí)不以原始碼率為標(biāo)準(zhǔn)，而是增加一定的比例，那么自然就可以達(dá)到減少圖片顯存的效果了。

同樣，系統(tǒng)提供了相關(guān)的API：

BitmapFactory.Options.inSampleSize

設(shè)置后，寬度和高度會(huì)減少兩倍。 例如：一張寬高為 的圖片，設(shè)置為 4 后，實(shí)際加載到顯存的圖片寬高為 。占用顯存為 0.75M，而不是 12M，節(jié)省 15 倍

其中的段落摘自最后鏈接的文章。 網(wǎng)上也有很多關(guān)于如何操作的講解文章，這里不再贅述。 我沒(méi)有看過(guò)這些開(kāi)源圖像庫(kù)的內(nèi)部處理，但我推測(cè)它們對(duì)圖像的優(yōu)化處理應(yīng)該也是通過(guò)這個(gè)API來(lái)操作的。

雖然，無(wú)論哪種圖像開(kāi)源庫(kù)，在加載圖像時(shí)，內(nèi)部都必須對(duì)圖像進(jìn)行優(yōu)化，盡管我們并沒(méi)有自動(dòng)表明需要圖像壓縮過(guò)程。 這就是我在里面說(shuō)的，為什么當(dāng)你使用開(kāi)源圖像庫(kù)時(shí)，你不能再根據(jù)圖像內(nèi)存大小部分提到的理論來(lái)估計(jì)圖像內(nèi)存的大小了。

我們可以做一個(gè)實(shí)驗(yàn)，先看下面的實(shí)驗(yàn)：

開(kāi)源庫(kù)必備顯存大小

圖片位于res/，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.86MB)

圖片位于res/-hdpi，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.86MB)

圖片位于res/-xhdpi，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.86MB)

圖片位于c盤，設(shè)備dpi=240，設(shè)備1dp=1.5px

(1.86MB)

如果使用的話，無(wú)論圖片來(lái)源在哪里，都會(huì)根據(jù)原始圖片的比特率來(lái)估計(jì)幀率，從中得到的數(shù)據(jù)也可以得到確認(rèn)。 像素大小按默認(rèn)格式處理。

我推測(cè)，內(nèi)部加載res圖像時(shí)，應(yīng)該先通過(guò)自己的方法獲取圖像文件對(duì)象，最后通過(guò)()或()等形式加載圖像，總之不是通過(guò)()加載圖片，這就可以解釋為什么無(wú)論放在哪個(gè)res目錄下，圖片的大小都是根據(jù)原圖的幀率來(lái)估計(jì)的。有時(shí)間的話可以去看看源碼代碼來(lái)驗(yàn)證它。

我們來(lái)看看Glide的實(shí)驗(yàn)：

開(kāi)源庫(kù)必備顯存大小

滑行

圖片位于res/，設(shè)備dpi=240，設(shè)備1dp=1.5px，顯示到寬高為500dp的控件

(91.99KB)

滑行

圖片位于res/-hdpi，設(shè)備dpi=240，設(shè)備1dp=1.5px，顯示到寬高為500dp的控件

(91.99KB)

滑行

圖片位于res/-hdpi，設(shè)備dpi=240，設(shè)備1dp=1.5px，不顯示到控件，只獲取對(duì)象

(1.86MB)

滑行

圖片位于c盤，設(shè)備dpi=240，設(shè)備1dp=1.5px，不顯示到控件，只獲取對(duì)象

(1.86MB)

滑行

圖片位于c盤，設(shè)備dpi=240，設(shè)備1dp=1.5px，全屏控制顯示（1920*984）

(7.21MB)

可以看到，Glide的處理方式與以下有很大不同：

如果只獲取物體，則根據(jù)原始圖片的碼率估算圖片占用的顯存大小。 但如果通過(guò)into()將圖像加載到控件中，則幀速率將根據(jù)控件的大小進(jìn)行壓縮。

例如第一個(gè)，顯示控件的寬度和高度都是500dp=750px，原始圖像碼率是1080*452，最終轉(zhuǎn)換后的碼率是：750*314，所以圖像內(nèi)存大?。?50*314*4B=；

比如最后一張，顯示的控件的寬高為1920*984，原圖的幀率換算為：1920*984，所以圖像內(nèi)存大?。?920*984*4B=；

至于這個(gè)轉(zhuǎn)換的規(guī)則，我不知道。 有時(shí)間的話可以去源碼看看，不過(guò)也就是說(shuō)Glide會(huì)根據(jù)顯示控件的大小手動(dòng)轉(zhuǎn)換碼率，然后加載到顯存中。

但無(wú)論是Glide，無(wú)論圖片來(lái)源是否在res中，也無(wú)論設(shè)備的dpi是多少，是否需要與源res目錄進(jìn)行幀率轉(zhuǎn)換。

因此，在關(guān)于圖像內(nèi)存大小的章節(jié)中，我會(huì)說(shuō)，如果使用開(kāi)源庫(kù)圖像，那么，這個(gè)理論就不適用，因?yàn)橄到y(tǒng)已經(jīng)開(kāi)放了設(shè)置，允許我們根據(jù)需要加載中的圖片首先將顯存按一定比例進(jìn)行壓縮，以減少顯存占用。

而這種圖像開(kāi)源庫(kù)自然會(huì)利用系統(tǒng)的支持，內(nèi)部做一些顯存優(yōu)化，還可能涉及到圖像裁剪等其他優(yōu)化，但不管怎樣，這個(gè)時(shí)候系統(tǒng)原生的估計(jì)圖像內(nèi)存大小的理論基礎(chǔ)自然不適用。

為了提高碼率，不僅僅是圖像開(kāi)源庫(kù)內(nèi)部默認(rèn)的優(yōu)化處理，他們自然會(huì)提供相關(guān)的供我們使用，例如：

//fresco
ImageRequestBuilder.newBuilderWithSource(uri)
    .setResizeOptions(new ResizeOptions(500, 500)).build()

比如可以用這些方法來(lái)自動(dòng)提高碼率，這樣圖片占用的顯存大小也會(huì)減少，但是我不知道這個(gè)內(nèi)部是如何處理傳入的(500,500)的，因?yàn)槲覀円?，系統(tǒng)開(kāi)放的API只支持一定速率的壓縮，所以內(nèi)部肯定會(huì)進(jìn)行一層處理和轉(zhuǎn)換。

需要注意的是，我使用的是0.14.1版本。 不知道高版本怎么樣。 該版本的()套接字僅支持jpg格式的圖片。 如果要處理png圖片，網(wǎng)上有很多，可以自己查一下。

對(duì)于Glide來(lái)說(shuō)，它已經(jīng)根據(jù)控件的大小做了一個(gè)處理。 如果想自動(dòng)處理，可以使用它的()方法。

總結(jié)

最后，稍微總結(jié)一下：

本文整理的理論基本上都是總結(jié)別人博客顯存并做相關(guān)實(shí)驗(yàn)得到的推論。 推論的正確性自然弱于閱讀源碼本身。 因此，如果有錯(cuò)誤的地方，歡迎賜教。 如果有時(shí)間，也可以看一下相關(guān)源碼來(lái)確認(rèn)一下。

186信息網(wǎng)原創(chuàng)文章，轉(zhuǎn)載請(qǐng)注明本文來(lái)自：www.lutong-group.com