一 測試目標：
以滿足用戶設備的內存性能和不殺后臺為目標。
1：滿足用戶設備的內存性能是指不出現因為內存原因導致的安卓設備死機，卡頓等問題。

2：滿足不殺后臺是指整個設備使用時，不出現后臺app被殺。
通常是估算如果有后臺被殺，則該設備所最多能容納的app數量值。

二 測試思路：
原生android的內存架構設計會優先考慮內存性能，為了性能，會犧牲掉后臺app駐留能力。
所以可以首要關注滿足不殺后臺這一目標。

另外實際應用中，多是需要做上面測試目標的第2個估算，所以下來會針對這個做詳細設計。
可以在測試時，選取首次出現殺后臺問題的這一時間點，捕獲下此時系統對應的整機內存分布，以便算出設備容納的app數量以及還有無優化空間。

三 測試方法：
1: 清空android設備內存駐留的所有app，并重啟。

2：開機后，測試app啟動后，操作2分鐘，再退出啟動下一個app.
這樣連續啟動操作若干個app，直至出現第一個后臺殺進程時，捕獲下此時系統對應的整機內存分布，并記錄下此時已經啟動并操作過的app數目。
（選取app時, 一般選取用戶場景中高頻使用的app）

3:估算殺進程時間點對應的整機總共消耗內存容量大小：
（totalpss - totalswappss)(用戶態內存消耗) + ?
(shmem + slab_unreclaimable + vmalloc_used + page_tables + kernel_stack + ion_heap)(內核態內存消耗,很多是/proc/meminfo里面的) +
memInfo.getZramTotalSizeKb() (zram占的實際物理內存大小)

四 進一步的提升后臺駐留能力方面的優化方法:

如果目標是在不犧牲性能的情況下，使得有更多的app可以駐留后臺:
則首先需要檢查：
1：各app的內存消耗是否正常。
需要采集下app位于前臺和后臺兩個不同的內存消耗值，然后拿該兩個內存值和同類型(比如都是天氣預報app)的其他app的這兩個數值做比較。
分析該app的內存占用是否有異常。(異常包括有無內存泄漏或者內存占用不合理)

異常對應處理措施：
1)app位于前臺時，采集的是其最大峰值內存占用，還需要捕獲到對應的app進程棧回溯上下文，輔助app開發者找到哪地方代碼占內存有問題。
2)位于后臺時，如果內存占用不合理，多是因為該app退到后臺時，其占用的圖形內存資源沒有釋放，需要優化該app。

2: 系統工作集的內存消耗是否正常.
android整機內存占用可以分為三大塊：
系統工作集 + 用戶感知app + 后臺的非感知app

系統工作集內存消耗：包括adj<0的系統所有進程pss內存占用總和，還有內核態內存消耗.

這個系統工作集內存消耗具體統計上面三 測試方法里面有提到。
可以和其他的同類型(都是車載機)，同軟件大版本的android設備做比較，來發現其內存占用是否異常。

異常對應處理措施：
內核態除了ION heap之外，其他幾項不會占內存太多，除非有內存泄漏問題出現。
ION heap可以用我這邊專門工具捕獲到每一塊ION內存對應的線程棧回溯上下文。這樣可以輔助分析哪塊ION內存占用不合理。

3：后臺cached級別進程是否已經被凍結，其占用的用戶態內存是否已經被回收掉。
這個cached級別進程就是上面說的后臺非感知app。

現在原生android14版本對cached進程是會凍結，并回收其內存資源的。
可以通過看進程棧回溯上下文，檢查有無真正被凍結，另外通過dumpsys meminfo命令看其用戶態占用內存是否已經被回收掉。

4：app退到后臺時，除了上面提的用戶感知app之外，其他app是否已經退到cached級別。

1)如果發現有沒退到cached級別,但又不會被用戶感知的app，則估計是該app利用了系統缺陷，做了后臺優先級提升工作。
此時，需要把該app降級，并重新退到cached級別。

2)如果可感知app稍微比較多，則需要評估需要有這么多這種類型的app存在。
因為此類app多的話，影響系統內存回收，增大系統總內存占用消耗。

其次如果上面三 測試方法中的步驟3算出的系統總內存消耗和ddr總內存的差值比較大時(1G以上)，
則表明在系統有比較多的可用內存時，還發生了殺后臺現象。
這個是原生安卓過于重視內存性能，忽視后臺駐留的一個不足缺陷，
具體原因是lmkd采用了mem psi方式殺進程，該殺進程方式比較活躍，一旦稍微有內存壓力，就會殺后臺進程。
需要對Lmkd做改進。

五：識別內存性能問題以及相應的優化
上面提的是優化殺后臺問題，提升后臺app駐留能力。
另外針對平時測試場景中的死機卡頓這些性能問題，也需要有針對性的優化方案部署。

1 卡頓測試方法：

可以在發版本之前跑monkey或者mtbf測試，并且版本要帶上卡頓檢測功能。

這樣在跑測試時，如果有前臺app操作卡頓問題，會自動輸出相關的捕獲log.（會有第一現場的bugreport log生成）

2 卡頓問題分析：

卡頓分必現卡頓和偶現卡頓：
必現卡頓可以通過systrace和simpleperf等性能工具，來看出卡頓原因。

偶現卡頓則需要部署卡頓檢測功能，提升系統的可觀測性。
該功能可以做到：
每次安卓設備端出現卡頓問題時，可以輸出cpu端，io端和內存端的各自性能耗時數據(都在卡頓檢測功能輸出的log里面)，這樣可以通過數據初步知道該卡頓問題主要是cpu,io和內存這3大塊哪塊導致的。

如果是內存，則可以通過bugreport ?log，再結合上面提升后臺駐留方面的優化方法，來分析是否有內存泄漏，或者內存占用不合理等。
如果是IO，則可以通過進一步的IO打點log,來看出是存儲IO棧的哪一層導致的問題，是內核層，還是存儲設備端導致的問題。
?