Figure

ftp://cdiot@192.168.87.46/Pre_figure/Test_Log/Bug_118113/%E6%80%A7%E8%83%BD%E5%8D%A1%E9%A1%BF.7z

[当前状态]
1. 之前的AI：
a) 当memory有压力时，cached kernel没有释放足够的memory来缓解压力，是否正常。
---> 目前内部多次测试，在free memory存在压力时，cached kernel有释放memory 给到free使用，之前抓取的日志大概率是没有抓取到现场，cached kernel是后面又升上去的（内部测试结果如此）

b) 调查为什么figure项目开机后cached kernel占用的memory为2.5G左右，是否为正常值。
这个依赖高通Memory management - AP case（06644550）

2. 内部测试，设备跑完monkey后，在快速点击多个app，的确存在系统不流畅的问题，但是客户的测试现场没有跑monkey（日志也没有monkey相关记录）

3. 如果不跑menkey，快速点击多个app,系统有轻微的卡顿，感觉比较正常，且有查看真正能用的memory（available memory）确实很少，但是还能比较及时响应。

4. 同步有提一个高通case给到UX performace（06645981），看上层是否有什么发现。

5. 客户现场memory RSS 占用情况（前十），看起来APP占用memory较多，加上当时频繁发生GC操作，的确会导致卡顿。

Total RSS by process:
    561,960K: com.cmcc.cmvideo:remote_web (pid 5395)
    520,100K: system (pid 1511)
    481,008K: com.cmcc.cmvideo (pid 4548)
    437,208K: com.smile.gifmaker (pid 5049)
    344,480K: com.tencent.mobileqq (pid 3511)
    332,000K: com.tencent.android.qqdownloader:daemon (pid 3239)
    328,604K: com.qiyi.video.pad (pid 6236)
    293,312K: com.android.systemui (pid 1855)
    285,740K: com.cmcc.cmvideo:pushservice (pid 7949)
    285,200K: com.android.settings (pid 2347 / activities)

[下一步动作]
1. 跟踪高通的2个case：UX performace（06645981）和Memory management - AP（06644550）
2. 根据dumpsys meminfo的数据，是不是第三方app没有适配，导致占用过多memory，这个可以需要依赖上层从app的角度分析。
3. 内部沟通接下来的规避方案

[当前状态]
1. 和高通这边沟通，目前初步认为memory虽然比较少，但是影响不太大。
2. 目前使用同平台的QCS8250跑完monkey后也概率出现卡顿现象，现象比figure会好一点，使用memory压力工具进行测试，同样也会出现卡顿。

[下一步动作]
1. 目前认为经过monkey后，系统已经出现错误，再加上memory较少，频繁发生GC等事件同步发生，出现卡顿现象为正常行为。
2. 但是客户的现场没有进行monkey测试，我们内部没有复现过这种场景（开机直接点击多个app出现明显卡顿的问题），所以需要客户这边帮忙复现，同时复现问题时的抓取systrace。

ftp://cdiot@192.168.87.46/Pre_figure/Test_Log/Bug_118113/trace-kona-SKQ1.220201.001-2023-05-31-09-16-26.perfetto-trace

• kswapd进程,内存不足时进程内存交换，占用cpu资源，正常现象
• cn.moduoketech.recorder 卡顿期间，后台一直在运行，且占用的cpu比前台的喜马拉雅还多，

快速同步打开多个app，CPU使用率几乎占满，导致app进程不能及时分配到cpu资源，同样系统会卡顿，属于正常行为。

3. 查看后续的meminfo信息，可以发现swap也差不多使用完了。

Mem:  7896244K total,  7685616K used,   210628K free,      896K buffers
Swap:  4194300K total,  3838304K used,   355996K free,   736408K cached

• CPU资源不够
• 系统内存不足（又启动kswapd继续占用CPU资源，同时启动android回收机制）

1. 在快速打开多个app压力测试时，不启动cn.moduoketech.recorder进程（FM有声调频收音机），不清楚当时客户在使用这个app做什么操作，可以大大减轻CPU的负担。
2. 在1的基础上，看是否还会复现系统点击app卡顿的问题，可以实际情况看是否需要优化memory。

[当前状态]
1. 快速打开过个app时，以喜马拉雅为例，打开时刻基本都会占用200%~300%CPU资源，再加上其他app处于后台，但任然处于active状态，继续占用cpu资源，导致如果打开多个app时，memory资源也紧张，启动kswapd进一步占用CPU资源，导致CPU资源不够，系统运行卡顿。

[下一步动作]
1. 准备限制后台app的数量，来减少后台app的占用cpu资源的问题，但是有个问题，后台app的数量达到限制数量时，系统也不是立马释放资源，所以还是可能导致cpu资源不够，需要验证测试后台保留app的数量为多少时，用户体验最佳。
正在出VB进行验证。

1. 在开发者选项中，可以找到设置后台的app限制数量的选项，设置对应的值后（比如说设置为4），通过覃刚提供的命令：

adb shell dumpsys activity settings | grep -Ei "max" 
mCustomizedMaxCachedProcesses=32
CUR_MAX_CACHED_PROCESSES=4
CUR_MAX_EMPTY_PROCESSES=2

可以看到，对应的变量有生效。

• 不保留后台进程
• 保留1个后台进程
• 保留2个后台进程
• 保留3个后台进程
• 保留4个后台进程

但是发现至少“今天头条”和“抖音"，"腾讯视频"，"快手” ，“百度网络相关进程”和“喜马拉雅的网络推送进程”后台使用都没有受到限制，即使不对这几个app进行操作，在测试手顺一样的情况，由于链接网络，这几个app时不时的就会占用cpu，导致cpu使用率没法量化。

• 不保留后台进程 40%~65%
• 保留3个后台进程 cpu占用率35%-65%

和胡兵进行沟通后，修改CUR_MAX_CACHED_PROCESSES这种方式，主要适用于如下场景：
应用切换到后台时，其后台进程属于非缓存进程，如果此进程没有更多的业务或者资源的需求，才有可能转换成缓存进程，而DEFAULT_MAX_CACHED_PROCESSES是控制缓存进程数量，缓存进程的优先级较低，当系统内存不足时，会被系统回收以释放内存资源。根据设置的最大缓存进程数，系统会尽量保留指定数量的缓存进程，而其他进程则可能会被回收。

某些app切换到后台时，还会占用系统资源（网络请求等），就不会转换为缓存进程，导致即使设置了DEFAULT_MAX_CACHED_PROCESSES，也没法被释放。（比如“今天头条”和“抖音"，"腾讯视频"，"快手” ，“百度网络相关进程”和“喜马拉雅的网络推送进程”）

• 不保留后台进程 cached pss：800M左右
• 保留1个后台进程 cached pss：300-400M
• 保留3个后台进程 cached pss：200-300M

从上面的测试来看，修改限制后台数量后，进行快速打开app时，CPU的占用率很难量化，没法对比cpu的使用率。
但是设置后台数量后，上层cached占用的memory确实会减少，这样总的free memory会增加，在这个测试环境，内存不足的条件下，可以减少kswap进程的工作频率，同样会降低cpu的占用率。

所以，从目前的测试结果来看，设置config_customizedMaxCachedProcesses是有一定优化作用。

客户攻关会决议只保留3个应用，拉专项评估工作量