刚开始接触 HarmonyOS 开发时，我并没有急着写业务逻辑，而是先花了一点时间去“看工具”。因为一个很现实的问题是：如果工具链没搞清楚，后面所有问题都会变得更难定位。

这篇就记录一下我第一次上手 DevEco Studio 时，对它整个工具体系的一些理解和判断。

一个直观判断：这不是一个“全新IDE”

第一次打开 DevEco Studio，其实有一种很强的既视感。

界面、操作方式、快捷键，基本都和 IntelliJ IDEA 非常接近。

所以我一开始的一个直观判断是：

DevEco Studio ≈ IntelliJ IDEA + HarmonyOS SDK + 一套新的构建工具链

也就是说，它本质上不是从零做的一个 IDE，而是建立在 JetBrains 体系之上的一层“鸿蒙开发能力扩展”。

我现在的拆解是这样的：

• IDE壳： JetBrains（IDEA体系）
  
• 语言支持： ArkTS（鸿蒙主推语言）
  
• 构建系统： Hvigor（替代 Gradle 的角色）
  
• 运行环境： HarmonyOS SDK + 模拟器 / 真机
  

从这个角度看，它更像是 Android Studio 的“平行版本”，而不是完全陌生的一套东西。

项目创建后的结构观察：有点熟，但不完全一样

创建一个 Empty Ability 项目之后，我第一件事就是看目录结构。

核心看到两个关键路径：

entrysrc/main/ets

这里有几个我当时的理解：

1. entry 是什么？

我的判断：它就是应用模块

可以类比 Android：

• Android：app module
  
• HarmonyOS：entry module
  

后面的一些配置、资源、Ability，基本都围绕这个模块展开。

2. ets 目录是什么？

src/main/ets

这里放的是 ArkTS 代码。

但一开始我其实有点误判，以为是“TypeScript”。

后来发现不是那么简单。

我的当前理解是：

• 它语法上类似 TypeScript
  
• 但并不是标准 TS
  
• 更像是一个“裁剪 + 定制”的语言版本
  

也就是说：

ArkTS ≠ TS，而是一个带类型、面向UI声明的DSL

这一点在写 UI 的时候会更明显（后面会单独写一篇）。

点击 Run 之后，到底发生了什么？

第一次点击 Run 的时候，其实整个过程是一个“黑盒”。你能看到的只是 IDE 开始编译、模拟器启动，然后应用运行起来，但中间到底发生了什么并不直观。

基于以往 Android 和前端开发的经验，我尝试对这个过程做了一个简化的推测。目前我的理解是：当点击运行时，ArkTS 代码首先会被转换成某种中间表示（而不是直接执行），随后由构建工具 Hvigor 介入，完成依赖处理、编译和打包流程，最终生成一个 HAP 包，并通过调试通道部署到模拟器或真机上运行。

关于 HAP 的一个直观理解

在这个过程中，HAP 是一个比较关键的产物。它的全称是 Harmony Ability Package，可以理解为 HarmonyOS 的应用打包格式。从直觉上看，它和 Android 的 APK 很类似，但整体感觉更轻量一些。

不过目前我还没有深入研究 HAP 的内部结构，比如它在多模块场景下的组织方式、是否支持动态加载能力、以及在分布式场景中的拆分策略。这些应该是后面深入做项目时必须要搞清楚的部分。

一个隐含但很重要的点：Hvigor

在整个工具链里，有一个一开始不太显眼，但实际上非常关键的组件，就是 Hvigor。可以把它理解为 HarmonyOS 体系中的构建系统，类似于 Android 里的 Gradle。

不过目前的体验是，它的生态和文档还在持续完善中。我现在还不完全清楚它和 Gradle 是完全替代关系，还是存在一定的兼容机制；另外它的插件体系、扩展能力以及构建性能表现，也都还需要在实际项目中进一步验证。

如果用一句话总结我现在对 DevEco Studio 的认知，它并不是一个全新的 IDE，而是一套围绕 HarmonyOS 重新组织起来的开发工具链。

更具体一点来说，它是在一个成熟 IDE（IDEA体系）的基础上，引入 ArkTS 来重构 UI 开发方式，同时用 Hvigor 替代传统构建系统，并通过 HAP 作为新的应用打包格式，形成了一整套相对独立的开发闭环。

今天最大的收获其实不是写了多少代码，而是对整个工具链的结构有了一个初步的轮廓。至少现在可以大致判断，当问题出现时，更可能是出在 IDE、构建流程还是运行环境，这一点在后续开发中会非常重要。

如果用一句话总结今天的进展，那就是：相比语法本身，理解工具链结构反而是更优先的一步。

目前还有几个关键问题没有完全搞清楚，包括 Hvigor 的完整构建机制、ArkTS 最终会被编译成什么形式、HAP 在复杂项目中的结构，以及调试链路是否类似于 Android 的 ADB。这些问题基本都需要在后续实际开发过程中逐步验证。