在android中，乙個process 只能使用16m記憶體，要是超過了這個限定就會跳出這個異常。
那麼，開發中，有哪些措施能避免這個問題呢？不僅僅是bitmap的處理，其他方面也會導致oom。有哪些好的記憶體優化方式呢？
以下有幾個網友給出的7 個答案可以參考：
對於oom，其實最重要的是注意不要memory leak。而memory leak是會有多個方面會引起的，比如drawable, remoteviews, receiver, cursor,inputstream, mediaplayer等，此外，如果使用jni也會因為c或c++的**導致memory leak。
除了memory leak，大資料量的操作也會導致oom，比如之前其他回答提到的bitmap，還有listadapter，如果在getview時處理不當，也很容易導致oom，所以在listadapter時應該盡量使用convertview。
最後，可以用android.os.strictmode以及eclipse的mat工具來進行oom和memory leak的檢測。
我的做法是時間換空間，盡量檔案化一些占用記憶體的資料。最典型的就是listview中的bitmap，可以參考這個開源元件的實現。code.google.com/p/androi… 其將bitmap都本地檔案快取，記憶體中只保留最近使用的4張，在使用中發現還是會偶爾出現oom，然後我就將其改為完全的讀取檔案，記憶體中不保留，使用以後都自動**，由此擴充套件的資料檔案也同樣快取成檔案。
經常會oom我覺得就是在bitmap處理的時候，比如decodefile，在往介面上載入時，不用直接載入原圖，可以進行縮放。一張1000*1000的要載入到乙個100*100的imageview上，直接載入進來大多數都會oom,可以先用injustdecodebounds
bitmapfactory.options options = new bitmapfactory.options();
options.injustdecodebounds = true;
拿到這個的大小，再算好縮放比例
int scale = 0;
scale = (int)(options.outheight / (float)size);
if (scale <= 0)
options.insamplesize = scale;
options.injustdecodebounds = false;
再進行decode。
總之就是盡量時間換空間，實際這個時間是非常非常短的，使用者體驗內的。
對於要注意recycle吧，解析度大的也要使用bitmapfactory.decode來降低解析度，減少記憶體占用，資源也要注意不要使用太大的
銷毀一定要recycle，盡量使用softreference,網上可以找到資料。
使用泛型演算法或者泛型容器多多少少都會引起memory leak，在現代物件導向程式設計中似乎memory leak已經無法避免了，總之能自己寫的演算法就不要用泛型。
最後都會說
1.recycle所有物件，排除程式對該物件的引用，然後system.gc()，但有時候不能根本的解決問題，因為android內部的對記憶體的限制機制導致的
2.bitmap是在我開發過程中，oom最多的地方，最後結論是，只能大幅度的縮小比例
可以用mat來檢查記憶體洩露，或者用monkey test也能夠幫助發現應用的記憶體洩露。
但記憶體使用的優化就看工程師的功力了。
Oracle SQL 優化（一點一點來）
為了提高 sql的執行效率，在任何可能的時候使用等值連線 在索引列上使用表示式 包括函式 將會導致優化器忽略該列上的索引，除非該列上定義的為基於函式的索引，所以應該將函式寫在相對的位置上 e.empno 為數值索引列 select from emp e where e.empno 1001 使用索引...
Oracle SQL 優化（一點一點來）
為了提高sql 的執行效率，在任何可能的時候使用等值連線 在索引列上使用表示式 包括函式 將會導致優化器忽略該列上的索引，除非該列上定義的為基於函式的索引，所以應該將函式寫在相對的位置上 e.empno 為數值索引列 select from emp e where e.empno 1001 使用索引...
pushmail的一點總結
從push方法上說有ip push和sms push。ip push就是讓手機始終握著gprs，從而有個ip，讓mail server和手機之間始終有個通路，這樣server一旦有郵件就馬上通過ip push到手機終端上了。sms push就是mail server有郵件了，通知運營商push個簡訊...