Android內(nèi)存優(yōu)化一:java垃圾回收機(jī)制
創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),內(nèi)蒙古企業(yè)網(wǎng)站建設(shè),內(nèi)蒙古品牌網(wǎng)站建設(shè),網(wǎng)站定制,內(nèi)蒙古網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,內(nèi)蒙古網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
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: 圖片對(duì)應(yīng)的文件夾的像素密度dpi
1)、同一張圖片放在不同的資源目錄下，其分辨率會(huì)有變化。
2)、Bitmap的分辨率越高，其解析后的寬高越小，甚至小于原有的圖片（及縮放），從而內(nèi)存也響應(yīng)的減少。
3)、圖片不放置任何資源目錄時(shí)，其使用默認(rèn)分辨率mdpi：160。
4)、資源目錄分辨率和屏幕分辨率一致時(shí)，圖片尺寸不會(huì)縮放。
Bitmap放在資源目錄中的計(jì)算方式為：
主要通過編碼、采樣、復(fù)用、匿名共享區(qū)進(jìn)行優(yōu)化
由于ARGB_4444的畫質(zhì)慘不忍睹，一般假如對(duì)圖片沒有透明度要求的話，可以改成RGB_565，相比ARGB_8888將節(jié)省一半的內(nèi)存開銷
其中，A代表透明度；R代表紅色；G代表綠色；B代表藍(lán)色。
ALPHA_8 表示8位Alpha位圖,即A=8,一個(gè)像素點(diǎn)占用1個(gè)字節(jié),它沒有顏色,只有透明度。
ARGB_4444 表示16位ARGB位圖，即A=4,R=4,G=4,B=4,一個(gè)像素點(diǎn)占4+4+4+4=16位，2個(gè)字節(jié)。
ARGB_8888 表示32位ARGB位圖，即A=8,R=8,G=8,B=8,一個(gè)像素點(diǎn)占8+8+8+8=32位，4個(gè)字節(jié)。
RGB_565 表示16位RGB位圖,即R=5,G=6,B=5,它沒有透明度,一個(gè)像素點(diǎn)占5+6+5=16位，2個(gè)字節(jié)。
bitmap的占用內(nèi)存，是以bitmap的寬高和每個(gè)像素占用的字節(jié)數(shù)決定的。
根據(jù)BitmapFactory 的采樣率進(jìn)行壓縮 設(shè)置采樣率，不能小于1 假如是2 則寬為之前的1/2，高為之前的1/2，一共縮小1/4 以此類推
圖片復(fù)用指的是inBitmap這個(gè)屬性。
不使用這個(gè)屬性，你加載三張圖片，系統(tǒng)會(huì)給你分配三份內(nèi)存空間，用于分別儲(chǔ)存這三張圖片
如果用了inBitmap這個(gè)屬性，加載三張圖片，這三張圖片會(huì)指向同一塊內(nèi)存，而不用開辟三塊內(nèi)存空間。
inBitmap的限制：
1、3.0-4.3
復(fù)用的圖片大小必須相同
編碼必須相同
2、4.4以上
復(fù)用的空間大于等于即可
編碼不必相同
3、不支持WebP
4、圖片復(fù)用，這個(gè)屬性必須設(shè)置為true；
options.inMutable = true;
Android 系統(tǒng)為了進(jìn)程間共享數(shù)據(jù)開辟的一塊內(nèi)存區(qū)域，由于這塊區(qū)域不受應(yīng)用的Head的大小限制，相當(dāng)于可以繞開oom，F(xiàn)aceBook的Fresco首次應(yīng)用到實(shí)際中。
限制：5.0以后就限制了匿名共享內(nèi)存的使用。
在SDK 11 - 18之間，重用的bitmap大小必須是一致的，例如給inBitmap賦值的圖片大小為100-100，那么新申請(qǐng)的bitmap必須也為100-100才能夠被重用。從SDK 19開始，新申請(qǐng)的bitmap大小必須小于或者等于已經(jīng)賦值過的bitmap大小。 新申請(qǐng)的bitmap與舊的bitmap必須有相同的解碼格式，例如大家都是8888的，如果前面的bitmap是8888，那么就不能支持4444與565格式的bitmap了。 我們可以創(chuàng)建一個(gè)包含多種典型可重用bitmap的對(duì)象池，這樣后續(xù)的bitmap創(chuàng)建都能夠找到合適的“模板”去進(jìn)行重用。
8.0Bitmap的像素?cái)?shù)據(jù)存儲(chǔ)在Native，為什么又改為Native存儲(chǔ)呢？
因?yàn)?.0共享了整個(gè)系統(tǒng)的內(nèi)存，測試8.0手機(jī)如果一直創(chuàng)建Bitmap，如果手機(jī)內(nèi)存有1G，那么你的應(yīng)用加載1G也不會(huì)oom。
可以利用LRU開管理Bitmap，給他設(shè)置內(nèi)存最大值，及時(shí)回收。
BitmapRegionDecoder
2個(gè)基本原則
既然需要的內(nèi)存公式已得到，那優(yōu)化就顯而易見了，無非就是減小的這三個(gè)參數(shù)的值，具體的策略如下：
這里我們將圖片分為2種情況來探討：
圖片占用的內(nèi)存 大小為：
為什么mipmap不在這種情況的考慮范圍之內(nèi)呢？
因?yàn)閙ipmap是Android系統(tǒng)為了避免Launcher Icon變形而添加的資源目錄，也就是說，mipmap中的圖片不會(huì)被縮放。所以Google也不推薦將除Launcher Icon之外的圖片放在mipmap目錄中。
本地圖片通常都是通過Android提供的BitmapFactory來加載的, 這里看幾個(gè)常用的API：
圖片的優(yōu)化可通過Options參數(shù)來實(shí)現(xiàn)(Options的介紹可參考 從fresco 看圖片優(yōu)化 ：
inPreferredConfig的取值為Bitmap.Config類型(這里只考慮以下幾種情況)，它是一個(gè)枚舉類型，用來設(shè)置每個(gè)像素需要的字節(jié)數(shù)：
1.jpeg和gif
2.webp
3.png8, png24, png32
網(wǎng)絡(luò)圖片通常我們都是使用開源庫進(jìn)行加載, 所以不需要拿到Bitmap再進(jìn)行縮放或裁剪。
這時(shí)可讓后臺(tái)實(shí)現(xiàn)網(wǎng)絡(luò)圖片的裁剪，即：根據(jù)圖片的請(qǐng)求參數(shù)返回合適的尺寸，最大也只需要控件的大小即可。
再大也沒意義，不僅浪費(fèi)流量，還占用內(nèi)存。
如果你的APP中有很多圖片，那么可對(duì)圖片的寬高根據(jù)設(shè)備的內(nèi)存情況進(jìn)行適當(dāng)?shù)目s?。?/p>
盡量為所有分辨率創(chuàng)建資源 資源匹配分辨率 = 減少不必要的縮放，從而提高UI繪制效率
對(duì)于一個(gè)多圖片的APP來說，圖片所占內(nèi)存的優(yōu)化是一項(xiàng)必不可少的工作。
總的來說，其優(yōu)化也就是通過 縮放 和指定 Bitmap.Config的值 來實(shí)現(xiàn)的，只是不同位置，不同格式的圖片有所差異而已。
;utm_source=weixinqun
內(nèi)容整理自網(wǎng)絡(luò)。
在做內(nèi)存優(yōu)化的時(shí)候，我們發(fā)現(xiàn)除了解決內(nèi)存泄露問題，剩下的就只有想辦法減少真實(shí)的內(nèi)存占用。而在App中，大部分內(nèi)存可能被我們圖片占用了，所以減少圖片的內(nèi)存占用可以帶來直接的效果。本文就簡單介紹一張圖片到底占用多少內(nèi)存，我們先假設(shè)我們有一張圖片時(shí)** 600 * 800** 的，圖片占用空間大小假設(shè)是** 100KB**。
圖片內(nèi)存大小跟占用空間大小有什么關(guān)系？
占用空間的大小不是圖片占用內(nèi)存的大小，一些初學(xué)者可能會(huì)誤解一下。占用空間是在磁盤上占用的空間，內(nèi)存大小是加載到內(nèi)存中占用的內(nèi)存大小。兩個(gè)只是單位是一樣的，本質(zhì)不是一個(gè)概念。
一張圖片到底占用多少內(nèi)存呢？（ARGB_8888編碼）
1. 圖片占用內(nèi)存的計(jì)算公式： 圖片高度 * 圖片寬度 * 一個(gè)像素占用的內(nèi)存大小
2. 所以上面的圖片占用內(nèi)存是：**800 * 600 * 4 byte = 1875KB = 1.83M **
上面的計(jì)算公式中，為什么是4byte呢？文章后面有總結(jié)哦
圖片所在目錄對(duì)內(nèi)存的影響？
在Android中，圖片的存放目錄和手機(jī)的屏幕密度影響圖片最終的大小，舉個(gè)例子：
假設(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**
所以，計(jì)算圖片占用內(nèi)存大小的時(shí)候，要考慮圖片所在的目錄跟設(shè)備密度，這兩個(gè)因素其實(shí)影響的是圖片的高寬，android會(huì)對(duì)圖片進(jìn)行拉升跟壓縮。
總結(jié)
1. 圖片確實(shí)很占用內(nèi)存，內(nèi)存優(yōu)化先考慮圖片內(nèi)存占用；
2. 一定要避免使用大圖片，這就是.9圖很有用的原因之一；
3. 圖片的大小對(duì)內(nèi)存的影響是正比關(guān)系；
4. 本文只是簡單的告知讀者怎么計(jì)算圖片的內(nèi)存大小。
大圖： 440 * 336 ?? 小圖： 220 * 168 資源目錄： xhdpi
小圖的高寬都是大圖的1/2--小圖是原圖的1/4
界面效果：
測試設(shè)備： Coolpad ? 8676-M01 ? 5.1 ? density=2.0
測試前準(zhǔn)備操作： 同一款設(shè)備，設(shè)置圖片前后多次調(diào)用gc直到內(nèi)存短時(shí)間內(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)計(jì)工具的誤差，理論上就是相等的)
同樣的方式在另外一臺(tái)設(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)存，圖片大?。ǚ直媛剩┡c占用內(nèi)存成正比關(guān)系
備注： 圖片在硬盤上占用的磁盤空間大小，與在內(nèi)存中占用的內(nèi)存大小完全不一樣，不是一個(gè)概念，不要混淆
根據(jù)上文中圖片大小與內(nèi)存的關(guān)系，可以更加深刻的理解Android中.9圖片的作用，它不但能減少apk的體積，還能減少圖片占用內(nèi)存。
有些時(shí)候我們根本不需要圖片，而是自己繪制背景，可以在自定義View的onDraw中繪制背景，當(dāng)然最方便的還是使用系統(tǒng)的Drawable，繪制部分交給系統(tǒng)去完成。
下面測試圖片與Drawable的內(nèi)存占用對(duì)比
原始圖片大小： 482 * 482
界面效果：
測試設(shè)備： Xiaomi ? Mi-4c ? V8.2.1.0.LXKCNDL ? 5.1.1
測試前準(zhǔn)備操作： 同一款設(shè)備，設(shè)置背景前后多次調(diào)用gc直到內(nèi)存短時(shí)間內(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 （不會(huì)是0，有誤差，只是很少）
使用onDraw繪制占用內(nèi)存： 11.98 MB - 11.97 MB = 0.01 MB
結(jié)論： 繪制背景，或者使用系統(tǒng)提供Drawable作為背景，會(huì)大大減少內(nèi)存占用
Drawable參考資料：
Drawable實(shí)戰(zhàn)解析：Android XML shape 標(biāo)簽使用詳解（apk瘦身，減少內(nèi)存好幫手）
Android GradientDrawable（shape標(biāo)簽定義）靜態(tài)使用和動(dòng)態(tài)使用(圓角，漸變實(shí)現(xiàn))
“讓你的圖片最小化”一節(jié)中描述的方法：使用盡可能小的圖，使用.9，自己繪制背景或者使用Drawable來繪制背景
加載大圖片時(shí)需要對(duì)圖片進(jìn)行壓縮，使用等比例壓縮方法直接在內(nèi)存中處理圖片
這樣做要注意的是，圖片質(zhì)量會(huì)變差，inSampleSize設(shè)置的值越大，圖片質(zhì)量就越差。
有時(shí)候我們?nèi)〉靡粡垐D片，也許只是為了獲得這個(gè)圖片的一些信息，比如圖片的width、height等信息，不需要顯示到界面上，這個(gè)時(shí)候我們可以不把圖片加載到內(nèi)存中。
由于Android外層是使用java，而底層使用的是C語言為圖片對(duì)象分配的內(nèi)存空間。所以我們的外部雖然看起來釋放了，但里層卻并不一定完全釋放了，我們使用完圖片后最好再釋放掉里層的內(nèi)存空間。
RGB(ARGB)
RGB色彩模式是工業(yè)界的一種顏色標(biāo)準(zhǔn)，是通過對(duì)紅(R)、綠(G)、藍(lán)(B)三個(gè)顏色通道的變化以及它們相互之間的疊加來得到各式各樣的顏色的，RGB即是代表紅、綠、藍(lán)三個(gè)通道的顏色，這個(gè)標(biāo)準(zhǔn)幾乎包括了人類視力所能感知的所有顏色，是目前運(yùn)用最廣的顏色系統(tǒng)之一。在Android中還有包含透明度Alpha的顏色模型，即ARGB。
YUV
YUV，分為三個(gè)分量，“Y”表示明亮度（Luminance或Luma），也就是灰度值；而“U”和“V” 表示的則是色度（Chrominance或Chroma），作用是描述影像色彩及飽和度，用于指定像素的顏色。
YUV的原理是把亮度與色度分離，研究證明，人眼對(duì)亮度的敏感超過色度。利用這個(gè)原理，可以把色度信息減少一點(diǎn)，人眼也無法查覺這一點(diǎn)。
主要用于電視系統(tǒng)以及模擬視頻領(lǐng)域，它將亮度信息（Y）與色彩信息（UV）分離，沒有UV信息一樣可以顯示完整的圖像，只不過是黑白的，這樣的設(shè)計(jì)很好地解決了彩色電視機(jī)與黑白電視的兼容問題
YUV的存儲(chǔ)中與RGB格式最大不同在于，RGB格式每個(gè)點(diǎn)的數(shù)據(jù)是連繼保存在一起的。即R，G，B是前后不間隔的保存在2-4byte空間中。而YUV的數(shù)據(jù)中為了節(jié)約空間，U，V分量空間會(huì)減小。每一個(gè)點(diǎn)的Y分量獨(dú)立保存，但連續(xù)幾個(gè)點(diǎn)的U，V分量是保存在一起的，（反正人眼一般也看不出區(qū)別）.這幾個(gè)點(diǎn)合起來稱為macro-pixel， 這種存儲(chǔ)格式稱為Packed格式。另外一種存儲(chǔ)格式是把一幅圖像中Y，U，V分別用三個(gè)獨(dú)立的數(shù)組表示。這種模式稱為planar模式。
CMYK
??CMYK也稱作印刷色彩模式，顧名思義就是用來印刷的。印刷四分色模式是彩色印刷時(shí)采用的一種套色模式，利用色料的三原色混色原理，加上黑色油墨，共計(jì)四種顏色混合疊加，形成所謂“全彩印刷”。四種標(biāo)準(zhǔn)顏色是：
CMYK和RGB相比有一個(gè)很大的不同：RGB模式是一種發(fā)光的色彩模式，你在一間黑暗的房間內(nèi)仍然可以看見屏幕上的內(nèi)容；CMYK是一種依靠反光的色彩模式，我們是怎樣閱讀報(bào)紙的內(nèi)容呢？是由陽光或燈光照射到報(bào)紙上，再反射到我們的眼中，才看到內(nèi)容。它需要有外界光源，如果你在黑暗房間內(nèi)是無法閱讀報(bào)紙的。只要是在印刷品上看到的圖像，就是CMYK模式表現(xiàn)的。比如期刊、雜志、報(bào)紙、宣傳畫等，都是印刷出來的，那么就是CMYK模式的了。
CMYK原色與疊加之后的顏色對(duì)比
在不考慮透明度的情況下，一個(gè)像素點(diǎn)的顏色值在計(jì)算機(jī)中的表示方法有以下3種：
在Java中，float類型的變量占32位，int類型的變量占32位，short和char類型的變量都在16位，因此可以看出，用浮點(diǎn)數(shù)表示法編碼一個(gè)像素的顏色，內(nèi)存占用量是96位即12字節(jié)；而用24位整數(shù)表示法編碼，只要一個(gè)int類型變量，占用4個(gè)字節(jié)（高8位空著，低24位用于表示顏色）；用16位整數(shù)表示法編碼，只要一個(gè)short類型變量，占2個(gè)字節(jié)；因此可以看出采用整數(shù)表示法編碼顏色值，可以大大節(jié)省內(nèi)存，當(dāng)然，顏色質(zhì)量也會(huì)相對(duì)低一些。在Android中獲取Bitmap的時(shí)候一般也采用整型編碼。
回想一下Android的BitmapConfig類中，有ARGB_8888、ARGB_4444、RGB565等常量，現(xiàn)在可以知道它們分別代表了什么含義。同時(shí)也可以計(jì)算一張圖片在內(nèi)存中可能占用的大小，比如采用ARGB_8888編碼載入一張1920 1200的圖片，大概就會(huì)占用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中，對(duì)圖片的使用一定要關(guān)注，大多數(shù)情況下，占用內(nèi)存多，OOM發(fā)生都是因?yàn)閳D片資源使用不當(dāng)。不要盲目加一個(gè)大圖到Android項(xiàng)目中，能使用.9進(jìn)來使用，而且.9圖本身盡可能小，另外能使用繪制實(shí)現(xiàn)就不要加一個(gè)圖片資源。有些時(shí)候，在不影響用戶體驗(yàn)的情況下，可以降低圖片素材質(zhì)量，比如不需要透明度的就不要了，有些透明度用肉眼看不出來。
Android內(nèi)存優(yōu)化實(shí)踐
1.內(nèi)存模型與分布
我們知道android應(yīng)用大多是使用java語言進(jìn)行開發(fā)的，這就需要我們了解java的內(nèi)存模型，此外在android中的應(yīng)用都是基于Dalvik 虛擬機(jī)或者ART虛擬機(jī)，那么對(duì)這些虛擬機(jī)的內(nèi)存分布也應(yīng)該有所了解。
上圖是常見的java虛擬機(jī)的內(nèi)存分布圖：
方法區(qū)：主要存儲(chǔ)虛擬機(jī)加載的類信息，常量，靜態(tài)變量，及時(shí)編譯器編譯后的代碼等數(shù)據(jù)。內(nèi)存優(yōu)化時(shí)這一部分主要考慮是不是加載了很多不必要的第三方庫。這部分的內(nèi)存減少主要是常量池的回收和類的卸載（類卸載條件：無引用，類加載器可卸載）
堆：幾乎所有的對(duì)象都在這個(gè)區(qū)域產(chǎn)生，該區(qū)域?qū)儆诰€程共享的區(qū)域，所以寫代碼時(shí)更要注意多線程安全。這個(gè)內(nèi)存區(qū)域的大小變化主要是對(duì)象的創(chuàng)建和回收，比如：如果短時(shí)間內(nèi)有大量的對(duì)象創(chuàng)建和回收，可能會(huì)造成內(nèi)存抖動(dòng)，如果對(duì)象創(chuàng)建之后一直回收不掉，則會(huì)導(dǎo)致內(nèi)存泄漏，嚴(yán)重的內(nèi)存泄漏會(huì)導(dǎo)致頻繁的gc，從而是界面卡頓。
虛擬機(jī)棧：這個(gè)區(qū)域描述的是java方法執(zhí)行的內(nèi)存模型，我們常說的方法棧的入棧就是將方法的棧幀存儲(chǔ)到虛擬機(jī)棧，這個(gè)區(qū)域是線程私有的，其生命周期就是線程的生命周期。也就是說每個(gè)線程都會(huì)有，默認(rèn)一個(gè)線程的線程棧大小是1M，這不包括在方法中產(chǎn)生的其他對(duì)象的大小。這一塊我們能控制的就是線程的數(shù)量，特別是程序中沒有使用線程池或者使用的多個(gè)第三方庫都帶有線程池的情況。
本地方法棧：同虛擬機(jī)棧的作用非常類似，是為虛擬機(jī)執(zhí)行native方法服務(wù)的，所以需要注意的地方也和虛擬機(jī)棧一樣，特別是使用了第三方so的情況
程序計(jì)數(shù)器：當(dāng)前線程執(zhí)行的虛擬機(jī)字節(jié)碼的行號(hào)記錄器，占用的內(nèi)存較小，可以不考慮
2.內(nèi)存限制
android是基于Linux系統(tǒng)的，android中的進(jìn)程分為兩種：
1.native進(jìn)程：采用C/C++實(shí)現(xiàn)，不包含dalvik實(shí)例的linux進(jìn)程，/system/bin/目錄下面的程序文件運(yùn)行后都是以native進(jìn)程形式存在的
2.java進(jìn)程：實(shí)例化了dalvik虛擬機(jī)實(shí)例的linux進(jìn)程，進(jìn)程的入口main函數(shù)為java函數(shù)。dalvik虛擬機(jī)實(shí)例的宿主進(jìn)程是fork()系統(tǒng)調(diào)用創(chuàng)建的linux進(jìn)程，所以每一個(gè)android上的java進(jìn)程實(shí)際上就是一個(gè)linux進(jìn)程，只是進(jìn)程中多了一個(gè)dalvik虛擬機(jī)實(shí)例
我們知道，操作系統(tǒng)對(duì)進(jìn)程的內(nèi)存是有限制的，而且操作系統(tǒng)對(duì)dalvik虛擬機(jī)自身的堆內(nèi)存大小也是有限制的?？梢酝ㄟ^如下命令查看限制大?。?/p>
adb shell getprop | grep dalvik.vm.heapgrowthlimit
可以在Androidmanifest文件中application節(jié)點(diǎn)加入android:largeHeap=“true”來增加其dalvik虛擬機(jī)中堆的大小
我們常說的堆大小其實(shí)是包涵兩部分的，一是java的堆，而是native的堆，java堆中主要是一下java對(duì)象，由 C/C++申請(qǐng)的內(nèi)存空間則在native堆中，也有一些對(duì)象需要結(jié)合native和java堆共同完成，比如bitmap，bitmap分為bitmap對(duì)象和其中存儲(chǔ)的像素值，對(duì)象分配在java堆，而存儲(chǔ)的像素值則根據(jù)版本不同存儲(chǔ)的位置也不同，api 11 - api 25是存儲(chǔ)在java堆中的，其他版本是存儲(chǔ)在native堆中的；
3.內(nèi)存泄漏
常見的內(nèi)存泄漏：
1.靜態(tài)引用（自身代碼和第三方代碼）
2.集合內(nèi)引用
3.Handler消息未清除
4.非靜態(tài)的內(nèi)部類中持有外部內(nèi)的應(yīng)用
5.匿名內(nèi)部類/非靜態(tài)內(nèi)部類和異步線程
檢查的方式：
我這里使用的是leakcanary，一般簡單的內(nèi)存泄漏可以直接在leakcanary中查到引用鏈路，不能查看的我是使用MAT來分析的當(dāng)前內(nèi)存信息；
上圖中各項(xiàng)詳細(xì)的指標(biāo)的意義可以在這里查到，這里主要占比比較大的幾個(gè)區(qū)域：
allocated：表示app內(nèi)分配的java的對(duì)象數(shù)，從當(dāng)前數(shù)值可以看出程序內(nèi)可能存在過多創(chuàng)建對(duì)象的情況，比如string對(duì)象
Native：從 C 或 C++ 代碼分配的對(duì)象內(nèi)存，頻繁進(jìn)出相關(guān)頁面發(fā)現(xiàn)native堆的大小并沒有減小，說明存在c/c++層的內(nèi)存泄漏
Code：您的應(yīng)用用于處理代碼和資源（如 dex 字節(jié)碼、已優(yōu)化或已編譯的 dex 碼、.so 庫和字體）的內(nèi)存。這個(gè)區(qū)域能優(yōu)化的就是移除不需要的so庫，懶加載使用so庫，移除無用代碼（import，方法和類）
4.優(yōu)化實(shí)踐
了解了android中的內(nèi)存分布和泄漏相關(guān)，接下來就是結(jié)合自身業(yè)務(wù)進(jìn)行內(nèi)存優(yōu)化了，如下：
1.先解決程序中內(nèi)存占用較大的業(yè)務(wù)模塊中的內(nèi)存泄漏，不熟悉MAT的使用的可以看看這個(gè)
2.移除程序中多余的代碼和引用，這里使用默認(rèn)的lint檢測再配合shrinkResources來刪除無效資源
3.優(yōu)化圖片，保證圖片放置在合理的文件夾，根據(jù)View大小加載合適的圖片大小，根據(jù)手機(jī)狀態(tài)配置bitmap和回收策略
4.優(yōu)化對(duì)象創(chuàng)建，比如string，使用對(duì)象池等
重慶分公司
重慶分公司
