仓颉-ArkTS 互操作实战：ArkTS 侧用 import 与 loadNativeModule 加载并调用仓颉模块

文档知识库教程OpenHarmony【免费下载链接】CangjieCorpus本仓库为仓颉编程语言语料库聚焦 仓颉编程语言 核心知识体系整合官方开发指南、API 文档、典型代码示例及语法规范等多维度资源经结构化处理与专业标注构建为支持 RAG检索增强生成技术 的高质量知识基座适配智能编码助手、学习辅助工具等应用开发需求。 欢迎开发者基于本语料库构建仓颉语言智能应用推动鸿蒙开发生态智能化升级项目地址https://gitcode.com/Cangjie/CangjieCorpus点击查看免费下载本篇指南聚焦仓颉-ArkTS 互操作中ArkTS 侧使用互操作代码这一环节系统讲解在 OpenHarmony 的 ArkTS 工程中通过import语法静态方式和loadNativeModule接口同步动态加载方式加载仓颉模块并调用仓颉侧导出接口的完整流程。文章覆盖普通仓颉模块、仓颉三方库、静态库模块、HAR 包以及带三方依赖的仓颉库共六种加载场景并结合仓库中的互操作库 API 说明与错误码文档帮助读者从能用进阶到懂原理、会排障。一、先看懂 ArkTS 调用仓颉的整体链路在 OpenHarmony 上仓颉与 ArkTS 的相互调用统称为仓颉-ArkTS 互操作其实现基于仓颉 CFFIC Foreign Function Interface与 ArkTS 运行时接口提供库级别的互操作能力。从开发流程上ArkTS 调用仓颉分为两步仓颉侧实现互操作代码可选声明式互操作宏Interop或仓颉-ArkTS 互操作库两种方式。其中互操作宏以静态声明简化使用、适合初学者互操作库提供JSValue、JSContext等动态类型接口适合与 JavaScript/TypeScript 互相调用的灵活场景详见仓颉-ArkTS 互操作库与声明式互操作宏。ArkTS 侧使用互操作代码即本文主题有两种方式使用import语法加载仓颉模块与静态方式加载 native 模块的方式一致使用loadNativeModule接口加载仓颉模块同步方式动态加载 native 模块。无论哪种方式前提都是先在自己的 ArkTS 工程中创建仓颉模块。在 DevEco Studio 中选中 ArkTS 的entry目录中的任意文件右键选择New - Cangjie(Interop)即可自动生成cjpm.toml配置文件和cangjie文件夹内含模板代码index.cj与存放互操作接口声明的types文件夹同时会在entry/oh-package.json5中自动生成仓颉依赖。静态库模块则在工程名上右键New - Module选择[Cangjie] Static Library创建。完整创建步骤请参见在 ArkTS 工程中添加仓颉模块。二、方式一使用 import 语法加载仓颉模块import方式的核心思路是把仓颉模块编译产物.so动态库或静态库当作一个可导入的依赖包通过oh-package.json5的dependencies声明其路径再在 ArkTS 代码中直接import。下面按六种场景依次展开。2.1 加载工程内仓颉模块并调用接口ohos_app_cangjie_entry addNumber这是最基础的场景仓颉模块与 ArkTS 模块位于同一个工程同一 module内ArkTS 侧调用仓颉侧实现的addNumber两数相加接口。第 1 步在 ArkTS 工程中创建仓颉模块。创建后仓颉侧生成entry/src/main/cangjie/index.cj模板文件详见在 ArkTS 工程中添加仓颉模块。第 2 步实现仓颉侧互操作接口。在index.cj中编写互操作函数并完成 ArkTS 侧类型声明// entry/src/main/cangjie/index.cj // 定义包名该包名需要和 cjpm.toml 的 package name 保持一致 package ohos_app_cangjie_entry // 导入互操作库 import ohos.ark_interop.* // 定义互操作函数该函数参数类型必须为(JSContext,JSCallInfo)返回值类型必须为JSValue func addNumber(context: JSContext, callInfo: JSCallInfo): JSValue { // 从JSCallInfo获取参数列表 let arg0: JSValue callInfo[0] let arg1: JSValue callInfo[1] // 把JSValue转换为仓颉类型 let a: Float64 arg0.toNumber() let b: Float64 arg1.toNumber() // 实际仓颉函数行为 let value a b // 把结果转换为JSValue let result: JSValue context.number(value).toJSValue() // 返回 JSValue return result } // 必须注册该函数到JSModule中 let EXPORT_MODULE JSModule.registerModule { runtime, exports exports[addNumber] runtime.function(addNumber).toJSValue() }这段代码是互操作库方式的标准模板几个要点值得注意包名即模块名package ohos_app_cangjie_entry必须与cjpm.toml中配置的 package name 保持一致因为最终生成的动态库名就是包名对应的libohos_app_cangjie_entry.soArkTS 侧导入时靠这个名字定位符号。固定的函数签名每个要导出的互操作函数参数必须是(JSContext, JSCallInfo)返回值必须是JSValue。JSContext是单线程执行的 ArkTS 互操作上下文JSCallInfo是一次 ArkTS 函数调用的参数集合可通过callInfo[0]、callInfo[1]按下标取入参也可用callInfo.count获取入参数量、callInfo.thisArg获取 this 指针。类型双向转换arg0.toNumber()把统一类型JSValue转成仓颉Float64context.number(value).toJSValue()则把仓颉数值包装为JSValue再返回。必须注册导出通过JSModule.registerModule把addNumber注册进导出表ArkTS 引擎在动态库加载时才拿得到这个符号。除registerModule外JSModule还提供registerFunc导出函数与registerClass导出类等注册入口。接着在types文件夹中提供 ArkTS 侧的接口声明.d.ts并关联 so 库// entry/src/main/cangjie/types/libohos_app_cangjie_entry/Index.d.ts export declare function addNumber(a: number, b: number): number;// entry/src/main/cangjie/types/libohos_app_cangjie_entry/oh-package.json5 { name: libohos_app_cangjie_entry.so, types: ./Index.d.ts, version: 1.0.0, description: }说明以上 oh-package.json5 无须复制创建仓颉模块以后工程中已自动配置好。其中name为互操作代码对应的包名对应的 so 名types指向Index.d.ts声明文件。第 3 步在 ArkTS 模块的oh-package.json5中配置对 so 库的依赖。// entry/oh-package.json5 { dependencies: { // ... libohos_app_cangjie_entry.so: file:./src/main/cangjie/types/libohos_app_cangjie_entry // ... } }第 4 步ArkTS 侧使用 import 语法直接导入仓颉模块并调用接口。// 导入仓颉动态库该动态库名称为仓颉包名的名称该名称需要和互操作接口所在的包名一致 import { addNumber } from libohos_app_cangjie_entry.so; // 调用仓颉接口 let result addNumber(1, 2); console.log(1 2 ${result});运行后可得到1 2 3。注意一个名称一致性铁律import 的模块名libohos_app_cangjie_entry.so、oh-package.json5 的name字段、仓颉侧的package名必须彼此对应任一处对不上都会导致加载失败。2.2 加载仓颉三方库并调用接口libapplication.so当仓颉侧的能力被打包成独立的.so三方库例如libapplication.so已实现可供 ArkTS 调用的addNumber接口时加载步骤稍有不同在 ArkTS 工程中创建仓颉模块同上作为承载声明的载体。在 ArkTS 工程新建libs/arm64-v8a目录将仓颉三方库libapplication.so拷贝到该目录下。创建仓颉三方库libapplication.so的接口声明在types/libapplication文件夹下新建Index.d.ts与oh-package.json5。// entry/src/main/cangjie/types/libapplication/Index.d.ts export declare function addNumber(a: number, b: number): number;// entry/src/main/cangjie/types/libapplication/oh-package.json5 { name: libapplication.so, types: ./Index.d.ts, version: 1.0.0, description: }在 ArkTS 模块内的oh-package.json5中声明 so 库的根目录路径// entry/oh-package.json5 { dependencies: { // ... libapplication.so: file:./src/main/cangjie/types/libapplication // ... } }ArkTS 侧使用 import 语法直接导入三方库并调用// 导入仓颉动态库该动态库名称为仓颉三方库的名称该名称需要和互操作接口所在的包名一致 import { addNumber } from libapplication.so; // 调用仓颉接口 let result addNumber(1, 2); console.log(1 2 ${result});与 2.1 的唯一区别在于so 文件不是由本工程编译产生而是以三方库身份放置在libs/arm64-v8a由开发者手工拷贝声明文件与依赖配置的写法完全一致。2.3 加载仓颉静态库模块并调用接口cangjielib仓颉静态库模块如cangjielib通过New - Module - [Cangjie] Static Library创建是独立于entry的另一个模块工程结构为cangjielib/src/main/cangjie/。创建仓颉静态库模块cangjielib详见在 ArkTS 工程中添加仓颉模块。在cangjielib/src/main/cangjie/index.cj中实现互操作接口// cangjielib/src/main/cangjie/index.cj // 包名 package ohos_app_cangjie_cangjielib // 导入文件 internal import ohos.ark_interop.JSModule internal import ohos.ark_interop.JSContext internal import ohos.ark_interop.JSCallInfo internal import ohos.ark_interop.JSValue // 互操作函数 func addNumber(context: JSContext, callInfo: JSCallInfo): JSValue { // 从JSCallInfo获取参数列表 let arg0: JSValue callInfo[0] let arg1: JSValue callInfo[1] // 把JSValue转换为仓颉类型 let a: Float64 arg0.toNumber() let b: Float64 arg1.toNumber() // 实际仓颉函数行为 let value a b // 把结果转换为JSValue let result: JSValue context.number(value).toJSValue() // 返回 JSValue return result } let EXPORT_MODULE JSModule.registerModule { runtime, exports exports[addNumber] runtime.function(addNumber).toJSValue() }这里采用internal import逐个导入ohos.ark_interop下的类型与 2.1 的import ohos.ark_interop.*通配导入等价两种写法均可。提供 ArkTS 侧声明。在cangjielib/src/main/cangjie/types/libohos_app_cangjie_cangjielib文件夹下创建Index.d.ts与oh-package.json5// cangjielib/src/main/cangjie/types/libohos_app_cangjie_cangjielib/Index.d.ts export declare function addNumber(a: number, b: number): number;// cangjielib/src/main/cangjie/types/libohos_app_cangjie_cangjielib/oh-package.json5 { name: libohos_app_cangjie_cangjielib.so, types: ./Index.d.ts, version: 1.0.0, description: }在 ArkTS 模块的entry/oh-package.json5中配置对静态库模块及对应 so 的依赖// entry/oh-package.json5 { dependencies: { // ... cangjielib: ../cangjielib, libohos_app_cangjie_cangjielib.so: file:../cangjielib/src/main/cangjie/types/ohos_app_cangjie_cangjielib // ... } }注意这里出现了两项依赖cangjielib指向静态库模块本体供仓颉源码引用libohos_app_cangjie_cangjielib.so指向其声明文件目录供 ArkTS 类型解析。ArkTS 侧导入调用// 导入仓颉动态库该动态库名称为仓颉包名的名称该名称需要和互操作接口所在的包名一致 import { addNumber } from libohos_app_cangjie_cangjielib.so; // 调用仓颉接口 let result addNumber(1, 2); console.log(1 2 ${result});2.4 加载本地 HAR 包并调用仓颉接口若仓颉能力被打包进本地 HAR 包例如cangjielib.har其中包含libohos_app_cangjie_cangjielib.so且 so 内已实现addNumber加载方式如下在 ArkTS 工程中创建仓颉模块作为声明载体。将本地 HAR 包cangjielib.har拷贝到 ArkTS 工程的libs目录下。创建libohos_app_cangjie_cangjielib.so的接口声明在types/libohos_app_cangjie_cangjielib下新建Index.d.ts与oh-package.json5// entry/src/main/cangjie/types/libohos_app_cangjie_cangjielib/Index.d.ts export declare function addNumber(a: number, b: number): number;// entry/src/main/cangjie/types/libohos_app_cangjie_cangjielib/oh-package.json5 { name: libohos_app_cangjie_cangjielib.so, types: ./Index.d.ts, version: 1.0.0, description: }在 ArkTS 模块内的oh-package.json5中同时声明 HAR 包与 so 的根目录路径// entry/oh-package.json5 { dependencies: { // ... cangjielib: file:libs/cangjielib.har, libohos_app_cangjie_cangjielib.so: file:src/main/cangjie/types/ohos_app_cangjie_cangjielib // ... } }ArkTS 侧导入调用// 导入仓颉动态库该动态库名称为仓颉包名的名称该名称需要和互操作接口所在的包名一致 import { addNumber } from libohos_app_cangjie_cangjielib.so; // 调用仓颉接口 let result addNumber(1, 2); console.log(1 2 ${result});与 2.2 相比这里声明依赖时cangjielib指向file:libs/cangjielib.harHAR 包文件so 的声明路径则是工程内的相对目录。2.5 仓颉三方库 A 依赖三方库 B三种装配方案当 ArkTS 需要加载仓颉三方库 A 中的returnA接口而returnA内部又依赖三方库 B 的returnB接口时需要解决库间依赖如何打包、如何被 ArkTS 解析的问题。原文档给出了三种方案。方案一通过 cjpm.toml 配置三方库依赖在 ArkTS 工程中新建package_a和package_b两个目录分别创建源文件与 cjpm.toml// package_a/a.cj package package_a // 导入互操作库 import ohos.ark_interop.JSModule import ohos.ark_interop.JSContext import ohos.ark_interop.JSCallInfo import ohos.ark_interop.JSValue // 导入三方库 B import package_b.returnB // 定义三方库 A 中的 returnA 接口 public func returnA(context: JSContext, callInfo: JSCallInfo): JSValue { let result A returnB() return context.string(result).toJSValue() } // 注册该函数到JSModule中 let EXPORT_MODULE JSModule.registerModule { runtime, exports exports[returnA] runtime.function(returnA).toJSValue() }// package_b/b.cj package package_b public func returnB(): String { return B }在三方库 A 的cjpm.toml的dependencies字段添加对三方库 B 的依赖# package_a/cjpm.toml [dependencies] [dependencies.package_b] path ../package_b在 ArkTS 工程中创建仓颉模块作为声明载体。创建仓颉三方库 A 的接口声明在types/libpackage_a下新建Index.d.ts与oh-package.json5// entry/src/main/cangjie/types/libpackage_a/Index.d.ts export declare function returnA(): string;// entry/src/main/cangjie/types/libpackage_a/oh-package.json5 { name: libpackage_a.so, types: ./Index.d.ts, version: 1.0.0, description: }在 ArkTS 模块内的oh-package.json5中声明仓颉三方库 A 的根目录路径// entry/oh-package.json5 { dependencies: { // ... libpackage_a.so: file:./src/main/cangjie/types/libpackage_a // ... } }在entry模块内的cjpm.toml的dependencies字段声明仓颉三方库 A 的路径# entry/cjpm.toml [dependencies] [dependencies.package_a] path ../package_aArkTS 侧导入三方库 A 并调用// 导入仓颉动态库该动态库名称为仓颉三方库的名称该名称需要和互操作接口所在的包名一致 import { returnA } from libpackage_a.so; // 调用仓颉接口 let result returnA(); console.log(${result});方案二三方库 B 作为三方库 A 的子包子包方案不需要独立的package_b/cjpm.toml把package_b目录放进package_a内部即可// package_a/a.cj package package_a // 导入互操作库 import ohos.ark_interop.JSModule import ohos.ark_interop.JSContext import ohos.ark_interop.JSCallInfo import ohos.ark_interop.JSValue // 导入子包 B import package_a.package_b.returnB // 定义三方库 A 中的 returnA 接口 public func returnA(context: JSContext, callInfo: JSCallInfo): JSValue { let result A returnB() return context.string(result).toJSValue() } // 注册该函数到JSModule中 let EXPORT_MODULE JSModule.registerModule { runtime, exports exports[returnA] runtime.function(returnA).toJSValue() }// package_a/package_b/b.cj package package_a.package_b public func returnB(): String { return B }其后的 ArkTS 侧声明、entry/oh-package.json5依赖、entry/cjpm.toml依赖与 ArkTS import 代码与方案一完全相同libpackage_a.so、returnA不再赘述。区别仅在仓颉侧组织方式B 的包名变为package_a.package_bimport 语句相应改为import package_a.package_b.returnB。方案三三方库 B 作为一个模块编译成 har 包创建仓颉静态库模块package_b详见在 ArkTS 工程中添加仓颉模块并在模块下声明returnB接口// package_b/src/main/cangjie/index.cj package ohos_app_cangjie_package_b public func returnB(): String { return B }在 ArkTS 模块内的oh-package.json5中配置对静态库模块package_b的依赖// entry/oh-package.json5 { dependencies: { // ... package_b: ../package_b, // ... } }在 ArkTS 工程中创建仓颉模块声明载体。在cangjie文件夹下新建package_a目录其中新建src/a.cj与cjpm.toml// entry/src/main/cangjie/package_a/src/a.cj package package_a // 导入互操作库 import ohos.ark_interop.JSModule import ohos.ark_interop.JSContext import ohos.ark_interop.JSCallInfo import ohos.ark_interop.JSValue // 导入三方库 B import ohos_app_cangjie_package_b.returnB // 定义三方库 A 中的 returnA 接口 public func returnA(context: JSContext, callInfo: JSCallInfo): JSValue { let result A returnB() return context.string(result).toJSValue() } // 注册该函数到JSModule中 let EXPORT_MODULE JSModule.registerModule { runtime, exports exports[returnA] runtime.function(returnA).toJSValue() }在三方库 A 的cjpm.toml的dependencies字段添加对三方库 B 的依赖# entry/src/main/cangjie/package_a/cjpm.toml [dependencies] [dependencies.ohos_app_cangjie_package_b] path ${package_b}创建三方库 A 的 ArkTS 侧声明types/libpackage_a下的Index.d.ts与oh-package.json5内容同方案一。在 ArkTS 模块内的oh-package.json5中声明三方库 A 和静态库模块package_b的路径// entry/oh-package.json5 { dependencies: { // ... package_b: ../package_b, libpackage_a.so: file:./src/main/cangjie/types/libpackage_a // ... } }在entry模块内的cjpm.toml中声明三方库 A 的路径# entry/cjpm.toml [dependencies] [dependencies.package_a] path ../package_aArkTS 侧导入调用// 导入仓颉动态库该动态库名称为仓颉三方库的名称该名称需要和互操作接口所在的包名一致 import { returnA } from libpackage_a.so; // 调用仓颉接口 let result returnA(); console.log(${result});三种方案的核心差异在于B 库的交付形态方案一把 B 作为独立源码包通过cjpm.toml路径依赖引入方案二把 B 折叠为 A 的子包方案三把 B 编译成可复用的 har 包静态库模块。而 ArkTS 侧永远只 import 暴露了returnA的libpackage_a.soB 的依赖关系被封闭在仓颉构建体系中。三、方式二使用 loadNativeModule 接口加载仓颉模块loadNativeModule是同步方式动态加载 native 模块的接口与import静态方式相比它不依赖编译期的依赖声明而是在运行时以模块名加载 so返回一个ESObject类型的模块对象再通过对象属性调用仓颉导出的函数。适合需要动态决定加载哪个模块、或仅在特定逻辑分支使用仓颉能力的场景。仍以加载ohos_app_cangjie_entry模块并调用addNumber为例在 ArkTS 工程中创建仓颉模块详见在 ArkTS 工程中添加仓颉模块。仓颉侧互操作接口实现与 2.1 完全相同index.cj中定义addNumber并通过JSModule.registerModule注册同时在types/libohos_app_cangjie_entry下提供Index.d.ts声明与oh-package.json5关联// entry/src/main/cangjie/index.cj // 定义包名该包名需要和 cjpm.toml 的 package name 保持一致 package ohos_app_cangjie_entry // 导入互操作库 import ohos.ark_interop.* // 定义互操作函数该函数参数类型必须为(JSContext,JSCallInfo)返回值类型必须为JSValue func addNumber(context: JSContext, callInfo: JSCallInfo): JSValue { // 从JSCallInfo获取参数列表 let arg0: JSValue callInfo[0] let arg1: JSValue callInfo[1] // 把JSValue转换为仓颉类型 let a: Float64 arg0.toNumber() let b: Float64 arg1.toNumber() // 实际仓颉函数行为 let value a b // 把结果转换为JSValue let result: JSValue context.number(value).toJSValue() // 返回 JSValue return result } // 必须注册该函数到JSModule中 let EXPORT_MODULE JSModule.registerModule { runtime, exports exports[addNumber] runtime.function(addNumber).toJSValue() }// entry/src/main/cangjie/types/libohos_app_cangjie_entry/Index.d.ts export declare function addNumber(a: number, b: number): number;// entry/src/main/cangjie/types/libohos_app_cangjie_entry/oh-package.json5 { name: libohos_app_cangjie_entry.so, types: ./Index.d.ts, version: 1.0.0, description: }在 ArkTS 模块内的oh-package.json5中配置对 so 库的依赖// entry/oh-package.json5 { dependencies: { // ... libohos_app_cangjie_entry.so: file:./src/main/cangjie/types/libohos_app_cangjie_entry // ... } }ArkTS 侧使用loadNativeModule加载并调用// 使用 loadNativeModule 接口加载仓颉动态库 let module: ESObject loadNativeModule(libohos_app_cangjie_entry.so); // 调用仓颉接口 let result: number module.addNumber(1, 2); console.log(1 2 ${result});注意调用形态的差异import方式直接import { addNumber } from ...后以函数形式调用loadNativeModule方式则先拿到模块对象module再以module.addNumber(1, 2)的属性访问形式调用。四、互操作库核心类型与导出注册机制理解 ArkTS 侧加载之前仓颉侧的互操作库ohos.ark_interop提供了几个关键类型本文示例全部用到了它们详见ohos.ark_interopArkTS互操作库类型作用本文对应用法JSValueArkTS 运行时统一类型跨语言传参的载体弱类型、短生命周期只能由互操作接口创建callInfo[0]、arg0.toNumber()、返回值JSContext单线程执行的 ArkTS 互操作上下文与 ArkTS 运行时一一对应负责创建 JSValue 与安全引用context.number(...)、context.string(...)JSCallInfo一次 ArkTS 函数调用的参数集合含全部入参与 this 指针生命周期仅限本次调用callInfo[0]、callInfo[1]、callInfo.count、callInfo.thisArgJSModule提供符号导出能力的静态类把导出目标注册到全局表由 ArkTS 引擎执行导出JSModule.registerModule { runtime, exports ... }JSModule.registerModule的参数是一个形如{ runtime, exports ... }的注册闭包闭包内通过exports[接口名] runtime.function(函数).toJSValue()把仓颉函数包装成JSValue挂到导出表。在动态库被加载时这些导出目标会被注册到全局表供 ArkTS 引擎解析——这正是前文所有场景中 ArkTS 侧能import到addNumber、returnA等符号的底层机制。符号覆盖风险在同一个仓颉模块同一个包及其子包中需遵守两条命名规则否则可能出现符号覆盖使用JSModule.registerModule、JSModule.registerClass、JSModule.registerFunc注册到 JSModule 中的函数、interface、class 不能同名。例如同一注册块内先后执行exports[addNumber] ...两次后者会覆盖前者。注册到 JSModule 中的符号与使用Interop修饰的函数、interface、class 也不能同名否则互操作宏导出的同名函数会被注册表的同名导出覆盖。五、加载失败怎么办互操作错误码速查ArkTS 侧加载或调用仓颉接口过程中抛出的异常以BusinessException形式出现对应3430000x系列错误码详见ArkTS互操作库错误码错误码错误信息常见原因与处理34300001非法索引callInfo索引小于 0 或大于入参上限确认索引位于[0, 入参数量)区间34300002ArkTS 代码异常ArkTS 运行时异常如 StackOverflow或调用的 ArkTS 函数逻辑错误排查传参与函数实现34300003访问非法对象超出作用域访问JSValue、访问已完成回调的JSPromiseCapability、运行时释放后继续访问JSContext改用安全引用逃逸作用域34300004线程校验失败在非 ArkTS 运行线程上创建或访问 ArkTS 对象互操作前可用JSContext.isBindThread()判断当前线程34300005类型校验失败ArkTS 数据类型不匹配例如把 number 强转为 JSString操作数据前先判断类型34300006导入的 ArkTS 模块不存在仓颉侧导入的模块路径错误或系统模块在低版本系统上不存在检查路径与设备 ApiLevel34300007在仓颉导出 ArkTS 接口期间不能导入 ArkTS 模块在注册的模块导出函数中调用了requireArkModule移除或延迟调用34300008当前应用不支持导入指定 ArkTS 模块在仓颉应用里导入 ArkTS 源码模块尚不支持时抛出其中34300003访问超出生命周期的对象与34300004线程不匹配是互操作库方式下最常见的两类问题前者要求开发者理解JSValue的短生命周期特性后者要求严格在 ArkTS 运行线程上进行互操作。六、两种使用方式对比与选型建议维度import 语法静态loadNativeModule同步动态加载时机编译期声明依赖构建期解析运行期以模块名加载调用写法import { fn } from libxxx.so后直接函数调用loadNativeModule(libxxx.so)取ESObject再module.fn(...)适用场景模块固定、需类型提示、追求首屏性能运行时动态选择模块、条件加载前提条件仓颉模块已通过JSModule.registerModule等注册导出与 import 方式完全相同两种方式共享同一套前置条件仓颉侧必须用互操作库或互操作宏实现并注册导出接口oh-package.json5与Index.d.ts声明齐备且 so 名称与仓颉包名保持一致。差别只在于 ArkTS 侧怎么拿这个模块。开发时建议模块结构固定且长期复用优先import需要在运行时按条件加载不同仓颉库再考虑loadNativeModule。延伸阅读本文聚焦ArkTS 侧使用互操作代码完整互操作开发涉及的前置与进阶内容可继续阅读仓库中的配套文档仓颉-ArkTS 互操作概述互操作的整体架构与场景划分在 ArkTS 工程中添加仓颉模块仓颉模块与静态库模块的 IDE 创建步骤仓颉-ArkTS 互操作库互操作库方式的完整开发流程与符号命名约束声明式互操作宏Interop宏方式及类型映射表ArkTS 调用仓颉ArkTS 调用仓颉的两步开发总览ohos.ark_interopArkTS互操作库 与 ArkTS互操作库错误码核心 API 与错误码的权威参考。赞分享文档知识库教程OpenHarmony【免费下载链接】CangjieCorpus本仓库为仓颉编程语言语料库聚焦 仓颉编程语言 核心知识体系整合官方开发指南、API 文档、典型代码示例及语法规范等多维度资源经结构化处理与专业标注构建为支持 RAG检索增强生成技术 的高质量知识基座适配智能编码助手、学习辅助工具等应用开发需求。 欢迎开发者基于本语料库构建仓颉语言智能应用推动鸿蒙开发生态智能化升级项目地址https://gitcode.com/Cangjie/CangjieCorpus点击查看免费下载相关推荐鸿蒙跨语言开发实战仓颉与ArkTS互操作全指南鸿蒙跨语言开发实战仓颉与ArkTS互操作全指南 你还在为鸿蒙应用开发中跨语言调用难题困扰本文将通过19 CangjiexArkTS示例项目系统讲解仓颉C示例工程仓颉调用 ArkTS API 实战基于 JSFFI 互操作库实现 HarmonyOS 日历服务HarmonyOS-Examples CangjieCallArkTS仓颉调用 ArkTS API 实战基于 JSFFI 互操作库实现 HarmonyOS 日历服务HarmonyOS Examples CangjieCallA示例工程仓颉与ArkTS互操作实战基于 HarmonyOS-Examples OCR 应用的混合编程全解析仓颉与ArkTS互操作实战基于 HarmonyOS Examples OCR 应用的混合编程全解析 导读 本文以 19 CangjiexArkTS/OCR h示例工程上一篇如何快速解密QQ音乐加密音频qmc-decoder终极指南下一篇QQ音乐加密音频格式解密高性能C解码引擎技术解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考