为什么第一篇先谈“比什么”

很多 Android 开发者第一次看 HarmonyOS，会下意识寻找一张一一对应表：Activity 对应什么？Intent 对应什么？XML 布局对应什么？Gradle 对应什么？

这种对照很有用，但如果一开始只做 API 映射，很容易越学越乱。因为 Android 和 HarmonyOS 的差异不只在类名和配置文件上，还包括应用模型、UI 范式、语言约束、构建工具、设备生态，以及系统能力的开放方式。

所以这个系列的第一篇不急着写代码，而是先画一张地图：我们到底在比较哪几层。

开发者视角的对比总览

对比层次	Android 开发者熟悉的东西	HarmonyOS 侧需要建立的新直觉	读者可以先抓住的判断
应用模型	Activity、Fragment、Service、Intent、Manifest	Stage 模型、UIAbility、Page、Want、module.json5	先理解生命周期和模块边界，再看概念映射
UI 范式	XML View、RecyclerView、Jetpack Compose	ArkUI、@Component、Row/Column/List、状态装饰器	Compose 经验更容易迁移，传统 XML View 经验需要重新组织
语言栈	Java、Kotlin、Coroutine、Flow	ArkTS、async/await、声明式组件写法	ArkTS 更像带平台约束的工程语言，不只是换一种语法
Native 桥接层	JNI 连接 Java/Kotlin 与 C/C++	NAPI 连接 ArkTS/JS 与 C/C++ 原生模块	都是跨语言桥，真正的差异藏在类型映射、线程和构建接入里
状态管理	ViewModel、LiveData、StateFlow、Compose State	@State、@Prop、@Link、@Provide、@Consume	关键不是记装饰器名称，而是看数据如何驱动界面刷新
工程化	Android Studio、Gradle、APK/AAB、Jetpack 生态	DevEco Studio、hvigor、ohpm、HAP/HAR/HSP	工具链换了，依赖、签名、调试和发布节奏也会跟着变化
设备生态	手机为主，兼顾平板、折叠屏、车机等	手机、平板、PC/2in1、穿戴、多设备协同	当业务跨设备流转时，HarmonyOS 的优势会更明显

第一层：操作系统和生态不是同一个问题

Android 首先是一个成熟的移动操作系统生态。对应用开发者来说，它背后有 Linux Kernel、Android Runtime、Framework API、Google / 国内厂商服务、应用市场、Jetpack 组件和庞大的三方库生态。

HarmonyOS 这边则要稍微分清几个词：HarmonyOS、OpenHarmony、HarmonyOS NEXT、ArkTS、ArkUI。它们不是完全同一层的概念。

对应用开发者最关键的不是“谁的内核是什么”，而是：

• 应用用什么语言写。
• 页面和生命周期怎么组织。
• UI 用什么方式声明。
• 系统能力怎么申请和调用。
• 工程怎么构建、调试和发布。
• 多设备能力是不是业务的一部分。

换句话说，这个系列主要比较的是“应用开发体验”，不是做操作系统内核史。

第二层：语言栈的变化

Android 开发的主流语言经历过 Java 到 Kotlin 的迁移。今天写 Android，很多项目会用 Kotlin、Coroutine、Flow、Jetpack Compose，也会保留大量 Java、XML View 和老项目架构。

HarmonyOS 应用开发更强调 ArkTS。ArkTS 和 TypeScript 有关系，但不能简单理解成“随便写 TS”。它有自己的约束、性能导向和工程规范。对于 Android 开发者来说，学习 ArkTS 的关键不是把 Java/Kotlin 语法逐条翻译过去，而是适应一种更偏声明式 UI 和组件状态驱动的写法。

这里会出现第一个心理落差：Android 老项目里很多逻辑是 Activity / Fragment 持有 View，再通过回调、观察者或 ViewModel 更新界面；HarmonyOS 的 ArkUI 写法会更靠近“状态变化驱动界面重新描述”。

如果你已经熟悉 Jetpack Compose，理解 ArkUI 会轻松不少。如果你主要写 XML View，那需要先转换 UI 思维。

第三层：JNI 与 NAPI 是容易被忽略的中间层

移动开发不只有应用层 API。只要项目涉及音视频、图像处理、加密算法、硬件能力封装、跨平台 C/C++ 库，都会碰到“上层语言如何调用原生能力”的问题。

在 Android 里，这一层最典型的是 JNI。Java / Kotlin 代码通过 JNI 调用 C/C++，常见于 NDK 开发、性能敏感模块、已有 C/C++ SDK 接入等场景。

在 HarmonyOS 里，类似位置的是 NAPI。ArkTS / JS 侧可以通过 NAPI 接入 C/C++ 原生模块，把系统能力、算法库或已有 native 逻辑暴露给上层应用使用。

从开发心智看，JNI 和 NAPI 有相似性：

• 都是在托管/脚本层和 C/C++ 层之间搭桥。
• 都要处理类型转换、内存管理、线程边界和错误返回。
• 都常出现在性能敏感、平台能力封装、跨平台库复用的场景。

但它们不能简单画等号。JNI 面向 Java 虚拟机体系，NAPI 面向 ArkTS / JS 运行时和 HarmonyOS 的模块机制；工程接入方式、类型映射、生命周期边界、构建配置都不同。

这个系列后面会单独安排一篇讲 JNI 与 NAPI：它们为什么相似，迁移 C/C++ 能力时该保留什么，重写什么，以及怎么避免把 native 层做成难维护的黑盒。

第四层：应用模型不能机械对照

Android 的入口直觉通常来自四大组件：Activity、Service、BroadcastReceiver、ContentProvider。页面主要围绕 Activity / Fragment 展开，页面跳转常用 Intent，应用配置在 AndroidManifest.xml 里声明。

HarmonyOS 侧需要先理解 Stage 模型、UIAbility、Page、Want、module.json5、app.json5 等概念。你可以粗略地把 UIAbility 看成承载界面和生命周期的重要入口，把 Want 看成页面跳转和跨应用拉起时的重要信息载体，但这只是入门类比，不是等价替换。

比如 Intent 和 Want 都能做跳转与传参，但它们背后的应用模型、配置方式、系统能力边界并不完全一样。Activity 和 UIAbility 都和界面生命周期有关，但项目组织方式、页面栈管理、模块配置也不同。

所以后续文章会采用这样的讲法：

• Android 中这个问题怎么解决。
• HarmonyOS 中这个问题怎么解决。
• 两者在开发心智上的差异是什么。
• 如果从 Android 迁移，哪里可以复用经验，哪里需要重建。

第五层：UI 框架是最容易产生“熟悉感”的地方

如果只从 UI 看，HarmonyOS 的 ArkUI 会让 Compose 开发者感到亲切：组件化、声明式、状态驱动、链式属性设置。这和传统 Android XML View 的差异很大。

Android 这边至少有两套常见经验：

• 传统 View 系统：XML、ViewBinding、RecyclerView、自定义 View。
• Jetpack Compose：Composable、State、Modifier、重组。

HarmonyOS 这边则会看到：

• @Entry、@Component、build()。
• Row、Column、Stack、Flex、List、Grid。
• @State、@Prop、@Link、@Provide、@Consume 等状态装饰器。
• .width()、.height()、.backgroundColor()、.onClick() 这类链式属性。

因此后面讲 UI 时，我不会只说“LinearLayout 对应 Column”。更重要的是讲清楚：传统 Android View 的命令式更新，Compose 的声明式重组，ArkUI 的状态装饰器和组件描述之间，各自解决了什么问题。

第六层：工程化和生态成熟度也要比较

真实项目里，开发体验不只取决于 UI API。

Android 有 Android Studio、Gradle、Logcat、Profiler、Jetpack、丰富的三方库和大量历史经验。它的问题也很明显：历史包袱重，设备碎片化，旧项目架构差异大，XML View 和 Compose 经常长期并存。

HarmonyOS 有 DevEco Studio、hvigor、ohpm、HAP/HAR/HSP、多设备适配、ArkUI 预览和官方样例。它的优势是新体系更集中，官方样例对 ArkUI 和多设备场景的引导更明显；挑战是生态仍在快速变化，开发者需要持续跟进工具链和 API 版本。

所以这个系列不会只讲“某个控件怎么写”，也会讲构建、依赖、调试、发布、样例工程结构，以及一个 Android 开发者怎么判断学习优先级。

第七层：HarmonyOS 的特殊点是多设备

如果把 HarmonyOS 只理解成“换了一套 UI 框架的 Android”，就会错过它真正想强调的方向：多设备、分布式、跨端协同。

官方代码工坊样例里能看到手机、折叠屏、平板、PC/2in1、智能穿戴等多设备入口，也能看到组件库、样例、实践文章这些模块化组织方式。这类材料对我们后面写实例拆解会很有价值。

对很多普通业务应用来说，登录、列表、详情、网络、存储、权限、通知仍然是日常主线；这些场景里，两套体系的对比更多落在应用模型和开发范式上。等业务开始涉及手机、平板、手表、车机之间的流转与协同，HarmonyOS 的多设备设计才会真正进入核心视野。也正是在这里，它和传统移动应用开发拉开了距离。

这个系列怎么展开

接下来我会按从浅到深的方式写：

• 项目结构：Android 工程和 HarmonyOS 工程分别长什么样。
• 页面模型：Activity / Fragment 与 UIAbility / Page。
• 跳转通信：Intent 与 Want。
• UI 范式：XML View、Compose 与 ArkUI。
• Native 桥接层：JNI 与 NAPI。
• 状态管理：LiveData、Flow、Compose State 与 ArkUI 状态装饰器。
• 数据和系统能力：网络、存储、权限、通知、后台任务。
• 工程化：Gradle、hvigor、DevEco Studio、调试和发布。
• 迁移案例：登录页、列表页、详情页怎么从 Android 思维迁到 HarmonyOS。

我希望这个系列最后不是一堆零散笔记，而是一条 Android 开发者能真正走完的学习路线。

小结

Android 和 HarmonyOS 的对比，不能停留在“类名对应类名”。更合理的比较方式，是把它们拆成语言、应用模型、UI 范式、状态管理、系统能力、工程化和生态几个层次。

第一篇先把地图画出来。后面我们再一层层展开，从项目结构开始，逐步进入页面、UI、状态、数据和真实迁移案例。

// Kai@CodeHubble

// 观测坐标：Android-HarmonyOS/2026-05-07