听了几年的“鸿蒙”，这两天终于正儿八经地尝试了一下，没想到出乎意料的爽。
- 内推朋友适配鸿蒙
事情还要从我做前端的哥们说起。
去年年底，朋友工作了 8 年的公司终于支撑不住，开始裁员，他也是其中一个。万幸的是，赔偿还可以。但年底求职本就不易，这两年 AI 的强势进化又让老板们看到了“降本增效”的机会，工作更不好找了。
经过持续的努力，年初朋友终于入职了一家做 AI 编辑器的公司。无奈通勤实在太远，加之初创团队加班压力大，一直苦撑至今。今年 9 月份，我公司的定制化业务组接了个大项目，刚好缺前端好手，我内推了一把。于是才有了上面的对话。
鸿蒙对于前端、客户端开发的小伙伴来说，可能比较熟悉了，但我是做 Java 后端开发的，属于“没吃过猪肉只看过猪跑”。索性趁此机会，去了解了一下。
- 该如何介绍鸿蒙？
比起“鸿蒙是什么”，搞清楚“鸿蒙想要做什么”更重要。
鸿蒙的核心目标是解决传统操作系统在多设备互联、生态协同、用户体验一致性等方面的痛点：
- 解决 “多设备割裂” 问题：打破硬件边界，实现 “超级终端” 体验
- 解决 “操作系统碎片化” 问题：一套系统适配全场景硬件
- 解决 “生态协同弱” 问题：打通跨设备应用与服务生态
- ...
这么说还是有点抽象，我举几个例子。
对于普通用户
传统场景下，手机、平板、电脑等设备是独立运行的，数据（如照片、文档）和服务（如视频通话、导航）难以无缝流转，比如手机上的视频不能直接在电视上 续播、电脑编辑的文档需 手动传到平板。而鸿蒙可以将多个物理设备 “虚拟整合” 为一个 “超级终端”，让设备间 自动协同，数据和服务能在设备间无感流转，彻底消除多设备使用时的 “割裂感”。例如：手机拍摄的视频，可直接在电视上继续剪辑；电脑上未完成的文档，打开平板就能无缝接续编辑，无需手动传输。
怎么做到的？这就是鸿蒙系统（Harmony OS）在做的事。通过分布式软总线、分布式数据管理、分布式任务调度这些核心技术达到 “分布式设备虚拟化”的目的，打破硬件边界，实现“超级终端”。
分布式软总线就像用一根看不见的网线把 近场设备都串联起来，协同效率可以达到几十MB/s甚至上百MB/s。通常的传输路径是手机 -> 路由器 -> 电脑，但当检测到需要传输大文件（如视频、大量照片）时，它通常不会让数据再绕道路由器，而是会促使手机和电脑之间建立一个 Wi-Fi P2P (Peer-to-Peer，点对点) 直连通道。
分布式软总线是设备连接的基石，为分布式数据管理、分布式任务调度提供了支撑。
当你在电脑上编辑文档时，“分布式数据管理”技术就像一个勤奋的“同步秘书”。它会 实时地、在后台将你文档的最新内容、光标停留的具体位置、甚至你刚刚输入但还未手动保存的文字等“任务上下文信息”，安全地同步到你账号下的设备圈内。
你在平板上打开同一个文档App（或者通过控制中心点击“流转”卡片），“分布式任务调度”会立刻命令App 从“分布式数据管理”中读取刚刚同步好的、最新的“任务上下文信息”。于是，App瞬间就将文档恢复到你在电脑上离开时的样子，实现了真正的“无缝接续”。
总之，不同的设备间通过鸿蒙系统连成了一个“超级终端”。
那么，作为当前两大优秀生态系统，苹果的“协同”和鸿蒙的“协同”有什么区别呢？
苹果的生态协同能力，以“连续互通”（Continuity）为代表，非常成熟、稳定且好用。而鸿蒙的协同，以“超级终端”为核心，理念上更进一步，更具颠覆性。
对于开发者
传统模式下，不同类型的硬件（手机、IoT设备、工业设备）需适配不同的操作系统（如手机用Android/iOS，IoT设备用Linux/RTOS，电脑用Windows/macOS），开发者需为不同设备重复开发应用，硬件厂商也需维护多套系统，导致生态碎片化严重。鸿蒙提出“一次开发、多端部署”“一套系统、万物互联”的理念。
你可以这么去理解：鸿蒙手机、鸿蒙电脑、鸿蒙平板、智能设备上运行的，都是基于 同一套鸿蒙核心架构的系统。鸿蒙通过其“弹性部署”的核心能力，会根据设备的硬件资源，智能地“组装”出最适合它的系统版本。
- 对于开发者： 鸿蒙的ArkUI框架具备强大的 自适应UI能力和响应式布局机制。这意味着，应用的核心业务逻辑代码只需编写一套。而UI展现层，开发者可以在同一个代码工程内， 通过提供差异化的布局策略，就能高效适配手机、平板、手表、车机、智能家居等不同屏幕尺寸和交互方式的设备， 而无需为每个平台从零开始重复开发。
- 对于硬件厂商： 无需为不同设备定制不同系统。鸿蒙的“弹性部署”能力，使其可以灵活适配从仅需轻量版系统的低算力智能灯泡，到需标准版系统的中算力智能手表，再到需完整版系统的高算力手机/电脑，极大降低了硬件厂商进行系统级研发和维护的成本与复杂性。
鸿蒙与安卓
说到鸿蒙，有一个问题是无法回避的：鸿蒙到底是不是安卓？这也是大众容易混淆的问题。
最精准的回答是： 过去的鸿蒙（2.0-4.0版本）包含了安卓的“遗产”，可以运行安卓应用；但现在及未来的鸿蒙（HarmonyOS NEXT）则完全不是安卓，是一个与安卓和iOS平行的独立系统。
为什么 HarmonyOS NEXT 以前要兼容 AOSP 呢？简单来说，就是为了在新操作系统发布的初期，解决 最致命的“应用生态”问题而采取的一项极其务实且必要的“过渡策略”。
这背后是科技行业一个闻名的“先有鸡还是先有蛋”的困境：
- 没有应用，就没有用户：如果一个手机操作系统上不能运行微信、支付宝、抖音等日常应用，那它对消费者来说就是一块“板砖”，根本不会有人用。
- 没有用户，就没有开发者：如果一个操作系统没有足够多的用户，开发者就没有动力去投入时间、金钱和人力为其开发专门的应用。
历史上，很多试图挑战安卓和iOS的操作系统最终都倒在了这个“生态困境”上。
为了打破这个死循环，华为选择了一条非常聪明的“两步走”战略，而兼容AOSP就是这至关重要的第一步。这是很正常、也很聪明的做法。
- DevEco、ArkTS、ArkUI
作为普通开发者，相比鸿蒙系统，我们更关心如何为鸿蒙系统开发app。其中最重要的就是 DevEco（编辑器）、ArkTS（语言）、ArkUI（框架）。
开发工具
DevEco Studio 是华为官方为鸿蒙（HarmonyOS）和欧拉（openEuler）生态推出的一站式、集成开发环境（IDE）。和谷歌官方的安卓开发工具 Android Studio 一样，DevEco也是基于IntelliJ IDEA开发的。所以，做 Java 开发的小伙伴会很眼熟。
下载中心 | 华为开发者联盟-HarmonyOS开发者官网，共建鸿蒙生态
安装好后，新建一个空项目：
什么都不用做，DevEco 会自动帮你下载好项目所需的环境。
语言与用户界面
我一直对 TypeScript 非常感兴趣，也很喜欢这门语言，因为它同时具备了 JavaScript 的灵活和 Java 的类型限制。如果你之前学习过 TypeScript，或者本身就是前端开发者，那么 ArkTS 几乎可以零门槛入手。
ArkTS 作为鸿蒙应用开发的核心语言，它的语法重点可以分为两大块：
- 完全继承自TypeScript（TS）的基础语法：这是语言的根基。
- ArkUI框架赋予的声明式UI语法：这是ArkTS在鸿蒙开发中的核心特色，主要通过各种“装饰器”来实现。
所谓 ArkUI（方舟开发框架），是一套构建鸿蒙应用界面的框架。在鸿蒙应用的世界里，构建页面的 最小单位是“组件”：
- 基础组件：界面呈现的基础元素
- Text 文本
- Image 图片
- Button 按钮等
- 容器组件：控制布局
- Row 行
- Column 列
ArkTS+ArkUI 极大简化了开发的难度，比如我们可以很快地基于 ArkUI 提供的组件构建一个自定义组件：
是不是非常简单？这得益于 ArkUI 倡导的“声明式 UI”的思想。
什么是声明式UI？
核心思想：你只管描述 “UI应该长成什么样”，而不用关心“UI是如何一步步变成那个样子的”。
你可以把它想象成“点餐”
- 声明式 (Declarative)：你直接告诉服务员：“我想要一个12寸的、有芝士和香肠的披萨。” 你 声明了你最终想要的 结果 (What)。至于厨师是先放香肠还是先放芝士，你是完全不关心的。
- 命令式 (Imperative)：你跑进后厨，一步步地指挥厨师：“1. 拿出面团；2. 把它擀成12寸；3. 抹上番茄酱；4. 撒上芝士；5. 摆上香肠...”。你提供的是一套详细的 步骤 (How)。
如果把上面的代码翻译成 旧版安卓的写法，可能是这样的。
- 先定义界面布局 (XML文件)
2.再编写界面逻辑
前端开发也是如此。传统的 HTML+CSS+JS 中，HTML 和 CSS 是典型的 声明式语言，但用于操作它们的传统 JavaScript 则是 命令式的。我们通过 HTML 和 CSS 声明了文档结构和样式规则，但当页面需要交互和动态变化时，传统的JS就登场了，而它操作UI的方式是命令式的。
假设我们想在点击按钮后，把段落的颜色变成红色。传统的JS代码会是这样：
你必须亲手一步步地指挥浏览器去完成UI的变更。
正是因为传统JS的命令式操作非常繁琐且容易出错，才催生了 React、Vue 这类现代前端框架。它们的核心思想，就是 在JavaScript的世界里引入“声明式”的开发范式。从而让开发者更专注于业务逻辑（数据状态），而非繁琐的UI操作步骤。鸿蒙的ArkTS和ArkUI也是顺应了这个行业的大趋势。
数据驱动
如果你了解过 Vue 或者 React，那么对下面的 @State 也会感觉很熟悉。
简单来说，@State 是一个“状态”装饰器。@State 的核心功能就一个：把它所“装饰”的变量，变成当前UI组件的“状态数据源（Source of Truth）”。一旦这个变量的值发生改变，ArkUI框架就会自动重新渲染（re-render）所有依赖该变量的UI部分。
UI 构建函数
@Builder 是一个装饰器，用来 在组件内部，定义一个可复用的、可参数化的“UI构建函数”。
你可以把ArkUI的@Builder，理解成一种定义在组件内部的、可带参数的‘具名插槽’模板，但它不是用来给父组件填充内容的，而是给自己内部的build方法调用，用来封装和复用UI片段，让你的主build函数保持干净。
关于 ArkUI，还有很多很多值得说的，篇幅有限，留待大家去探索。总体而言，无论对于前端开发者还是后端新手，都非常容易上手。
- APMS
上面的 demo 让我们感受了ArkTS声明式UI的简洁和高效。但作为开发者，我们都清楚，代码写完只是第一步，真正的考验来自应用上线之后。
在后端开发的世界里，应用上线后如果出了问题，我们的第一反应是什么？没错，ssh登录服务器，tail -f xxx.log看日志。如果遇到性能瓶颈，我们有JProfiler、Arthas、SkyWalking这些神器。我们有一整套方法论来监控和诊断线上问题。
但App开发不一样。应用是运行在上千种不同型号、不同网络环境的用户设备上。它就是一个个“黑匣子”，我们无法登录，也看不到日志。当用户抱怨“你的App总是卡退”或“用起来好慢”时，我们常常一头雾水，无法复现，更无从下手。
我现在公司是做 SAAS 服务的，经常会收到一些小程序行为不符合逾期的情况，为了更好地排查问题，我们的前端小伙伴专门接入了小程序用户行为等数据。
那么，鸿蒙是怎么做的呢？
在翻阅官方文档的过程中，我惊喜地发现鸿蒙提供了一个“开箱即用”的官方解决方案—— APMS (Application Performance Management Service)， 只需要开通服务即可，非常容易上手。
最后，推荐对前端和鸿蒙感兴趣的小伙伴可以去试试，思想都是相通的。网上已有很多鸿蒙开发的教程，相对前端复杂的体系，确实简单了很多。