HarmonyOS 應用開發學習記錄 - 從Windows開發者視角看鴻蒙開發

起始

????????2024年6月21日召開的華為開發者大會2024上宣布Harmony OS NEXT（即鴻蒙星河版）面向開發者啟動Beta版，這也被人們稱為“純血鴻蒙”，它基于鴻蒙內核，不再兼容安卓開發的APP應用。

? ? ? ? 時至今日近一年了，我也有了嘗試鴻蒙系統的念頭。

? ? ? ? 這個系列，將記錄我逐步學習 HarmonyOS 應用開發的過程，記錄一位老牌?Windows 程序員視角下轉型開發的過程，沉淀自己所學，如果能為大家帶來一些幫助，幸甚之至。文章中的不當之處，請及時指正，感謝！

? ? ? ? 在寫這篇文章前，我在華為官方開發者文檔上學習了幾天，當前（205年06月10日）?HarmonyOS SDK 版本是 5.0.5(17)，后續內容都是基于此版本的討論，最新的版本可以在這里查看。

? ? ? ? 第一篇，主要是談談從Windows開發者感受HarmonyOS的差異，以及開發轉型需要注意的技術細節。

? ? ? ? 坦白地說，學習了幾天 HarmonyOS 開發，對于 Windows C++/Delphi 原生開發的我來說：

開發體感差異巨大? ? ? ?

????????首先，對有其他系統程序開發經驗，尤其是有 Windows 系統開發經驗的朋友提個醒，HarmonyOS 上的開發思路、體感和過去的“程序”截然不同。

????????開發語言 -?ArKTS，擴展自TypeScript的HarmonyOS應用開發官方高級語言。前端對此更親切。
????????開發IDE -??DevEco Studio 基于IntelliJ IDEA Community開源版本打造。Java開發者狂喜，與idea基本一樣。
????????開發范式 -?分別是基于ArkTS的聲明式開發范式（簡稱“聲明式開發范式”）和兼容JS的類Web開發范式（簡稱“類Web開發范式”）。前端又狂喜。

????????HarmonyOS 有很多縫合的觀感，就比如開發過程，讓我有種拿著JAVA IDE 寫前端的體感。甚至，像是在寫 Electron、Tarui?程序?-- HarmonyOS 附帶了一個拓展版本的Node.js，UI可以通過它和原生模塊交互，做過 Electron、Tarui 開發的朋友對此應該十分熟悉。

????????這一迥異的開發體驗背后是系統理念的差異。Windows 原生 C++ 開發程序員會有些抓瞎。

? ? ? ? 有些同學會想，我不打算新學語言了，那么? ? ? ?

可以只用 C++ 開發程序嗎？

? ? ? ? 答案是：基本不能。

? ? ? ? 首先是UI框架方面，?HarmonyOS 定制了UI框架，這是為 ArkTs 定制的。C++和Java主要用于特定場景的開發??，但無法完全替代ArkTS（尤其是界面開發）。

? ? ? ? 因此，學習 ArkTS 是鴻蒙開發必備的基礎。

ArkTS 難學嗎？

? ? ? ? 對前端，對熟悉 TypeScript ，尤其是熟悉 Electron、Tarui 開發的的同學來說應該是如魚得水。對于 C++ 的同學，恐怕要經歷一個不小的轉型。除非你的目標僅僅是開發特定性能敏感模塊的功能模塊。

? ? ? ? 不過僅僅就 ArkTS 語言來說，問題不大。尤其是我必須提一點，HarmonyOS 的文檔教程十分的豐富詳實，示例、練習題、視頻課程應有盡有，有種在線輔助的貼心感👍。

? ? ? ? 只要想學，肯定不難，尤其從 C++ 這種超級語法怪過來，會覺得輕松不少，更多的是開發范式的適應。?

? ? ? ? 回過頭來，我們看看?HarmonyOS 本身，拋開一些口水仗的問題，前面提到的系統理念差異具體是什么差異，華為為什么要推出新的系統，它新在哪里？
?

Windows 和?HarmonyOS 對比

先來對比下兩個系統中的一些基礎概念

系統核心概念映射表

Windows概念	HarmonyOS對應概念	重要差異說明
進程(Process)	Ability	Ability是功能單元而非純粹執行容器
窗口(Window)	Component/Page	鴻蒙采用聲明式UI描述
注冊表(Registry)	Preferences/DataAbility	分布式數據管理替代中心化配置
DLL動態庫	HAR靜態包	鴻蒙強調編譯時確定依賴
Win32 API	Native API	鴻蒙API更面向服務化場景

? ? ? ? 可見，在 HarmonyOS 中用戶和開發人員已經遠離了系統底層細節，UI是聲明式的，數據是分布式的，系統功能是面向場景式的。

開發模式的區別

????????傳統的跨平臺、多端的開發模式是為每一個系統環境使用獨立的SDK，開發獨立的APP，打獨立的包。每個包最終是一個只包含對應端的獨立實體。

????????而HarmonyOS強調的是“一次開發，多端部署”，即“一多開發”。因此，從項目工程管理、到界面布局到包的生成，都是一套。底層設備環境的差異被 HarmonyOS 抹平。

系統架構對比

Windows NT：集中式設計

經典的Windows NT架構緊湊致密：

分層明確：用戶態/內核態嚴格分離
單體式內核：文件系統、設備驅動、安全機制等都運行在內核空間
注冊表中心化：系統配置高度集中

HarmonyOS架構：分布式設計

HarmonyOS則體現為分布式場景化：

微內核設計：僅最基礎的功能在內核中（任務調度、內存管理）
服務組件化：文件系統、設備驅動等都作為獨立服務運行在用戶態
無中心配置：采用分布式數據管理替代傳統注冊表

關鍵差異點：

模塊耦合度：Windows各模塊間調用關系復雜，鴻蒙通過IPC嚴格隔離
擴展性：Windows依賴驅動模型，鴻蒙通過Ability動態加載
安全性：鴻蒙的權限粒度更細，默認遵循最小權限原則

HarmonyOS 的全場景分布式特性

? ? ??

????????

? ? ? ? 我們要重點要理解鴻蒙的"分布式"特點，這是最值得Windows開發者注意的差異點，我們從一個打開文件的操作來對比直觀感受這個差異。

在Windows上：

// 傳統Windows文件操作
var file = File.Open(@"C:\Users\Name\file.txt", FileMode.Open);

在HarmonyOS中可能是：

// 鴻蒙分布式文件訪問
let fileAccessHelper = fileIO.createFileAccessHelper(context);
let file = await fileAccessHelper.openFile("deviceId://file.txt");

關鍵區別：

沒有固定路徑概念，而是通過統一資源標識符(URI)定位
自動處理設備間通信細節
異步操作是默認模式

開發思維轉變

1. 從"設備為中心"到"場景為中心"

Windows開發通常假設：

應用運行在單一設備上
硬件配置相對固定
網絡連接是可選功能

鴻蒙開發需要假設：

應用可能跨多個設備協同工作
硬件能力動態變化（設備隨時可能加入或離開）
網絡連接是基礎能力

2. 生命周期管理的差異

Windows應用生命周期：

啟動 → 運行 → 最小化/最大化 → 關閉

HarmonyOS Ability生命周期：

Create → Foreground → Background → Destroy↑___________↓     ↑______↓

特別注意：

鴻蒙應用更頻繁地在前后臺切換
必須妥善處理狀態保存/恢復
后臺運行有嚴格限制（與Windows服務概念不同）

為了更好的感受分布式特性，我們再次展示一個示例：


// 發現附近設備
import deviceManager from '@ohos.distributedDeviceManager';let deviceList = [];
const SUBSCRIBE_ID = 100;// 1. 創建設備管理器
let dmInstance = deviceManager.createDeviceManager("com.example.demo");// 2. 注冊設備狀態回調
dmInstance.on("deviceStateChange", (data) => {let device = data.device;if (data.action === 0) { // 設備上線deviceList.push(device);} else { // 設備離線deviceList = deviceList.filter(item => item.deviceId !== device.deviceId);}
});// 3. 開始發現設備
dmInstance.startDeviceDiscovery(SUBSCRIBE_ID);// 4. 選擇設備后發送數據
async function sendData(deviceId, data) {let channel = await dmInstance.createDataChannel(deviceId);channel.send(data);
}

這個簡單示例展示了：