image

轉(zhuǎn)換后的理解：單進(jìn)程場(chǎng)景掠抬，Activity被回收只可能是因?yàn)檫M(jìn)程被系統(tǒng)回收了。

感覺(jué)不太對(duì)校哎？因?yàn)樵诤芫靡郧傲讲ǎ龅竭^(guò)這樣一個(gè)場(chǎng)景：

App打開(kāi)多個(gè)Activity，然后手機(jī)晾一邊闷哆，過(guò)一段時(shí)間后(屏幕常亮)踩叭，點(diǎn)擊回退，之前的Activity空白采记，然后重新加載了螃概。

image

App在前臺(tái)，不在棧頂?shù)腁ctivity卻被干掉屈留，但進(jìn)程還健在局冰，如果真是這樣，就和上面的理解有些出入了灌危。

立馬寫(xiě)個(gè)代碼驗(yàn)證下康二，大概流程如下：

寫(xiě)個(gè)父類Activity，生命周期回調(diào)加日志打印勇蝙，接著打開(kāi)一個(gè)Activity沫勿，包含一個(gè)按鈕，點(diǎn)擊后依次打開(kāi)多個(gè)Activity味混，最后一個(gè)加個(gè)按鈕产雹，點(diǎn)一下就申請(qǐng)一個(gè)大一點(diǎn)的ByteArray來(lái)模擬內(nèi)存分配，看內(nèi)存不足時(shí)是否會(huì)回收Activity翁锡。

測(cè)試結(jié)果如下：

image

App寧愿OOM蔓挖，也不愿意回收Activity，鬼使神差地加上 android:largeHeap="true" 盗誊，結(jié)果一樣时甚。

em...難道是我記錯(cuò)了隘弊？？荒适？

等等＠嫖酢！刀诬！我好像混淆了兩個(gè)東西：系統(tǒng)可用內(nèi)存不足 和 應(yīng)用可用內(nèi)存不足咽扇。

0x1、系統(tǒng)可用內(nèi)存不足

LMK機(jī)制

Android系統(tǒng)中陕壹，進(jìn)程的生命周期由系統(tǒng)控制质欲，處于體驗(yàn)和性能考慮，在APP中點(diǎn)擊Home鍵或Back回退操作糠馆，并不會(huì)真的殺掉APP嘶伟，進(jìn)程依舊存在于內(nèi)存中，這樣下次啟動(dòng)此APP時(shí)就能更加快速又碌。隨著系統(tǒng)運(yùn)行時(shí)間增長(zhǎng)九昧，打開(kāi)APP越來(lái)越多，內(nèi)存中的進(jìn)程隨著增多毕匀，系統(tǒng)的可用內(nèi)存會(huì)越來(lái)越少铸鹰。咋辦，總不能讓用戶自己去殺進(jìn)程吧皂岔，所以系統(tǒng)內(nèi)置一套 回收機(jī)制蹋笼，當(dāng)系統(tǒng)可用內(nèi)存達(dá)到一個(gè) 閾值，系統(tǒng)會(huì)根據(jù) 進(jìn)程優(yōu)先級(jí) 來(lái)殺掉一部分進(jìn)程躁垛，釋放內(nèi)存供后續(xù)啟動(dòng)APP使用剖毯。

Android的這套回收機(jī)制，是基于Linux內(nèi)核的OOM規(guī)則改進(jìn)而來(lái)的缤苫，叫 Low Memory Killer速兔，簡(jiǎn)稱 LMK。

閾值 & 殺誰(shuí)

通過(guò)下述兩個(gè)文件配合完成活玲，不同手機(jī)數(shù)值可能不同，以我的老爺機(jī) 魅藍(lán)E2 為例 (Android 11的Mix2S一直說(shuō)沒(méi)權(quán)限打開(kāi)此文件)：

# /sys/module/lowmemorykiller/parameters/minfree
# 單位：Page頁(yè)谍婉，1Page = 4KB
18432,23040,27648,46080,66560,97280

# /sys/module/lowmemorykiller/parameters/adj
0,58,117,176,529,1000 

Android系統(tǒng)會(huì)為每個(gè)進(jìn)程維護(hù)一個(gè) adj(優(yōu)先級(jí))：

• Android 6及以前稱為：oom_adj舒憾，值范圍：[-17,16]，LMK要換算*1000/17

• Android 7后稱為：oom_score_adj穗熬，值范圍：[-1000,1000]

然后镀迂，上面兩個(gè)文件的值，其實(shí)是以一一對(duì)應(yīng)的唤蔗，比如：

66560 * 4 / 1024 = 260MB → 當(dāng)系統(tǒng)可用內(nèi)存減少到260MB時(shí)探遵，會(huì)殺掉adj值大于529的進(jìn)程窟赏；
18432 * 4 / 1024 = 72MB → 當(dāng)系統(tǒng)可用內(nèi)存減少到72MB，殺掉ajd值大于0的進(jìn)程箱季； </pre>

adj怎么看

直接通過(guò)命令行查看：

image

可以看到涯穷，adj是動(dòng)態(tài)變化的，當(dāng)App狀態(tài)及四大組件生命周期發(fā)生改變時(shí)藏雏，都會(huì)改變它的值拷况。常見(jiàn)ADJ級(jí)別如下：

• NATIVE_ADJ → -1000，init進(jìn)程fork出來(lái)的native進(jìn)程掘殴，不受system管控赚瘦；

• SYSTEM_ADJ → -900，system_server進(jìn)程奏寨；

• PERSISTENT_PROC_ADJ → -800起意，系統(tǒng)persistent進(jìn)程，一般不會(huì)被殺病瞳，殺了或者Carsh系統(tǒng)也會(huì)重新拉起杜恰；

• PERSISTENT_SERVICE_ADJ → -700，關(guān)聯(lián)著系統(tǒng)或persistent進(jìn)程仍源；

• FOREGROUND_APP_ADJ → 0心褐，前臺(tái)進(jìn)程；

• VISIBLE_APP_ADJ → 100笼踩，可見(jiàn)進(jìn)程逗爹；

• PERCEPTIBLE_APP_ADJ → 200，可感知進(jìn)程嚎于，比如后臺(tái)音樂(lè)播放掘而；

• BACKUP_APP_ADJ → 300，執(zhí)行bindBackupAgent()過(guò)程的備份進(jìn)程于购；

• HEAVY_WEIGHT_APP_ADJ → 400袍睡，重量級(jí)進(jìn)程，system/rootdir/init.rc文件中設(shè)置肋僧；

• SERVICE_ADJ → 500斑胜，服務(wù)進(jìn)程；

• HOME_APP_ADJ → 600嫌吠，Home進(jìn)程止潘，類型為ACTIVITY_TYPE_HOME的應(yīng)用，如Launcher辫诅；

• PREVIOUS_APP_ADJ → 700凭戴，用戶上一個(gè)使用的App進(jìn)程；

• SERVICE_B_ADJ → 800炕矮，B List中的Service么夫；

• CACHED_APP_MIN_ADJ → 900者冤，不可見(jiàn)進(jìn)程 的adj最小值；

• CACHED_APP_MAX_ADJ → 906档痪，不可見(jiàn)進(jìn)程的adj最大值涉枫；

• UNKNOWN_ADJ → 1001，一般指將要會(huì)緩存進(jìn)程钞它，無(wú)法獲取確定值拜银；

關(guān)于ADJ計(jì)算的詳細(xì)算法分析可見(jiàn)Gityuan大佬的：《解讀Android進(jìn)程優(yōu)先級(jí)ADJ算法》，干貨多多遭垛，順帶從總結(jié)處撈一波進(jìn)程蹦嵬埃活伎倆：

• UI進(jìn)程與Service進(jìn)程分離，包含Activity的Service進(jìn)程锯仪，一進(jìn)后臺(tái)ADJ>=900泵督，隨時(shí)可能被系統(tǒng)回收，分離的話ADJ=500庶喜，被殺的可能性降低小腊，尤其是系統(tǒng)允許自啟動(dòng)的服務(wù)進(jìn)程，必須做UI分離久窟，避免消耗較大內(nèi)存秩冈；

• 真正需要用戶可感知的應(yīng)用，調(diào)用startForegroundService()啟用前臺(tái)服務(wù)斥扛，ADJ=200;

• 進(jìn)程中的Service工作完入问，務(wù)必主動(dòng)調(diào)用stopService或stopSelf來(lái)停止服務(wù)，避免占用內(nèi)存稀颁，浪費(fèi)系統(tǒng)資源芬失；

• 不要長(zhǎng)時(shí)間綁定其他進(jìn)程的service或者provider，每次使用完成后應(yīng)立刻釋放匾灶，避免其他進(jìn)程常駐于內(nèi)存棱烂；

• APP應(yīng)該實(shí)現(xiàn)接口onTrimMemory()和onLowMemory()，根據(jù)TrimLevel適當(dāng)?shù)貙⒎潜仨殐?nèi)存在回調(diào)方法中加以釋放阶女，當(dāng)系統(tǒng)內(nèi)存緊張時(shí)會(huì)回調(diào)該接口颊糜，減少系統(tǒng)卡頓與殺進(jìn)程頻次；

• 更應(yīng)在優(yōu)化內(nèi)存上下功夫张肾，相同ADJ級(jí)別芭析，系統(tǒng)會(huì)優(yōu)先殺內(nèi)存占用的進(jìn)程；

問(wèn)：能否把自己的App的ADJ值設(shè)置為-1000吞瞪，讓其殺不死？ 答：不可以驾孔，要有root權(quán)限才能修改adj芍秆，而且改了重啟手機(jī)還是恢復(fù)的惯疙。

扯得有點(diǎn)遠(yuǎn)了，回到問(wèn)題上：

系統(tǒng)內(nèi)存不足時(shí)妖啥，會(huì)在內(nèi)核層直接查殺進(jìn)程霉颠，不會(huì)在Framework層還跟你叨逼叨看回收哪個(gè)Activity。

所以在系統(tǒng)這個(gè)層面荆虱，單進(jìn)程場(chǎng)景蒿偎，Activity被回收只可能是因?yàn)檫M(jìn)程被系統(tǒng)回收了，這句話是沒(méi)毛病的怀读，但在應(yīng)用層面就不一定了诉位。

0x2、應(yīng)用可用內(nèi)存不足

APP進(jìn)程(虛擬機(jī))的內(nèi)存分配實(shí)際上是對(duì) 堆的分配和釋放菜枷，為了整個(gè)系統(tǒng)的內(nèi)存控制需要苍糠，會(huì)為每個(gè)應(yīng)用程序設(shè)置一個(gè) 堆的限制閾值，如果應(yīng)用使用內(nèi)存接近閾值還嘗試分配內(nèi)存啤誊，就很容易引起OOM岳瞭。

image

當(dāng)然，不會(huì)那么蠢蚊锹，還要開(kāi)發(fā)仔自己在APP里回收內(nèi)存瞳筏，虛擬機(jī)自帶 GC，這里就不向去卷具體的回收算法了

假設(shè)應(yīng)用內(nèi)存不足真的會(huì)回收Activity牡昆，那該怎么設(shè)計(jì)姚炕？一種解法如下：

應(yīng)用啟動(dòng)時(shí)，開(kāi)一個(gè)子線程迁杨，定時(shí)輪詢當(dāng)前可用內(nèi)存是否超過(guò)閾值钻心，超過(guò)的話干掉Activity

那就來(lái)跟下Android是不是也是這樣設(shè)計(jì)的？

Activity回收機(jī)制

跟下應(yīng)用啟動(dòng)入口：ActivityThread → main()

image

跟下 attach()：

image

這里就非常像铅协，run()中計(jì)算：已用內(nèi)存 > 3/4最大內(nèi)存，就執(zhí)行 releaseSomeActivities()，跟下：

image

所以 getService() 是獲取了 IActivityTaskManager.aidl接口，具體的實(shí)現(xiàn)類是 ActivityTaskManangerService：

image

繼續(xù)往下跟： RootActivityContainer → releaseSomeActivitiesLocked()：

image

跟下：WindowProcessController → getReleaseSomeActivitiesTasks()

image

然后再往下走就是釋放Activity的代碼了：ActivityStack → releaseSomeActivitiesLocked()

image

具體咋釋放熄捍，就不往下跟了哈，接著跟下是怎么監(jiān)控的~

內(nèi)存監(jiān)控機(jī)制

跟回：BinderInternal.addGcWatcher()

image

這里可能看得你有點(diǎn)迷缚柏，但是當(dāng)你理解了就會(huì)覺(jué)得很妙了：

虛擬機(jī)GC會(huì)干掉 WeakReference 的對(duì)象，在釋放內(nèi)存前，會(huì)調(diào)用對(duì)象的 finalize()怜浅，而這里有創(chuàng)建了一個(gè)新的 WeakReference 實(shí)例。下次GC沥阳，又會(huì)走一遍這里的代碼，嘖嘖嘖功炮，相比起輪詢高效多了

image

到此设捐，應(yīng)用內(nèi)存不足回收Activity的流程就大概縷清了，接著可以寫(xiě)個(gè)代碼驗(yàn)證下是否真的這樣。

Demo驗(yàn)證

先試下兩個(gè)Task的：

image

模擬內(nèi)存分配的頁(yè)面槐沼，然后一直點(diǎn)~

image

image

寧愿OOM凹嘲，也不回收构韵，試試三個(gè)~

image

image

好家伙杂数，onDestory()了，此時(shí)按Back回退這些頁(yè)面那伐，發(fā)現(xiàn)走了onCreate()踏施，即回收了，接著試試四個(gè)的情況：

image

image

可以罕邀，每次只回收一個(gè)Task畅形，到此驗(yàn)證完畢了~

0x3、結(jié)論

• 系統(tǒng)內(nèi)存不足時(shí)诉探，直接在內(nèi)核層查殺(回收)進(jìn)程日熬，并不會(huì)考慮回收哪個(gè)Activity；

• 進(jìn)程內(nèi)存不足時(shí)阵具，如果此進(jìn)程 Activity Task數(shù) >= 3 且 使用內(nèi)存超過(guò)3/4碍遍，會(huì)對(duì) 不可見(jiàn) Task進(jìn)行回收，每次回收 1個(gè) Task阳液，回收時(shí)機(jī)為每次gc怕敬；