鸿蒙小助手 2026-10-21 13:51:39 发布本原创文章帖发布在华为开发者联盟社区,欢迎开发者前往访问评论交流,更多与该内容相关讨论,请点击原帖查看:
提升鸿蒙应用冷启动速度案例(二) -华为开发者话题 | 华为开发者联盟
缩短Application和Ability初始化阶段耗时
Application和Ability初始化包括资源加载、虚拟机创建、相关对象的创建与初始化及依赖模块的加载。其中最主要耗时点在资源加载阶段,分为以下几个步骤。
1、文件加载:查找并解析所有的文件到模块中记录。
2、依赖模块解析(实例化):分配内存空间来存放模块所有导出的变量,此时内存中并没有分配变量的值。
3、文件执行:运行`.ets`文件,将内存中之前未分配值的变量赋为真实的值。
减少import的模块
应用程序在执行代码前,必须找到并加载所有导入的模块。每个加载的第三方框架或模块都会增加启动时间,具体耗时取决于模块的数量和大小。建议开发者优先使用系统提供的模块,按需加载。如果某些必要模块的导入较为耗时,建议采用动态导入方式。具体方法可参考https://developer.huawei.com/consumer/cn/ doc/harmonyos-guides/arkts-dynamic-import?ha_source=zxqy-IT&ha_sourceId=89000468。
减少使用嵌套的export *方式进行全量导出。应用冷启动过程中,`HandleLaunchAbility` 会执行冷启动相关的 `.ets` 文件。所有被主页面import的 `.ets` 文件均会被执行,包括数据结构、变量和全局函数的初始化,建议使用具体文件名导出方式减少这部分耗时。
使用Launch分析,对比优化前(嵌套8层export *)和优化后(直接从目标文件中import)的启动性能。分析阶段从开始加载abc文件(H:JSPandaFileExecutor::ExecuteFromAbcFile)到abc文件加载完成。
优化前,存在8层嵌套export *:

优化后,不存在嵌套export *,从目标文件中直接import:

对比数据如下:

减少import *的方式全量引用。应用程序加载时,通常将相同类型的变量或函数放在同一个工具类文件中。使用时,通过import方式引入对应的模块。当工具类中存在较多暴露的函数或变量时,推荐按需引用具体的变量,以减少 `.ets` 文件的执行耗时和文件中所有export变量的初始化过程。
对优化前(使用 `import * as nm` 全量引用2000条数据)和优化后(使用import { One }按需引用)的启动性能进行对比分析。分析阶段从 `H:void OHOS::AppExecFwk::MainThread::HandleLaunchAbility(const std::shared_ptr<AbilityLocalRecord> &)` 的开始点到结束点。
优化前,使用import * as nm全量引用2000条数据:

优化后,使用import { One }按需引用:

优化前后的对比数据如下:

以上两种实操方法案例可参考链接:https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-arkts-high-performance#section1218510102815?ha_source=zxqy-IT&ha_sourceId=89000468。

合理拆分导出文件,减少冗余文件执行
应用程序加载模块后,需执行应用侧的.ets文件,进行初始化并执行全局变量和函数的初始化。文件可分类为冷启动强相关文件(如首页展示界面及组件相关文件)和非冷启动强相关文件(如跳转后二级页面)。
【场景示例】
应用包含两个页面:首页Index和二级页面SecondPage。首页展示HAR包中MainPage.ets文件的Text组件,该文件中没有耗时操作。点击首页中的Text组件时,跳转至二级页面。二级页面引用HAR包中的SubPage.ets文件,该文件包含全局函数的耗时操作,这些操作在模块加载时执行。
HAR包中的导出文件Index.ets同时导出了MainPage.ets和SubPage.ets两个文件。当首页直接使用 “import { MainPage } from 'library/Index'” 的方式进行导入时,会导致应用在冷启动过程中执行非冷启动强相关文件SubPage.ets,增加了冷启动时间。
优化前,加载模块时执行了非冷启动相关文件 SubPage.ets:

以下为示例代码:





【优化方案一】
将HAR包的导出文件Index.ets进行拆分,IndexAppStart.ets文件仅导出首页相关文件,即MainPage.ets。IndexOthers.ets文件导出非首页相关文件,即SubPage.ets。
优点:使用此种方案优化后可以将冷启动阶段(加载首页文件)与非冷启动阶段(加载非首页文件)需要执行的.ets文件进行完全拆分,类比其他需优化的场景也可以使用本方案进行拆分。
缺点:拆分后,需确保IndexAppStart.ets中的导出文件不引用IndexOthers.ets中的导出文件。
优化方案一,拆分HAR导出文件框图如下:

示例代码如下:
1. 将HAR包的导出文件Index.ets进行拆分,IndexAppStart.ets文件仅导出首页相关文件,IndexOthers.ets文件导出非首页相关文件。

2. 首页Index从IndexAppStart.ets导入MainPage。

3. 跳转后的页面SecondPage从IndexOthers.ets导入SubPage。

【优化方案二】
在首页的Index.ets文件中导入MainPage.ets时,使用全路径。
优点:无需新增文件即可汇总导出所有冷启动阶段的文件。
缺点:引用时需对冷启动阶段的所有文件路径进行展开,增加开发和维护成本。
优化方案二,首页导入冷启动文件时使用全路径展开框图如下:

示例代码如下:


使用Launch分析优化前后启动性能。阶段起点为UI Ability Launching,终点为应用首帧即First Frame - App Phase。
优化前:加载模块时执行了非冷启动相关文件:

优化方案一:拆分HAR导出文件:

优化方案二:导入冷启动文件时全路径展开:

优化前后的对比数据如下:

优化`.ets`文件执行耗时
为减少应用冷启动时.ets文件的执行耗时,可以采取以下措施:拆分HAR包导出的Index.ets文件,或在导入冷启动文件时展开完整路径,从而提升应用冷启动速度。
减少多个HAP/HSP对相同HAR的引用
在应用开发的过程中,可以使用HSP 或HAR 的共享包方式,整合同类模块,实现多个模块或工程间共享ArkUI组件、资源等相关代码。同时,避免多个HAP/HSP引用相同HAR。详细信息请参见该链接中“多HAP/HSP引用相同HAR包的影响 ”部分(https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-modular-design#section9492615385?ha_source=zxqy-IT&ha_sourceId=89000468)。
优化加载HSP时间过长
对于单窗口应用的APP工程,其仅包含一个Entry类型的HAP。如果划分的模块没有按需加载的需求,建议业务组件和公共组件采用HAR的打包方式。最终构建应用HAP包时,这些被依赖的HAR将被编译进HAP包中。HSP采用动态加载,在启动过程中会将依赖的HSP加载进来,增加额外的IO与运行耗时。在单HAP场景下,如果使用多模块的话,推荐使用多HAR,不推荐使用HSP。
以下为示例代码:

下面使用Launch分析,对比HAP与20个HSP混合打包以及将20个HSP包设计成HAR包的启动性能。
优化前,HAP+20个HSP混合打包:

优化后,将20个HSP包设计成HAR包:

对比数据如下:

本文讲述了缩短Application和Ability初始化阶段耗时的一些手段,包括减少import的模块,合理拆分导出文件,减少冗余文件执行,优化`.ets`文件执行耗时。下一章节我们将带你了解更多优化冷启动阶段耗时的手段。
----------------------------------------------------------------------------------------------------------

🔗 社区DFX专题文章: https://developer.huawei.com/consumer/cn/forum/subject/2101218731402391001?ha_source=zxqy-IT&ha_sourceId=89000468


【扫码加入 HarmonyOS DFX 技术交流群】
相关推荐
鸿蒙小助手
29
0
GeorgePanda
4352
0
鸿蒙小助手
421
0
828
1
老杜
681
0
鸿蒙小助手
致力于为鸿蒙开发者谋福利
帖子
提问
粉丝
提升鸿蒙应用冷启动速度案例(一)
2026-10-21 13:44:01 发布“向光而行,码向未来”1024主题线下沙龙(西安站)精彩回顾
2026-10-21 09:59:06 发布



京公网安备:11010502051901号