開發工具

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

安裝 Node.js

在安裝好 DevEco 之后，首次點開需要開發者設置 Node.js 環境，并且有版本要求：

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），是鴻蒙系統的包管理工具（類似于 Android SDK Package Manager），支持查看、安裝和卸載 SDK 組件，SDK 組件包括 API 和工具鏈，也需要獨立安裝。這里推薦直接在 DevEco IDE 中安裝，能省事不少。

HarmonyOS SDK

和 Android SDK 相同，除了 Manager 工具之外，還需要下載鴻蒙系統用于開發的各個系統版本的 SDK APIs 和工具，也推薦直接在 DevEco IDE 中傻瓜式安裝。從 SDK 大小看，275.93MB 中規中矩，大概是剛起步的原因，內容并不多。SDK 中包含了如下內容（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

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

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

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

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

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

HelloWorld

按照國際慣例，接觸一門新的開發技術，首先從 Hello World 開始，那么在學習鴻蒙時，我們也從創建一個基礎的工程開始。

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

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

v

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

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

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

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

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

工程結構

不出意外地出了意外，開始執行工程創建之后報錯了，詳見后面「問題」章節問題一。

解決之后，繼續探索。

包結構

我們先從 APP 包結構入手，具體看下打包后的產物長什么樣子。當前鴻蒙支持 Stage 和 FA（Feature Ability）兩種應用模型，我們來看下兩者包體上的異同。

VS

從包結構里可以看出，對于 FA 模型，內部的 HAP 模塊相對獨立，每個 HAP 都包含了相同的 assets 和 config.json 類型代碼、資源和數據，側面印證了 FA 模型每個應用組件獨享一個 ArkTS 引擎實例的現象。

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

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

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

AppScope

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

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

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

json5 支持對數據進行注釋，使可讀性更高

舉個例子：

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

entry

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

hvigor

類似于 Android 的 gradle 目錄，存放了系統開發構建環境依賴的版本號

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" ] } ] } ] }

應用層級的配置文件，包括簽名、產品配置、模塊信息等，對標 Android 的 app 級別的 build.gradle + settings.gradle。

hvigorfile.ts

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

oh-package.json5

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

編譯運行打包

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

當使用真機來進行編譯運行時，會出現「沒有簽名」運行失敗的情況，詳見后面「問題」章節問題二。

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

打包

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

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

命令行工具

在鴻蒙的構建生態中，存在幾種工具指令輔助進行開發，這里也做一個歸納總結：

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

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

問題

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

原因分析：

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

解決：

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

問題二：Failure[MSG_ERR_INSTALL_FAILED_NO_BUNDLE_SIGNATURE]

原因分析：

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

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

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

問題三：Demo 在 鴻蒙 4.0.0 系統上出現卡死、黑屏問題

原因分析：

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

解決：

暫時無法解決，后續跟進更新

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

原因分析：端口沖突？

解決：

關掉一個 IDE，重新插拔即可

與 Android Studio 異同

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

同

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

異

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

總結

該篇文章通過 IDE 以及構建過程，對一些鴻蒙相關的開發語言、構建環境、命令工具等基本概念進行了解釋，為后續進一步開發打下基礎。同時，在整個過程中，我們簡單對比 Android 系統，發現鴻蒙現有的開發環境還有待改進，比如對命令工具需要單獨下載配置、IDE Previewer 極耗 CPU、應用對系統兼容性等問題。

審核編輯 黃宇