您好,登錄后才能下訂單哦!
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-p_w_picpathloader或者xUtils,牛人出品,必屬精品。
6、Cursor及時關閉
在查詢SQLite數據庫時,會返回一個Cursor,當查詢完畢后,及時關閉,
這樣就可以把查詢的結果集及時給回收掉。
7、頁面背景和圖片加載
在布局和代碼中設置背景和圖片的時候,如果是純色,盡量使用color;
如果是規則圖形,盡量使用shape畫圖;如果稍微復雜點,
可以使用9patch圖;如果不能使用9patch的情況下,
針對幾種主流分辨率的機型進行切圖。
8、ListView和GridView的item緩存
對于移動設備,尤其硬件參差不齊的android生態,頁面的繪制其實是很耗時的,
findViewById也是蠻慢的。所以不重用View,在有列表的時候就尤為顯著了,
經常會出現滑動很卡的現象。
9、BroadCastReceiver、Service
綁定廣播和服務,一定要記得在不需要的時候給解綁。
10、I/O流
I/O流操作完畢,讀寫結束,記得關閉。
11、線程
線程不再需要繼續執行的時候要記得及時關閉,開啟線程數量不易過多,一般和自己機器內核數
一樣最好,推薦開啟線程的時候,使用線程池。
12、String/StringBuffer
當有較多的字符創需要拼接的時候,推薦使用StringBuffer。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。