1. Memory Leak

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

1.1 Memory Monitor

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

 

 

 

頻繁的內存抖動，可能存在內存泄漏

A：initiate GC 手動觸發GC操作;

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

C：Start Allocation Tracking 內存分配追蹤工具，用于追蹤一段時間的內存分配使用情況，能夠知道執行一些列操作后，有哪些對象被分配空間。一般用于追蹤某項操作之后的內存分配，調整相關的方法調用來優化app性能與內存使用;

D：剩余可用內存;

E：已經使用的內存。

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

 

 

 

Hprof Viewer打開.hprof文件

左面板說明：

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

右面板說明：

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

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

1.2 MAT

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

格式轉換命令：hprof-conv 原文件路徑 轉換后文件路徑 

 

 

 

MAT打開.hprof

注意下面的Actions：

• Histogram可以列出內存中每個對象的名字、數量以及大小。
• Dominator Tree會將所有內存中的對象按大小進行排序，并且我們可以分析對象之間的引用結構。

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

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

• 使用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訪問到導致其不能被回收，從而它所持有的其它引用也無法被回收了，包括MainActivity，也包括MainActivity中所包含的其它資源。

此時我們就找到了內存泄漏的原因。

• 使用Dominator Tree 

 

 

 

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

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

1.3 LeakCanary

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

 

 

 

2. Out Of Memory

2.1 Android OOM

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

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

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

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

2.2 Avoid Android OOM

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

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

TRIM_MEMORY_RUNNING_MODERATE：你的應用正在運行并且不會被列為可殺死的。但是設備此時正運行于低內存狀態下，系統開始觸發殺死LRU Cache中的Process的機制。

TRIM_MEMORY_RUNNING_LOW：你的應用正在運行且沒有被列為可殺死的。但是設備正運行于更低內存的狀態下，你應該釋放不用的資源用來提升系統性能。

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

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

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

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

TRIM_MEMORY_COMPLETE: 系統正運行于低內存的狀態并且你的進程正處于LRU名單中最容易被殺掉的位置。你應該釋放任何不影響你的應用恢復狀態的資源。

3. Memory Churn

Memory Churn內存抖動：大量的對象被創建又在短時間內馬上被釋放。

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

 

 

 

Drop Frame Occur

常見的可能引發內存抖動的情形：

• 循環中創建臨時對象;
• onDraw中創建Paint或Bitmap對象等;

例如之前使用過的有些下拉刷新控件的實現方式，在onDraw中創建Bitmap等多個臨時大對象會導致內存抖動。

4. Bitmap

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

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

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

5. Program Advice

5.1 節制地使用Service

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

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

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

5.2 使用優化過的集合

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

5.3 謹慎對待面向抽象

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

例如：使用枚舉通常會比使用靜態常量要消耗兩倍以上的內存，在Android開發當中我們應當盡可能地不使用枚舉。

5.4 使用nano protobufs序列化數據

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

5.5 避免內存抖動

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

例如：在For循環中分配了多個臨時對象，或在onDraw()方法中創建了Paint、Bitmap對象，應用產生了大量的對象;這會很快耗盡young generation的可用內存，導致GC發生。

使用Analyze your RAM usage中的工具找出代碼里內存抖動的地方。考慮把操作移出內部循環，或者將其移動到基于工廠的分配結構中。

5.6 移除消耗內存的庫、縮減Apk的大小

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

5.7 使用Dagger 2進行依賴注入

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

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

5.8 謹慎使用第三方庫

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

6. Other

6.1 謹慎使用LargeHeap屬性

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

6.2 謹慎使用多進程

多進程確實是一種可以幫助我們節省和管理內存的高級技巧。如果你要使用它的話一定要謹慎使用，因為絕大多數的應用程序都不應該在多個進程當中運行的，一旦使用不當，它甚至會增加額外的內存而不是幫我們節省內存;同時需要知曉多進程帶來的缺點。這個技巧比較適用于那些需要在后臺去完成一項獨立的任務，和前臺的功能是可以完全區分開的場景。

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

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

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

 

 

 

使用HeapViewer可直接查看Bitmap 

 

 

 

內存中出現的不應該被加載的圖

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

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

6.4 使用try catch進行捕獲

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

7. Summary

內存優化的套路：

（1）解決所有的內存泄漏

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

（2）避免內存抖動

• 避免在循環中創建臨時對象;
• 避免在onDraw中創建Paint、Bitmap對象等。

（3）Bitmap的使用

• 使用三方庫加載圖片一般不會出內存問題，但是需要注意圖片使用完畢的釋放，而不是被動等待釋放。
• 使用優化過的數據結構
• 使用onTrimMemory根據不同的內存狀態做相應處理

（4）Library的使用

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