如需轉(zhuǎn)載請(qǐng)?jiān)u論或簡(jiǎn)信，并注明出處，未經(jīng)允許不得轉(zhuǎn)載

目錄

前言

在Android中邓夕，內(nèi)存是十分寶貴的資源聂薪，內(nèi)存優(yōu)化有助于提高用戶的體驗(yàn)，所以學(xué)習(xí)內(nèi)存優(yōu)化技巧是非常重要的锯仪。本文主要介紹性能優(yōu)化的一些手段，但是為了便于理解以及融會(huì)貫通，建議先了解Android內(nèi)存管理機(jī)制

減小對(duì)象的內(nèi)存占用

盡量減少新分配出來(lái)的對(duì)象占用內(nèi)存的大小连舍，使用更加輕量的對(duì)象

1. 使用性能高的數(shù)據(jù)結(jié)構(gòu)

基本數(shù)據(jù)類型的包裝類占用內(nèi)存較大，如果不是特別需要包裝類的話涩哟，就不要用包裝類（可以從 Allocation Tracker 看到索赏，Integer 要占 16 字節(jié)，而 int 只占 4 個(gè)字節(jié)）贴彼。Hashmap的泛型規(guī)定了只能用包裝類潜腻，所以 get，put 等操作均會(huì)涉及到自動(dòng)拆裝箱器仗，在操作頻繁時(shí)可能會(huì)出現(xiàn)性能問(wèn)題

我們可以用 Android 中提供的一些容器來(lái)替代 Java 中的一些容器融涣，比如：SparseBoolArray童番，SparseIntArray，SparseLongArray威鹿，LongSparseArray 等剃斧，以上這幾個(gè)容器的key都是集合名中的那個(gè)基本類型，value 都是Object忽你。他們都是用 ArrayMap 實(shí)現(xiàn)的幼东，ArrayMap 會(huì)對(duì) key 占用空間進(jìn)行壓縮，并且可以通過(guò)普通 for 循環(huán)進(jìn)行遍歷（ keyAt(i), valueAt(i) ）這樣遍歷效率高于迭代器遍歷（foreach 底層就是迭代器）科雳。在容器 size 小于 1000 或者嵌套 map 的情況下根蟹，適合用 Sparse 系列替換 HashMap

HashMap 的數(shù)據(jù)結(jié)構(gòu)如下：

可以看到，HaspMap 創(chuàng)建時(shí)直接申請(qǐng)了一些空間來(lái)存 key 的hash 值糟秘，在 key 數(shù)量沒(méi)有占滿這些空間時(shí)简逮，就很浪費(fèi)。我們?cè)賮?lái)看看 ArrayMap 的數(shù)據(jù)結(jié)構(gòu) ：

有關(guān)Hashmap及hash算法分析見(jiàn)：深入理解 hashcode() 和 HashMap 中的hash 算法

2. 避免在Android里面使用Enum

Enum比起使用static常量會(huì)至少增加2倍以上bytes的APK大小蚌堵，增加5到10倍的RAM

Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android

具體原因見(jiàn)：Android中避免使用枚舉類（Enum）

3. 減小Bitmap對(duì)象的內(nèi)存占用

Bitmap極容易消耗內(nèi)存买决，減小創(chuàng)建出來(lái)的Bitmap的內(nèi)存占用可謂是重中之重，通常來(lái)說(shuō)有以下兩個(gè)措施：

• inSampleSize：縮放比例吼畏，在把圖片載入內(nèi)存之前督赤，我們需要先計(jì)算出一個(gè)合適的縮放比例，避免不必要的大圖載入泻蚊。
• decode format：解碼格式躲舌，選擇ARGB_8888/RBG_565/ARGB_4444/ALPHA_8

更多關(guān)于Bitmap的優(yōu)化技巧：Bitmap性能優(yōu)化

4. 使用壓縮后的圖片

在涉及給到資源圖片時(shí)，我們需要特別留意這張圖片是否存在可以壓縮的空間性雄，是否可以使用更小的圖片没卸。盡量使用更小的圖片不僅可以減少內(nèi)存的使用，還能避免出現(xiàn)大量的InflationException秒旋。假設(shè)有一張很大的圖片被XML文件直接引用约计，很有可能在初始化視圖時(shí)會(huì)因?yàn)閮?nèi)存不足而發(fā)生InflationException，這個(gè)問(wèn)題的根本原因其實(shí)是發(fā)生了OOM

這里推薦一個(gè)比較好用的圖片壓縮網(wǎng)站：tinypng

5. 某些場(chǎng)景下迁筛，用shape替代圖片

有時(shí)候會(huì)有一些漸變或者描邊的UI效果煤蚌，如果可以用<shape/>畫(huà)的就盡量不要直接引用圖片資源了，如下所示：

<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android"
    android:shape="rectangle">
    <gradient
        android:startColor="#000000"
        android:angle="0"
        android:endColor="#ffffff"/>
</shape>

6. 代碼混淆&減少不必要的類细卧、類庫(kù)

不必要的類尉桩、對(duì)象以及功能庫(kù)會(huì)帶來(lái)巨大的性能開(kāi)銷（每個(gè)類的實(shí)例在運(yùn)行內(nèi)存中占12-16個(gè)字節(jié)）。代碼混淆可以去除無(wú)用代碼贪庙，通過(guò)語(yǔ)意模糊對(duì)類蜘犁、字段進(jìn)行重命名，從而縮小止邮、優(yōu)化代碼这橙，產(chǎn)生更少量的內(nèi)存映射

有關(guān)代碼混淆的更多知識(shí)見(jiàn)：最全的Android代碼混淆使用手冊(cè)

7. 使用Parcelable進(jìn)行內(nèi)存間數(shù)據(jù)傳輸

Parcelable是Android特有的類奏窑，Parcelable的性能比Serializable好，在內(nèi)存開(kāi)銷方面較小析恋，所以在內(nèi)存間數(shù)據(jù)傳輸時(shí)推薦使用Parcelable良哲，如activity間傳輸數(shù)據(jù)盛卡。而Serializable可將數(shù)據(jù)持久化方便保存助隧，所以在需要保存或網(wǎng)絡(luò)傳輸數(shù)據(jù)時(shí)選擇Serializable（因?yàn)閍ndroid不同版本Parcelable可能不同，所以不推薦使用Parcelable進(jìn)行數(shù)據(jù)持久化）

Parcelable大致原理

內(nèi)存對(duì)象的復(fù)用

減少內(nèi)存對(duì)象的復(fù)用總的來(lái)說(shuō)一般有兩種思路

• 使用對(duì)象池技術(shù)
• 利用系統(tǒng)框架既有的某些復(fù)用特性滑沧，減少對(duì)象的重復(fù)創(chuàng)建

1. 復(fù)用系統(tǒng)自帶的資源

Android系統(tǒng)本身內(nèi)置了很多的資源并村，比如string、color滓技、drawable哩牍、anim、style以及簡(jiǎn)單layout等令漂，這些資源都可以在應(yīng)用程序中直接引用膝昆。這樣做不僅能減小APK的大小，還可以在一定程度上減少內(nèi)存的開(kāi)銷

2. 列表item的復(fù)用

在ListView/GridView/RecyclerView等出現(xiàn)大量重復(fù)子組件的視圖里對(duì)itemView的復(fù)用

延伸：現(xiàn)在很多人都推薦用RecyclerView替代ListView叠必，但是Google為什么沒(méi)有給ListView劃上一杠呢荚孵，關(guān)于RecyclerView和ListView的差異，可以看Android ListView 與 RecyclerView 對(duì)比淺析—緩存機(jī)制

3. Bitmap對(duì)象的復(fù)用

1）顯示RecyclerView這種需要大量顯示圖片的控件里纬朝，使用LRU的機(jī)制來(lái)緩存處理好的Bitmap

有關(guān)LRU緩存機(jī)制更詳細(xì)的介紹：LRU緩存機(jī)制

2）利用inBitmap的高級(jí)特性提高Android系統(tǒng)在Bitmap分配與釋放執(zhí)行效率

關(guān)于inBitmap具體見(jiàn)：Bitmap性能優(yōu)化

4. 使用handler.obtainMessage()創(chuàng)建Message對(duì)象

不要再用new Message()的方式創(chuàng)建Message對(duì)象啦收叶！handler.obtainMessage()內(nèi)部使用了對(duì)象池技術(shù)，可以有效幫助我們減少創(chuàng)建Message對(duì)象的內(nèi)存消耗

具體源碼分析見(jiàn)：對(duì)象池技術(shù)：如何正確創(chuàng)建對(duì)象

避免對(duì)象的內(nèi)存泄露

內(nèi)存對(duì)象的泄漏共苛，會(huì)導(dǎo)致一些不再使用的對(duì)象無(wú)法及時(shí)釋放判没，這樣一方面占用了寶貴的內(nèi)存空間，很容易導(dǎo)致后續(xù)需要分配內(nèi)存的時(shí)候隅茎，空閑空間不足而出現(xiàn)OOM澄峰。顯然，這還使得每級(jí)Generation的內(nèi)存區(qū)域可用空間變小辟犀，GC就會(huì)更容易被觸發(fā)俏竞，容易出現(xiàn)內(nèi)存抖動(dòng)，從而引起性能問(wèn)題

關(guān)于內(nèi)存泄漏相關(guān)問(wèn)題具體見(jiàn)：寫給程序員的內(nèi)存泄漏治理手冊(cè)

內(nèi)存使用策略優(yōu)化

優(yōu)化布局層次踪蹬，減少內(nèi)存消耗

越扁平化的視圖布局胞此，占用的內(nèi)存就越少，效率越高跃捣。我們需要盡量保證布局足夠扁平化漱牵，當(dāng)使用系統(tǒng)提供的View無(wú)法實(shí)現(xiàn)足夠扁平的時(shí)候考慮使用自定義View來(lái)達(dá)到目的

關(guān)于布局優(yōu)化問(wèn)題可參考：Android布局優(yōu)化

使用StringBuilder拼接字符串

在有些時(shí)候，代碼中會(huì)需要使用到大量的字符串拼接的操作疚漆，這種時(shí)候有必要考慮使用StringBuilder來(lái)替代頻繁的“+”酣胀，否則有可能引起內(nèi)存抖動(dòng)

關(guān)于內(nèi)存抖動(dòng)的介紹見(jiàn)：五分鐘了解內(nèi)存抖動(dòng)

避免在onDraw()內(nèi)創(chuàng)建對(duì)象

類似onDraw()等頻繁調(diào)用的方法刁赦，一定需要注意避免在這里做創(chuàng)建對(duì)象的操作，因?yàn)樗麜?huì)迅速增加內(nèi)存的使用闻镶，而且很容易引起頻繁的gc甚脉，甚至是內(nèi)存抖動(dòng)

選擇合適的文件夾存放資源文件

我們知道hdpi/xhdpi/xxhdpi等等不同dpi的文件夾下的圖片在不同的設(shè)備上會(huì)經(jīng)過(guò)scale的處理。例如我們只在hdpi的目錄下放置了一張100 * 100的圖片铆农，那么根據(jù)換算關(guān)系牺氨，xxhdpi的手機(jī)去引用那張圖片就會(huì)被拉伸到200 * 200。需要注意到在這種情況下墩剖，內(nèi)存占用是會(huì)顯著提高的猴凹。對(duì)于不希望被拉伸的圖片，需要放到assets或者nodpi的目錄下

try catch某些大內(nèi)存分配的操作

在某些情況下岭皂，我們需要事先評(píng)估那些可能發(fā)生OOM的代碼郊霎，對(duì)于這些可能發(fā)生OOM的代碼，加入catch機(jī)制爷绘，可以考慮在catch里面嘗試一次降級(jí)的內(nèi)存分配操作书劝。例如decode bitmap的時(shí)候，catch到OOM土至，可以嘗試把采樣比例再增加一倍之后购对，再次嘗試decode

設(shè)計(jì)合適的緩存大小

例如，在設(shè)計(jì)ListView或者GridView的Bitmap 的LruCache的時(shí)候毙籽，需要考慮的點(diǎn)有：

• 應(yīng)用程序剩下了多少可用的內(nèi)存空間
• 有多少圖片會(huì)被一次呈現(xiàn)到屏幕上
• 有多少圖片需要事先緩存好以便快速滑動(dòng)時(shí)能夠立即顯示到屏幕
• 設(shè)備的屏幕大小與密度是多少（一個(gè)xhdpi的設(shè)備會(huì)比hdpi需要一個(gè)更大的緩存來(lái)hold住同樣數(shù)量的圖片）
• 不同的頁(yè)面針對(duì)Bitmap的設(shè)計(jì)的尺寸與配置是什么
• 頁(yè)面圖片被訪問(wèn)的頻率是否存在其中的一部分比其他的圖片具有更高的訪問(wèn)頻繁（如果是洞斯，可以保存那些最常訪問(wèn)的到內(nèi)存中，或者為不同組別的Bitmap(按訪問(wèn)頻率分組)設(shè)置多個(gè)LruCache容器）

使用IntentService

當(dāng)啟動(dòng)常駐服務(wù)時(shí)坑赡，系統(tǒng)會(huì)優(yōu)先保持服務(wù)在后臺(tái)不斷運(yùn)行烙如，也就是系統(tǒng)會(huì)傾向?yàn)榱吮Ａ暨@個(gè)Service而一直保留Service所在的進(jìn)程，這減少了系統(tǒng)能夠存放到LRU緩存當(dāng)中的進(jìn)程數(shù)量毅否，它會(huì)影響應(yīng)用之間的切換效率亚铁。另外還需要注意當(dāng)這個(gè)Service完成任務(wù)之后因?yàn)橥Ｖ?code>Service失敗而引起的內(nèi)存泄漏，建議使用IntentService螟加，他會(huì)在任務(wù)執(zhí)行完成后主動(dòng)調(diào)用stopSelf()

關(guān)于Service和IntentService具體見(jiàn)：Service詳解

合理使用數(shù)據(jù)引用類型
根據(jù)不同的引用場(chǎng)景徘溢，選擇不同的引用類型

• 強(qiáng)引用（StrongReference）
  強(qiáng)引用是使用最普遍的引用。如果一個(gè)對(duì)象具有強(qiáng)引用捆探，那垃圾回收器絕不會(huì)回收它然爆。當(dāng)內(nèi)存空間不足，Java虛擬機(jī)寧愿拋出OutOfMemoryError錯(cuò)誤黍图，使程序異常終止曾雕，也不會(huì)靠隨意回收具有強(qiáng)引用的對(duì)象來(lái)解決內(nèi)存不足的問(wèn)題。強(qiáng)引用其實(shí)也就是我們平時(shí)A a = new A()這個(gè)意思

• 軟引用（SoftReference）
  如果一個(gè)對(duì)象只具有軟引用助被，則內(nèi)存空間足夠剖张，垃圾回收器就不會(huì)回收它切诀；如果內(nèi)存空間不足了，就會(huì)回收這些對(duì)象的內(nèi)存搔弄。只要垃圾回收器沒(méi)有回收它幅虑，該對(duì)象就可以被程序使用。軟引用可用來(lái)實(shí)現(xiàn)內(nèi)存敏感的高速緩存
  軟引用可以和一個(gè)引用隊(duì)列（ReferenceQueue）聯(lián)合使用顾犹，如果軟引用所引用的對(duì)象被垃圾回收器回收倒庵，Java虛擬機(jī)就會(huì)把這個(gè)軟引用加入到與之關(guān)聯(lián)的引用隊(duì)列中

• 弱引用（WeakReference）
  弱引用與軟引用的區(qū)別在于：只具有弱引用的對(duì)象擁有更短暫的生命周期。在垃圾回收器線程掃描它所管轄的內(nèi)存區(qū)域的過(guò)程中蹦渣，一旦發(fā)現(xiàn)了只具有弱引用的對(duì)象哄芜，不管當(dāng)前內(nèi)存空間足夠與否貌亭，都會(huì)回收它的內(nèi)存柬唯。不過(guò)，由于垃圾回收器是一個(gè)優(yōu)先級(jí)很低的線程圃庭，因此不一定會(huì)很快發(fā)現(xiàn)那些只具有弱引用的對(duì)象
  弱引用可以和一個(gè)引用隊(duì)列（ReferenceQueue）聯(lián)合使用锄奢，如果弱引用所引用的對(duì)象被垃圾回收，Java虛擬機(jī)就會(huì)把這個(gè)弱引用加入到與之關(guān)聯(lián)的引用隊(duì)列中

• 虛引用（PhantomReference）
  “虛引用”顧名思義剧腻，就是形同虛設(shè)拘央，與其他幾種引用都不同，虛引用并不會(huì)決定對(duì)象的生命周期书在。如果一個(gè)對(duì)象僅持有虛引用灰伟，那么它就和沒(méi)有任何引用一樣，在任何時(shí)候都可能被垃圾回收器回收
  虛引用主要用來(lái)跟蹤對(duì)象被垃圾回收器回收的活動(dòng)儒旬。虛引用與軟引用和弱引用的一個(gè)區(qū)別在于：虛引用必須和引用隊(duì)列 （ReferenceQueue）聯(lián)合使用栏账。當(dāng)垃圾回收器準(zhǔn)備回收一個(gè)對(duì)象時(shí)，如果發(fā)現(xiàn)它還有虛引用栈源，就會(huì)在回收對(duì)象的內(nèi)存之前挡爵，把這個(gè)虛引用加入到與之 關(guān)聯(lián)的引用隊(duì)列中

謹(jǐn)慎使用SharePreference

• 對(duì)于同一個(gè)sp，會(huì)將整個(gè)xml導(dǎo)入到內(nèi)存中甚垦，容易出現(xiàn)為了讀取一個(gè)配置而將幾百k的數(shù)據(jù)寫入內(nèi)存茶鹃，造成內(nèi)存浪費(fèi)
• 每個(gè)sp存儲(chǔ)的鍵值對(duì)不宜過(guò)多，否則在加載文件數(shù)據(jù)到內(nèi)存時(shí)會(huì)耗時(shí)過(guò)長(zhǎng)艰亮，導(dǎo)致sp的相關(guān)get或put方法被阻塞闭翩，造成UI卡頓及內(nèi)存浪費(fèi)
• 頻繁更改的配置項(xiàng)和不常更改的配置項(xiàng)應(yīng)該分開(kāi)為不同的sp存放

謹(jǐn)慎使用抽象編程

很多時(shí)候，開(kāi)發(fā)者會(huì)使用抽象類作為”好的編程習(xí)慣”迄埃，因?yàn)槌橄竽軌蛱嵘a的靈活性與可維護(hù)性疗韵。然而，抽象會(huì)導(dǎo)致一個(gè)顯著的額外內(nèi)存開(kāi)銷调俘，那些代碼會(huì)被mapping到內(nèi)存中伶棒，因此如果你的抽象沒(méi)有顯著的提升效率旺垒，應(yīng)該盡量避免他們

謹(jǐn)慎使用依賴注入框架

依賴注入框架在Android端越來(lái)越流行了（如ButterKnife），因?yàn)檫@些框架往往可以簡(jiǎn)化代碼肤无，方便開(kāi)發(fā)先蒋。然而，這些依賴注入框架會(huì)通過(guò)掃描代碼執(zhí)行許多初始化的操作宛渐，這會(huì)導(dǎo)致你的代碼需要大量的內(nèi)存空間來(lái)mapping代碼竞漾，而且mapped pages會(huì)長(zhǎng)時(shí)間的被保留在內(nèi)存中。所以如何取舍窥翩，就根據(jù)實(shí)際項(xiàng)目需要來(lái)決定了

對(duì)依賴注入感興趣的可以看：手把手教你實(shí)現(xiàn)仿ButterKnife依賴注入框架

謹(jǐn)慎使用多進(jìn)程

使用多進(jìn)程可以把應(yīng)用中的部分組件運(yùn)行在單獨(dú)的進(jìn)程當(dāng)中业岁，這樣可以擴(kuò)大應(yīng)用的內(nèi)存占用范圍，但是這個(gè)技術(shù)必須謹(jǐn)慎使用寇蚊，絕大多數(shù)應(yīng)用都不應(yīng)該貿(mào)然使用多進(jìn)程笔时，一方面是因?yàn)槭褂枚噙M(jìn)程會(huì)使得代碼邏輯更加復(fù)雜，另外如果使用不當(dāng)仗岸，它可能反而會(huì)導(dǎo)致顯著增加內(nèi)存（空進(jìn)程也會(huì)占用約1M的內(nèi)存）允耿。當(dāng)你的應(yīng)用需要運(yùn)行一個(gè)常駐后臺(tái)的任務(wù)，而且這個(gè)任務(wù)并不輕量扒怖，可以考慮使用多進(jìn)程

一個(gè)典型的例子是創(chuàng)建一個(gè)可以長(zhǎng)時(shí)間后臺(tái)播放的Music Player较锡。如果整個(gè)應(yīng)用都運(yùn)行在一個(gè)進(jìn)程中，當(dāng)后臺(tái)播放的時(shí)候盗痒，前臺(tái)的那些UI資源也沒(méi)有辦法得到釋放蚂蕴。類似這樣的應(yīng)用可以切分成2個(gè)進(jìn)程：一個(gè)用來(lái)操作UI，另外一個(gè)給后臺(tái)的Service

謹(jǐn)慎使用幀動(dòng)畫(huà)

幀動(dòng)畫(huà)是非常消耗內(nèi)存的俯邓，在使用幀動(dòng)畫(huà)之前骡楼，我們盡量考慮一下這個(gè)動(dòng)畫(huà)效果能不能通過(guò)補(bǔ)間動(dòng)畫(huà)或?qū)傩詣?dòng)畫(huà)來(lái)實(shí)現(xiàn)。如果是大圖做幀動(dòng)畫(huà)或者上百幀的動(dòng)畫(huà)看成，那么在低端設(shè)備上就極有可能出現(xiàn)OOM君编，這時(shí)候我們可以使用SurfaceView來(lái)實(shí)現(xiàn)“幀動(dòng)畫(huà)”。

對(duì)SurfaceView感興趣的可以看幀動(dòng)畫(huà)導(dǎo)致OOM川慌？手把手教你用SurfaceView實(shí)現(xiàn)幀動(dòng)畫(huà)

SurfaceView繼承之View吃嘿，但擁有獨(dú)立的繪制表面，即它不與其宿主窗口共享同一個(gè)繪圖表面梦重，可以單獨(dú)在一個(gè)線程進(jìn)行繪制兑燥，并不會(huì)占用主線程的資源

謹(jǐn)慎使用static對(duì)象

因?yàn)?code>static的生命周期過(guò)長(zhǎng)，和應(yīng)用的進(jìn)程保持一致琴拧，使用不當(dāng)很可能導(dǎo)致對(duì)象泄漏降瞳，在Android中應(yīng)該謹(jǐn)慎聲明static對(duì)象

謹(jǐn)慎使用large heap

當(dāng)我們非常確定我們的應(yīng)用需要用到更多的內(nèi)存，并且知道為什么這些內(nèi)存必須被保留時(shí)，我們可以去使用large heap挣饥。(例如一個(gè)大圖片的編輯應(yīng)用)除师。因?yàn)槭褂妙~外的內(nèi)存空間會(huì)影響系統(tǒng)整體的體驗(yàn)，并且會(huì)使得每次gc的運(yùn)行時(shí)間更長(zhǎng)扔枫。我們可以通過(guò)在manifest的application標(biāo)簽下添加largeHeap=true來(lái)為應(yīng)用聲明一個(gè)更大的heap閾值汛聚。之后可以通過(guò)執(zhí)行ActivityManager.getMemoryClass()來(lái)檢查實(shí)際獲取到的heap閾值

onTrimMemory()

Android 4.0后提供的一個(gè)API，在應(yīng)用生命周期的任何階段短荐，調(diào)用 onTrimMemory()獲取應(yīng)用程序 當(dāng)前內(nèi)存使用情況（以內(nèi)存級(jí)別進(jìn)行識(shí)別）倚舀，可根據(jù)該方法返回的內(nèi)存緊張級(jí)別參數(shù) 來(lái)釋放內(nèi)存。當(dāng)視圖變?yōu)殡[藏狀態(tài)時(shí)忍宋，則釋放內(nèi)存痕貌。當(dāng)用戶跳轉(zhuǎn)到不同的應(yīng)用 & 視圖不再顯示時(shí), 應(yīng)釋放應(yīng)用視圖所占的資源

• Application.onTrimMemory()
• Activity.onTrimMemory()
• Fragement.OnTrimMemory()
• Service.onTrimMemory()
• ContentProvider.OnTrimMemory()

onTrimMemory.png

TRIM_MEMORY_UI_HIDDEN這個(gè)等級(jí)比較常用，此時(shí)釋放所占用的資源能顯著的提高系統(tǒng)的緩存處理容量

具體操作：實(shí)現(xiàn)當(dāng)前Activity類的onTrimMemory()后糠排，當(dāng)用戶離開(kāi)視圖時(shí)會(huì)得到通知舵稠；若得到返回的參數(shù) = TRIM_MEMORY_UI_HIDDEN 即代表視圖變?yōu)殡[藏狀態(tài)，則可釋放視圖所占用的資源

總結(jié)

其實(shí)內(nèi)存優(yōu)化不光光是要學(xué)習(xí)一些優(yōu)化技巧乳讥，同時(shí)也要學(xué)習(xí)更多的基礎(chǔ)知識(shí)柱查，因?yàn)楹芏鄷r(shí)候一些內(nèi)存問(wèn)題其實(shí)是一些不規(guī)范的代碼寫法導(dǎo)致的。所以很多性能問(wèn)題都盡量在開(kāi)發(fā)過(guò)程中去避免云石，而不是開(kāi)發(fā)完之后再想著有空再回來(lái)進(jìn)行性能優(yōu)化