Android 高效內(nèi)存-圖片內(nèi)存使用優(yōu)化

內(nèi)容整理自網(wǎng)絡(luò)。

創(chuàng)新互聯(lián)專注于中大型企業(yè)的成都做網(wǎng)站、網(wǎng)站建設(shè)、外貿(mào)營銷網(wǎng)站建設(shè)和網(wǎng)站改版、網(wǎng)站營銷服務(wù)，追求商業(yè)策劃與數(shù)據(jù)分析、創(chuàng)意藝術(shù)與技術(shù)開發(fā)的融合，累計客戶上千家，服務(wù)滿意度達97%。幫助廣大客戶順利對接上互聯(lián)網(wǎng)浪潮，準確優(yōu)選出符合自己需要的互聯(lián)網(wǎng)運用，我們將一直專注品牌網(wǎng)站設(shè)計和互聯(lián)網(wǎng)程序開發(fā)，在前進的路上，與客戶一起成長！

在做內(nèi)存優(yōu)化的時候，我們發(fā)現(xiàn)除了解決內(nèi)存泄露問題，剩下的就只有想辦法減少真實的內(nèi)存占用。而在App中，大部分內(nèi)存可能被我們圖片占用了，所以減少圖片的內(nèi)存占用可以帶來直接的效果。本文就簡單介紹一張圖片到底占用多少內(nèi)存，我們先假設(shè)我們有一張圖片時** 600 * 800** 的，圖片占用空間大小假設(shè)是** 100KB**。

圖片內(nèi)存大小跟占用空間大小有什么關(guān)系？

占用空間的大小不是圖片占用內(nèi)存的大小，一些初學者可能會誤解一下。占用空間是在磁盤上占用的空間，內(nèi)存大小是加載到內(nèi)存中占用的內(nèi)存大小。兩個只是單位是一樣的，本質(zhì)不是一個概念。

一張圖片到底占用多少內(nèi)存呢？（ARGB_8888編碼）

1. 圖片占用內(nèi)存的計算公式： 圖片高度 * 圖片寬度 * 一個像素占用的內(nèi)存大小

2. 所以上面的圖片占用內(nèi)存是：**800 * 600 * 4 byte = 1875KB = 1.83M **

上面的計算公式中，為什么是4byte呢？文章后面有總結(jié)哦

圖片所在目錄對內(nèi)存的影響？

在Android中，圖片的存放目錄和手機的屏幕密度影響圖片最終的大小，舉個例子：

假設(shè)我們的圖片放到 xhdpi 目錄下，那么我們本文中的圖片占用的內(nèi)存大小如下：

屏幕密度為2的設(shè)備：800 * 600 * 4byte = 1.83M

屏幕密度為3的設(shè)備：800 * 1.5 * 600 * 1.5 * 4byte = 1.83 * 2.25M =** 4.12M**

所以，計算圖片占用內(nèi)存大小的時候，要考慮圖片所在的目錄跟設(shè)備密度，這兩個因素其實影響的是圖片的高寬，android會對圖片進行拉升跟壓縮。

總結(jié)

1. 圖片確實很占用內(nèi)存，內(nèi)存優(yōu)化先考慮圖片內(nèi)存占用；

2. 一定要避免使用大圖片，這就是.9圖很有用的原因之一；

3. 圖片的大小對內(nèi)存的影響是正比關(guān)系；

4. 本文只是簡單的告知讀者怎么計算圖片的內(nèi)存大小。

大圖： 440 * 336 ?? 小圖： 220 * 168 資源目錄： xhdpi

小圖的高寬都是大圖的1/2--小圖是原圖的1/4

界面效果：

測試設(shè)備： Coolpad ? 8676-M01 ? 5.1 ? density=2.0

測試前準備操作： 同一款設(shè)備，設(shè)置圖片前后多次調(diào)用gc直到內(nèi)存短時間內(nèi)保持穩(wěn)定不再變化

內(nèi)存使用情況： 下圖依次是 初始內(nèi)存，大圖內(nèi)存，小圖內(nèi)存

大圖占用內(nèi)存： 11.23 MB - 10.66 MB = 0.57 MB

小圖占用內(nèi)存： 10.81 MB - 10.66 MB = 0.15 MB

大圖小圖內(nèi)存關(guān)系： 0.15 MB * 4 = 0.60 MB 約等于 0.57 MB (這是統(tǒng)計工具的誤差，理論上就是相等的)

同樣的方式在另外一臺設(shè)備小米4c上得到的結(jié)果如下：

測試設(shè)備： Xiaomi ? Mi-4c ? V8.2.1.0.LXKCNDL ? 5.1.1 ? density=3.0

大圖占用內(nèi)存： 13.22 MB - 11.95 MB = 1.27 MB

小圖占用內(nèi)存： 12.27 MB - 11.95 MB = 0.32 MB

大圖小圖內(nèi)存關(guān)系： 0.32 MB * 4 = 1.28 MB 約等于 1.27 MB

結(jié)論： 由此可見大圖比小圖占用更多的內(nèi)存，圖片大小（分辨率）與占用內(nèi)存成正比關(guān)系

備注： 圖片在硬盤上占用的磁盤空間大小，與在內(nèi)存中占用的內(nèi)存大小完全不一樣，不是一個概念，不要混淆

根據(jù)上文中圖片大小與內(nèi)存的關(guān)系，可以更加深刻的理解Android中.9圖片的作用，它不但能減少apk的體積，還能減少圖片占用內(nèi)存。

有些時候我們根本不需要圖片，而是自己繪制背景，可以在自定義View的onDraw中繪制背景，當然最方便的還是使用系統(tǒng)的Drawable，繪制部分交給系統(tǒng)去完成。

下面測試圖片與Drawable的內(nèi)存占用對比

原始圖片大小： 482 * 482

界面效果：

測試設(shè)備： Xiaomi ? Mi-4c ? V8.2.1.0.LXKCNDL ? 5.1.1

測試前準備操作： 同一款設(shè)備，設(shè)置背景前后多次調(diào)用gc直到內(nèi)存短時間內(nèi)保持穩(wěn)定不再變化

內(nèi)存使用情況： 下圖依次是 初始內(nèi)存，使用圖片占用的內(nèi)存，使用Drawable占用的內(nèi)存，使用onDraw繪制占用的內(nèi)存

使用圖片占用內(nèi)存： 13.97 MB - 11.97 MB = 2.00 MB

使用Drawable占用內(nèi)存： 11.97 MB - 11.97 MB = 0.00 MB （不會是0，有誤差，只是很少）

使用onDraw繪制占用內(nèi)存： 11.98 MB - 11.97 MB = 0.01 MB

結(jié)論： 繪制背景，或者使用系統(tǒng)提供Drawable作為背景，會大大減少內(nèi)存占用

Drawable參考資料：

Drawable實戰(zhàn)解析：Android XML shape 標簽使用詳解（apk瘦身，減少內(nèi)存好幫手）

Android GradientDrawable（shape標簽定義）靜態(tài)使用和動態(tài)使用(圓角，漸變實現(xiàn))

“讓你的圖片最小化”一節(jié)中描述的方法：使用盡可能小的圖，使用.9，自己繪制背景或者使用Drawable來繪制背景

加載大圖片時需要對圖片進行壓縮，使用等比例壓縮方法直接在內(nèi)存中處理圖片

這樣做要注意的是，圖片質(zhì)量會變差，inSampleSize設(shè)置的值越大，圖片質(zhì)量就越差。

有時候我們?nèi)〉靡粡垐D片，也許只是為了獲得這個圖片的一些信息，比如圖片的width、height等信息，不需要顯示到界面上，這個時候我們可以不把圖片加載到內(nèi)存中。

由于Android外層是使用java，而底層使用的是C語言為圖片對象分配的內(nèi)存空間。所以我們的外部雖然看起來釋放了，但里層卻并不一定完全釋放了，我們使用完圖片后最好再釋放掉里層的內(nèi)存空間。

RGB(ARGB)

RGB色彩模式是工業(yè)界的一種顏色標準，是通過對紅(R)、綠(G)、藍(B)三個顏色通道的變化以及它們相互之間的疊加來得到各式各樣的顏色的，RGB即是代表紅、綠、藍三個通道的顏色，這個標準幾乎包括了人類視力所能感知的所有顏色，是目前運用最廣的顏色系統(tǒng)之一。在Android中還有包含透明度Alpha的顏色模型，即ARGB。

YUV

YUV，分為三個分量，“Y”表示明亮度（Luminance或Luma），也就是灰度值；而“U”和“V” 表示的則是色度（Chrominance或Chroma），作用是描述影像色彩及飽和度，用于指定像素的顏色。

YUV的原理是把亮度與色度分離，研究證明，人眼對亮度的敏感超過色度。利用這個原理，可以把色度信息減少一點，人眼也無法查覺這一點。

主要用于電視系統(tǒng)以及模擬視頻領(lǐng)域，它將亮度信息（Y）與色彩信息（UV）分離，沒有UV信息一樣可以顯示完整的圖像，只不過是黑白的，這樣的設(shè)計很好地解決了彩色電視機與黑白電視的兼容問題

YUV的存儲中與RGB格式最大不同在于，RGB格式每個點的數(shù)據(jù)是連繼保存在一起的。即R，G，B是前后不間隔的保存在2-4byte空間中。而YUV的數(shù)據(jù)中為了節(jié)約空間，U，V分量空間會減小。每一個點的Y分量獨立保存，但連續(xù)幾個點的U，V分量是保存在一起的，（反正人眼一般也看不出區(qū)別）.這幾個點合起來稱為macro-pixel， 這種存儲格式稱為Packed格式。另外一種存儲格式是把一幅圖像中Y，U，V分別用三個獨立的數(shù)組表示。這種模式稱為planar模式。

CMYK

??CMYK也稱作印刷色彩模式，顧名思義就是用來印刷的。印刷四分色模式是彩色印刷時采用的一種套色模式，利用色料的三原色混色原理，加上黑色油墨，共計四種顏色混合疊加，形成所謂“全彩印刷”。四種標準顏色是：

CMYK和RGB相比有一個很大的不同：RGB模式是一種發(fā)光的色彩模式，你在一間黑暗的房間內(nèi)仍然可以看見屏幕上的內(nèi)容；CMYK是一種依靠反光的色彩模式，我們是怎樣閱讀報紙的內(nèi)容呢？是由陽光或燈光照射到報紙上，再反射到我們的眼中，才看到內(nèi)容。它需要有外界光源，如果你在黑暗房間內(nèi)是無法閱讀報紙的。只要是在印刷品上看到的圖像，就是CMYK模式表現(xiàn)的。比如期刊、雜志、報紙、宣傳畫等，都是印刷出來的，那么就是CMYK模式的了。

CMYK原色與疊加之后的顏色對比

在不考慮透明度的情況下，一個像素點的顏色值在計算機中的表示方法有以下3種：

在Java中，float類型的變量占32位，int類型的變量占32位，short和char類型的變量都在16位，因此可以看出，用浮點數(shù)表示法編碼一個像素的顏色，內(nèi)存占用量是96位即12字節(jié)；而用24位整數(shù)表示法編碼，只要一個int類型變量，占用4個字節(jié)（高8位空著，低24位用于表示顏色）；用16位整數(shù)表示法編碼，只要一個short類型變量，占2個字節(jié)；因此可以看出采用整數(shù)表示法編碼顏色值，可以大大節(jié)省內(nèi)存，當然，顏色質(zhì)量也會相對低一些。在Android中獲取Bitmap的時候一般也采用整型編碼。

回想一下Android的BitmapConfig類中，有ARGB_8888、ARGB_4444、RGB565等常量，現(xiàn)在可以知道它們分別代表了什么含義。同時也可以計算一張圖片在內(nèi)存中可能占用的大小，比如采用ARGB_8888編碼載入一張1920 1200的圖片，大概就會占用1920 1200*4/1024/1024=8.79MB的內(nèi)存。

采用低內(nèi)存占用量的編碼方式，比如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省內(nèi)存；

1920 1200的圖片:*

ARGB_8888:1920 1200 4/1024/1024=8.79MB

ARGB_4444,RGB565:1920 1200 2/1024/1024=4.39MB

在Android中，對圖片的使用一定要關(guān)注，大多數(shù)情況下，占用內(nèi)存多，OOM發(fā)生都是因為圖片資源使用不當。不要盲目加一個大圖到Android項目中，能使用.9進來使用，而且.9圖本身盡可能小，另外能使用繪制實現(xiàn)就不要加一個圖片資源。有些時候，在不影響用戶體驗的情況下，可以降低圖片素材質(zhì)量，比如不需要透明度的就不要了，有些透明度用肉眼看不出來。

Android性能優(yōu)化（八）--Android圖片內(nèi)存優(yōu)化

2個基本原則

既然需要的內(nèi)存公式已得到，那優(yōu)化就顯而易見了，無非就是減小的這三個參數(shù)的值，具體的策略如下：

這里我們將圖片分為2種情況來探討：

圖片占用的內(nèi)存 大小為：

為什么mipmap不在這種情況的考慮范圍之內(nèi)呢？

因為mipmap是Android系統(tǒng)為了避免Launcher Icon變形而添加的資源目錄，也就是說，mipmap中的圖片不會被縮放。所以Google也不推薦將除Launcher Icon之外的圖片放在mipmap目錄中。

本地圖片通常都是通過Android提供的BitmapFactory來加載的, 這里看幾個常用的API：

圖片的優(yōu)化可通過Options參數(shù)來實現(xiàn)(Options的介紹可參考 從fresco 看圖片優(yōu)化 ：

inPreferredConfig的取值為Bitmap.Config類型(這里只考慮以下幾種情況)，它是一個枚舉類型，用來設(shè)置每個像素需要的字節(jié)數(shù)：

1.jpeg和gif

2.webp

3.png8, png24, png32

網(wǎng)絡(luò)圖片通常我們都是使用開源庫進行加載, 所以不需要拿到Bitmap再進行縮放或裁剪。

這時可讓后臺實現(xiàn)網(wǎng)絡(luò)圖片的裁剪，即：根據(jù)圖片的請求參數(shù)返回合適的尺寸，最大也只需要控件的大小即可。

再大也沒意義，不僅浪費流量，還占用內(nèi)存。

如果你的APP中有很多圖片，那么可對圖片的寬高根據(jù)設(shè)備的內(nèi)存情況進行適當?shù)目s小：

盡量為所有分辨率創(chuàng)建資源 資源匹配分辨率 = 減少不必要的縮放，從而提高UI繪制效率

對于一個多圖片的APP來說，圖片所占內(nèi)存的優(yōu)化是一項必不可少的工作。

總的來說，其優(yōu)化也就是通過 縮放 和指定 Bitmap.Config的值 來實現(xiàn)的，只是不同位置，不同格式的圖片有所差異而已。

;utm_source=weixinqun

Android性能優(yōu)化總結(jié)

常用的Android性能優(yōu)化方法：

一、布局優(yōu)化：

1）盡量減少布局文件的層級。

層級少了，繪制的工作量也就少了，性能自然提高。

2）布局重用 include標簽

3）按需加載：使用ViewStub,它繼承自View,一種輕量級控件，本身不參與任何的布局和繪制過程。他的layout參數(shù)里添加一個替換的布局文件，當它通過setVisibility或者inflate方法加載后，它就會被內(nèi)部布局替換掉。

二、繪制優(yōu)化：

基于onDraw會被調(diào)用多次，該方法內(nèi)要避免兩類操作：

1）創(chuàng)建新的局部對象，導致大量垃圾對象的產(chǎn)生，從而導致頻繁的gc，降低程序的執(zhí)行效率。

2）不要做耗時操作，搶CPU時間片，造成繪制很卡不流暢。

三、內(nèi)存泄漏優(yōu)化：

1）靜態(tài)變量導致內(nèi)存泄漏 ? 比較明顯

2）單例模式導致的內(nèi)存泄漏?單例無法被垃圾回收，它持有的任何對象的引用都會導致該對象不會被gc。

3）屬性動畫導致內(nèi)存泄漏 ?無限循環(huán)動畫，在activity中播放，但是onDestroy時沒有停止的話，動畫會一直播放下去，view被動畫持有，activity又被view持有，導致activity無法被回收。

四、響應(yīng)速度優(yōu)化：

1）避免在主線程做耗時操作 包括四大組件，因為四大組件都是運行在主線程的。

2）把一些創(chuàng)建大量對象等的初始化工作放在頁面回到前臺之后，而不應(yīng)該放到創(chuàng)建的時候。

五、ListView的優(yōu)化：

1）使用convertView，走listView子View回收的一套：RecycleBin 機制

主要是維護了兩個數(shù)組，一個是mActiveViews,當前可見的view,一個是mScrapViews，當前不可見的view。當觸摸ListView并向上滑動時，ListView上部的一些OnScreen的View位置上移，并移除了ListView的屏幕范圍，此時這些OnScreen的View就變得不可見了，不可見的View叫做OffScreen的View，即這些View已經(jīng)不在屏幕可見范圍內(nèi)了，也可以叫做ScrapView，Scrap表示廢棄的意思，ScrapView的意思是這些OffScreen的View不再處于可以交互的Active狀態(tài)了。ListView會把那些ScrapView（即OffScreen的View）刪除，這樣就不用繪制這些本來就不可見的View了，同時，ListView會把這些刪除的ScrapView放入到RecycleBin中存起來，就像把暫時無用的資源放到回收站一樣。

當ListView的底部需要顯示新的View的時候，會從RecycleBin中取出一個ScrapView，將其作為convertView參數(shù)傳遞給Adapter的getView方法，從而達到View復(fù)用的目的，這樣就不必在Adapter的getView方法中執(zhí)行LayoutInflater.inflate()方法了。

RecycleBin中有兩個重要的View數(shù)組，分別是mActiveViews和mScrapViews。這兩個數(shù)組中所存儲的View都是用來復(fù)用的，只不過mActiveViews中存儲的是OnScreen的View，這些View很有可能被直接復(fù)用；而mScrapViews中存儲的是OffScreen的View，這些View主要是用來間接復(fù)用的。

2）使用ViewHolder避免重復(fù)地findViewById

3)快速滑動不適合做大量異步任務(wù)，結(jié)合滑動監(jiān)聽，等滑動結(jié)束之后加載當前顯示在屏幕范圍的內(nèi)容。

4）getView中避免做耗時操作，主要針對圖片：ImageLoader來處理(原理：三級緩存)

5）對于一個列表，如果刷新數(shù)據(jù)只是某一個item的數(shù)據(jù)，可以使用局部刷新，在列表數(shù)據(jù)量比較大的情況下，節(jié)省不少性能開銷。

六、Bitmap優(yōu)化：

1）減少內(nèi)存開支：圖片過大，超過控件需要的大小的情況下，不要直接加載原圖，而是對圖片進行尺寸壓縮，方式是BitmapFactroy.Options 采樣，inSampleSize 轉(zhuǎn)成需要的尺寸的圖片。

2）減少流量開銷：對圖片進行質(zhì)量壓縮，再上傳服務(wù)器。圖片有三種存在形式：硬盤上時是file，網(wǎng)絡(luò)傳輸時是stream，內(nèi)存中是stream或bitmap，所謂的質(zhì)量壓縮，它其實只能實現(xiàn)對file的影響，你可以把一個file轉(zhuǎn)成bitmap再轉(zhuǎn)成file，或者直接將一個bitmap轉(zhuǎn)成file時，這個最終的file是被壓縮過的，但是中間的bitmap并沒有被壓縮。bitmap.compress(Bitmap.CompressFormat.PNG,100,bos);

七、線程優(yōu)化：

使用線程池。為什么要用線程池？

1、從“為每個任務(wù)分配一個線程”轉(zhuǎn)換到“在線程池中執(zhí)行任務(wù)”

2、通過重用現(xiàn)有的線程而不是創(chuàng)建新線程，可以處理多個請求在創(chuàng)建銷毀過程中產(chǎn)生的巨大開銷

3、當使用線程池時，在請求到來時間 ，不用等待系統(tǒng)重新創(chuàng)建新的線程，而是直接復(fù)用線程池中的線程，這樣可以提高響應(yīng)性。

4、通過和適當調(diào)整線程池的大小 ，可以創(chuàng)建足夠多的線程以使處理器能夠保持忙碌狀態(tài)，同時還可以防止過多線程相互競爭資源而使應(yīng)用程序耗盡內(nèi)存或者失敗。

5、一個App里面所有的任務(wù)都放在線程池中執(zhí)行后，可以統(tǒng)一管理 ，當應(yīng)用退出時，可以把程序中所有的線程統(tǒng)一關(guān)閉，避免了內(nèi)存和CPU的消耗。

6、如果這個任務(wù)是一個循環(huán)調(diào)度任務(wù)，你則必須在這個界面onDetach方法把這個任務(wù)給cancel掉，如果是一個普通任務(wù)則可cancel，可不cancel，但是最好cancel

7、整個APP的總開關(guān)會在應(yīng)用退出的時間把整個線程池全部關(guān)閉。

八、一些性能優(yōu)化建議：

1）避免創(chuàng)建過多對象，造成頻繁的gc

2)不要過多使用枚舉，枚舉占用的空間比整型大很多

3）字符串的拼接使用StringBuffer、StringBuilder來替代直接使用String,因為使用String會創(chuàng)建多個String對象，參考第一條。

4）適當使用軟引用，（弱引用就不太推薦了）

5）使用內(nèi)存緩存和磁盤緩存。

Android內(nèi)存優(yōu)化五：Bitmap優(yōu)化

Android內(nèi)存優(yōu)化一:java垃圾回收機制

Android內(nèi)存優(yōu)化二:內(nèi)存泄漏

Android內(nèi)存優(yōu)化三:內(nèi)存泄漏檢測與監(jiān)控

Android內(nèi)存優(yōu)化四：OOM

Android內(nèi)存優(yōu)化五：Bitmap優(yōu)化

壓縮比：scale = (flaot) targetDensity / density

targetDensity : 設(shè)備屏幕像素密度dpi

density: 圖片對應(yīng)的文件夾的像素密度dpi

1)、同一張圖片放在不同的資源目錄下，其分辨率會有變化。

2)、Bitmap的分辨率越高，其解析后的寬高越小，甚至小于原有的圖片（及縮放），從而內(nèi)存也響應(yīng)的減少。

3)、圖片不放置任何資源目錄時，其使用默認分辨率mdpi：160。

4)、資源目錄分辨率和屏幕分辨率一致時，圖片尺寸不會縮放。

Bitmap放在資源目錄中的計算方式為：

主要通過編碼、采樣、復(fù)用、匿名共享區(qū)進行優(yōu)化

由于ARGB_4444的畫質(zhì)慘不忍睹，一般假如對圖片沒有透明度要求的話，可以改成RGB_565，相比ARGB_8888將節(jié)省一半的內(nèi)存開銷

其中，A代表透明度；R代表紅色；G代表綠色；B代表藍色。

ALPHA_8 表示8位Alpha位圖,即A=8,一個像素點占用1個字節(jié),它沒有顏色,只有透明度。

ARGB_4444 表示16位ARGB位圖，即A=4,R=4,G=4,B=4,一個像素點占4+4+4+4=16位，2個字節(jié)。

ARGB_8888 表示32位ARGB位圖，即A=8,R=8,G=8,B=8,一個像素點占8+8+8+8=32位，4個字節(jié)。

RGB_565 表示16位RGB位圖,即R=5,G=6,B=5,它沒有透明度,一個像素點占5+6+5=16位，2個字節(jié)。

bitmap的占用內(nèi)存，是以bitmap的寬高和每個像素占用的字節(jié)數(shù)決定的。

根據(jù)BitmapFactory 的采樣率進行壓縮 設(shè)置采樣率，不能小于1 假如是2 則寬為之前的1/2，高為之前的1/2，一共縮小1/4 以此類推

圖片復(fù)用指的是inBitmap這個屬性。

不使用這個屬性，你加載三張圖片，系統(tǒng)會給你分配三份內(nèi)存空間，用于分別儲存這三張圖片

如果用了inBitmap這個屬性，加載三張圖片，這三張圖片會指向同一塊內(nèi)存，而不用開辟三塊內(nèi)存空間。

inBitmap的限制：

1、3.0-4.3

復(fù)用的圖片大小必須相同

編碼必須相同

2、4.4以上

復(fù)用的空間大于等于即可

編碼不必相同

3、不支持WebP

4、圖片復(fù)用，這個屬性必須設(shè)置為true；

options.inMutable = true;

Android 系統(tǒng)為了進程間共享數(shù)據(jù)開辟的一塊內(nèi)存區(qū)域，由于這塊區(qū)域不受應(yīng)用的Head的大小限制，相當于可以繞開oom，F(xiàn)aceBook的Fresco首次應(yīng)用到實際中。

限制：5.0以后就限制了匿名共享內(nèi)存的使用。

在SDK 11 - 18之間，重用的bitmap大小必須是一致的，例如給inBitmap賦值的圖片大小為100-100，那么新申請的bitmap必須也為100-100才能夠被重用。從SDK 19開始，新申請的bitmap大小必須小于或者等于已經(jīng)賦值過的bitmap大小。 新申請的bitmap與舊的bitmap必須有相同的解碼格式，例如大家都是8888的，如果前面的bitmap是8888，那么就不能支持4444與565格式的bitmap了。 我們可以創(chuàng)建一個包含多種典型可重用bitmap的對象池，這樣后續(xù)的bitmap創(chuàng)建都能夠找到合適的“模板”去進行重用。

8.0Bitmap的像素數(shù)據(jù)存儲在Native，為什么又改為Native存儲呢？

因為8.0共享了整個系統(tǒng)的內(nèi)存，測試8.0手機如果一直創(chuàng)建Bitmap，如果手機內(nèi)存有1G，那么你的應(yīng)用加載1G也不會oom。

可以利用LRU開管理Bitmap，給他設(shè)置內(nèi)存最大值，及時回收。

BitmapRegionDecoder

網(wǎng)站題目：android內(nèi)存優(yōu)化,android性能優(yōu)化和內(nèi)存優(yōu)化
鏈接地址：http://chinadenli.net/article5/dseihii.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、品牌網(wǎng)站制作、關(guān)鍵詞優(yōu)化、商城網(wǎng)站、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)