HarmonyOS鸿蒙Next ArkTS极简开发新范式——通过路径展开优化性能

HarmonyOS鸿蒙Next ArkTS极简开发新范式——通过路径展开优化性能

背景介绍

在 ArkTS 工程开发中，开发者通常会通过 Index.ets 作为统一出口文件，对外暴露组件、工具函数和服务能力。这样写的优点很明显：导入方式统一，业务代码更简洁，模块边界也更清晰。

但是，当 Index.ets 只是一个转发层时，业务代码如果仍然依赖它，就会让模块加载链路变长，造成性能浪费。

对于这类场景，ArkTS编译器提供expandImportPath（工程级配置、模块级配置）配置项。通过修改配置项，编译器会将间接包名导入转换为精准的文件路径导入，跳过中间模块。该优化可消除冗余的模块解析和初始化，减少冷启动阶段不必要的资源消耗。

什么是路径展开

下面用一个典型场景来说明。

假设工程中存在如下模块关系：

• entry 为应用入口模块
• har 对外暴露部分能力

其中，har 中的 Index.ets 只是统一出口文件，Utils.ets 继续向下转发，最终目标能力实际定义在 OtherModule3.ets、OtherModule4.ets 等文件中。

原始导入方式

业务侧通过 har 的统一出口导入：

import { xxx } from 'har'

它背后可能对应这样的导出链路：

// har/Index.ets
export * from './Utils'

// har/Utils.ets
export * from './OtherModule3'
export * from './OtherModule4'

也就是说，虽然业务代码只写了一句 from 'har'，但真正使用的能力并不在 Index.ets 本身，而是还要继续穿过 Utils.ets，最后落到具体模块。

路径展开后的方式

如果确认中间模块只是纯转发层，就可以直接依赖真实模块，例如：

import { xxx } from 'har/src/main/ets/OtherModule3'

这样就跳过了 Index.ets 和 Utils.ets 这类中间路径。

为什么这样能优化性能

import 路径展开的价值，不只是“把路径写长”，而是让依赖关系变得更直接。

在原始写法中：

entry -> har/Index.ets -> har/Utils.ets -> OtherModule3.ets

而展开后变成：

entry -> OtherModule3.ets

这样做有两个直接收益：

1. 减少中间模块参与

当 Index.ets、Utils.ets 只是统一出口或转发层时，让业务代码继续经过它们，其实会增加不必要的中间依赖。

路径展开后，依赖会直接落到真实模块，模块链路更短，运行时处理过程也更直接。

2. 避免无关模块被一并带入

统一出口文件常常会同时转发多个模块，例如：

// har/Utils.ets
export * from './OtherModule3'
export * from './OtherModule4'

这意味着业务明明只关心 OtherModule3，但结构上却仍然先依赖了 Utils.ets。 而 import 路径展开之后，业务只连到自己真正使用的那个模块，依赖关系会更精确。

使用时需要注意的问题

import 路径展开虽然能优化性能，但它有一个非常关键的副作用： 会跳过中间模块的执行。

还是以上面的示例来说，如果 har/Index.ets 中不仅仅有导出，还包含执行逻辑，例如：

// har/Index.ets
console.info('har Index.ets execute.')
export * from './Utils'

原始导入：

import { xxx } from 'har'

会经过 Index.ets，因此这段执行逻辑会发生。

但如果改成路径展开：

import { xxx } from 'har/src/main/ets/OtherModule3'

那么 Index.ets 这一层就被跳过了，对应的执行逻辑也不会发生。

这意味着：

• 如果中间模块只是纯转发层，路径展开通常是安全的
• 如果中间模块承担了初始化、注册、配置注入等职责，就要谨慎展开
• 如果业务依赖模块执行顺序，展开后可能引发异常

实践建议

在 ArkTS 工程中，可以遵循以下原则：

1. 对纯导出文件优先展开

如果 Index.ets、Utils.ets 只负责 export，不负责执行逻辑，那么可以优先考虑路径展开。

2. 对存在副作用的中间模块谨慎展开

如果中间模块有 console、初始化调用、注册动作、配置注入等逻辑，就不能只看路径长短，而要先确认语义是否变化。

3. 结合编译配置统一治理

在工程治理中，可以结合项目实际情况，对适合展开的路径进行统一优化，而不是完全依赖人工逐个改 import。

总结

通过这个例子可以看出，import 路径展开的本质并不是改变编码习惯，而是减少中间依赖层，让业务直接依赖真实模块。

它适合的是这类场景：

• 上层 Index.ets 是统一对外接口文件
• 中间模块只是转发层
• 不依赖中间模块执行逻辑
• 目标是优化运行时性能