Rust登陸【華為鴻蒙】操作系統(tǒng)之Native模塊開(kāi)發(fā)

名詞解釋

• 【鴻蒙操作系統(tǒng)】的英文全名是Open Harmony Operation System。正文將以其首字母縮寫(xiě)詞ohos引用該詞條。

• 【鴻蒙軟件開(kāi)發(fā)工具包】的英文全名是Open Harmony Software Development Kit。正文也將以它的首字母縮寫(xiě)詞ohsdk引用該詞條。

• DevEco Studio IDE是【華為】為鴻蒙應(yīng)用程序開(kāi)發(fā)免費(fèi)提供的集成開(kāi)發(fā)環(huán)境。它的最新穩(wěn)定版內(nèi)置了ohsdk 3.1.0 (API v9)。

• 【Native模塊】是指由遵循了ArkTs NAPI接口規(guī)范的C/Cpp/Rust程序經(jīng)交叉編譯輸出的鏈接庫(kù).so文件。

前言

到寫(xiě)文章時(shí)止，雖然華為技術(shù)團(tuán)隊(duì)既未將rustup工具鏈無(wú)縫集成入DevEco Studio IDE也未提供ArkTs + Rust的“一站式”混合編程體驗(yàn)，但Rust登陸ohos依舊勢(shì)不可擋，因?yàn)橄噍^于Rust帶來(lái)的生產(chǎn)效率收益（參照c / cpp），搭建交叉編譯環(huán)境的人工成本真的微不足道。甚至，求助于【操作系統(tǒng)鏡像】或Docker技術(shù)，@Rustacean 還能避免這類(lèi)重復(fù)性勞動(dòng)的再次發(fā)生。

為了填補(bǔ)DevEco Studio IDE與rustup工具鏈之間的“窄溝”，僅有兩步操作需被執(zhí)行：

1. 搭建面向ohos的交叉編譯環(huán)境。

• 限于作者dev box是Windows 11，所以本篇文章僅分享從Windows至ohos的交叉編譯環(huán)境搭建心得。

將交叉編譯輸出的.so文件注入DevEco Studio工作流。

搭建Windows ?? ohos交叉編譯環(huán)境

鑒于華為硬件產(chǎn)品的三款主流CPU架構(gòu)，@Rustacean 需同時(shí)準(zhǔn)備三套交叉編譯方案，分別是：

• 面向64位ARM CPU的aarch64-unknown-linux-ohos方案。

• 面向32位ARM CPU的armv7-unknown-linux-ohos方案。

• 面向64位AMD / Intel CPU的x86_64-unknown-linux-ohos方案。

前兩套方案是為【真機(jī)】設(shè)備提供動(dòng)態(tài)鏈接庫(kù)/Native模塊；而后一套方案則是服務(wù)于手機(jī)模擬器（虛擬機(jī)）的。

上表中Triple的信息描述格式統(tǒng)一是：

<CPU架構(gòu)><CPU子架構(gòu)>-<廠商>-<操作系統(tǒng)>-<應(yīng)用程序二進(jìn)制接口格式>

于是，armv7-unknown-linux-ohos應(yīng)被讀作

【廠商】欄的unkown是Mozilla公司的“鍋”，而不是我定的。就我本意，這一欄餒餒的是漢語(yǔ)拼音HuaWei。

下面上干貨了...

第一步，給ohsdk補(bǔ)裝native組件

DevEco Studio IDE的內(nèi)置ohsdk位于%LocalAppData%\Huawei\Sdk\openharmony\<API 版本號(hào)>目錄下，但其初始安裝卻缺失了native組件（— 可能是因?yàn)檫@個(gè)模塊太大了，超過(guò)2GB）。所以，@Rustacean 需要

1. 補(bǔ)裝native組件

2. 記住ohsdk對(duì)應(yīng)的【API版本號(hào)】，因?yàn)楹罄m(xù)配置得用。

具體步驟

1. 打開(kāi)DevEco Studio IDE

2. 若出現(xiàn)的是【歡迎界面】，就從菜單Configure ? Settings，打開(kāi)Settings對(duì)話框

3. 若出現(xiàn)的是【工程界面】，就從菜單File ? Settings，打開(kāi)Settings對(duì)話框

4. 從對(duì)話框左側(cè)選擇SDK；從右側(cè)查看Platform選項(xiàng)卡下面的內(nèi)容

5. 尋找并記憶被勾選的【SDK版本號(hào) (API版本號(hào))】。比如，下圖中的3.1.0 (API 9)。

   

6. 勾選native復(fù)選框

7. 點(diǎn)擊OK按鈕

8. 等待native組件安裝完成 — 耐心點(diǎn)兒，等待時(shí)間可不短

待上述操作都正常完成之后，便可見(jiàn)如下所示的新目錄結(jié)構(gòu)

第二步，重新編譯Rust標(biāo)準(zhǔn)庫(kù)

之所以把事情搞這么大是因?yàn)?code>Mozilla廠方并沒(méi)有為ohos提供預(yù)編譯的【標(biāo)準(zhǔn)庫(kù)】二進(jìn)制文件。于是，盡管ohos已被納入了rustc交叉編譯支持清單（請(qǐng)見(jiàn)下圖）

，但直接執(zhí)行交叉編譯指令

cargo?build?--release?--target=aarch64-unknown-linux-ohos

還是會(huì)遭遇失敗和看到E0463號(hào)錯(cuò)誤

技術(shù)方案選型

編譯【標(biāo)準(zhǔn)庫(kù)】源碼有兩條技術(shù)路徑

1. 重新編譯整條rustup工具鏈，捎帶著也就編譯出【標(biāo)準(zhǔn)庫(kù)】了 — 難！我沒(méi)搞定

2. 將【標(biāo)準(zhǔn)庫(kù)】作為普通依賴crate和Cargo (Lib) Package工程的業(yè)務(wù)代碼一起編譯（— 注：這個(gè)解釋并不精確，因?yàn)榧?xì)究起來(lái)主crate與依賴crates是攪和在一起的各自獨(dú)立編譯，而不是絕對(duì)意義上的“一鍋燴”）。下圖中被紅框圈定的crates就都出自于【標(biāo)準(zhǔn)庫(kù)】

   

我選擇了第二條技術(shù)路線。雖然后一條技術(shù)路線拖長(zhǎng)了程序編譯的總用時(shí)，但它僅會(huì)影響首次編譯操作。從那以后，借助sccache編譯緩存技術(shù)，由【標(biāo)準(zhǔn)庫(kù)】引入的額外延時(shí)幾乎可以忽略不計(jì)。更重要的是，該技術(shù)路線不會(huì)阻塞 @Rustacean 對(duì)rustup工具鏈的后續(xù)升級(jí)。咱們隨時(shí)都可以rustup update。

采用【方案二】的準(zhǔn)備工作與先決條件

1. 給rustup工具鏈，補(bǔ)裝【標(biāo)準(zhǔn)庫(kù)】源碼（即，rust-src組件）。

   從命令行，立即執(zhí)行且僅執(zhí)行一次：

   rustup?component?add?rust-src

2. 啟用nigtly工具鏈，因?yàn)楣ぞ哝湹?code>stable版本還尚不支持“裹挾【標(biāo)準(zhǔn)庫(kù)】共同編譯”的新功能。

   從命令行，立即執(zhí)行且僅執(zhí)行一次：

   rustup?default?nightly

3. 采用ohsdk內(nèi)置的llvm - clang作為rustc鏈接器（下一節(jié)將詳細(xì)介紹）

4. 向交叉編譯指令添加新命令行參數(shù)-Zbuild-std。

   1. cargo會(huì)透?jìng)髟搮?shù)給rustc并指示編譯器不是尋找現(xiàn)成的【標(biāo)準(zhǔn)庫(kù)】鏈接文件而是現(xiàn)場(chǎng)編譯【標(biāo)準(zhǔn)庫(kù)】源碼。

   2. 編譯指令也將變?yōu)?/p>

      cargo?+nightly?build?-Zbuild-std?--release?--target=aarch64-unknown-linux-ohos

如何把ohsdk內(nèi)置的llvm - clang作為rustc鏈接器

第一步，回憶之前記下的【鴻蒙API版本號(hào)】數(shù)字和新建環(huán)境變量OHOS_API_V。【推薦】從Cargo全局配置文件%UserProfile%\.cargo\config.toml新建OHOS_API_V環(huán)境變量，因?yàn)?/p>

• 一方面，這可最小化對(duì)系統(tǒng)環(huán)境的“污染” — 該變量?jī)H對(duì)Rust交叉編譯有用，沒(méi)有必要系統(tǒng)級(jí)全局可見(jiàn)。

• 另一方面，它隨時(shí)可被【會(huì)話級(jí)】同名環(huán)境變量短暫復(fù)寫(xiě)，方便以后臨時(shí)變更做試驗(yàn)。

打開(kāi)%UserProfile%\.cargo\config.toml配置文件和添加配置表

[env]
OHOS_API_V = "9"

【注意】伴隨今后ohsdk的自動(dòng)升級(jí)，該環(huán)境變量的值須被同步地手動(dòng)更新，以避免編譯失敗。

第二步，將ohsdk目錄下的LLVM前端編譯器llvm\bin\clang.exe包裝為rustc的【鴻蒙鏈接器】。敲黑板，重點(diǎn)來(lái)了！@Rustacean 需分別構(gòu)建三個(gè)鏈接器，以服務(wù)三套交叉編譯方案，和向華為的三類(lèi)硬件設(shè)備提供.so文件。于是，有

• 【鏈接器1】面向64位ARM CPU真機(jī)的aarch64-unknown-linux-ohos交叉編譯方案。在%UserProfile%目錄下，新建cmd文件aarch64-unknown-linux-ohos-clang.cmd，并添加如下代碼

  %LocalAppData%\Huawei\Sdk\openharmony\%OHOS_API_V%\native\llvm\bin\clang.exe ^
  -target aarch64-linux-ohos ^
  --sysroot=%LocalAppData%\Huawei\Sdk\openharmony\%OHOS_API_V%\native\sysroot ^
  -D__MUSL__ %*

• 【鏈接器2】面向32位ARM CPU真機(jī)的armv7-unknown-linux-ohos交叉編譯方案。在%UserProfile%目錄下，新建cmd文件armv7-unknown-linux-ohos-clang.cmd，并添加如下代碼

  %LocalAppData%\Huawei\Sdk\openharmony\%OHOS_API_V%\native\llvm\bin\clang.exe ^
  -target arm-linux-ohos ^
  --sysroot=%LocalAppData%\Huawei\Sdk\openharmony\%OHOS_API_V%\native\sysroot ^
  -D__MUSL__ ^
  -march=armv7-a ^
  -mfloat-abi=softfp ^
  -mtune=generic-armv7-a ^
  -mthumb %*

• 【鏈接器3】面向64位AMD / Intel CPU模擬器的x86_64-unknown-linux-ohos交叉編譯方案。在%UserProfile%目錄下，新建cmd文件x86_64-unknown-linux-ohos-clang.cmd，并添加如下代碼

  %LocalAppData%\Huawei\Sdk\openharmony\%OHOS_API_V%\native\llvm\bin\clang.exe ^
  -target x86_64-linux-ohos ^
  --sysroot=%LocalAppData%\Huawei\Sdk\openharmony\%OHOS_API_V%\native\sysroot ^
  -D__MUSL__ %*

第三步，全局且有條件地向rustc裝配【鴻蒙鏈接器】。其中，

• 【全局】意味著修改Cargo全局配置文件%UserProfile%\.cargo\config.toml和作用于所有Cargo Package工程。

• 【有條件】意味著采用條件編譯語(yǔ)法target.<triple>.linker限定該【鏈接器】?jī)H生效于面向ohos的交叉編譯操作。

具體作法，打開(kāi)%UserProfile%\.cargo\config.toml配置文件和添加配置表

[target.aarch64-unknown-linux-ohos]
linker = "./aarch64-unknown-linux-ohos-clang.cmd"
[target.armv7-unknown-linux-ohos]
linker = "./armv7-unknown-linux-ohos-clang.cmd"
[target.x86_64-unknown-linux-ohos]
linker = "./x86_64-unknown-linux-ohos-clang.cmd"
[profile.dev.package.compiler_builtins]
opt-level = 2

再對(duì)前面配置片段補(bǔ)充兩點(diǎn)解釋?zhuān)?/p>

1. 配置項(xiàng)linker以相對(duì)路徑引用鏈接器文件的背后邏輯是cargo總是以config.toml的父文件夾（.cargo）所處目錄為起點(diǎn)開(kāi)始解析相對(duì)路徑（，而不是以config.toml的同級(jí)目錄為起點(diǎn)）。所以，本例中的./路徑前綴對(duì)應(yīng)的就是登錄賬號(hào)的根目錄%UserProfile%。

2. 配置項(xiàng)opt-level，借助【Profile重寫(xiě)（i.e. Override）】配置表頭[profile.dev.package.compiler_builtins]，僅將【開(kāi)發(fā)編譯】模式下【標(biāo)準(zhǔn)庫(kù)】?jī)?nèi)compiler_builtins crate的代碼優(yōu)化級(jí)別強(qiáng)制錨定于2。否則，cargo build -Zbuild-std --target=aarch64-unknown-linux-ohos指令（注意：沒(méi)有--release參數(shù)）會(huì)概率性地失敗于exit code: 0xc0000005, STATUS_ACCESS_VIOLATION錯(cuò)誤。

第四步，給冗長(zhǎng)的交叉編譯指令約定（短）別名。

還是打開(kāi)%UserProfile%\.cargo\config.toml配置文件和增補(bǔ)如下配置表

[alias]
ohos-build = ["build", "-Zbuild-std", "--target=aarch64-unknown-linux-ohos", "--target=armv7-unknown-linux-ohos", "--target=x86_64-unknown-linux-ohos"]

于是，只要執(zhí)行一條cargo ohos-build指令就相當(dāng)于連續(xù)執(zhí)行下面三條編譯指令：

1. cargo build -Zbuild-std --target=aarch64-unknown-linux-ohos

2. cargo build -Zbuild-std --target=armv7-unknown-linux-ohos

3. cargo build -Zbuild-std --target=x86_64-unknown-linux-ohos

總結(jié)交叉編譯環(huán)境的搭建成果

以后每次在Cargo (Lib) Package工程根目錄下執(zhí)行

cargo?ohos-build?--release

，編譯器都會(huì)立即

1. 喚起ohsdk內(nèi)置的LLVM前端編譯器llvm - clang作為rustc鏈接器

2. 將【標(biāo)準(zhǔn)庫(kù)】源碼作為普通依賴crate與主crate業(yè)務(wù)程序一起編譯

3. 并行啟動(dòng)三個(gè)JOB進(jìn)程對(duì)同一套Rust源碼同時(shí)執(zhí)行三組交叉編譯操作

4. 交叉編譯輸出三個(gè)文件名相同但 ABI格式不同的動(dòng)態(tài)鏈接庫(kù).so文件

新建Cargo (Library) Package工程，驗(yàn)證交叉編譯環(huán)境

首先，克隆stuartZhang/socket2至本地，并將代碼分支切至v0.4.x。

git?clone?git@github.com:stuartZhang/socket2.git
cd?socket2
git?checkout?-q?v0.4.x

關(guān)于這一步操作的必要性，我已經(jīng)詳細(xì)地闡述于ohos-node-bindgen還不能被直接使用章節(jié)了。簡(jiǎn)單地講，這是為了繞過(guò)socket2 crate對(duì)華為鴻蒙操作系統(tǒng)的不兼容缺陷。

然后，從命令行，新建Cargo (Library) Package工程

cd?..
cargo?new?--lib?calculator
code?calculator

其次，在VSCode內(nèi)，打開(kāi)Cargo.toml文件，和追加如下內(nèi)容

[lib]
crate-type = ["dylib"]

[dependencies]
ohos-node-bindgen = "6.0.3"
socket2 = "0.4.10"

[patch.crates-io]
socket2 = { path = "../socket2" }

前面配置片段內(nèi)的【依賴圖重寫(xiě)】配置表[patch.crates-io]指示Cargo包管理器使用本地的stuartZhang/socket2 crate山寨貨替換crates.io上的正品，因?yàn)檎?strong>不兼容華為操作系統(tǒng)。

接著，從VSCode打開(kāi)src/lib.rs文件，和增補(bǔ)如下Demo代碼。這是一段簡(jiǎn)單的整數(shù)加運(yùn)算程序。請(qǐng)把注意力聚焦在【派生宏】的使用上。

use?::ohos_node_bindgen::derive::ohos_node_bindgen;
#[ohos_node_bindgen]
fn?add(first:?i32,?second:?i32)?->?i32?{
????first?+?second
}

再次，執(zhí)行交叉編譯

cargo?ohos-build?--release

最后，從【資源管理器】查看編譯輸出結(jié)果

Cargo (Library) Package 工程根目錄
├── Cargo.toml
├── src — Rust 源碼目錄
├── target
│  ├── aarch64-unknown-linux-ohos
│  │  └── release
│  │     └── libcalculator.so
│  ├── armv7-unknown-linux-ohos
│  │  └── release
│  │     └── libcalculator.so
│  ├── x86_64-unknown-linux-ohos
│  │  └── release
│  │     └── libcalculator.so

值得注意的是，編譯輸出的鏈接庫(kù)文件名是有lib前綴的。所以，Native模塊的文件名是lib<包名>.so，而不是<包名>.so。

將Native模塊注入普通的DevEco Studio工程

Native模塊就是由前面交叉編譯輸出的ArkTs N-API鏈接庫(kù).so文件。

首先，從DevEco Studio IDE新建/打開(kāi)普通Empty Ability工程。

然后，修改模塊級(jí)的build-profile.json5文件（比如，entry/build-profile.json5），和添加如下配置項(xiàng)至buildOption節(jié)點(diǎn)

"externalNativeOptions":?{
??"abiFilters":?[
????"arm64-v8a",
????"armeabi-v7a",
????"x86_64"
??]
}

其次，在模塊根目錄下，創(chuàng)建下面三個(gè)子文件夾

• libs/arm64-v8a

• libs/armeabi-v7a

• libs/x86_64

接著，依次向它們復(fù)制入編譯好的鏈接庫(kù)文件。例如，

最后，在ArkTs業(yè)務(wù)代碼內(nèi)（比如，entry/src/main/ets/pages/Index.ets），以ES Module語(yǔ)法，導(dǎo)入Native模塊，和調(diào)用其成員方法

import?calculator?from?'libcalculator.so';
const?result?=?calculator.add(2,?3);

總的來(lái)講，調(diào)用端的ets代碼就這么簡(jiǎn)單！但還是有三處優(yōu)化可做以改善開(kāi)發(fā)體驗(yàn)：

優(yōu)化DevEco Studio工程目錄結(jié)構(gòu)

將Cargo (Lib) Package與DevEco Studio Project合并為一個(gè)工程更有利于提高Rust + ArkTs的混合編程生產(chǎn)力。所以，如下DevEco Studio工程目錄結(jié)構(gòu)是被強(qiáng)力推薦的：

DevEco?Studio?工程根目錄
├──?entry?—?模塊根目錄
│???├──?libs?—?交叉編譯輸出的?.so?文件都被復(fù)制到下面的子文件夾內(nèi)
│???│???├──?arm64-v8a
│???│???├──?armeabi-v7a
│???│???└──?x86_64
│???├──?src
│???│???├──?main
│???│???│??├──?resources
│???│???│??├──?cpp??—?*舊有*的?Cpp(ArkTs?N-API)?工程目錄
│???│???│??├──?ets??—?*舊有*的?ArkTs?源碼目錄
│???│???│??├──?rust?—?*新建*的?Rust(ArkTs?N-API)?工程目錄
│???│???│??│???├──?Cargo.toml
│???│???│??│???├──?src?—?Rust?源碼目錄
│???│???│??│???├──?target
│???│???│??│???│??├──?aarch64-unknown-linux-ohos
│???│???│??│???│??│??└──?release
│???│???│??│???│??├──?armv7-unknown-linux-ohos
│???│???│??│???│??│??└──?release
│???│???│??│???│??├──?x86_64-unknown-linux-ohos
│???│???│??│???│??│??└──?release

將Cargo (Lib) Package降級(jí)為DevEco Studio Project內(nèi)某個(gè)特定模塊下的子工程有兩個(gè)好處：

1. 同一個(gè)DevEco Studio工程內(nèi)可同時(shí)包含多個(gè)Native子工程。

2. 每個(gè)Native子工程既可獨(dú)占一個(gè)模塊以達(dá)成與主模塊業(yè)務(wù)代碼有限隔離的目的，也能與ets程序“混住”耦合于相同模塊內(nèi)。

友情提示

在移動(dòng)Cargo (Lib) Package工程位置后，千萬(wàn)別忘了同步修改Cargo.toml配置文件中【依賴圖重寫(xiě)】配置表[patch.crates-io]對(duì)本地stuartZhang/socket2 crate的引用路徑。否則，會(huì)編譯失敗！

自動(dòng)化鏈接庫(kù).so文件的復(fù)制操作

在每次執(zhí)行cargo ohos-build --release指令之后都徒手復(fù)制三個(gè).so文件至不同的文件夾是非常低效的，所以 @Rustacean 有必要給Cargo編寫(xiě)build.rs與post_build.rs構(gòu)建程序，以擴(kuò)展包管理器在編譯前與編譯后的處理行為，并自動(dòng)完成文件復(fù)制操作。其中，

1. build.rs作為【前置處理】程序

   1. 從環(huán)境變量，收集.so文件的位置信息

   2. 生成[CMD] COPY /Y或[Shell] cp -f文件復(fù)制指令

   3. 將【文件復(fù)制】指令尾追加至同一個(gè).cmd / .sh腳本文件

2. post_build.rs作為【后置處理】程序

   1. 執(zhí)行被寫(xiě)入【文件復(fù)制】指令的程序文件，并

   2. 刪除該程序文件

【打廣告】build.rs與post_build.rs皆未對(duì)上下文做任何的假設(shè)。所以，它們可被零成本地復(fù)用于其它同類(lèi)工程中。

還是看圖吧，一圖抵千詞

設(shè)計(jì)很完美但現(xiàn)實(shí)很骨感，因?yàn)?code>Mozilla廠方的rustup工具鏈尚不支持【后置處理】。所以，@Rustacean 需

1. 額外安裝功能增補(bǔ)包c(diǎn)argo-post

   cargo?install?cargo-post

2. 修改Cargo全局配置文件%UserProfile%\.cargo\config.toml中的ohos-build別名設(shè)置，以使cargo-post生效

   [alias]
   ohos-build = ["post", "build", "-Zbuild-std", "--target=aarch64-unknown-linux-ohos", "--target=armv7-unknown-linux-ohos", "--target=x86_64-unknown-linux-ohos"]

   【注意】在"build"左側(cè)新添加了"post"數(shù)組項(xiàng)

給Native模塊導(dǎo)出接口，添加.d.ts類(lèi)型提示

DevEco Studio IDE并沒(méi)有集成類(lèi)似于DLL Export Viewer的【動(dòng)態(tài)鏈接庫(kù)外部接口反射工具】。所以需要

1. @Rustacean 在輸出.so文件的同時(shí)也提供一份接口類(lèi)型說(shuō)明的.d.ts文件（— 其功能幾乎等效于C頭文件），并

2. 將該類(lèi)型說(shuō)明文件注入DevEco Studio工作流

接下來(lái)，我沿著前面Rust + ArkTs混合編程的新目錄結(jié)構(gòu)，描述操作步驟：

1. 在模塊entry的根目錄下，創(chuàng)建src/main/rust/types/libcalculator子目錄。注意：路徑末端的文件夾名libcalculator是鏈接庫(kù)文件的basename。

2. 在新建文件夾內(nèi)，再新建文件index.d.ts和添入Native模塊導(dǎo)出函數(shù)的函數(shù)簽名

   export?const?add:?(frist:?number,?second:?number)?=>?number;

3. 接著新建文件oh-package.json5和添入Native模塊的摘要信息。

   {
   ????"name":?"libcalculator.so",
   ????"types":?"./index.d.ts",
   ????"version":?"0.1.0",
   ????"description":?"ArkTs?NAPI?原生模塊示例"
   }

   其中，

   1. name字段就是鏈接庫(kù)的文件名（含擴(kuò)展名）。

   2. types字段是指向類(lèi)型說(shuō)明文件的相對(duì)路徑。

   3. version字段是Native模塊版本號(hào)。【推薦】該字段值與Cargo (Lib) Package子工程中Cargo.toml配置文件內(nèi)[package]配置表下version配置項(xiàng)的值保持一致 — 這又是一處純?nèi)斯ね近c(diǎn)。

   4. description字段是Native模塊描述信息。

4. 打開(kāi)entry模塊的oh-package.json5文件，并添加對(duì)Native模塊的依賴項(xiàng)條目。

   "dependencies":?{
   ????"libcalculator.so":?"file:src/main/rust/types/libcalculator"
   }

   在依賴項(xiàng)條目中，左側(cè)是鏈接庫(kù)的文件名；而右側(cè)是指向了類(lèi)型說(shuō)明文件所處文件夾的相對(duì)目錄。

   

5. 最后，從DevEco Studio IDE依次點(diǎn)擊菜單項(xiàng)Build ? Rebuild Project重新構(gòu)建整個(gè)工程和使配置項(xiàng)修改生效。

于是，鴻蒙應(yīng)用軟件開(kāi)發(fā)程序員就能在ets與ts代碼編輯器內(nèi)獲得針對(duì)Native模塊API的豐富類(lèi)型提示了。

線上例程

我已將上述全部文字描述內(nèi)容都例程化到github工程Arkts-NAPI-Rust-Demo內(nèi)了。線下運(yùn)行該工程可加強(qiáng)對(duì)文章繁雜內(nèi)容的理解。

運(yùn)行例程工程的環(huán)境要求

1. rustc 1.75.0-nightly

2. VSCode 1.86

3. ohsdk 3.1.0(API v9)

4. DevEco Studio 3.1.1 Release

運(yùn)行例程工程的具體步驟

1. 克隆git@github.com:stuartZhang/Arkts-NAPI-Rust-Demo.git

2. 在VSCode內(nèi)，

   1. 打開(kāi)entry/src/main/rust目錄

   2. 敲擊Alt + T + R鍵。

   3. 依次點(diǎn)擊菜單項(xiàng)build ? ohos-build ? --release

   4. 觀察控制臺(tái)輸出日志，等待交叉編譯結(jié)束。

3. 在DevEco Studio IDE內(nèi)，

   

   1. 打開(kāi)工程根目錄

   2. 啟動(dòng)手機(jī)模擬器

   3. 敲擊Shift + F10鍵，運(yùn)行移動(dòng)端程序

結(jié)束語(yǔ)與擴(kuò)展閱讀

搞定【交叉編譯】難關(guān)僅只是鴻蒙Rust原生開(kāi)發(fā)萬(wàn)里征程的第一步。加深對(duì)ArkTs - NAPI接口定義的理解才是【形成生產(chǎn)力】的核心任務(wù)。好消息是

1. ArkTs - NAPI與nodejs N-API高度相似。至少截至目前，它們的相似度還>= 95%。所以，已熟悉nodejs原生模塊編程的“老司機(jī)”們上手鴻蒙ArkTs - NAPI應(yīng)該不難。

2. 另外，我在春節(jié)假期期間貢獻(xiàn)的ohos-node-bindgen crate更可大幅降低ArkTs - NAPI原生開(kāi)發(fā)的復(fù)雜度。請(qǐng)對(duì)比下圖左右側(cè)的代碼量

   所以，ohos-node-bindgen crate值得大家點(diǎn)star呀！也請(qǐng)大家給Arkts-NAPI-Rust-Demo點(diǎn)star！

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-827251.html