1. Memory Leak

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

內(nèi)存泄漏：對于Java來說，就是new出來的Object 放在Heap上無法被GC回收(內(nèi)存中存在無法被回收的對象)；內(nèi)存泄漏發(fā)生時的主要表現(xiàn)為內(nèi)存抖動，可用內(nèi)存慢慢變少。

1.1 Memory Monitor

AndroidStudio自帶的Memory Monitor可以方便的觀察堆內(nèi)存的分配情況，并且可以粗略的觀察有沒有Memory Leak。

頻繁的內(nèi)存抖動，可能存在內(nèi)存泄漏

A：initiate GC 手動觸發(fā)GC操作;

B：Dump Java Heap 獲取當前的堆棧信息，生成一個.hprof文件，AndroidStudip會自動使用HeapViewer打開;一般用于操作之后檢測內(nèi)存泄漏的情況;

C：Start Allocation Tracking 內(nèi)存分配追蹤工具，用于追蹤一段時間的內(nèi)存分配使用情況，能夠知道執(zhí)行一些列操作后，有哪些對象被分配空間。一般用于追蹤某項操作之后的內(nèi)存分配，調(diào)整相關(guān)的方法調(diào)用來優(yōu)化app性能與內(nèi)存使用;

D：剩余可用內(nèi)存;

E：已經(jīng)使用的內(nèi)存。

點擊Memory Monitor的Dump Java Heap，會生成一個.hprof文件，AndroidStudio會自動使用HeapViewer打開。

Hprof Viewer打開.hprof文件

左面板說明：

• Total Count 該類的實例個數(shù)
• Heap Count 選定的Heap中實例的個數(shù)
• Sizeof 每個實例占用的內(nèi)存大小
• Shallow Size 所有該類的實例占用的內(nèi)存大小
• Retained Size 該類的所有實例可支配的內(nèi)存大小

右面板說明：

• Instance 該類的所有實例對象(左側(cè)Total Count為15，此處就有15個對象)
• Depth 深度, GC Root點到該實例的最短鏈路數(shù)
• Dominating Size 該實例可支配的內(nèi)存大小

此處可以看出MainActivity存在了15個示例對象，懷疑此處有問題。

1.2 MAT

上述只是可以粗略的看出是不是有問題，而要知道問題出在哪里就需要借助MAT了。將生成的.hprof文件進行轉(zhuǎn)換，然后使用MAT打開;

格式轉(zhuǎn)換命令：hprof-conv 原文件路徑 轉(zhuǎn)換后文件路徑

MAT打開.hprof

注意下面的Actions：

• Histogram可以列出內(nèi)存中每個對象的名字、數(shù)量以及大小。
• Dominator Tree會將所有內(nèi)存中的對象按大小進行排序，并且我們可以分析對象之間的引用結(jié)構(gòu)。

一般使用最多的也是這兩個功能。

Retained Heap表示這個對象以及它所持有的其它引用(包括直接和間接)所占的總內(nèi)存

• 使用Histogram：
• 點擊Histogram并在頂部的Regex中輸入MainActivity會進行正則匹配，會將包含“MainActivity”的所有對象全部列出了出來，其中***行就是MainActivity的實例。 

• 對著想查看的對象點擊右鍵 -> List objects -> with incoming references 查看具體MainActivity實例。 

• 對想要查看的對象實例點擊右鍵-> Path To Gc Roots -> exclude weak reference(排除掉軟引用)。 

注意：

this$0前面的圖標的左下角有個圓圈，這代表這個引用可以被Gc Roots引用到，由于MainActivity$LeakClass能被GC Roots訪問到導(dǎo)致其不能被回收，從而它所持有的其它引用也無法被回收了，包括MainActivity，也包括MainActivity中所包含的其它資源。

此時我們就找到了內(nèi)存泄漏的原因。

• 使用Dominator Tree 

使用上面Histogram的操作方式也可以找到泄漏的具體原因，此處不再累述。

注意：每個對象前的圖標的圓圈，并不代表一定是導(dǎo)致內(nèi)存泄漏的原因，有些對象就是需要在內(nèi)存中存活的，需要區(qū)別對待。

1.3 LeakCanary

LeakCanary是square出品的一個檢測內(nèi)存泄漏的庫，集成到App之后便無需關(guān)心，在發(fā)生內(nèi)存泄漏之后會Toast、通知欄彈出等方式提示，可以指出泄漏的引用路徑，而且可以抓取當前的堆棧信息供詳細分析。

2. Out Of Memory

2.1 Android OOM

Android系統(tǒng)的每個進程都有一個***內(nèi)存限制，如果申請的內(nèi)存資源超過這個限制，系統(tǒng)就會拋出OOM錯誤。

• Android 2.x系統(tǒng)，當dalvik allocated + external allocated + 新分配的大小 >= dalvik heap ***值時候就會發(fā)生OOM。其中bitmap是放于external中 。
• Android 4.x系統(tǒng)，廢除了external的計數(shù)器，類似bitmap的分配改到dalvik的java heap中申請，只要allocated + 新分配的內(nèi)存 >= dalvik heap ***值的時候就會發(fā)生OOM(art運行環(huán)境的統(tǒng)計規(guī)則還是和dalvik保持一致)

內(nèi)存溢出是程序運行到某一階段的最終結(jié)果，直接原因是剩余的內(nèi)存不能滿足內(nèi)存的申請，但是再分析間接原因內(nèi)存為什么沒有了：

• 內(nèi)存泄漏的存在可能導(dǎo)致可用內(nèi)存越來越少;
• 內(nèi)存申請的峰值超過了系統(tǒng)時間點剩余的內(nèi)存;(例如：某手機單個進程可用***內(nèi)存為192M，目前分配內(nèi)存80M，此時申請5M內(nèi)存，但是當前時間點整個系統(tǒng)可用內(nèi)存只有3M，此時沒有超出單個進程可用***內(nèi)存，但是OOM也會發(fā)生)

2.2 Avoid Android OOM

除了避免內(nèi)存泄漏之外，根據(jù)《Manage Your App's Memory》，我們可以對內(nèi)存的狀態(tài)進行監(jiān)聽，在Activity中覆寫此方法，根據(jù)不同的case進行不同的處理：

 
 
 
 
  
  
  
  
@Override 
  
  
  
  
    public void onTrimMemory(int level) {        super.onTrimMemory(level); 
  
  
  
  
    }  
 
 
 

TRIM_MEMORY_RUNNING_MODERATE：你的應(yīng)用正在運行并且不會被列為可殺死的。但是設(shè)備此時正運行于低內(nèi)存狀態(tài)下，系統(tǒng)開始觸發(fā)殺死LRU Cache中的Process的機制。

TRIM_MEMORY_RUNNING_LOW：你的應(yīng)用正在運行且沒有被列為可殺死的。但是設(shè)備正運行于更低內(nèi)存的狀態(tài)下，你應(yīng)該釋放不用的資源用來提升系統(tǒng)性能。

TRIM_MEMORY_RUNNING_CRITICAL：你的應(yīng)用仍在運行，但是系統(tǒng)已經(jīng)把LRU Cache中的大多數(shù)進程都已經(jīng)殺死，因此你應(yīng)該立即釋放所有非必須的資源。如果系統(tǒng)不能回收到足夠的RAM數(shù)量，系統(tǒng)將會清除所有的LRU緩存中的進程，并且開始殺死那些之前被認為不應(yīng)該殺死的進程，例如那個包含了一個運行態(tài)Service的進程。

當應(yīng)用進程退到后臺正在被Cached的時候，可能會接收到從onTrimMemory()中返回的下面的值之一：

TRIM_MEMORY_BACKGROUND: 系統(tǒng)正運行于低內(nèi)存狀態(tài)并且你的進程正處于LRU緩存名單中最不容易殺掉的位置。盡管你的應(yīng)用進程并不是處于被殺掉的高危險狀態(tài)，系統(tǒng)可能已經(jīng)開始殺掉LRU緩存中的其他進程了。你應(yīng)該釋放那些容易恢復(fù)的資源，以便于你的進程可以保留下來，這樣當用戶回退到你的應(yīng)用的時候才能夠迅速恢復(fù)。

TRIM_MEMORY_MODERATE: 系統(tǒng)正運行于低內(nèi)存狀態(tài)并且你的進程已經(jīng)已經(jīng)接近LRU名單的中部位置。如果系統(tǒng)開始變得更加內(nèi)存緊張，你的進程是有可能被殺死的。

TRIM_MEMORY_COMPLETE: 系統(tǒng)正運行于低內(nèi)存的狀態(tài)并且你的進程正處于LRU名單中最容易被殺掉的位置。你應(yīng)該釋放任何不影響你的應(yīng)用恢復(fù)狀態(tài)的資源。

3. Memory Churn

Memory Churn內(nèi)存抖動：大量的對象被創(chuàng)建又在短時間內(nèi)馬上被釋放。

瞬間產(chǎn)生大量的對象會嚴重占用Young Generation的內(nèi)存區(qū)域，當達到閥值，剩余空間不夠的時候，也會觸發(fā)GC。系統(tǒng)花費在GC上的時間越多，進行界面繪制或流音頻處理的時間就越短。即使每次分配的對象占用了很少的內(nèi)存，但是他們疊加在一起會增加Heap的壓力，從而觸發(fā)更多其他類型的GC。這個操作有可能會影響到幀率，并使得用戶感知到性能問題。

Drop Frame Occur

常見的可能引發(fā)內(nèi)存抖動的情形：

• 循環(huán)中創(chuàng)建臨時對象;
• onDraw中創(chuàng)建Paint或Bitmap對象等;

例如之前使用過的有些下拉刷新控件的實現(xiàn)方式，在onDraw中創(chuàng)建Bitmap等多個臨時大對象會導(dǎo)致內(nèi)存抖動。

4. Bitmap

Bitmap的處理也是Android中的一個難點，當然使用第三方框架的話就屏蔽掉了這個難點。

• Bitmap的內(nèi)存模型;
• Bitmap的加載、壓縮、緩存等策略;
• 版本的兼容等;

關(guān)于Bitmap之后會寫專門的一篇文章來介紹，此處可以參考《Handling Bitmaps》。

5. Program Advice

5.1 節(jié)制地使用Service

內(nèi)存管理***的錯誤之一就是讓Service一直運行。在后臺使用service時，除非它需要被觸發(fā)并執(zhí)行一個任務(wù)，否則其他時候Service都應(yīng)該是停止狀態(tài)。另外需要注意Service工作完畢之后需要被停止，以免造成內(nèi)存泄漏。

系統(tǒng)會傾向于保留有Service所在的進程，這使得進程的運行代價很高，因為系統(tǒng)沒有辦法把Service所占用的RAM空間騰出來讓給其他組件，另外Service還不能被Paged out。這減少了系統(tǒng)能夠存放到LRU緩存當中的進程數(shù)量，它會影響應(yīng)用之間的切換效率，甚至?xí)?dǎo)致系統(tǒng)內(nèi)存使用不穩(wěn)定，從而無法繼續(xù)保持住所有目前正在運行的service。

建議使用JobScheduler，而盡量避免使用持久性的Service。還有建議使用IntentService，它會在處理完交代給它的任務(wù)之后盡快結(jié)束自己。

5.2 使用優(yōu)化過的集合

Android API當中提供了一些優(yōu)化過后的數(shù)據(jù)集合工具類，如SparseArray，SparseBooleanArray，以及LongSparseArray等，使用這些API可以讓我們的程序更加高效。傳統(tǒng)Java API中提供的HashMap工具類會相對比較低效，因為它需要為每一個鍵值對都提供一個對象入口，而SparseArray就避免掉了基本數(shù)據(jù)類型轉(zhuǎn)換成對象數(shù)據(jù)類型的時間。

5.3 謹慎對待面向抽象

開發(fā)者經(jīng)常把抽象作為好的編程實踐，因為抽象能夠提升代碼的靈活性與可維護性。然而，抽象會導(dǎo)致一個顯著的開銷：面向抽象需要額外的代碼(不會被執(zhí)行到)，同樣會被咨映射到內(nèi)存中，耗費了更多的時間以及內(nèi)存空間。因此如果面向抽象對你的代碼沒有顯著的收益，那你應(yīng)該避免使用。

例如：使用枚舉通常會比使用靜態(tài)常量要消耗兩倍以上的內(nèi)存，在Android開發(fā)當中我們應(yīng)當盡可能地不使用枚舉。

5.4 使用nano protobufs序列化數(shù)據(jù)

Protocol buffers是Google為序列化數(shù)據(jù)設(shè)計的一種語言無關(guān)、平臺無關(guān)、具有良好擴展性的數(shù)據(jù)描述語言，與XML類似，但是更加輕量、快速、簡單。如果使用protobufs來實現(xiàn)數(shù)據(jù)的序列化及反序列化，建議在客戶端使用nano protobufs，因為通常的protobufs會生成冗余代碼，會導(dǎo)致可用內(nèi)存減少，Apk體積變大，運行速度減慢。

5.5 避免內(nèi)存抖動

垃圾回收通常不會影響應(yīng)用的表現(xiàn)，但是短時間內(nèi)多次的垃圾回收會消耗掉界面繪制的時間。系統(tǒng)花費在GC上的時間越多，進行界面繪制或流音頻處理的時間就越短。通常內(nèi)存抖動會導(dǎo)致多次的GC，實踐中內(nèi)存抖動代表了一段時間內(nèi)分配了臨時對象。

例如：在For循環(huán)中分配了多個臨時對象，或在onDraw()方法中創(chuàng)建了Paint、Bitmap對象，應(yīng)用產(chǎn)生了大量的對象;這會很快耗盡young generation的可用內(nèi)存，導(dǎo)致GC發(fā)生。

使用Analyze your RAM usage中的工具找出代碼里內(nèi)存抖動的地方。考慮把操作移出內(nèi)部循環(huán)，或者將其移動到基于工廠的分配結(jié)構(gòu)中。

5.6 移除消耗內(nèi)存的庫、縮減Apk的大小

查看Apk的大小，包括三方庫和內(nèi)嵌的資源，這些都會影響應(yīng)用消耗的內(nèi)存。通過減少冗余、非必須或大的組件、庫、圖片、資源、動畫等，都可以改善應(yīng)用的內(nèi)存消耗。

5.7 使用Dagger 2進行依賴注入

如果您打算在應(yīng)用程序中使用依賴注入框架，請考慮使用Dagger 2。 Dagger不使用反射來掃描應(yīng)用程序的代碼。 Dagger的編譯時注解技術(shù)實現(xiàn)意味著它不需要不必要的運行時成本。而使用反射的其它依賴注入框架通常通過掃描代碼來初始化過程。 此過程可能需要顯著更多的CPU周期和RAM，并可能導(dǎo)致應(yīng)用程序啟動時明顯的卡頓。

備注：之前的文檔是不建議使用依賴注入框架，因為實現(xiàn)原理是使用反射，而進化為編譯時注解之后，就不再有反射帶來的影響了。

5.8 謹慎使用第三方庫

很多開源的library代碼都不是為移動端而編寫的，如果運用在移動設(shè)備上，并不一定適合。即使是針對Android而設(shè)計的library，也需要特別謹慎，特別是在你不知道引入的library具體做了什么事情的時候。例如，其中一個library使用的是nano protobufs, 而另外一個使用的是micro protobufs。這樣一來，在你的應(yīng)用里面就有2種protobuf的實現(xiàn)方式。這樣類似的沖突還可能發(fā)生在輸出日志，加載圖片，緩存等等模塊里面。另外不要為了1個或者2個功能而導(dǎo)入整個library，如果沒有一個合適的庫與你的需求相吻合，你應(yīng)該考慮自己去實現(xiàn)，而不是導(dǎo)入一個大而全的解決方案。

6. Other

6.1 謹慎使用LargeHeap屬性

可以通過在manifest的application標簽下添加largeHeap=true的屬性來為應(yīng)用聲明一個更大的heap空間(可以通過getLargeMemoryClass()來獲取到這個更大的heap size閾值)。然而，聲明得到更大Heap閾值的本意是為了一小部分會消耗大量RAM的應(yīng)用(例如一個大圖片的編輯應(yīng)用)。不要輕易的因為你需要使用更多的內(nèi)存而去請求一個大的Heap Size。只有當你清楚的知道哪里會使用大量的內(nèi)存并且知道為什么這些內(nèi)存必須被保留時才去使用large heap，使用額外的內(nèi)存空間會影響系統(tǒng)整體的用戶體驗，并且會使得每次gc的運行時間更長。在任務(wù)切換時，系統(tǒng)的性能會大打折扣。另外, large heap并不一定能夠獲取到更大的heap。在某些有嚴格限制的機器上，large heap的大小和通常的heap size是一樣的。

6.2 謹慎使用多進程

多進程確實是一種可以幫助我們節(jié)省和管理內(nèi)存的高級技巧。如果你要使用它的話一定要謹慎使用，因為絕大多數(shù)的應(yīng)用程序都不應(yīng)該在多個進程當中運行的，一旦使用不當，它甚至?xí)黾宇~外的內(nèi)存而不是幫我們節(jié)省內(nèi)存;同時需要知曉多進程帶來的缺點。這個技巧比較適用于那些需要在后臺去完成一項獨立的任務(wù)，和前臺的功能是可以完全區(qū)分開的場景。

這里舉一個比較適合去使用多進程技巧的場景，比如說我們正在做一個音樂播放器軟件，其中播放音樂的功能應(yīng)該是一個獨立的功能，它不需要和UI方面有任何關(guān)系，即使軟件已經(jīng)關(guān)閉了也應(yīng)該可以正常播放音樂。如果此時我們只使用一個進程，那么即使用戶關(guān)閉了軟件，已經(jīng)完全由Service來控制音樂播放了，系統(tǒng)仍然會將許多UI方面的內(nèi)存進行保留。在這種場景下就非常適合使用兩個進程，一個用于UI展示，另一個則用于在后臺持續(xù)地播放音樂。

6.3 實現(xiàn)方式可能存在的問題：例如啟動頁閃屏圖，show完畢之后應(yīng)該釋放掉Bitmap。

一些實現(xiàn)方式看起來沒有問題實現(xiàn)了功能但是實際上可能對內(nèi)存造成了影響。我在使用Heap Viewer查看Bitmap對象時發(fā)現(xiàn)了一張只需下載不應(yīng)該被加載的圖。

使用HeapViewer可直接查看Bitmap

內(nèi)存中出現(xiàn)的不應(yīng)該被加載的圖

通過查閱代碼，發(fā)現(xiàn)問題出在：此處下載圖片作為另一個模塊的使用圖，但是下載的方法竟然是使用圖片加載器加載出來Bitmap然后再保存到本地;而且保存之后也沒有將Bitmap對象釋放掉。

與之類似的還有：首頁閃屏圖展示之后，Bitmap對象應(yīng)該及時釋放掉。

6.4 使用try catch進行捕獲

對高風(fēng)險OOM代碼塊如展示高清大圖等進行try catch，在catch塊加載非高清的圖片并做相應(yīng)內(nèi)存回收的處理。注意OOM是OutOfMemoryError，不能使用Exception進行捕獲。

7. Summary

內(nèi)存優(yōu)化的套路：

（1）解決所有的內(nèi)存泄漏

• 集成LeakCanary，可以方便的定位出90%的內(nèi)存泄漏問題;
• 通過反復(fù)進出可疑界面，觀察內(nèi)存增減的情況，Dump Java Heap獲取當前堆棧信息使用MAT進行分析。
• 內(nèi)存泄漏的常見情形可參照《Android 內(nèi)存泄漏分析心得》

（2）避免內(nèi)存抖動

• 避免在循環(huán)中創(chuàng)建臨時對象;
• 避免在onDraw中創(chuàng)建Paint、Bitmap對象等。

（3）Bitmap的使用

• 使用三方庫加載圖片一般不會出內(nèi)存問題，但是需要注意圖片使用完畢的釋放，而不是被動等待釋放。
• 使用優(yōu)化過的數(shù)據(jù)結(jié)構(gòu)
• 使用onTrimMemory根據(jù)不同的內(nèi)存狀態(tài)做相應(yīng)處理

（4）Library的使用

• 去掉無用的Library，對生成的Apk進行反編譯查看使用到的Library，避免出現(xiàn)無用的Lib仍然被打進Apk;
• 避免引入巨大的Library;
• 使用Proguard進行混淆、壓縮。

網(wǎng)站名稱：【寶貴經(jīng)驗】Android性能優(yōu)化之內(nèi)存優(yōu)化實戰(zhàn)
網(wǎng)頁網(wǎng)址：http://uogjgqi.cn/article/dheghid.html