騰訊
1 KOOM會(huì)啟動(dòng)多進(jìn)程，每個(gè)進(jìn)程都要初始化OOMMonitor的初始化進(jìn)行內(nèi)存的dump內(nèi)存分析

默認(rèn)15秒會(huì)觸發(fā)對(duì)內(nèi)存的檢測(cè)

1 android中觸發(fā)OOM的具體場(chǎng)景有哪些？
1.1 內(nèi)存抖動(dòng)
1.2 內(nèi)存泄漏
1.3 文件數(shù)上限（進(jìn)程中文件數(shù)打開太多了也會(huì)oom）
1.4 線程數(shù)上限（進(jìn)程中線程數(shù)打開太多了也會(huì)oom）
1.5 內(nèi)存不足（比如圖片申請(qǐng)了一個(gè)大的內(nèi)存不夠分配的）

image.png

以上對(duì)應(yīng)的四種內(nèi)存檢測(cè)器
分別是
1內(nèi)存占用率：HeapOOMTracker 閾值80% 每隔15s檢測(cè)一次

image.png

image.png

2 FastHugeMemoryOOMTracker
條件一： 閾值90% 后立馬報(bào)出
條件二： 前后差值超過(guò)150M也會(huì)報(bào)出

OnHeapDumpedListener 收集泄漏對(duì)象 上傳到服務(wù)端或存儲(chǔ)到本地會(huì)不會(huì)文件太大 導(dǎo)致手機(jī)內(nèi)存劇增

如果不加控制地收集和保存 heap dump 文件，確實(shí)可能會(huì)導(dǎo)致文件過(guò)大，占用手機(jī)內(nèi)存，尤其是在應(yīng)用內(nèi)存占用本身較大的情況下。heap dump 文件是應(yīng)用運(yùn)行時(shí)的完整內(nèi)存快照，通常體積較大，特別是在內(nèi)存泄漏嚴(yán)重時(shí)。

為了避免 heap dump 文件過(guò)大導(dǎo)致手機(jī)內(nèi)存劇增，以下是一些常見的優(yōu)化方案：

1. 控制 heap dump 文件生成的頻率和大小
   限制文件生成頻率：不要頻繁地生成 heap dump 文件，只在必要的時(shí)候生成，比如應(yīng)用內(nèi)存占用異常高或者檢測(cè)到內(nèi)存泄漏時(shí)生成。
   設(shè)置內(nèi)存使用閾值：通過(guò) KOOM 的配置，可以設(shè)置一個(gè)內(nèi)存使用的閾值，只有當(dāng)內(nèi)存使用超過(guò)某個(gè)臨界值時(shí)才生成 heap dump 文件。
   定期清理舊文件：生成新 heap dump 文件之前，可以檢查本地是否已經(jīng)存在舊文件，定期清理或覆蓋舊文件，避免占用過(guò)多的存儲(chǔ)空間。
   示例：控制生成頻率并清理舊文件

KOOM.INSTANCE.init(JavaHeapDumper.Config.Builder()
    .setHeapAnalyzePath(filesDir.absolutePath) // 設(shè)置 heap dump 文件存儲(chǔ)路徑
    .setThreshold(512 * 1024 * 1024L)          // 設(shè)置內(nèi)存閾值
    .setOnHeapDumpedListener { heapDumpFile ->
        // 清理之前生成的文件，避免過(guò)多占用存儲(chǔ)空間
        cleanUpOldDumpFiles(filesDir)
        
        // 上傳文件或保存到本地
        uploadHeapDumpToServer(heapDumpFile)
    }
    .build())

// 定期清理舊的 heap dump 文件
fun cleanUpOldDumpFiles(dumpDir: File) {
    val files = dumpDir.listFiles { _, name -> name.endsWith(".hprof") }
    files?.forEach { file ->
        if (file.exists() && file.length() > 0) {
            file.delete()
        }
    }
}

2. 文件壓縮
   在上傳 heap dump 文件之前，對(duì)文件進(jìn)行壓縮可以顯著減少占用空間和網(wǎng)絡(luò)流量。壓縮后的文件體積通常比原始文件小很多，傳輸速度也會(huì)更快。

文件壓縮示例：

fun compressHeapDumpFile(heapDumpFile: File, outputZipFile: File) {
    FileInputStream(heapDumpFile).use { fis ->
        FileOutputStream(outputZipFile).use { fos ->
            ZipOutputStream(BufferedOutputStream(fos)).use { zos ->
                val zipEntry = ZipEntry(heapDumpFile.name)
                zos.putNextEntry(zipEntry)
                fis.copyTo(zos)
                zos.closeEntry()
            }
        }
    }
}

總結(jié)：
為了防止 heap dump 文件過(guò)大導(dǎo)致手機(jī)內(nèi)存占用劇增，你可以采取以下優(yōu)化措施：

控制 heap dump 文件的生成頻率和條件。
壓縮文件，減小體積后再進(jìn)行上傳或存儲(chǔ)。
定期清理本地的舊 dump 文件。
只在必要時(shí)上傳文件，并根據(jù)需求進(jìn)行分片上傳。
這些措施可以有效控制 heap dump 文件的大小，減少對(duì)設(shè)備存儲(chǔ)和性能的影響。
hprof文件就是二進(jìn)制快照文件，

1、內(nèi)存泄漏監(jiān)控需要高實(shí)時(shí)性嘛?某個(gè)Activity泄露了，哪怕占用內(nèi)存很小真的有必要馬上dump內(nèi)存嗎?
不需要實(shí)時(shí)；
沒(méi)必要 根據(jù)策略可以控制內(nèi)存達(dá)到90%后觸發(fā)或者前后兩次相差150M以上再觸發(fā)

2、dump 內(nèi)存這么慢，能不能在子線程中執(zhí)行?
不能
可以在子進(jìn)程中執(zhí)行，但是會(huì)遇到fork與多線程的問(wèn)題。應(yīng)用進(jìn)程會(huì)復(fù)制一個(gè)跟主線程完全相同的子進(jìn)程主進(jìn)程的線程也會(huì)被復(fù)制過(guò)來(lái)，只會(huì)把主進(jìn)程中線程的對(duì)象和狀態(tài)復(fù)制過(guò)來(lái)，這樣就會(huì)導(dǎo)致子進(jìn)程卡死無(wú)法運(yùn)行，因?yàn)楸粡?fù)制過(guò)來(lái)的子線程復(fù)制了狀態(tài)但是本身的線程對(duì)象沒(méi)有任何狀態(tài)的，當(dāng)根據(jù)狀態(tài)來(lái)改變線程后就會(huì)卡死。

為解決這個(gè)問(wèn)題，當(dāng)進(jìn)程被復(fù)制前 先進(jìn)行線程狀態(tài)的變更 利用反射調(diào)用libart so中的方法
JVMTI :反射調(diào)用so中的方法libart.so
art::Dbg::suspendVM:suspend虛擬機(jī)恢復(fù)虛擬機(jī)art::Dbg::ResumeVM:
反射!

3、hprof文件是什么?為什么會(huì)這么大，能不能壓縮?
hprof文件記錄了當(dāng)前內(nèi)存快照信息的一個(gè)文件，之所以大是因?yàn)榘芏酂o(wú)用信息 包括時(shí)間、版本、標(biāo)簽，可以通過(guò)hooK技術(shù)的IO 一邊分析一邊寫到文件中去 就完成了高效的內(nèi)存監(jiān)控工具