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);
}

这个简单示例展示了：