783
Android內存管理之道
相信一步步走過來的Android從業者，每個人都會遇到OOM的情況。如何避免和防範OOM的出現，對於每一個程序員來說確實是一門必不可少的能力。今天我們就談談在Android平台下內存的管理之道，開始今天的主題之前，先再次回顧兩個概念。
相信一步步走過來的Android從業者，每個人都會遇到OOM的情況。如何避免和防範OOM的出現，對於每一個程序員來說確實是一門必不可少的能力。今天我們就談談在Android平台下內存的管理之道，開始今天的主題之前，先再次回顧兩個概念。
內存泄漏：對象在內存heap堆中中分配的空間，當不再使用或沒有引用指向的情況下，仍不能被GC正常回收的情況。多數出現在不合理的編碼情況下，比如在Activity中注冊了一個廣播接收器，但是在頁麵關閉的時候進行unRegister，就會出現內存溢出的現象。通常情況下，大量的內存泄漏會造成OOM。
OOM：即OutOfMemoery，顧名思義就是指內存溢出了。內存溢出是指APP向係統申請超過最大閥值的內存請求，係統不會再分配多餘的空間，就會造成OOM error。在我們Android平台下，多數情況是出現在圖片不當處理加載的時候。
內存管理之道嘛，無非就是先理解並找出內存泄漏的原因，再基於這些反式去合理的編碼，去防範進而避免內存開銷過大的情形。學習如何合理的管理內存，最好先了解內存分配的機製和原理。隻有深層次的理解了內部的原理，才能真正避免OOM的發生。但是本文就不介紹Jvm/Davilk內存分配的機製了，如有興趣，請查看曆史消息，以前做過題為《JVM運行時數據區域分析》的分享。
Android APP的所能申請的最大內存大小是多少，有人說是16MB，有人又說是24MB。這種事情，還是親自用自己的手機測試下比較靠譜。測試方式也比較簡單，Java中有個Runtime類，主要用作APP與運行環境交互，APP並不會為我們創建Runtime的實例，但是Java為我們提供了單例獲取的方式Runtime.getRuntime()。通過maxMemory()方法獲取係統可為APP分配的最大內存，totalMemory()獲取APP當前所分配的內存heap空間大小。我手上有兩部手機，一部Oppo find7，運行Color
OS，實測最大內存分配為192MB；一部天語v9，運行小米係統，實測最大內存分配為100MB。這下看出點眉目了吧，由於Android是開源係統，不同的手機廠商其實是擁有修改這部分權限能力的，所以就造成了不同品牌和不同係統的手機，對於APP的內存支持也是不一樣的，和IOS的恒久100MB是不同的。一般來說，手機內存的配置越高，廠商也會調大手機支持的內存最大閥值，尤其是現在旗艦機滿天發布的情況下。但是開發者為了考慮開發出的APP的內存兼容性，無法保證APP運行在何種手機上，隻能從編碼角度來優化內存了。
下麵我們逐條來分析Android內存優化的關鍵點。
1、萬惡的static
static是個好東西，聲明賦值調用就是那麼的簡單方便，但是伴隨而來的還有性能問題。由於static聲明變量的生命周期其實是和APP的生命周期一樣的，有點類似與Application。如果大量的使用的話，就會占據內存空間不釋放，積少成多也會造成內存的不斷開銷，直至掛掉。static的合理使用一般用來修飾基本數據類型或者輕量級對象，盡量避免修複集合或者大對象，常用作修飾全局配置項、工具類方法、內部類。
2、無關引用
很多情況下，我們需求用到傳遞引用，但是我們無法確保引用傳遞出去後能否及時的回收。比如比較有代表性的Context泄漏，很多情況下當Activity 結束掉後，由於仍被其他的對象指向導致一直遲遲不能回收，這就造成了內存泄漏。這時可以考慮第三條建議。
3、善用SoftReference/WeakReference/LruCache
Java、Android中有沒有這樣一種機製呢，當內存吃緊或者GC掃過的情況下，就能及時把一些內存占用給釋放掉，從而分配給需要分配的地方。答案是肯定的，java為我們提供了兩個解決方案。如果對內存的開銷比較關注的APP，可以考慮使用WeakReference，當GC回收掃過這塊內存區域時就會回收；如果不是那麼關注的話，可以使用SoftReference，它會在內存申請不足的情況下自動釋放，同樣也能解決OOM問題。同時Android自3.0以後也推出了LruCache類，使用LRU算法就釋放內存，一樣的能解決OOM，如果兼容3.0一下的版本，請導入v4包。關於第二條的無關引用的問題，我們傳參可以考慮使用WeakReference包裝一下。
4、謹慎handler
在處理異步操作的時候，handler + thread是個不錯的選擇。但是相信在使用handler的時候，大家都會遇到警告的情形，這個就是lint為開發者的提醒。handler運行於UI線程，不斷處理來自MessageQueue的消息，如果handler還有消息需要處理但是Activity頁麵已經結束的情況下，Activity的引用其實並不會被回收，這就造成了內存泄漏。解決方案，一是在Activity的onDestroy方法中調用
handler.removeCallbacksAndMessages(null);取消所有的消息的處理，包括待處理的消息；二是聲明handler的內部類為static。
5、Bitmap終極殺手
Bitmap的不當處理極可能造成OOM，絕大多數情況都是因這個原因出現的。Bitamp位圖是Android中當之無愧的胖小子，所以在操作的時候當然是十分的小心了。由於Dalivk並不會主動的去回收，需要開發者在Bitmap不被使用的時候recycle掉。使用的過程中，及時釋放是非常重要的。同時如果需求允許，也可以去BItmap進行一定的縮放，通過BitmapFactory.Options的inSampleSize屬性進行控製。如果僅僅隻想獲得Bitmap的屬性，其實並不需要根據BItmap的像素去分配內存，隻需在解析讀取Bmp的時候使用BitmapFactory.Options的inJustDecodeBounds屬性。最後建議大家在加載網絡圖片的時候，使用軟引用或者弱引用並進行本地緩存，推薦使用android-universal-imageloader或者xUtils，牛人出品，必屬精品。前幾天在講《自定義控件（三） 繼承控件》的時候，也整理一個，大家可以去Github下載看看。
6、Cursor及時關閉
在查詢SQLite數據庫時，會返回一個Cursor，當查詢完畢後，及時關閉，這樣就可以把查詢的結果集及時給回收掉。
7、頁麵背景和圖片加載
在布局和代碼中設置背景和圖片的時候，如果是純色，盡量使用color；如果是規則圖形，盡量使用shape畫圖；如果稍微複雜點，可以使用9patch圖；如果不能使用9patch的情況下，針對幾種主流分辨率的機型進行切圖。
8、ListView和GridView的item緩存
對於移動設備，尤其硬件參差不齊的android生態，頁麵的繪製其實是很耗時的，findViewById也是蠻慢的。所以不重用View，在有列表的時候就尤為顯著了，經常會出現滑動很卡的現象。具體參照曆史文章《說說ViewHolder的另一種寫法》
9、BroadCastReceiver、Service
綁定廣播和服務，一定要記得在不需要的時候給解綁。
10、I/O流
I/O流操作完畢，讀寫結束，記得關閉。
11、線程
線程不再需要繼續執行的時候要記得及時關閉，開啟線程數量不易過多，一般和自己機器內核數一樣最好，推薦開啟線程的時候，使用線程池。
12、String/StringBuffer
當有較多的字符創需要拚接的時候，推薦使用StringBuffer。
今天沒有代碼，純文字，純手打，蠻辛苦。整理了這麼多優化的策略，相信大家在理解後使用，再也不會遇上OOM了。
本文鏈接：https://my.oschina.net/u/1171391/blog/293145
最後更新：2017-04-03 05:40:09