原文鏈接 讓你不再懼怕內(nèi)存優(yōu)化
之前曾經(jīng)寫過一篇關(guān)于如何做性能優(yōu)化的文章菊霜，現(xiàn)在針對內(nèi)存這一專項(xiàng)再做精細(xì)化的討論。對于安卓應(yīng)用開發(fā)來說，內(nèi)存究竟會遇到什么樣的問題蔓涧，有什么方法可以用來測試和分析翰舌，以及有什么樣的策略可以去實(shí)踐優(yōu)化滥酥，今天就來好好聊聊這個話題结啼。
[圖片上傳失敗...(image-1a670a-1694436567164)]
緣起
現(xiàn)代計(jì)算機(jī)是基于馮*諾依曼架構(gòu)的坎缭，計(jì)算機(jī)的軟件是運(yùn)行在內(nèi)存之中的白群，進(jìn)程（也即運(yùn)行中的程序）會耗費(fèi)一定的內(nèi)存尚胞，才能夠正常執(zhí)行。 在軟件開發(fā)的中世紀(jì)川抡，C和C++盛行的時代辐真，是由軟件開發(fā)人員（下稱猿）自己管理內(nèi)存，也就是說猿自己申請內(nèi)存崖堤，并處理申請不到內(nèi)存的情況侍咱，并在使用完成后自己負(fù)責(zé)釋放內(nèi)存，這無疑會加大程序開發(fā)難度密幔，產(chǎn)生一些難以調(diào)試的問題楔脯，如內(nèi)存越界或者內(nèi)存踩踏以及野指針。到了近現(xiàn)代胯甩，自動內(nèi)存管理成為主流昧廷，研發(fā)人員不再用自己去手動管理內(nèi)存了堪嫂，盡管用，可勁兒造木柬，一切由GC（也即是Garbage Collector內(nèi)存回收器）來善后皆串。
這極大的解放了研發(fā)人員的雙手，可以讓他們把更多的精力放在接收產(chǎn)品經(jīng)理的需求上面了眉枕，三天一小需求恶复，一周一大需求，產(chǎn)品迭代速度相當(dāng)快速挑，業(yè)務(wù)發(fā)展迅速谤牡，老板相當(dāng)高興啊，這干掉BAT指日可待姥宝，趕英超美就在明天翅萤，IPO觸手可及。然而腊满，現(xiàn)實(shí)是極其骨感的套么。
內(nèi)存問題會引發(fā)什么問題
對于安卓 應(yīng)用程序來說，內(nèi)存優(yōu)化很重要糜烹，因?yàn)镴ava VM本身就是比較耗資源的违诗，當(dāng)應(yīng)用復(fù)雜到一定程度的時候，就會出現(xiàn)由內(nèi)存使用不當(dāng)造成的問題疮蹦。如诸迟，測試同學(xué)反饋說應(yīng)用越用越卡，經(jīng)常crash愕乎，用戶也反饋說應(yīng)用越來越不好用了阵苇。老板把老猿叫進(jìn)辦公室一頓罵，然后老板讓老猿盡快來解決一下問題感论。
老猿只得把需求放一邊绅项，花時間看一看這些問題，然后說憑我多年經(jīng)驗(yàn)來看比肄，這怕是內(nèi)存出了問題快耿。
前面提過，現(xiàn)代編程語言一般都有GC芳绩，幫助研發(fā)人員管理內(nèi)存掀亥。但由于各種原因，還是會出現(xiàn)內(nèi)存相關(guān)的問題妥色。
特別是對于安卓猿來說搪花，實(shí)現(xiàn)應(yīng)用的編程語言是Java（準(zhǔn)確說是JVM，Java和Kotlin 以及像Scala都是基于JVM的編程語言），天生支持GC撮竿，導(dǎo)致很多人對內(nèi)存管理知之甚少吮便。當(dāng)應(yīng)用程序復(fù)雜到一定程度，當(dāng)源碼龐大到一定的量級時幢踏，性能問題髓需，特別是內(nèi)存性能問題便隨之而來。
具體可能是內(nèi)存出現(xiàn)問題的場景有：
- OOM導(dǎo)致的crash惑折。OOM授账，也即OutOfMemoryError，可能發(fā)生在任何地方惨驶，當(dāng)Heap中可用內(nèi)存不足時，便可能會遇到此類crash
- 應(yīng)用程序越用越慢敛助，出現(xiàn)黑屏或者白屏粗卜。
- UI操作出現(xiàn)卡頓，不流暢纳击。造成UI卡续扔，不流暢的原因很多，當(dāng)排除了其他原因時焕数，就是內(nèi)存問題了
- 應(yīng)用程序莫名閃退
內(nèi)存問題的具體類型及其原因
要想做好內(nèi)存優(yōu)化纱昧，則必須先弄懂內(nèi)存問題的根本原因，然后再對內(nèi)存問題進(jìn)行歸類堡赔，最后是通過技術(shù)手段來解決识脆。
內(nèi)存問題的根本原因
安卓應(yīng)用程序是由Java構(gòu)建的，而Java是支持GC的編程語言善已，所以安卓猿是不需要自己手動的去做內(nèi)存管理的灼捂，只管不停的創(chuàng)建對象即可，Java虛擬機(jī)（JVM）會幫助我們管理內(nèi)存换团，當(dāng)有不用的對象時會自動被GC悉稠。
但是Java應(yīng)用程序（當(dāng)然也包括安卓）還是會遇到內(nèi)存問題，主要是兩類艘包，一類是內(nèi)存不合理使用的猛，如內(nèi)存使用過多，頻繁創(chuàng)建大量對象想虎，內(nèi)存碎片等等卦尊；二是內(nèi)存泄漏。很多人會把二者混為一談磷醋，網(wǎng)絡(luò)上絕大多數(shù)文章一談性能優(yōu)化猫牡，一談內(nèi)存優(yōu)化，必然說到內(nèi)存泄漏邓线，但其實(shí)并不嚴(yán)謹(jǐn)淌友。內(nèi)存泄漏確實(shí)是最常見的內(nèi)存優(yōu)化內(nèi)容煌恢，也確實(shí)是內(nèi)存使用不合理的最常見問題，但內(nèi)存問題并不局限于內(nèi)存泄漏震庭。
內(nèi)存使用不合理
主要分為三個方面：
- 浪費(fèi)內(nèi)存瑰抵，簡單來理解就是用一個人住著一千平米的大平層
- 大量創(chuàng)建小對象，產(chǎn)生碎片器联，內(nèi)存碎片會造成JVM中的內(nèi)存管理效率變低二汛，當(dāng)后面申請大塊內(nèi)存的時候效率就變差，它需要把小對象（碎片）進(jìn)行轉(zhuǎn)移壓縮拨拓，以騰出更大的空間給大的對象使用肴颊。簡單理解，這個時候JVM的效率就會變差渣磷，你的應(yīng)用程序性能變差婿着，甚至可能引起卡頓。
- 頻繁創(chuàng)建對象醋界，特別是較大的對象竟宋，造成內(nèi)存抖動，也即應(yīng)用程序使用的內(nèi)存忽多忽少形纺，會頻繁的觸發(fā)GC丘侠，從而影響JVM的運(yùn)行效率。
[圖片上傳失敗...(image-3068a8-1694436567164)]
內(nèi)存泄漏
JVM是支持自動GC的逐样，也就是說JVM幫助你管理內(nèi)存蜗字，當(dāng)有不再使用的對象時，會被JVM自動回收官研，此稱之為GC（Garbage Collection）秽澳。但如果對象長期處于『使用』狀態(tài)，并且超出了它本應(yīng)該存的周期戏羽，無法被及時GC担神，這就會造成泄漏。一般來說始花，這也沒啥影響妄讯，但是如果泄漏的對象太多，或者泄漏的時間夠長酷宵，就會把系統(tǒng)配額Java Heap空間耗盡亥贸，應(yīng)用程序便會因沒有內(nèi)存創(chuàng)建對象而OOM，就會crash浇垦。即使沒有crash炕置，因?yàn)槭Ｓ嗫臻g較少，會頻繁觸發(fā)GC，從而導(dǎo)致應(yīng)用程序卡頓嚴(yán)重朴摊。
內(nèi)存泄漏的根本原因是對象的生命周期錯亂默垄，對象存活了超過了其本該的生命周期，或者簡言之甚纲，一個本該是較短的生命周期的對象被一個更長生命周期的對象所引用著口锭，就會導(dǎo)致它本該生命周期結(jié)束時無法被GC，便產(chǎn)生了泄漏介杆。
這是要重點(diǎn)關(guān)注對象的生命周期鹃操，只有管理好了對象的生命周期，才能徹底的解決內(nèi)存泄漏問題春哨。
安卓應(yīng)用中的生命周期
固定生命周期的對象
安卓應(yīng)用程序里面荆隘，有一些是有固定生命周期的，或者說有明顯生命周期悲靴，且不是由研發(fā)人猿自己控制的臭胜，如框架層控制的那一坨東西。
- Activity
- Fragment
- View
特別是Activity癞尚，它也是內(nèi)存泄漏的頭號對象，90%的內(nèi)存泄漏都是Activity對象乱陡。這貨完全由系統(tǒng)框架控制浇揩，并且有明顯的生命周期，而且還有重建實(shí)例的情況（涉及狀態(tài)恢復(fù)時）憨颠，所以它的生命周期其實(shí)相當(dāng)短暫胳徽，并且它跟進(jìn)程和主線程沒有任何關(guān)系，Activity退出 了（走了onDestroy）進(jìn)程仍還在爽彤，主線程也仍還在养盗。而，又因?yàn)樗菓?yīng)用程序的第1級入口适篙，應(yīng)用程序所有的對象往核，以及GUI所有的東西，全部都由Activity直接或者間接持有嚷节，換句話說聂儒，Activity泄漏了，你整個應(yīng)用程序的對象也基本上全泄漏了硫痰。
較長生命周期對象
這里所謂的長生命周期衩婚，是指它們的生命周期是與進(jìn)程綁定的，除非進(jìn)程退出效斑，或者明顯的執(zhí)行一些退出非春，否則一直隨進(jìn)程而存在：
- Looper，或者說消息隊(duì)列，這玩意兒除非主動quit奇昙，否則一直存在护侮。主線程的Looper與進(jìn)程同在，自己創(chuàng)建的Looper要手動退出才算終結(jié)敬矩。
- 被static修飾的成員變量概行，這東西的生命周期是跟進(jìn)程一樣的
- 單例，單例必須由static來修飾弧岳，所以與進(jìn)程生命周期是一樣的凳忙，進(jìn)程在，則單例在
- 線程池禽炬，或者一個長時間運(yùn)行的thread涧卵，除非主動去shutdown
- RxJava的Schedulers饿幅，這玩意跟looper一樣拙泽，都是長時間運(yùn)行的消息隊(duì)列哑蔫，且與進(jìn)程綁定的
- 系統(tǒng)框架傍药，手機(jī)還在開機(jī)系統(tǒng)框架就在運(yùn)行慧脱，所以它的生命周期遠(yuǎn)遠(yuǎn)長于某一個應(yīng)用程序
- Application和ApplicationContext玄帕，這東西與進(jìn)程生命周期是一樣的晚树，相當(dāng)于單例了
業(yè)務(wù)邏輯中的生命周期
業(yè)務(wù)邏輯就純屬于應(yīng)用程序的本身邏輯了灸拍，無法一概而論绎巨，但一般來說近尚，主頁面的生命周期肯定是長于某個子頁面的。那么子頁面在其退出后场勤，理論上它的絕大多數(shù)對象應(yīng)該要被回收戈锻。
如何發(fā)現(xiàn)內(nèi)存問題
生活中不是缺少美，而是缺少發(fā)現(xiàn)和媳。
對于內(nèi)存優(yōu)化格遭，第一步就是要通過各種測試手段發(fā)現(xiàn)問題。最理想的情況是建立一種監(jiān)控手段留瞳，這樣最能保住革命果實(shí)拒迅，以及非常及時的發(fā)現(xiàn)問題。
這里指的是一般性的粗略手段來發(fā)現(xiàn)你的應(yīng)用有內(nèi)存問題了撼港，可能需要優(yōu)化了坪它。并且這些測試方法最好能做成定期監(jiān)控，這樣一旦內(nèi)存性能有回撤時帝牡，能盡快發(fā)現(xiàn)往毡。
『隊(duì)長，我們暴露了』
很多時候都是問題主動找上門來了靶溜。
前方有雷區(qū)
很不幸开瞭，你的應(yīng)用程序中彈身亡（crash了）懒震，還是OOM。這是Java語言中的一個運(yùn)行時的錯誤嗤详，可能在創(chuàng)建任何對象時發(fā)生个扰，但一般來說創(chuàng)建比較大的對象時，這里的大是指對內(nèi)存需求大葱色，如圖片递宅，或者大塊數(shù)組時，更容易發(fā)生苍狰。
當(dāng)你的應(yīng)用程序出現(xiàn)了OOM的時候办龄，就是一個特別明顯的信號，告訴你要重視內(nèi)存優(yōu)化了淋昭。
遇到終結(jié)者了俐填，是lowmemorykiller
有時候，沒有明顯的錯誤翔忽，但是應(yīng)用卻閃退了英融，特別是在后臺，或者跳到其他應(yīng)用頁面時歇式。
這個會比較隱蔽驶悟，通常會引發(fā)其他表象的問題。最明顯的問題就是材失，當(dāng)跳轉(zhuǎn)到其他頁面撩银，再返回時，發(fā)現(xiàn)原來的頁面狀態(tài)不存在了豺憔，比如你的應(yīng)用要訪問一個URL，跳轉(zhuǎn)到了網(wǎng)頁瀏覽器够庙，但從瀏覽器返回時恭应，要么你的應(yīng)用不在了，要么你的應(yīng)用的原先狀態(tài)不在了耘眨。這其中的原因就是當(dāng)你的應(yīng)用不在前臺了昼榛，就被系統(tǒng)回收了，其中一個占大頭的原因就是占用內(nèi)存太多剔难，被系統(tǒng)的lmkd（lowmemorykiller）干掉了胆屿。
因?yàn)橄到y(tǒng)要保證整個設(shè)備的正常運(yùn)轉(zhuǎn)，所以會把占用內(nèi)存太多的先殺掉偶宫，以釋放內(nèi)存非迹。
當(dāng)你的應(yīng)用頻繁的遇到被lowmemory killer干掉時，也是一個明顯的信號纯趋，要重視內(nèi)存優(yōu)化了憎兽。
讀懂系統(tǒng)GC日志
有些時候不像前面那樣嚴(yán)重冷离，但是查看logcat日志時，能發(fā)現(xiàn)大量的GC日志纯命，就像這樣的
<pre class="custom" data-tool="mdnice編輯器" style="margin-top: 10px; margin-bottom: 10px; border-radius: 5px; box-shadow: rgba(0, 0, 0, 0.55) 0px 2px 10px; text-align: left;">259857:01-08 20:00:17.836 10083 26337 26347 I test.test: NativeAlloc concurrent copying GC freed 141174(6852KB) AllocSpace objects, 29(12MB) LOS objects, 49% free, 24MB/48MB, paused 180us total 308.126ms 279178:01-08 20:00:19.618 10083 26337 26347 I test.test: Background young concurrent copying GC freed 469755(20MB) AllocSpace objects, 40(3608KB) LOS objects, 41% free, 28MB/48MB, paused 396us total 124.817ms </pre>
這是系統(tǒng)在進(jìn)行GC西剥，通常來說這沒有什么問題。但如果在短時間內(nèi)亿汞，比如某個頁面瞭空，點(diǎn)了某個按扭后大量出現(xiàn)此類日志，也是一個明顯的信號疗我，告訴你要重視內(nèi)存優(yōu)化了咆畏。
主動出擊，以攻為守
作為一個優(yōu)秀的猿碍粥，不能坐著等問題上來鳖眼，要能主動的去創(chuàng)造問題。每當(dāng)完成一個需求后嚼摩，或者寫了一大坨代碼以后钦讳，就需要主動的去查看一下內(nèi)存方面是否有需要優(yōu)化的地方。我們可以通過如下測試方法枕面，來看內(nèi)存是否有問題愿卒，是否需要做優(yōu)化。重點(diǎn)就是看應(yīng)用程序在一定時間內(nèi)潮秘，使用的內(nèi)存是否一直在增長琼开， 有沒有抖動，并且在GC后枕荞，或者退出 后是否仍不回落柜候。
meminfo
具命令是adb shell dumpsys meminfo <package>，這個命令還是比較常見的躏精，網(wǎng)上有很多資料可以用渣刷，可以看后面羅列的參考文章中來詳細(xì)了解它的具體用法以及各個字段的意義，這里就重復(fù)了矗烛。</package>
需要關(guān)注一下重點(diǎn)辅柴，就是，可以重點(diǎn)看Java Heap一欄的數(shù)據(jù)變化瞭吃，這是Java層的占用內(nèi)存情況碌嘀。另外就是每次運(yùn)行meminfo其實(shí)會對進(jìn)程產(chǎn)生影響。所以歪架，這個命令可以用來粗維度的監(jiān)控股冗，查看一些信息，做一些定性的分析牡拇。
它最大的優(yōu)點(diǎn)是方便魁瞪，且只要是進(jìn)程都可以查看穆律，不用有源碼。
Android Studio的Memory Profiler
在遠(yuǎn)古時代安卓SDK中會有DDMS导俘，里面是一套調(diào)試工具峦耘，但現(xiàn)在都集成到Android Studio的Profiler里面了，通常會在下方的工具欄里面旅薄，如果 沒有就到菜單View->Tools Window->Profiler把它調(diào)出來辅髓。然后選擇要調(diào)試的進(jìn)程，默認(rèn)它會把CPU少梁，Network洛口，Memory和功耗都顯示，這里可以雙擊Memory那一坨凯沪，就會進(jìn)入專門的內(nèi)存頁面第焰。
[圖片上傳失敗...(image-10206f-1694436567164)]
它會以時間軸的方式來圖形化的展示內(nèi)存使用情況，非常的直觀和方便妨马。通過這個可以直觀的看到兩個問題挺举，就是嫌疑內(nèi)存泄漏以及內(nèi)存抖動。
嫌疑內(nèi)存泄漏就是看到曲線一直在增長烘跺，且通過顯示GC湘纵，或者退出后，或者停止某項(xiàng)目操作后滤淳，仍不回落的梧喷，這就非常有可能有泄漏的存在，泄漏是超出了它本該的生命周期脖咐，比如某一操作結(jié)束了铺敌，退出 了某一頁面，甚至退出應(yīng)用了屁擅，內(nèi)存仍沒有回落适刀，就可能有問題。
另外就是內(nèi)存抖動煤蹭，就是能看到內(nèi)存曲線 有毛刺，短時間內(nèi)忽上忽下的取视，這就是內(nèi)存抖動硝皂。
leakcanary
這貨也是非常流行的，專門用于檢測內(nèi)存泄漏的工具作谭，它的功能較為強(qiáng)大稽物，除了可以監(jiān)控以外，還可以給出詳細(xì)的trace折欠。具體使用可以參考官方的文檔贝或，并不難吼过。
但它最大的問題在于，必須參與項(xiàng)目構(gòu)建咪奖。假如你想研究一下競品的情況盗忱，就沒有辦法了。
如何調(diào)試內(nèi)存問題
通過前面提到的手段羊赵，我們可以發(fā)現(xiàn)內(nèi)存有一些問題了趟佃，需要進(jìn)行內(nèi)存方面的優(yōu)化了，但這還不夠昧捷，還需要一些精細(xì)化的調(diào)試方法來具體定位問題闲昭，這樣才能更好的去進(jìn)行優(yōu)化。
那么有哪些具體的調(diào)試方法呢靡挥？
Allocation tracer
這個是前面提到的Android Studio Profier里面的工具序矩。用Profiler可以發(fā)現(xiàn)問題，但還需要進(jìn)一步的深入的分析問題跋破。這就需要Allocation tracer了簸淀。
具體做法就是，當(dāng)你發(fā)現(xiàn)某一系列操作后內(nèi)存一直增長幔烛，或者看到有抖動現(xiàn)象時啃擦，就可以抓取這段時間的Heap dump，然后詳細(xì)分析饿悬，現(xiàn)在Android Studio都集成好了令蛉，只需要點(diǎn)幾下，就能抓到狡恬，并把結(jié)果列出來珠叔，可以看到具體創(chuàng)建哪些對象，以及它們的引用關(guān)系是怎樣的弟劲。
可以參考 以下資源來詳細(xì)了解如何使用此工具：
- The Android Profiler
- Inspect your app's memory usage with Memory Profiler
- Android 內(nèi)存優(yōu)化篇 - 使用profile 和 MAT 工具進(jìn)行內(nèi)存泄漏檢測
MAT
這是專門用于Java heap內(nèi)存分析的工具祷安，相當(dāng)強(qiáng)大。但不能直接使用兔乞。
需要先想辦法抓取進(jìn)程的heap dump汇鞭，然后轉(zhuǎn)換為Java標(biāo)準(zhǔn)的格式（因?yàn)榘沧康腍eap與Java SE的并不一樣，安卓 SDK中有轉(zhuǎn)換工具）庸追，然后再用MAT打開即可霍骄，它的功能要遠(yuǎn)強(qiáng)大于前面的提到的Allocation tracer。所以淡溯，如果要深度的分析和優(yōu)化读整，還是要用MAT。
關(guān)于MAT的具體使用方法咱娶，可以參考以下資源：
leakcanary
除了能監(jiān)控以外米间，它還能分析具體的內(nèi)存泄漏强品，并給出trace，所以當(dāng)發(fā)現(xiàn)問題后屈糊，具體定位問題的時候的榛，也可以使用此工具，還是相當(dāng)強(qiáng)大的另玖。
它的使用相當(dāng)簡單困曙，直接把它加入到dependencies，然后構(gòu)建 就好了谦去。
至于它的分析結(jié)果也是相當(dāng)直觀的慷丽，會以Notification的方式通知你，點(diǎn)開后有一個頁面展示出引用關(guān)系鏈鳄哭，然后判斷是否是泄漏要糊，即可。
詳細(xì)可以參閱它的官方文檔就可以了妆丘。
如何優(yōu)化內(nèi)存
內(nèi)存優(yōu)化锄俄，一大半在于測試，監(jiān)控和調(diào)試分析勺拣，約占70%奶赠，這部分是重頭，因?yàn)橹挥姓业骄唧w的代碼位置药有，才好去修復(fù)問題毅戈，并且修復(fù)后還要驗(yàn)證問題是否真的修復(fù)了。不能光在那里看代碼愤惰，想當(dāng)然的認(rèn)為把幾個內(nèi)部類改為static苇经，或者傳遞引用了ApplicationContext，就能優(yōu)化了內(nèi)存宦言。
對于性能優(yōu)化扇单，當(dāng)然也包括內(nèi)存優(yōu)化，必須用測試手段進(jìn)行量化奠旺，以此來驗(yàn)證是否真有有改善蜘澜。
本節(jié)內(nèi)容，假設(shè)已通過前面提到的測試方法發(fā)現(xiàn)了內(nèi)存問題响疚，并通過調(diào)試手段定位到了具體位置兼都。優(yōu)化的手段也要針對 具體的問題來進(jìn)行：
避免內(nèi)存泄漏
內(nèi)存優(yōu)化的大頭是要避免泄漏，所以重點(diǎn)來談?wù)勅绾伪苊鈨?nèi)存泄漏稽寒。
前面提到了，內(nèi)存泄漏的根本原因是生命周期混亂趟章，較長生命周期的對象杏糙，甚至是超長生命周期的對象慎王，持有了較短生命周期的對象，這一定會導(dǎo)致泄漏宏侍。所以赖淤，要想真的解決內(nèi)存泄漏問題，必須設(shè)計(jì)好對象的生命周期谅河，這是根本解決之法咱旱。
要盡可能的，縮小對象的生命周期
對象的生周期不應(yīng)該超出它本該存在的范圍绷耍，并且應(yīng)該盡可能的減少對象的生命周期吐限，這個可能在設(shè)計(jì)階段考慮到。但一般較難執(zhí)行褂始，代碼復(fù)雜了诸典，很難控得住。
對于超過Activity生命周期的對象要及時清理
前面提到過的超長生命周期的東西崎苗，如Looper狐粱，如Frameworks，如單例胆数，如RxJava的Schedulers肌蜻，如線程池，這些東西的生命周期遠(yuǎn)長于Activity必尼，所以蒋搜，一定要在對應(yīng)的地方，及時清除對Activity的引用持有胰伍。
后面的參考 資料里面也有大量的實(shí)用建議可以參考齿诞，這里就不重復(fù)了。避免內(nèi)存泄漏應(yīng)該要被總結(jié)成為編程規(guī)范骂租，然后在團(tuán)隊(duì)內(nèi)部推行祷杈，當(dāng)然也可以設(shè)計(jì)一些源碼靜態(tài)檢測工具，來強(qiáng)制執(zhí)行渗饮。當(dāng)然但汞，再好的工具和規(guī)范也需要人來遵守，任何事情能夠在編碼階段防止發(fā)生互站，成本是最小的私蕾，收益 是最大的。
WeakReference和SoftReference不是救命稻草
千萬不要用WeakReference和SoftReference這東西來修復(fù)內(nèi)存泄漏問題胡桃，它們根本就不是用來修復(fù)內(nèi)存泄漏問題的踩叭。
再說一遍，內(nèi)存泄漏是由生命周期混亂造成的。
如果強(qiáng)行使用WeakReference來代替原來的強(qiáng)引用容贝，就會造成想使用對象的時候它卻被回收了自脯，這時你的正常邏輯就沒法走了，而且如何正確的處理這種異常case斤富，也是很難恰當(dāng) 的處理的膏潮。
WeakReference這東西最最合理，最為適合的場景就是緩存里面满力，也就是說它本身是用于一種可有可無的引用關(guān)系焕参，這樣一旦被GC了，也不會影響原有邏輯油额，因?yàn)閷ο蟊緛砭涂赡茉冢–ache Hit）叠纷，也可能不在緩存里面（Cache Miss），使用者必須處理在或者不在兩種case悔耘。因?yàn)榫彺娴那謇砜赡懿粔蚣皶r（必須由編碼人員手動設(shè)置條件去清理讲岁，比如在退出的時候），當(dāng)JVM需要GC時衬以，因?yàn)槎际荳eakReference缓艳，GC就可以快速的回收對象釋放內(nèi)存。
不要到處給對象引用置為null
很多有過C++經(jīng)驗(yàn)的同學(xué)看峻，可能會習(xí)慣在對象使用完成后阶淘，手動把對象置為null。但其實(shí)這是完全沒有必要的互妓，只會造成不必要的混亂溪窒，JVM會自己去追蹤每個對象，它到底還有沒有被引用持有著冯勉。我們要把精力重點(diǎn)放在對象生命周期的把控上面澈蚌，簡單的置為null，不會縮減對象的生命周期灼狰，所以它對解決和防止泄漏方面沒有任何幫助宛瞄。
內(nèi)存使用優(yōu)化方式
除了避免內(nèi)存泄漏，其他一些方式也是有很多技術(shù)可以用于優(yōu)化的交胚。
減少內(nèi)存浪費(fèi)
內(nèi)存浪費(fèi)份汗，就是使用了沒必要的內(nèi)存，雖然可能不會引發(fā)問題蝴簇，但是還是會增加風(fēng)險杯活，比如同樣都是后臺進(jìn)程，你的應(yīng)用占用內(nèi)存稍大了一些熬词，被殺的風(fēng)險就高了一些旁钧。
減少內(nèi)存浪費(fèi)吸重，核心的方法就是按需申請，特別像圖片這種內(nèi)存占用大戶歪今，一定要按需要來加載晤锹，何為需要就是目標(biāo)View的大小，具體可以看官方教程Loading Large Bitmaps Efficiently彤委。以及盡可能的要復(fù)用bitmap。
再如資源圖片或衡，設(shè)置合理的分辨率焦影，沒有必要啥都上高清，且要為低精度設(shè)備提供單獨(dú)的一套資源封断。
以及像不是要求那么清晰的場景就用RGB_565斯辰，而非RGBA_8888等等，這些都是在編碼的時候就可以提高內(nèi)存使用的方法坡疼。
使用緩存
緩存是計(jì)算機(jī)史上最偉大的發(fā)明彬呻，甚至是人類史上最偉大的發(fā)明，它無處不在從硬件到軟件都會使用緩存柄瑰，并且它在各種東西的設(shè)計(jì)之中都是很重要的一部分闸氮。
前面提到的內(nèi)存抖動問題，就需要用緩存來解決教沾，以避免頻繁創(chuàng)建對象蒲跨。特別是涉及圖片的場景，比如流行的圖片加載開源庫里面都有專門的緩存的機(jī)制授翻，有些是二級或悲，有些是三級。當(dāng)需要設(shè)計(jì)緩存時堪唐，可以重點(diǎn)參考圖片加載庫中的緩存設(shè)計(jì)巡语。
另外，SDK中也有標(biāo)準(zhǔn)的緩存組件可以用淮菠，LruCache男公，這是針對內(nèi)存層面的緩存，可以看這篇文章來詳細(xì)了解使用方法兜材。
合理復(fù)用對象
這里的意思是使用像享元這樣的設(shè)計(jì)模式理澎，來合理的復(fù)用對象。
需要注意的是享元(Flyweight Pattern)的適用場景曙寡，它適用于創(chuàng)建對象的成本較高糠爬，比如創(chuàng)建對象需要的一些資源較昂貴，不同的對象僅是有不同的屬性举庶，或者說對象本身在使用的時候的表現(xiàn)是不同的执隧。
一個典型的例子就是繪圖的形狀，比如一個頁面有大量的不同的形狀需要繪制，有方的镀琉，有圓的峦嗤，有白色的，有彩色的屋摔，有實(shí)邊的有虛線的烁设。常規(guī)的思路是一個基類叫Shape，里面有各種屬性钓试，還有一個draw方法装黑，子類可以定義不同的屬性，各自實(shí)現(xiàn)draw方法弓熏。然后根據(jù)需求創(chuàng)建一大坨具體的對象恋谭，遍歷調(diào)用draw方法。這是面向?qū)ο缶幊蹋∣OP）中的非常標(biāo)準(zhǔn)的多態(tài)（Polymophsim）挽鞠。事實(shí)上疚颊，你只需要創(chuàng)建一個對象就夠了，它會根據(jù)不同的屬性畫出不同的效果信认。這就是設(shè)計(jì)模式中的享元模式材义，具體可以參考這篇文章來詳細(xì)了解。
認(rèn)識幾種不同的內(nèi)存類型
通過各種工具查看的內(nèi)存時狮杨，如通過meminfo以及像Memory profiler母截，但可以發(fā)現(xiàn)有不同種類，需要重點(diǎn)關(guān)注以幾種：
Java Heap
也即通常意義上的heap內(nèi)存（堆內(nèi)存）橄教，名字可能會是Java清寇，Java Heap，或者Java allocate护蝶，但都是一樣就是指純Java代碼中通過new創(chuàng)建對象時使用的內(nèi)存华烟。
Native Heap
因?yàn)镴ava是支持JNI與C/C++接通，也即native方法持灰，那么通過native方法創(chuàng)建的對象是計(jì)算在Native之中的盔夜，它與Java層是分開的，當(dāng)然通過native方法（malloc或者new）創(chuàng)建的對象堤魁，要記得去釋放喂链，否則是一定會泄漏的。
因?yàn)锳ndroid的大部分是由C/C++實(shí)現(xiàn)的妥泉，Java層僅是封裝椭微，F(xiàn)rameworks層大部分功能都由JNI轉(zhuǎn)到native層去實(shí)現(xiàn)的，因此native這部分的內(nèi)存也是很多的盲链，并且由于Frameworks本身會大量調(diào)用JNI native層蝇率，所以即使你的應(yīng)用程序根本沒有用到JNI迟杂，但是還是會看到Native內(nèi)存使用。
Graphics
主要是涉及OpenGL ES的相關(guān)內(nèi)存占用本慕，如GL Surfaces排拷，如Texture或者如Framebuffer等，它們所占用的內(nèi)存锅尘。
這里需要特別注意的是监氢，即使你的應(yīng)用沒有用到OpenGL相關(guān)的東西，但仍可能會有此部分內(nèi)存占用藤违，這是由于硬件加速本身也是通過OpenGL ES實(shí)現(xiàn)的忙菠。
ion內(nèi)存
這個是為了效率，直接從kernel層開出shared buffer纺弊，以加速內(nèi)存使用效率，這個是偏底層的骡男，大部分普通app是用不到的淆游。
可以參考一下這個The Android ION memory allocator。
共享內(nèi)存
可以理解為Linux中的匿名共享內(nèi)存隔盛，可以用來實(shí)現(xiàn)IPC通信犹菱，但它并不會被Profiler計(jì)算在Java或者Native里面。非死不可出品的Fresco當(dāng)初牛逼的地方就在于把Bitmap放在匿名共享內(nèi)存里面吮炕，從而不占用應(yīng)用自己的Heap空間腊脱。
可以參考這兩個文章：
學(xué)無止境
深入學(xué)習(xí)GC相關(guān)知識，如JVM的GC如何演進(jìn)龙亲。
也可以學(xué)習(xí)一下其他編程語言的GC機(jī)制陕凹。
不要過早優(yōu)化，更不能過度優(yōu)化
性能優(yōu)化這個事情是要在架構(gòu)設(shè)計(jì)和產(chǎn)品設(shè)計(jì)階段就需要考慮的事情鳄炉，比如是否要加入緩存杜耙。
但如果前期想太多，會造成嚴(yán)重的扭曲拂盯，會讓你陷入無限的復(fù)雜問題里面佑女，難以自拔（本是問題1，但是變成了問題A谈竿，問題B团驱，直到問題z，最初的問題1卻被忽略了）空凸，反倒不是好事情嚎花。
最為想理的情況就是小步迭代，先提出能滿足需求的最小版本劫恒，然后逐步迭代贩幻。比如說做一個新的feature的時候轿腺，先用最簡單的架構(gòu)和設(shè)計(jì)來實(shí)現(xiàn)，然后考慮補(bǔ)充細(xì)節(jié)丛楚，處理異常case族壳，再考慮可能的擴(kuò)展，然后考慮性能優(yōu)化趣些。
剩下的是態(tài)度
不是說一線開發(fā)的態(tài)度仿荆，而是老板們的態(tài)度。
[圖片上傳失敗...(image-6a32ff-1694436567163)]
性能問題是直接影響體驗(yàn)坏平，所以只有重視體驗(yàn)的老板才會重視性能問題拢操。而且這也不是研發(fā)猿的問題，需要測試舶替，產(chǎn)品經(jīng)理都要能重視性能問題令境，才能最終把性能做好。產(chǎn)品同學(xué)不能只顧著提需求顾瞪，也要平衡性能舔庶，并且給研發(fā)同學(xué)一定的時間去注重性能問題，而測試同學(xué)更加重要陈醒，需要不斷精進(jìn)你的測試方法惕橙，幫助研發(fā)同學(xué)更好的解決問題，并且要有監(jiān)控手段钉跷，比如說A版本做了性能優(yōu)化專項(xiàng)弥鹦，那么為了保留革命果實(shí)，需要有一種監(jiān)控手段爷辙，以防性能出現(xiàn)重大回撤彬坏。
很多事情不能怪研發(fā)，就像有一位技術(shù)相當(dāng)不錯的同事說過的話膝晾，當(dāng)時大家聊起性能優(yōu)化的事情苍鲜，他說：『道理大家都懂，但當(dāng)左邊是產(chǎn)品經(jīng)理在那里催需求玷犹，右邊是設(shè)計(jì)師在那說按扭還差幾個象素混滔，測試同學(xué)在那崔你趕緊發(fā)版本啊，我還等著測完回家呢歹颓！當(dāng)你處在這種條件下坯屿，誰TMD的還管性能啊，先實(shí)現(xiàn)了再說吧巍扛，甚至代碼格式都懶得改了领跛。』
所以撤奸，這是整個工程體系的事情吠昭，只有整個研發(fā)體系都注重性能喊括，性能才會好，體驗(yàn)才會好矢棚，而這就需要一個老板的支持了郑什，否則，性能不可能好蒲肋，產(chǎn)品汪們只顧著提需求蘑拯，設(shè)計(jì)師只顧著畫面精美，研發(fā)同學(xué)光實(shí)現(xiàn)需求都做不完兜粘，哪有精力去搞性能吧昃健！測試同學(xué)也不能只用粗淺的測試方法孔轴，只說性能不好剃法，具體哪不好，不應(yīng)該都讓研發(fā)自己去調(diào)試路鹰，去發(fā)現(xiàn)問題玄窝。另外，也需要做好性能監(jiān)控機(jī)制悍引，以保住革命果實(shí)。要不然帽氓，A版本辛辛苦苦搞了一輪性能優(yōu)化趣斤，也有大幅改善，然后到了B版本黎休，或者幾個月后浓领，再來一輪。
這就是很骨感的現(xiàn)實(shí)势腮。所以联贩，在現(xiàn)實(shí)生活中只有大廠頭部應(yīng)用 才真的重視性能和體驗(yàn)，并且才能把性能和體驗(yàn)做好捎拯。
參考資料
- Overview of memory management
- Profile your app performance
- Android內(nèi)存管理機(jī)制
- 最全的Android內(nèi)存優(yōu)化技巧
- Android性能優(yōu)化之內(nèi)存優(yōu)化
- 深入探索Android內(nèi)存優(yōu)化
- Android性能優(yōu)化之內(nèi)存優(yōu)化
- 深入探索 Android 內(nèi)存優(yōu)化（煉獄級別-上）
- 深入探索 Android 內(nèi)存優(yōu)化（煉獄級別-下）
- 內(nèi)存優(yōu)化深入版
- Dealing with Large Memory Requirements on Android
