在使用JSVM时，如何从JSVM调用结构的三层（native、JSVM - API、JSVM）角度分析启动变慢的原因？

Question

如题：在使用JSVM时，如何从JSVM调用结构的三层（native、JSVM - API、JSVM）角度分析启动变慢的原因？

本文参与了 【 HarmonyOS NEXT 技术问答冲榜，等你来战！】欢迎正在阅读的你也加入。

Answer 1

从JSVM调用结构的三层角度分析启动变慢的原因如下：

1. Native层：

   • 逻辑排布和组合问题：在Native层，小程序运行JS的逻辑层使用JSVM提供的接口进行JS代码编译、运行和code cache生成等操作。如果逻辑排布不合理，例如在冷启动时没有合理安排code cache的生成时机和方式，可能导致启动变慢。例如，若在冷启动时直接在主线程进行code cache生成所需的前置编译，会增加冷启动时间，因为code cache生成本身存在开销且可能需要全量编译（如开启eager compile选项时）。
   • 资源管理不当：在处理多线程相关操作时，如生成code cache的线程管理不善，可能导致资源竞争或不合理的资源占用。例如，在生成code cache的线程与主线程之间，如果没有正确协调资源（如内存、CPU等），可能会影响启动速度。

2. JSVM - API层：

   • 接口兼容性开销：JSVM - API作为连接Native和JSVM的接口兼容层，为保持对不同版本JS引擎的兼容，可能引入一定的开销。在不同版本的JS引擎切换或适配过程中，可能需要进行额外的处理，这可能会影响启动速度。例如，在调用某些接口时，需要进行版本兼容性检查或转换，导致一定的时间消耗。
   • 接口使用不当：如果开发者没有正确使用JSVM - API，例如使用了相对低效的接口方法（如在判断对象原生类型时，使用先查询类型再判断的方式，而不是直接使用更高效的IsXXX系列接口），也会导致启动变慢。

3. JSVM层：

   • 编译开销：JSVM层负责JS代码实际的编译运行，其开销很大一部分来源于编译。例如，在热启动时，如果没有足够的code cache或者code cache的覆盖率不高，会增加编译时间，导致启动变慢。在冷启动时，如果不合理使用编译选项（如eager compile），会增加不必要的编译时间，因为eager compile会将所有函数都进行编译，而没有利用v8 lazy compile的优化效果（将不在必经路径上的函数推迟编译）。

本文参与了 【 HarmonyOS NEXT 技术问答冲榜，等你来战！】欢迎正在阅读的你也加入。