Android 性能優化（四）以內存優化實戰

在上一篇《Android性能優化（三）以內存管理》中咱們對Android的內存管理有了必定的認識，本篇文章從實際出發對內存進行優化，主要包含如下部分：

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：

1. 點擊Histogram並在頂部的Regex中輸入MainActivity會進行正則匹配，會將包含「MainActivity」的全部對象所有列出了出來，其中第一行就是MainActivity的實例。
   

   

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

   

3. 對想要查看的對象實例點擊右鍵-> 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的使用

   • 使用三方庫加載圖片通常不會出內存問題，可是須要注意圖片使用完畢的釋放，而不是被動等待釋放。

4. 使用優化過的數據結構

5. 使用onTrimMemory根據不一樣的內存狀態作相應處理
6. Library的使用
   • 去掉無用的Library，對生成的Apk進行反編譯查看使用到的Library，避免出現無用的Lib仍然被打進Apk；
   • 避免引入巨大的Library；
   • 使用Proguard進行混淆、壓縮。

參考：

• Android性能優化典範
• Manage Your App's Memory

歡迎關注微信公衆號：按期分享Java、Android乾貨！

歡迎關注