Android中怎么實(shí)現(xiàn)內(nèi)存管理

Android中怎么實(shí)現(xiàn)內(nèi)存管理，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比南海網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式南海網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋南海地區(qū)。費(fèi)用合理售后完善，十多年實(shí)體公司更值得信賴。

內(nèi)存泄漏：對象在內(nèi)存heap堆中中分配的空間，當(dāng)不再使用或沒有引用指向的情況下，仍不能被GC正?；厥盏那闆r。多數(shù)出現(xiàn)在不合理的編碼情況下，比如在Activity中注冊了一個廣播接收器，但是在頁面關(guān)閉的時候進(jìn)行unRegister，就會出現(xiàn)內(nèi)存溢出的現(xiàn)象。通常情況下，大量的內(nèi)存泄漏會造成OOM。

OOM：即OutOfMemoery，顧名思義就是指內(nèi)存溢出了。內(nèi)存溢出是指APP向系統(tǒng)申請超過***閥值的內(nèi)存請求，系統(tǒng)不會再分配多余的空間，就會造成OOM error。在我們Android平臺下，多數(shù)情況是出現(xiàn)在圖片不當(dāng)處理加載的時候。

內(nèi)存管理之道嘛，無非就是先理解并找出內(nèi)存泄漏的原因，再基于這些反式去合理的編碼，去防范進(jìn)而避免內(nèi)存開銷過大的情形。學(xué)習(xí)如何合理的管理內(nèi)存，***先了解內(nèi)存分配的機(jī)制和原理。只有深層次的理解了內(nèi)部的原理，才能真正避免OOM的發(fā)生。但是本文就不介紹Jvm/Davilk內(nèi)存分配的機(jī)制了，如有興趣，請查看歷史消息，以前做過題為《JVM運(yùn)行時數(shù)據(jù)區(qū)域分析》的分享。

Android APP的所能申請的***內(nèi)存大小是多少，有人說是16MB，有人又說是24MB。這種事情，還是親自用自己的手機(jī)測試下比較靠譜。測試方式也比較簡單，Java中有個Runtime類，主要用作APP與運(yùn)行環(huán)境交互，APP并不會為我們創(chuàng)建Runtime的實(shí)例，但是Java為我們提供了單例獲取的方式Runtime.getRuntime()。通過maxMemory()方法獲取系統(tǒng)可為APP分配的***內(nèi)存，totalMemory()獲取APP當(dāng)前所分配的內(nèi)存heap空間大小。我手上有兩部手機(jī)，一部Oppo find7，運(yùn)行Color OS，實(shí)測***內(nèi)存分配為192MB；一部天語v9，運(yùn)行小米系統(tǒng)，實(shí)測***內(nèi)存分配為100MB。這下看出點(diǎn)眉目了吧，由于Android是開源系統(tǒng)，不同的手機(jī)廠商其實(shí)是擁有修改這部分權(quán)限能力的，所以就造成了不同品牌和不同系統(tǒng)的手機(jī)，對于APP的內(nèi)存支持也是不一樣的，和IOS的恒久100MB是不同的。一般來說，手機(jī)內(nèi)存的配置越高，廠商也會調(diào)大手機(jī)支持的內(nèi)存***閥值，尤其是現(xiàn)在旗艦機(jī)滿天發(fā)布的情況下。但是開發(fā)者為了考慮開發(fā)出的APP的內(nèi)存兼容性，無法保證APP運(yùn)行在何種手機(jī)上，只能從編碼角度來優(yōu)化內(nèi)存了。

下面我們逐條來分析Android內(nèi)存優(yōu)化的關(guān)鍵點(diǎn)。

1、萬惡的static

static是個好東西，聲明賦值調(diào)用就是那么的簡單方便，但是伴隨而來的還有性能問題。由于static聲明變量的生命周期其實(shí)是和APP的生命周期一樣的，有點(diǎn)類似與Application。如果大量的使用的話，就會占據(jù)內(nèi)存空間不釋放，積少成多也會造成內(nèi)存的不斷開銷，直至掛掉。static的合理使用一般用來修飾基本數(shù)據(jù)類型或者輕量級對象，盡量避免修復(fù)集合或者大對象，常用作修飾全局配置項、工具類方法、內(nèi)部類。

2、無關(guān)引用

很多情況下，我們需求用到傳遞引用，但是我們無法確保引用傳遞出去后能否及時的回收。比如比較有代表性的Context泄漏，很多情況下當(dāng)Activity 結(jié)束掉后，由于仍被其他的對象指向?qū)е乱恢边t遲不能回收，這就造成了內(nèi)存泄漏。這時可以考慮第三條建議。

3、善用SoftReference/WeakReference/LruCache

Java、Android中有沒有這樣一種機(jī)制呢，當(dāng)內(nèi)存吃緊或者GC掃過的情況下，就能及時把一些內(nèi)存占用給釋放掉，從而分配給需要分配的地方。答案是肯定的，java為我們提供了兩個解決方案。如果對內(nèi)存的開銷比較關(guān)注的APP，可以考慮使用WeakReference，當(dāng)GC回收掃過這塊內(nèi)存區(qū)域時就會回收；如果不是那么關(guān)注的話，可以使用SoftReference，它會在內(nèi)存申請不足的情況下自動釋放，同樣也能解決OOM問題。同時Android自3.0以后也推出了LruCache類，使用LRU算法就釋放內(nèi)存，一樣的能解決OOM，如果兼容3.0一下的版本，請導(dǎo)入v4包。關(guān)于第二條的無關(guān)引用的問題，我們傳參可以考慮使用WeakReference包裝一下。

4、謹(jǐn)慎handler

在處理異步操作的時候，handler + thread是個不錯的選擇。但是相信在使用handler的時候，大家都會遇到警告的情形，這個就是lint為開發(fā)者的提醒。handler運(yùn)行于UI線程，不斷處理來自MessageQueue的消息，如果handler還有消息需要處理但是Activity頁面已經(jīng)結(jié)束的情況下，Activity的引用其實(shí)并不會被回收，這就造成了內(nèi)存泄漏。解決方案，一是在Activity的onDestroy方法中調(diào)用

handler.removeCallbacksAndMessages(null);取消所有的消息的處理，包括待處理的消息；二是聲明handler的內(nèi)部類為static。

5、Bitmap***殺手

Bitmap的不當(dāng)處理極可能造成OOM，絕大多數(shù)情況都是因這個原因出現(xiàn)的。Bitamp位圖是Android中當(dāng)之無愧的胖小子，所以在操作的時候當(dāng)然是十分的小心了。由于Dalivk并不會主動的去回收，需要開發(fā)者在Bitmap不被使用的時候recycle掉。使用的過程中，及時釋放是非常重要的。同時如果需求允許，也可以去BItmap進(jìn)行一定的縮放，通過BitmapFactory.Options的inSampleSize屬性進(jìn)行控制。如果僅僅只想獲得Bitmap的屬性，其實(shí)并不需要根據(jù)BItmap的像素去分配內(nèi)存，只需在解析讀取Bmp的時候使用BitmapFactory.Options的inJustDecodeBounds屬性。***建議大家在加載網(wǎng)絡(luò)圖片的時候，使用軟引用或者弱引用并進(jìn)行本地緩存，推薦使用android-universal-imageloader或者xUtils，牛人出品，必屬精品。前幾天在講《自定義控件（三）  繼承控件》的時候，也整理一個，大家可以去Github下載看看。

6、Cursor及時關(guān)閉

在查詢SQLite數(shù)據(jù)庫時，會返回一個Cursor，當(dāng)查詢完畢后，及時關(guān)閉，這樣就可以把查詢的結(jié)果集及時給回收掉。

7、頁面背景和圖片加載

在布局和代碼中設(shè)置背景和圖片的時候，如果是純色，盡量使用color；如果是規(guī)則圖形，盡量使用shape畫圖；如果稍微復(fù)雜點(diǎn)，可以使用9patch圖；如果不能使用9patch的情況下，針對幾種主流分辨率的機(jī)型進(jìn)行切圖。

8、ListView和GridView的item緩存

對于移動設(shè)備，尤其硬件參差不齊的android生態(tài)，頁面的繪制其實(shí)是很耗時的，findViewById也是蠻慢的。所以不重用View，在有列表的時候就尤為顯著了，經(jīng)常會出現(xiàn)滑動很卡的現(xiàn)象。具體參照歷史文章《說說ViewHolder的另一種寫法》

9、BroadCastReceiver、Service

綁定廣播和服務(wù)，一定要記得在不需要的時候給解綁。

10、I/O流

I/O流操作完畢，讀寫結(jié)束，記得關(guān)閉。

11、線程

線程不再需要繼續(xù)執(zhí)行的時候要記得及時關(guān)閉，開啟線程數(shù)量不易過多，一般和自己機(jī)器內(nèi)核數(shù)一樣***，推薦開啟線程的時候，使用線程池。

12、String/StringBuffer

當(dāng)有較多的字符創(chuàng)需要拼接的時候，推薦使用StringBuffer。

關(guān)于Android中怎么實(shí)現(xiàn)內(nèi)存管理問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。

分享標(biāo)題：Android中怎么實(shí)現(xiàn)內(nèi)存管理
文章起源：http://bm7419.com/article46/jdschg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標(biāo)簽優(yōu)化、網(wǎng)站內(nèi)鏈、搜索引擎優(yōu)化、企業(yè)建站、企業(yè)網(wǎng)站制作、小程序開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)