鸿蒙冷启动优化：减少import、拆分HAR导出与HSP改HAR

鸿蒙专家

应用冷启动耗时并不只发生在首页渲染阶段。华为开发者联盟社区的一则实践案例指出，Application 和 Ability 初始化阶段包括资源加载、虚拟机创建、对象创建与初始化、依赖模块加载等环节，其中资源加载是最主要的耗时点。资源加载又可拆成三步：文件加载，即查找并解析文件并记录到模块中；依赖模块解析与实例化，为模块导出的变量分配内存空间；文件执行，运行 .ets 文件并把变量赋为真实值。围绕这条链路，案例给出了几项可直接落地的 ArkTS 工程优化手段。

一、减少 import 模块，优先使用系统模块并按需加载

应用执行代码前必须找到并加载所有导入的模块，每增加一个第三方框架或模块，都会增加启动时间，耗时取决于模块数量和大小。案例建议优先使用系统提供的模块，按需加载；对导入耗时较大的必要模块，可采用动态导入方式，官方文档中提供了 ArkTS 动态导入的说明。另一个容易忽略的点是嵌套的 export * 全量导出：冷启动时 HandleLaunchAbility 会执行相关 .ets 文件，主页面 import 的 .ets 文件都会被执行，包括数据结构、变量和全局函数的初始化。案例使用 Launch 分析对比了优化前嵌套 8 层 export * 与优化后直接从目标文件 import 的情况，分析阶段从开始加载 abc 文件（H:JSPandaFileExecutor::ExecuteFromAbcFile）到 abc 文件加载完成，优化后启动性能得到改善。

二、用按需引用替代 import * 全量引用

开发中常把相同类型的变量或函数集中到工具类文件，再通过 import 引入。当工具类暴露的函数或变量较多时，案例推荐按需引用具体变量，而不是使用 import * as nm 全量引用，以减少 .ets 文件执行耗时和所有 export 变量的初始化过程。案例对全量引用 2000 条数据与使用 import { One } 按需引用做了 Launch 对比，分析区间为 H:void OHOS::AppExecFwk::MainThread::HandleLaunchAbility(const std::shared_ptr &) 的开始点到结束点，优化后启动性能有提升。

三、拆分 HAR 导出文件，隔离非冷启动强相关文件

案例给出一个场景：应用包含首页 Index 和二级页面 SecondPage。首页展示 HAR 包中 MainPage.ets 的 Text 组件，该文件没有耗时操作；点击 Text 后跳转到二级页面，二级页面引用 HAR 包中的 SubPage.ets，而 SubPage.ets 包含在模块加载时执行的全局函数耗时操作。HAR 包的 Index.ets 同时导出 MainPage.ets 和 SubPage.ets，首页使用 import { MainPage } from 'library/Index' 导入时，冷启动过程会连带执行非冷启动强相关的 SubPage.ets，增加启动时间。

方案一是拆分 HAR 导出文件：新增 IndexAppStart.ets 仅导出首页相关文件 MainPage.ets，新增 IndexOthers.ets 导出非首页相关文件 SubPage.ets；首页从 IndexAppStart.ets 导入 MainPage，二级页面从 IndexOthers.ets 导入 SubPage。该方案能把冷启动阶段与非冷启动阶段需要执行的 .ets 文件完全拆开，但要求 IndexAppStart.ets 中的导出文件不能引用 IndexOthers.ets 中的导出文件。方案二是不新增文件，首页导入 MainPage.ets 时使用全路径，避免汇总导出把所有文件带进来；缺点是引用时要展开冷启动阶段所有文件路径，开发和维护成本更高。案例使用 Launch 分析优化前后性能，阶段起点为 UI Ability Launching，终点为应用首帧 First Frame - App Phase，两种方案均改善了启动表现。

四、减少多个 HAP/HSP 对相同 HAR 的引用

使用 HSP 或 HAR 共享包可以整合同类模块，在多个模块或工程间共享 ArkUI 组件、资源等代码。但案例提醒避免多个 HAP/HSP 引用相同 HAR，具体影响可参考官方模块化设计文档中“多 HAP/HSP 引用相同 HAR 包的影响”部分。

五、单 HAP 场景优先多 HAR，避免 HSP 额外加载开销

对于单窗口应用的 APP 工程，如果只包含一个 Entry 类型 HAP，且划分的模块没有按需加载需求，案例建议业务组件和公共组件采用 HAR 打包。最终构建 HAP 时，被依赖的 HAR 会编译进 HAP 包；HSP 采用动态加载，启动过程中会加载依赖的 HSP，带来额外 IO 与运行耗时。案例用 Launch 对比了 HAP 与 20 个 HSP 混合打包、以及把 20 个 HSP 设计成 HAR 包的启动性能，后者的启动表现更好。

整体来看，这组优化都围绕同一目标：缩短 Application 和 Ability 初始化阶段的资源加载与 .ets 执行时间。落地时可先用 Launch 分析定位模块加载和首帧阶段的时间分布，再按“减少 import 模块、避免嵌套 export *、按需引用、拆分 HAR 导出、控制 HAR/HSP 引用关系”的顺序逐项验证。案例也说明，这些手段需要结合具体模块划分和页面依赖关系取舍，例如拆分导出文件会带来额外维护约束，全路径导入则增加引用成本，适合在性能瓶颈明确后针对性实施。