鴻蒙 Harmony 工具篇

開發(fā)工具

鴻蒙的主開發(fā) IDE 為 DevEco-Studio（DevelopEcology Studio，生態(tài)開發(fā) Studio），和 Android Studio 一樣，基于 IntelliJ 平臺做的自定義 IDE。因此，對于 Java 開發(fā)者而言，DevEco 只是“在熟悉中帶有一點點陌生”。

安裝 Node.js

在安裝好 DevEco 之后，首次點開需要開發(fā)者設(shè)置 Node.js 環(huán)境，并且有版本要求：

Node.js version: even-
numbered version marked LTS, in the v14.19.1 to v16 range npm version: 6.14.16 or later

下載時需要注意選擇 Node 長期維護的版本并且使用較新的版本安裝包（可以選擇使用自裝包也可以通過 IDE 下載。有坑，見問題一）。

ohpm

ohpm（OpenHarmony Package Manager，亦稱 ohsdkmgr），是鴻蒙系統(tǒng)的包管理工具（類似于 Android SDK Package Manager），支持查看、安裝和卸載 SDK 組件，SDK 組件包括 API 和工具鏈，也需要獨立安裝。這里推薦直接在 DevEco IDE 中安裝，能省事不少。

HarmonyOS SDK

和 Android SDK 相同，除了 Manager 工具之外，還需要下載鴻蒙系統(tǒng)用于開發(fā)的各個系統(tǒng)版本的 SDK APIs 和工具，也推薦直接在 DevEco IDE 中傻瓜式安裝。從 SDK 大小看，275.93MB 中規(guī)中矩，大概是剛起步的原因，內(nèi)容并不多。SDK 中包含了如下內(nèi)容（Mac 中的下載路徑：/Users/xxxx/Library/Huawei/Sdk）：

3.1.0(API 9)
Previewer 3.2.3.6 75.00 MB
Toolchains 3.2.3.6 21.99 MB
OpenHarmony(API 9)
ArkTS 3.2.12.5 46.87 MB
JS 3.2.12.5 21.92 MB
Previewer 3.2.12.5 97.52 MB
Toolchains 3.2.12.5 12.64 MB

截止當(dāng)前，SDK 提供的最高版本是 3.1.0 API 9（鴻蒙 4.0+ 的系統(tǒng)需要額外的企業(yè)賬號授權(quán)才能體驗），里面包含了兩部分：Harmony SDK 和 OpenHarmony SDK。

HarmonyOS SDK VS OpenHarmony SDK
大家看到這里應(yīng)該會有一個疑惑，HarmonyOS 和
OpenHarmony 是兩個概念，有什么區(qū)別？ 首先 OpenHarmony 是一個開源項目，有開放原子開源基金會（OpenAtom
Foundation）孵化和運營。相當(dāng)于 Android 的 AOSP，但不支持 Java 開發(fā)應(yīng)用，不支持模擬器運行。 而
HarmonyOS 是在開源基礎(chǔ)上，實現(xiàn)現(xiàn)有 Android 生態(tài)應(yīng)用在部分搭載該 HarmonyOS
設(shè)備上運行（可以理解為鴻蒙過渡階段，中間態(tài)）。既然如此，那么在開發(fā)語言支持方面，自然是支持 Java/C/C++ 的。
同時，值得開發(fā)者注意的是，OpenHarmony 和 HarmonyOS 的 API
略有差別，且打包簽名的方式也不同，代碼層面上的不同在后面「編碼篇」我們在詳細展開。

這里對不熟悉 ArkTS 的同學(xué)在簡單解釋下概念，ArkTS 是一個 TS 應(yīng)用開發(fā)框架，支持 Node.js 和 WebAssembly（能力可擴展到 C/C++ 領(lǐng)域），所以它支持多種編程語言實現(xiàn)，ArkTS 涉及了多組件，如編譯器 TS 前端、TS 后端、TS 運行時、TS 調(diào)試器等。其中，ArkTS Runtime 是 OpenHarmony 上 TS 應(yīng)用使用的運行時，包含了 TS 對象的分配器以及垃圾回收器、符合 ECMAScript 規(guī)范的標(biāo)準(zhǔn)庫、用于運行 Ark 前端組件生成的「方舟」字節(jié)碼（ArkBytecode）的解釋器、用于存儲隱藏類的內(nèi)聯(lián)緩存、對外的函數(shù)接口（AFFI）等模塊。

ArkTS 就可以理解為是 TypeScript 語言基礎(chǔ)上的一個框架，該框架匹配了 ArkUI 框架，擴展了聲明式 UI、狀態(tài)管理等相應(yīng)的能力，讓開發(fā)者可以以更簡潔、更自然的方式開發(fā)跨端應(yīng)用。

ArkTS、TypeScrip t和 JavaScript 之間的關(guān)系： JavaScript 是一種屬于網(wǎng)絡(luò)的高級腳本語言，已經(jīng)被廣泛用于
Web 應(yīng)用開發(fā)，常用來為網(wǎng)頁添加各式各樣的動態(tài)功能，為用戶提供更流暢美觀的瀏覽效果。 TypeScript 是 JavaScript
的一個超集，它擴展了 JavaScript 的語法，通過在 JavaScript 的基礎(chǔ)上添加靜態(tài)類型定義構(gòu)建而成，是一個開源的編程語言。
ArkTS 兼容 TypeScript 語言，拓展了聲明式 UI、狀態(tài)管理、并發(fā)任務(wù)等能力。

HelloWorld

按照國際慣例，接觸一門新的開發(fā)技術(shù)，首先從 Hello World 開始，那么在學(xué)習(xí)鴻蒙時，我們也從創(chuàng)建一個基礎(chǔ)的工程開始。

首先，當(dāng)選擇「Create Project」時，DevEco 彈出的創(chuàng)建工程的選項只有兩個：「Application」和「Atomic Service」，Application 很好理解，就是基于嵌入式或者移動端的「需要安裝」的應(yīng)用，而 Atomic Service 則是通過服務(wù)組件、二維碼掃描、OneHop（基于 NFC 的不同應(yīng)用或設(shè)備間數(shù)據(jù)無縫傳輸和交互的能力）方式通過的「免安裝」服務(wù)。Atomic Service 等后續(xù)章節(jié)再來探索。我們先集中精力關(guān)注移動端「Application」的開發(fā)。

和 Android Studio 類似，只要我們在 DevEco 上選擇 Application 的創(chuàng)建標(biāo)簽，它提供的是以「頁面」維度的入口文件，區(qū)別在于 Android Studio 提供的是以 「Activity」 命名的入口文件（或者「活動」），而鴻蒙系統(tǒng)則稱之為 「Ability」 ，從這可以看出一些有意思的點是，Android 的 Activity 聚焦的是「行為」，而鴻蒙的 Ability 注重的是「能力」，「行為」注重和用戶的交互，而「能力」傾向的是邊界的擴展，這和鴻蒙的「萬物互聯(lián)」思想是相輔相成的。（格局大了有沒有）

v

在創(chuàng)建工程上，還可以看出一點，就是鴻蒙在開發(fā)的時候，正在淡化邊界，既然要做到「萬物互聯(lián)」，那么就不用去管當(dāng)前的開發(fā)設(shè)備到底是在手機端、還是手表、亦或是電視還是自動駕駛等，IDE 提供的是能力的創(chuàng)建，而這個能力可以應(yīng)用到各個設(shè)備端，當(dāng)然是否真的能做到，我們接著往下看。

還有一點小區(qū)別，可以看下創(chuàng)建工程的左上角，DevEco 提供了所謂的「Template Market」，即模版市場，初心應(yīng)該是提供開發(fā)這一些便捷的模版，減少開發(fā)成本，同時也能固定鴻蒙各個應(yīng)用間的體驗統(tǒng)一性，點進去看發(fā)現(xiàn)，目前只有一個「Shopping Mall」的 Template，后續(xù)可能還要依賴官方和開發(fā)者之間的支持，這里暫時按下不表。主頁卡片上，DevEco 提供的和 Android Studio 類似的使用于不同應(yīng)用類型的不同樣式頁面。作為一個有經(jīng)驗的開發(fā)者，我們就跳過「Empty Aliblity」這種簡單的模版，直接上難度，走一個較為復(fù)雜的 「Category Ability」。

選中以后，進入下一步，一股熟悉感鋪面而來:

定義工程名，語言只能選 ArkTS，Stage 和 FA 分別代表鴻蒙 API 4-8 和 API 9，還有目標(biāo)設(shè)備，直接下一步 「Finish」。

這里可能會有人好奇，在 DevEco IDE 上連接 Android 設(shè)備，是否也可以進行工程的編譯和運行，答案是否定的，如果是非鴻蒙系統(tǒng)，IDE 上并不會識別有設(shè)備連接到 IDE，理所當(dāng)然也不能進行 Android 設(shè)備的編譯調(diào)試。

工程結(jié)構(gòu)

不出意外地出了意外，開始執(zhí)行工程創(chuàng)建之后報錯了，詳見后面「問題」章節(jié)問題一。

解決之后，繼續(xù)探索。

包結(jié)構(gòu)

我們先從 APP 包結(jié)構(gòu)入手，具體看下打包后的產(chǎn)物長什么樣子。當(dāng)前鴻蒙支持 Stage 和 FA（Feature Ability）兩種應(yīng)用模型，我們來看下兩者包體上的異同。

VS

從包結(jié)構(gòu)里可以看出，對于 FA 模型，內(nèi)部的 HAP 模塊相對獨立，每個 HAP 都包含了相同的 assets 和 config.json 類型代碼、資源和數(shù)據(jù)，側(cè)面印證了 FA 模型每個應(yīng)用組件獨享一個 ArkTS 引擎實例的現(xiàn)象。

Stage 模型與 FA 模型最大的區(qū)別在于：Stage模型中，多個應(yīng)用組件共享同一個 ArkTS 引擎實例；而 FA
模型中，每個應(yīng)用組件獨享一個 ArkTS 引擎實例。因此在 Stage
模型中，應(yīng)用組件之間可以方便的共享對象和狀態(tài)，同時減少復(fù)雜應(yīng)用運行對內(nèi)存的占用。Stage
模型作為主推的應(yīng)用模型，開發(fā)者通過它能夠更加便利地開發(fā)出分布式場景下的復(fù)雜應(yīng)用。

對于 IDE，相信接觸過 Android Studio 的開發(fā)者都不陌生，對于一些開發(fā)調(diào)試工具、界面排布、入口等不再贅述，我們主要集中在工程結(jié)構(gòu)上。

來看一下，工程幾個重要的組成部分。這里不得不吐槽一句，作為官方的工程示例，同一個工程里，編碼風(fēng)格上既然包含了駝峰、小寫、下劃線、中線等多種命名風(fēng)格，顯得有那么點不統(tǒng)一和諧。

AppScope

存放整個應(yīng)用公共的信息和資源，屬于公共資源，對于各個 module 均可讀。app.json5文件里存放了關(guān)于應(yīng)用的配置信息，比如包名、版本號、應(yīng)用名稱、圖標(biāo)等，和 Android Manifest 類似。

這里對 json5 格式也做下進一步解釋，json5 是 json 的超集，通過包含一些 ECMAScript5.1 的產(chǎn)物來減少 json 的限制，擴展 JSON 的語法。簡單來說，json5 比 json 更加靈活，比如：

json 只能使用""來表示 String 類型數(shù)據(jù)，而 json5 可以使用單引號

json5 支持對數(shù)據(jù)進行注釋，使可讀性更高

舉個例子：

{ "name": 'John', "age": 30, // this is a comment /* this is another comment */ "email": "johndoe@example.com", "hobbies": [ "reading", "coding", "music", ], }

entry

默認的初始化入口模塊，是應(yīng)用的主模塊，存放 HarmonyOS 應(yīng)用的代碼和資源，其中里面包含源碼的目錄為 /entry/src/main/ets，包含模塊公共資源的目錄為 /entry/src/main/resources。ets 下可根據(jù)實際開發(fā)定義不同的文件夾目錄，如示例代碼中使用了 MVVM 的工程架構(gòu)。一般而言，pages 文件下存放的是頁面相關(guān)的代碼。

hvigor

類似于 Android 的 gradle 目錄，存放了系統(tǒng)開發(fā)構(gòu)建環(huán)境依賴的版本號

oh_modules

是工程的依賴包，存放工程依賴的源文件。

build-profile.json5

{ "app": { "signingConfigs": [], "compileSdkVersion": 9, "compatibleSdkVersion": 9, "products": [ { "name": "default", "signingConfig": "default", } ] }, "modules": [ { "name": "entry", "srcPath": "./entry", "targets": [ { "name": "default", "applyToProducts": [ "default" ] } ] } ] }

應(yīng)用層級的配置文件，包括簽名、產(chǎn)品配置、模塊信息等，對標(biāo) Android 的 app 級別的 build.gradle + settings.gradle。

hvigorfile.ts

工程級編譯構(gòu)建任務(wù)腳本，hvigor 是基于任務(wù)管理機制實現(xiàn)的一款全新的自動化構(gòu)建工具，主要提供任務(wù)注冊編排，工程模型管理、配置管理等核心能力。聽著比較抽象，可以先簡單理解為構(gòu)建腳本，我們在實際使用的時候再詳細介紹。

oh-package.json5

工程級依賴配置文件，用于記錄引入包的配置信息。

編譯運行打包

在接下來，我們來看一下鴻蒙上應(yīng)用的編譯運行打包部分的情況。

當(dāng)使用真機來進行編譯運行時，會出現(xiàn)「沒有簽名」運行失敗的情況，詳見后面「問題」章節(jié)問題二。

解決了簽名問題，終于可以在真機上運行了。然而，又出意外了，在正常進入 Demo 頁面的之后，整個頁面和交互就卡死了（沒錯，類似于 ANR 了），在屏幕上進行無意義的點擊之后，徹底黑屏。更意外的是，當(dāng)我點擊 Log 里的截屏能力時，能正常截到圖像，但真機卻是黑屏。同時還影響了系統(tǒng)的穩(wěn)定性，從后臺切回來后，能正常顯示頁面，但是后臺任務(wù)這里，又出現(xiàn)了異常顯示。詳見后面「問題」章節(jié)問題三。

打包

我們在“假設(shè)”應(yīng)用沒問題的情況下，自然而然地進入打產(chǎn)物包的階段。在「Build」工具欄，我們看到產(chǎn)物有兩種類型：Hap 和 APP，APP 無需贅述，我們了解下 Hap 是什么東西，HamonyOS Ability Package for short，我們從簽名了解到，鴻蒙是以 Ability 為主要維度來構(gòu)建應(yīng)用的，而 Hap 是 Ability 的部署包（類似于 Module 的概念），同時 Ability 又分為了 FA（Feature Ability，HarmonyOS 早期版本，不再主推） 和 PA（Particle Ability） 兩種類型，是組成應(yīng)用的基本單元。FA 和 PA 的區(qū)別在于「有無 UI 元素」。

當(dāng)我們選擇構(gòu)建 APP 類型時，生成的產(chǎn)物在 ProjectRootDir/build/outputs/default 下面，并且后綴是 .app。而選擇 Hap 類型構(gòu)建時，生成的產(chǎn)物后綴自然是 .hap，值得注意的是，無論 App 還是 Hap 都可以獨立安裝在鴻蒙設(shè)備上，App 可以上線應(yīng)用市場。這么設(shè)計的初衷，可能還是基于各個 IoT 設(shè)備都能運行的考慮。

命令行工具

在鴻蒙的構(gòu)建生態(tài)中，存在幾種工具指令輔助進行開發(fā)，這里也做一個歸納總結(jié)：

鴻蒙貼心地提供了 codelinter、ohpm、sdkmgr 三個工具的工具包（點這下載），將該包配置到環(huán)境變量中，即可快捷使用。

注意：sdkmgr 僅支持 17+ 的 JAVA 版本。否則無法使用

問題

問題一：ERROR: Cannot find module ‘node:path’

原因分析：

還記得前面提到的安裝編譯環(huán)境時，對 node.js 和 npm 版本是有要求的，然而我根據(jù)它的提示信息下載 node v15.14.0版本，還是會報錯，需要升級到 node v16.20.2 及以上版本，不得不說，確實「坑」，提示信息不準(zhǔn)確。

解決：

重新下載新的 node 包安裝后 Rebuild project。

問題二：Failure[MSG_ERR_INSTALL_FAILED_NO_BUNDLE_SIGNATURE]

原因分析：

即使是 debug 模式下，也需要有包簽名信息，不然無法運行到真機上

解決：打開 「Project Structure」，在登錄華為開發(fā)者賬號后自動生成一個簽名。（吐槽：在 DevEco 上增加了一個登錄按鈕，要登錄卻還是跳轉(zhuǎn)到了瀏覽器網(wǎng)頁去進一步驗證，做的不夠徹底和統(tǒng)一）

在生成簽名后，會發(fā)現(xiàn)在工程的 build-profile.json5 文件夾里就自動生成了相關(guān)的簽名文件和簽名信息：

問題三：Demo 在 鴻蒙 4.0.0 系統(tǒng)上出現(xiàn)卡死、黑屏問題

原因分析：

可能存在 app 4.0.0 系統(tǒng)和 3.x.x API 不兼容的情況。因為在 3.1.0 的模擬器上，Demo 是可以正常使用的，當(dāng)然由于測試設(shè)備有限，無法明確定位到是這個問題。

解決：

暫時無法解決，后續(xù)跟進更新

問題四：當(dāng) PC 上同時打開 Android Studio 和 DevEco IDE 時，連接鴻蒙手機，有可能出現(xiàn)兩個 IDE 都會識別不到設(shè)備的情況

原因分析：端口沖突？

解決：

關(guān)掉一個 IDE，重新插拔即可

與 Android Studio 異同

從我們上面幾個章節(jié)的介紹，或多或少可以總結(jié)出一些 Android 和 鴻蒙 在構(gòu)建工具方面的異同點出來：

同

1.都是基于 IntelliJ 改造后適用于 Android 和 Harmony 開發(fā)的 IDE，降低 Android 開發(fā)者遷移門檻
2.構(gòu)建編譯流程上，從代碼構(gòu)建、簽名生成、打包屬于同一類流程，即使是一些應(yīng)用資源分布和代碼構(gòu)建，都能看到 Android 的影子

異

1.開發(fā)語言的不同（ArkTS vs Java/Kotlin），工具也從 Android 的 ADB 變成了 HDC（HarmonyOS Device Connector，兩者命令對比可見下表）
2.構(gòu)建工具從 Android 的 gradle/groovy 變成了 hvigor/json5（一款全新基于 TS 實現(xiàn)的前端構(gòu)建任務(wù)編排工具，結(jié)合 npm 包管理機制，主要提供任務(wù)管理機制，任務(wù)注冊編排、工程模型管理、配置管理等關(guān)鍵能力，更符合 ArkTS/JS 開發(fā)者的開發(fā)習(xí)慣） 的組合
3.編碼風(fēng)格和工程結(jié)構(gòu)編排上也略有差異

總結(jié)

該篇文章通過 IDE 以及構(gòu)建過程，對一些鴻蒙相關(guān)的開發(fā)語言、構(gòu)建環(huán)境、命令工具等基本概念進行了解釋，為后續(xù)進一步開發(fā)打下基礎(chǔ)。同時，在整個過程中，我們簡單對比 Android 系統(tǒng)，發(fā)現(xiàn)鴻蒙現(xiàn)有的開發(fā)環(huán)境還有待改進，比如對命令工具需要單獨下載配置、IDE Previewer 極耗 CPU、應(yīng)用對系統(tǒng)兼容性等問題。

審核編輯 黃宇