概論
很多時候，寫代碼往往是興之所至。如行雲流水般，想到哪，便可以寫到哪，這是多麼的讓人心曠神怡。然而大多數隨興所至的代碼往往缺乏必要的思
考，從而導致一些不必要的內存浪費；這些泄漏累積之下，往往會造成讓人頭疼的後果，付出難以想象的代價；所以，寫代碼要學會思考。
思考
Android開發中，一部手機允許我們使用的內存空間屈指可數，標準的內存最大容量預計爲16M左右，伴隨着手機的發展，可能這個內存會擴展爲20多
M,甚 至40多M，對於一個需要展示若干多媒體或者圖片的App來說，都是杯水車薪；所以，內存的使用需要我們運籌帷幄，把握在自己手裏。
1、 新建變量，我們需要思考
1）該對象是否必須創建？
2）該對象是否需要重複創建？
3）該對象是否複用已經存在的對象？
對於以上的三個問題，我們可以Handler來作爲示例，Handler有兩個方法，sendEmptyMessage和obtainMessage。當我們需要發送一個通知時，可能
我們壓根就不需要發送數據，只是作爲一個通知使用，那麼此時我們可能會習慣性的
Message msg = new Message();
msg.what = 0;
handler.sendMessage(msg);
然而，sendMessage在一個項目中，我們需要調用太多次，需要新建太多Message對象，所以我們可以從系統池中取出複用的對象
Message msg = handler.obtainMessage();
msg.what = 0;
handler.sendMessage(msg);
通過以上步驟，在整個項目中，我們只需要創建一個Message對象即可，剩下的都可以複用之前的對象。對於只作爲通知之用，而無需傳遞數據的情況
handler.sendEmptyMessage(0);
以上一句便足夠了。
2、 UI對象，及時釋放了嗎？
1）什麼對象需要及時釋放內存？
2）這些對象如何釋放內存？
在開發中，實現功能所需要的新建變量所佔的內存只是很小的一塊；打開應用時，往往看到的是花花綠綠的視圖，這些視圖加載的背景圖片，填充着資源
圖片，或者佔用着其他資源，這些圖片資源的渲染所佔用的內存相比於功能對象要多的多，然而，GC回收的資源有時候並不及時，所以需要在不顯示的時 候將佔用的資源釋放掉。釋放方式就是1）將背景或者資源置空 2）將控件置空，以ImageView爲例
ImageView v;
if(v != null) {
v.setImageDrawable(null);
v = null;
}
3、 Activity/Fragment頁面，在銷燬時，請不要保持引用！
在開發中，很多人喜歡通過保持Activity引用的方式來實現完全退出吧，一個Activity或Framgnet所佔的內存往往佔有相當的比重，如果在Activity退出的
時候依舊保持該頁面的引用，那麼該頁面所佔的內存便不能夠及時有效的回收掉，幾個頁面下去，嗯，你懂的！
4、不要在重複的邏輯中，建立對象！
在for、while以及遍歷等重複的操作中，儘量儘量不要新建對象，除非特別有必要。
特別是在數據量比較大的情況下，加入重複的對象添加其一是需要消 耗大量的內存，其二這些耗費的內存不受我們掌控，不能及時釋放掉，會造成很大的隱患。
5、佔用內存比較大的變量，在不使用的時候順便關閉或釋放掉，如cursor/db等
在開發中，使用數據庫保存一些必要的數據是經常需要的，然而這些操作的cursor或者db等本身保持有不等量的數據或本身就佔用大量的資源，在我們執
行完響應的操作後，最好順手關閉掉，這會使我們的應用做出相應的回饋。
6、良好的控制線程對象
在開發中，數據的請求，文件的傳輸等都是需要用到線程的，無論是Thread也好，AsyncTask也罷，這些對象本身因爲涉及的操作，佔據着不小的內存消
耗，所以在執行完或者得到請求的數據後及時的關閉掉，會使得你的應用負擔大大的減少。當然網絡請求還是建議使用框架來實現，推薦Google原生的 Volley。
7、請注意控制xml界面的層次
在開發中，邏輯的實現需要佔據一部分內存空間，視圖界面的渲染也要佔據一部分的內存，而且涉及到界面的更新，往往需要反覆強制渲染，這就使得UI 的內存佔用放大了多倍，所以在佈局的時候一定要控制xml界面的佈局層次，過深的層次佈局使得渲染的代價呈指數上升。所以在佈局時推薦使用
Relativelayout。
8、 控制Bitmap的像素
Bitmap佔用內存的計算公式： width x height x pixel。在Bitmap的寬度與高度不可改變的情況下，有效的改變圖片顯示的像素可以大幅度縮減圖片所佔
的內存空間。這就是看着不大的圖片，顯示之後會OOM的原因之一，內存相比於原圖會瞬間方大幾十倍。
9、 圖片的加載與釋放
在開發中，最佔內存空間的資源便是bitmap - 圖片，這是衆所周知的；圖片的內存佔用很難控制，包括圖片的壓縮與釋放的時機等。在Java意義上的優
化已經不能滿足內存的優化需要，這就是即使添加二級緩存，即使想盡辦法去避免還是會產生OOM的原因。所以第九條的優化策略，不是給你們推薦什麼 壓縮方法與釋放，因爲這並不能解決問題。真正的解決OOM，最好還是從底層C的層次來使用解決策略，今年五月份Facebook開源的Fresco框架有力的解 決了OOM的問題，該框架從C的層面來解決OOM，解決的很徹底。建議xml的本地圖片顯示也從Fresco框架來加載，保證徹底解決問題。
相信從以上幾條進行控制後，基本可以完全避免OOM的問題，可以給你一個流暢的應用程序，還你一個好心情！！！如果該文章幫助到了你，還請動手給個贊！