可能是jvm運(yùn)行時(shí)內(nèi)存不足吧，你試下
創(chuàng)新互聯(lián)長期為超過千家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為競秀企業(yè)提供專業(yè)的網(wǎng)站制作、成都做網(wǎng)站，競秀網(wǎng)站改版等技術(shù)服務(wù)。擁有十余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。
java -Xms512m -Xmx512m -XX:MaxPermSize=128m -cp lib/bootstart.jar; TestJava
Xmx 用來設(shè)置你的應(yīng)用程序能夠使用的最大內(nèi)存數(shù)（看好，致使你的應(yīng)用程序，不是整個(gè)jvm）,如果你的程序要花很大內(nèi)存的話，那就需要修改缺省的設(shè)置，比如配置tomcat的時(shí)候，如果流量啊程序啊都很大的話就需要加大這個(gè)值了，不過有一點(diǎn)是要記住的，不要大得超過你的機(jī)器的內(nèi)存，那樣你的機(jī)器會受不了的，到時(shí)候就死翹翹了。
Xms 用它來設(shè)置程序初始化的時(shí)候內(nèi)存棧的大小，增加這個(gè)值的話你的程序的啟動性能會得到提高。不過同樣有前面的限制，以及受到xmx的限制。
在Android平臺上面，應(yīng)用程序OOM異常永遠(yuǎn)都是值得關(guān)注的問題。通常這一塊也是程序這中的重點(diǎn)之一。這下我就如何解決OOM作一點(diǎn)簡單的介紹。
首先，OOM就是內(nèi)存溢出，即Out Of Memory。也就是說內(nèi)存占有量超過了VM所分配的最大。
怎么解決OOM，通常OOM都發(fā)生在需要用到大量內(nèi)存的情況下（創(chuàng)建或解析Bitmap，分配特大的數(shù)組等），在這樣的一種情況下，就可能出現(xiàn)OOM，據(jù)我現(xiàn)在了解到，多數(shù)OOM都是因?yàn)锽itmap太大。所以，這里我就專門針對如何解決Bitmap的OOM。其實(shí)最核發(fā)的就是只加載可見范圍內(nèi)的Bitmap，試想這樣一種情況，在GridView或ListView中，數(shù)據(jù)量有5000，每一屏只顯示20個(gè)元素，那么不可見的，我們是不需要保存Bitmap在內(nèi)在中的。所以我們就是只把那么可見的Bitmap保留在內(nèi)存中，那些不可見的，就釋放掉。當(dāng)元素滑出來時(shí)，再去加載Bitmap。
這里我有兩種方式，都可以避免OOM。
一，主動釋放Bitmap的內(nèi)存
這種方式我簡單說一下，不太推薦，這也是我最開始使用的一種方法，但最后證明它不是最好的。（不推薦）
它的本質(zhì)思路是：
1、只加載可見區(qū)域的Bitmap
2、滑動時(shí)不加載
3、停止滑動（Idle）后，開始重新加載可見區(qū)域的圖片
4、釋放滑出可見區(qū)域的Bitmap的內(nèi)在。
它比較復(fù)雜：
1、我們需要監(jiān)聽GridView/ListView的滑動事件，這個(gè)很簡單做到，AbsListView#setOnScrollListener(OnScrollListener l)
2、主動調(diào)用Bitmap#recycle()方法，它會導(dǎo)致一個(gè)問題，必須判斷這個(gè)Bitmap是否被一個(gè)View(ImageView等）所引用，如果被引用，我們不能簡單地調(diào)用recycle()方法，這樣會導(dǎo)致異常，說是View使用了一個(gè)已經(jīng)被回收的Bitmap。
3，我們必須設(shè)計(jì)自己的線程來控制開始/暫停等，因?yàn)镚ridView/ListView的滑動狀態(tài)可能不斷地變化，也就是說滑動-停止-滑動，這種狀態(tài)可能不斷變化，這樣就會導(dǎo)致我們的線程中的run()方法里面的邏輯比較復(fù)雜，一旦復(fù)雜，問題就可能就得更多。
基于以上幾點(diǎn)，這種方式不是最好的，所以不推薦。
二，設(shè)計(jì)Cache
這種方式，我覺得是比較好的一種，它首先利用了cache，我認(rèn)為cache是一個(gè)很重要的東西，把Bitmap的內(nèi)存單獨(dú)放在一個(gè)地方來管理，這個(gè)地方就是cache，它的容量是一定的，我們可能會不斷的向這個(gè)cache中添加元素，也可能不斷的移除元素。
為了更好的說明這種方式，先要介紹一下LruCache。
LruCache
1、這其實(shí)就是一個(gè)LinkedHashMap，任意時(shí)刻，當(dāng)一個(gè)值被訪問時(shí)，它就會被移動到隊(duì)列的開始位置，所以這也是為什么要用LinkedHashMap的原因，因?yàn)橐l繁的做移動操作，為了提高性能，所以要用LinkedHashMap。當(dāng)cache滿了時(shí)，此時(shí)再向cache里面添加一個(gè)值，那么，在隊(duì)列最后的值就會從隊(duì)列里面移除，這個(gè)值就有可能被GC回收掉。
1.用MAT分析OOM
很多OOM看似發(fā)生在bitmap 分配得時(shí)候，但它一般不是rootcause。根本原因都在于本應(yīng)該自動釋放的資源，因?yàn)榇a的錯誤，而導(dǎo)致某些對象一直被引用（Reference）。
2.java靜態(tài)代碼分析工具
寫代碼過程中難免會有疏漏，我們也可以借助工具分析，這里是常用的java靜態(tài)代碼分析工具：
個(gè)人覺得Find Bugs 和 PMD就可以了，只是輔助，不必過分依賴，他并不是萬能的，不是所有錯誤都能找出來。
1. 正確釋放drawable的方式：
Bitmap bm = BitmapFactory.decodeResource(this.getResources(), R.drawable.splash);
BitmapDrawable bd = new BitmapDrawable(this.getResources(), bm);
mBtn.setBackgroundDrawable(bd);
來代替mBtn.setBackgroundResource(R.drawable.splash)。
銷毀的時(shí)候使用：
BitmapDrawable bd ＝ (BitmapDrawable)mBtn.getBackground();
mBtn.setBackgroundResource(0);//別忘了把背景設(shè)為null，避免onDraw刷新背景時(shí)候出現(xiàn)used a recycled bitmap錯誤
bd.setCallback(null);
bd.getBitmap().recycle();
2. 使用字節(jié)流，突破Android heap size的限制
從中不難發(fā)現(xiàn)，bitmap的存放位置根據(jù)Android版本的不同真的有所不同。好了，下面就是找出怎么把圖片存放到native heap里就行了，BitmapFactory里就那么幾個(gè)decode方法，很容易找到BitmapFactory .decodeStream就可以解決。下面貼一下代碼：
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Config.ARGB_8888;
options.inPurgeable = true;// 允許可清除
options.inInputShareable = true;// 以上options的兩個(gè)屬性必須聯(lián)合使用才會有效果
String sname = String.format( “xxx.png”, sTowerStyle, j, sDirction, i);
InputStream is = am.open(sname);
arrBmp[ iBmpIndex] = BitmapFactory .decodeStream(is, null, options);
ok搞定收工。
盡量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource來設(shè)置一張大圖，
因?yàn)檫@些函數(shù)在完成decode后，最終都是通過java層的createBitmap來完成的，需要消耗更多內(nèi)存。
因此，改用先通過BitmapFactory.decodeStream方法，創(chuàng)建出一個(gè)bitmap，再將其設(shè)為ImageView的 source，
decodeStream最大的秘密在于其直接調(diào)用JNInativeDecodeAsset()來完成decode，
無需再使用java層的createBitmap，從而節(jié)省了java層的空間。
如果在讀取時(shí)加上圖片的Config參數(shù)，可以跟有效減少加載的內(nèi)存，從而跟有效阻止拋out of Memory異常
另外，decodeStream直接拿的圖片來讀取字節(jié)碼了， 不會根據(jù)機(jī)器的各種分辨率來自動適應(yīng)，
使用了decodeStream之后，需要在hdpi和mdpi，ldpi中配置相應(yīng)的圖片資源，
否則在不同分辨率機(jī)器上都是同樣大?。ㄏ袼攸c(diǎn)數(shù)量），顯示出來的大小就不對了。
在 Java中，JavaVM擁有自動管理內(nèi)存的功能，Java的GC能夠進(jìn)行垃圾回收,但是Android中如果ImageView使用過多的Bitmap的話,經(jīng)常會報(bào)OOM(內(nèi)存溢出)。
造成內(nèi)存溢出及解決方案:
1.使用BitmapFactory.decodeStream替代createBitmap方法
原因是該方法直讀取圖片字節(jié)，調(diào)用JNInativeDecodeAsset()來完成decode，無需再使用java層的createBitmap。
2.使用壓縮讀取技術(shù)
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(imageSdUri, options);
final int height = options.outHeight;
final int width = options.outWidth;
options.inSampleSize = 1;
int w = 320;
int h = 480;
h = w*height/width;//計(jì)算出寬高等比率
int a = options.outWidth/ w;
int b = options.outHeight / h;
options.inSampleSize = Math.max(a, b);
options.inJustDecodeBounds = false;
Bitmap bitmap = BitmapFactory.decodeFile(imageSdUri, options);
3.及時(shí)釋放Bitamp
Bitmap對象在不使用時(shí),我們應(yīng)該先調(diào)用recycle()釋放內(nèi)存，然后才它設(shè)置為null.雖然recycle()從源碼上看，調(diào)用它應(yīng)該能立即釋放Bitmap的主要內(nèi)存，但是測試結(jié)果顯示它并沒能立即釋放內(nèi)存。但是我它應(yīng)該還是能大大的加速Bitmap的主要內(nèi)存的釋放。
重慶分公司
重慶分公司
