一 测试目标：
以满足用户设备的内存性能和不杀后台为目标。
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栈的哪一层导致的问题，是内核层，还是存储设备端导致的问题。