一、关键字：

窗口切换；最近任务；卡顿

二、问题描述

设备型号：黄鹂

系统版本：OpenHarmony 5.0

代码版本：OpenHarmony-5.0

问题现象：应用切换，最近任务退出，连续点击，窗口明显卡顿1.5s。

三、原因分析

前期定位分析可参考 https://laval.csdn.net/6725e03f82931a478c1721b7.html，此文仅针对memmgr未被成功调起做定位分析。

3.1 正常机制

在冷启动应用或窗口切换过程中，均会调用Memory：：MemMgrClient 中的接口，对内核节点进行访问。正常情况下，会读取/dev/memcg/下的接节点。会打印如下日志：

 

3.2 异常机制

在升级至5.0.0Release后，应用和窗管均无法获取到相关的服务进程，现象即表现为，应用冷启动或窗口切换时延迟近1.2s，严重影响设备性能。

日志打印如下：

 

3.3 差异分析

通过增加对访问节点的输出，可以看到实际访问的节点均为hyperhold内核特性生成，但黄鹂在适配过程中并未适配该特性，导致节点访问失败。

 

除此之外，foudation/resourceschedule/memmgr 目录下无任何其他差异，代码中的hyperhold特性在 foundation/resourceschedule/memmgr/services/memmgrservice/BUILD.gn 文件中通过 memmgr_hyperhold_memory 特性开关来控制。

 

但在 foundation/resourceschedule/memmgr/memmgr.gni 中声明时已置为false。

3.4 根因定位

通过在gn中添加打印，随后观察编译日志中发现，在 memmgr_hyperhold_memory 在编译时确实被置为 true，导致开启了MemMgr中hyperhold相关特性 ，通过全局搜索该开关，发现5.0.0 Release 在 productdefine/common/inherit/rich.json 中，新增了对 memmgr_hyperhold_memory 的赋值动作：

 

3.5 修改方案

通过对编译框架的分析，可在 vendor/hihope/rk3568/config.json 中添加对 memmgr_hyperhold_memory 特性的修改：

 重新编译后，该问题顺利解决。