ASCF元服务冷启动慢

问题现象：

首次打开元服务或长时间未使用后重新打开元服务时，从点击图标到元服务主页面完全加载出来的时间过长，期间可能显示空白屏幕或加载动画。

背景知识：

• 冷启动：当元服务启动时，设备后台没有该元服务的进程，需要重新创建进程并完成初始化。

• ASCF（Atomic Service Cross-Platform Framework）是元服务的跨平台运行框架，基于JSVM引擎和元服务技术栈实现。ASCF元服务的冷启动流程涉及AbilityStage生命周期、JSVM引擎初始化、元服务app.js加载执行、首页创建与渲染等ASCF框架特有的环节。

• ASCF元服务冷启动流程大致可分为以下阶段：

  阶段	说明
  运行环境准备	元服务的运行环境包括元服务进程、HarmonyOS系统组件和UI元素（如 导航栏、tabBar等）、渲染页面使用的WebView容器、开发者JavaScript代码的运行环境等。
  逻辑层代码注入	元服务启动时需要从代码包中读取元服务的配置和代码，并注入到JavaScript引擎中。在主包代码注入过程中，会触发元服务的App.onLaunch和App.onShow生命周期。
  视图层代码注入	WebView容器准备好后会根据用户访问的页面，加载页面渲染需要的页面结构和样式信息。逻辑层代码注入和视图层代码注入是并行进行的。
  页面渲染	逻辑层代码注入完成后，ASCF框架会根据用户访问的页面，进行页面组件树初始化，生成首屏渲染初始数据发送到视图层；结合首屏渲染初始数据和视图层的页面结构和样式信息，元服务进行首页渲染，展示元服务首屏。在这个过程中会触发页面的Page.onShow、Page.onLoad、Page.onReady生命周期。

• ASCF框架在冷启动关键环节埋设了Trace打点，开发者可使用DevEco Profiler的Launch分析能力抓取冷启动过程的耗时数据，通过搜索Trace关键字定位耗时瓶颈。

ASCF冷启动Trace打点说明：

借助DevEco Profiler抓取ASCF元服务冷启动过程的Trace数据，根据下表中ASCF框架提供的Trace关键字，定位各阶段耗时情况。

下表列出ASCF框架在冷启动流程中埋设的所有Trace打点，按执行顺序排列：

问题定位：

1. 使用DevEco Profiler的Launch分析抓取ASCF元服务冷启动过程的Trace数据。

2. 在Trace数据中搜索上表中的Trace关键字，查看各阶段耗时。

3. 根据耗时较长的Trace打点，对照详细说明定位具体原因：

   • 逻辑层代码注入阶段耗时：查看H:LaunchMiniApp阶段耗时，分析逻辑层代码注入和执行耗时。

   • 视图层代码注入阶段耗时：查看H:AscfRenderPageAppear结束节点到H:WebPageLoad开始节点期间的整体耗时，分析视图层代码页面结构和样式信息加载耗时。

   • 页面渲染阶段耗时：查看H:WebPageLoad持续阶段耗时，分析页面根据页面结构和页面数据完成渲染的耗时。

   • 运行时逻辑耗时：查看H:JSVM_Exe_Code耗时，分析逻辑层JS执行是否阻塞了数据更新。

分析结论：

ASCF元服务冷启动慢的常见原因有：

• 元服务逻辑层初始化（注册App、Page、Component）app.js文件过大，加载耗时。

• app.js中onLaunch、onShow初始化逻辑过于复杂，执行耗时长。

• 视图层页面结构、样式信息复杂；视图层代码注入加载耗时长。

• 逻辑层执行耗时同步API，影响了数据及时更新到视图层，阻塞了页面数据渲染。

• 首页数据在onLoad中使用网络请求获取，网络请求耗时长，导致冷启动整体耗时长。

修改建议：

• 分包优化：合理使用分包策略，将非首屏页面放入子包中按需加载，减少主包体积和首屏加载时间。

• 减少app.js初始化逻辑耗时：将app.js中onLaunch、onShow的非必要初始化逻辑改为异步执行，避免阻塞启动流程。将耗时操作延迟到首页渲染完成后再执行。

• 减少首页组件复杂度：简化首页组件结构，避免首页结构和样式信息过多；开启组件用时注入功能，减少启动时需要加载的组件数量。

• 逻辑层代码优化：在元服务初始化代码和启动相关的生命周期中，应避免复杂的运算逻辑并减少同步API的调用。

• 优化首页数据加载：使用数据预拉取能力，提前进行数据加载，减少首页onLoad的等待时间。