前端视角下的鸿蒙开发

前言

鸿蒙系统，一个从诞生就一直处于舆论风口浪尖上的系统，从最开始的“套壳”安卓的说法，到去年的不再兼容安卓的NEXT版本的技术预览版发布，对于鸿蒙到底是什么，以及鸿蒙的应用开发的讨论从来没停止过。

这次我们就从一个前端开发的角度来了解一下鸿蒙，学习一下鸿蒙应用的开发。

一、 什么是鸿蒙

在开始之前，先问大家一个问题，大家听说过几种鸿蒙？

其实到目前为止，我们经常听到的鸿蒙系统，总共有三种，分别是：

OpenHarmony，HarmonyOS，以及HarmonyOS NEXT。

1. OpenHarmony

OpenHarmony（开源鸿蒙系统），由开放原子开源基金会进行管理。开放原子开源基金会由华为、阿里、腾讯、百度、浪潮、招商银行、360等十家互联网企业共同发起组建。包含了“鸿蒙操作系统”的基础能力，是“纯血”鸿蒙的底座。

这个版本的鸿蒙是开源的，代码仓库的地址在这里：gitee.com/openharmony。

从我个人的一些粗浅理解来看，OpenHarmony类似于Android里的AOSP，可以装到各种设备上，比如手表、电视甚至是一些嵌入式设备上，详见可见官网的一些例子。

2. HarmonyOS

基于 OpenHarmony、AOSP等开源项目，同时加入了自己的HMS（因为被美国限制后无法使用GMS）的商用版本，可以兼容安卓，也可以运行部分OpenHarmony开发的鸿蒙原生应用。

这个也是目前经常被吐槽是“套壳”安卓的系统，截止到目前（2024.04）已经更新到了HarmonyOS 4.2。

3. HarmonyOS NEXT

2023年秋季发布的技术预览版，在当前HarmonyOS的基础上去除了AOSP甚至是JVM，不再兼容安卓，只能运行鸿蒙原生应用，同时对OpenHarmony的能里进行了大量的更新，增加和修改了很多API。

这个也就是所谓的“纯血”鸿蒙系统，可惜的是这个目前我们用不到，需要以公司名义找华为合作开权限，或者个人开发者使用一台Mate60 Pro做专门的开发机。并且目前由于有保密协议，网上也没有太多关于最新API的消息。

NEXT版本文档：developer.huawei.com/consumer/cn…

据说目前HarmonyOS NEXT使用的API版本已经到了API12，目前官网可以访问的最新文档还是API9，所以接下来的内容也都是基于API9的版本来的。

4. 小结

所以一个粗略的视角来看，OpenHarmony、HarmonyOS以及HarmonyOS NEXT这三者之间的关系是这样的：

二、 初识鸿蒙开发

在大概知道了什么是鸿蒙之后，我们先来简单看一下鸿蒙开发的套件。下图是官网所描述的一些开发套件，包括了设计、开发、测试、上架所涉及到的技术和产品。

我们这篇文章里主要讨论右下角的三个：ArkTS、ArkUI、ArkCompiler。

三、 关于ArkTS的一些疑惑

作为一个前端开发，最常用的编程语言就是JavaScript或者TypeScript，那么在看到鸿蒙应用开发用到的编程语言是ArkTS之后，我脑子里最先蹦出来的就是下面这几个问题：

1. ArkTS语言的运行时是啥？

既然编程语言是TS（TS的拓展，ArkTS），那么它的运行时是什么呢？是V8？JSC？Hermes？还是其他什么呢？

2. ArkTS还是单线程语言吗？

ArkTS还是和JS一样，是单线程语言吗？

3. 基于TS拓展了什么？

TS是JS的超集，对JS进行了拓展，增加了开发时的类型支持。而ArkTS对对TS又进行了拓展，是TS的超集，那它基于TS拓展了什么内容呢？

下面我们一个一个来看。

1. Question1 - ArkTS语言的运行时

先说结论，ArkTS的运行时不是V8，不是JSC、Hermes，不是目前任何一种JS引擎。ArkTS的运行时是一个自研的运行时，叫做方舟语言运行时（简称方舟运行时）。

而这个运行时，执行的也不是JS/TS/ArkTS代码，而是执行的字节码和机器码。
这是因为方舟运行时是ArkCompiler（方舟编译器）的一部分，对于JS/TS/ArkTS的编译在运行前就进行了（和Hermes有点像，下面会讲到）。

我们来简单了解一下ArkCompiler，从官网的描述可以看到，ArkCompiler关注的重点主要有三个方面：

• 
  
• AOT 编译模式
  
• LiteActor 轻量化并发
  
• 源码安全
  

AOT 编译模式

首先是编译模式，我们知道，目前编程语言大多以下几方式运行：

• 
  
• 机器码AOT编译
  
  

  在程序运行之前进行AST生成和代码编译，编译为机器码，在运行的时候无需编译，直接运行，比如C语言。

  
  
• 中间产物AOT编译
  
  

  在程序运行前进行AST生成并进行编译，但不是编译为机器码，而是编译为中间产物，之后在运行时将字节码解释为机器码再执行。比如Hermes或Java编译为字节码，之后运行时由Hermes引擎或JVM解释执行字节码。

  
  
• 完全的解释执行
  
  

  在程序运行前不进行任何编译，在运行时动态地根据源码生成AST，再编译为字节码，最后解释执行字节码。比如没有开启JIT的V8引擎执行JS代码时的流程。

  
  
• 混合的JIT编译
  
  

  在通过解释执行字节码时（运行时动态生成或者AOT编译生成），对多次执行的热点代码进行进一步的优化编译，生成机器码，后续执行到这部分逻辑时，直接执行优化后的机器码。比如开启JIT的V8引擎运行JS或者支持JIT的JVM运行class文件。

  
  

当然，以上仅考虑生产环境下的运行方式，不考虑部分语言在生产和开发阶段不同的运行方式。比如Dart和Swift，一般是开发阶段通过JIT实时编译快速启动，生产环境下为了性能通过AOT编译。

在V8 JIT出现之前，所有的JS虚拟机所采用的都是采用的完全解释执行的方式，在运行时把源码生成AST语法树，之后生成字节码，然后将字节码解释为机器码执行，这是JS执行速度过慢的主要原因之一。

而这么做有以下两个方面的原因：

• 
  
• JS是动态语言，变量类型在运行时可能改变
  
• JS主要用于Web应用，Web应用如果提前编译为字节码将导致体积增大很多，对网络资源的消耗会更大
  

我们一个一个来说。

a. JS变量类型在运行时可能改变

首先我们来看一张图，这张图描述了现在V8引擎的工作流程，目前Chrome和Node里的JS引擎都是这个：

从上面可以看到，V8在拿到JS源码后，会先解析成AST，之后经过Ignition解释器把语法树编译成字节码，然后再解释字节码执行。

于此同时还会收集热点代码，比如代码一共运行了多少次、如何运行的等信息，也就是上面的Feedback的流程。

如果发现一段代码会被重复执行，则监视器会将此段代码标记为热点代码，交给V8的Turbofan编译器对这段字节码进行编译，编译为对应平台（Intel、ARM、MIPS等）的二进制机器码，并执行机器码，也就是图里的Optimize流程。

等后面V8再次执行这段代码，则会跳过解释器，直接运行优化后的机器码，从而提升这段代码的运行效率。

但是我们发现，图里面除了Optimize外，还有一个Deoptimize，反优化，也就是说被优化成机器码的代码逻辑，可能还会被反优化回字节码，这是为什么呢？

其实原因就是上面提到的“JS变量类型在运行时可能改变”，我们来看一个例子：

比如一个add函数，因为JS没有类型信息，底层编译成字节码后伪代码逻辑大概如这张图所示。会判断x和y的各种类型，逻辑比较复杂。

在Ignition解释器执行add(1, 2)时，已经知道add函数的两个参数都是整数，那么TurboFan在进一步编译字节码时，就可以假定add函数的参数是整数，这样可以极大地简化生成的汇编代码，不再判断各种类型，伪代码如第三张图里所示。

接下来的add(3, 4)与add(5, 6)由于入参也是整数，可以直接执行之前编译的机器码，但是add("7", "8")时，发现并不是整数，这时候就只能将这段逻辑Deoptimize为字节码，然后解释执行字节码。

这就是所谓的Deoptimize，反优化。可以看出，如果我们的JS代码中变量的类型变来变去，是会给V8引擎增加不少麻烦，为了提高性能，我们可以尽量不要去改变变量的类型。

虽然说使用TS可以部分缓解这个问题，但是TS只能约束开发时的类型，运行的时候TS的类型信息是会被丢弃的，也无法约束，V8还是要做上面的一些假定类型的优化，无法一开始就编译为机器码。

可以说TS的类型信息被浪费了，没有给运行时代码特别大的好处。

b. JS编译为字节码将导致体积增大

上面说到JS主要用于Web应用，Web应用如果提前编译为字节码将导致体积增大很多，对网络资源的消耗会更大。那么对于非Web应用，其实是可以做到提前编译为字节码的，比如Hermes引擎。

Hermes作为React Native的运行时，是作为App预装到用户的设备上，除了热更新这种场景外，绝大部分情况下是不需要打开App时动态下载代码资源的，所以体积增大的问题影响不是很大，但是预编译带来的运行时效率提升的好处却比较明显。

所以相对于V8，Hermes去掉了JIT，支持了生成字节码，在构建App的时候，就把JS代码进行了预编译，预编译为了Hermes运行时可以直接处理的字节码，省去了在运行阶段解析AST语法树、编译为字节码的工作。

一句题外话，Hermes去除了对JIT的支持，除了因为JIT会导致JS引擎启动时间变长、内存占用增大外，还有一部分可能的原因是，在iOS上，苹果为了安全考虑，不允许除了Safari和WebView（只有WKWebView支持JIT，UIWebView不支持）之外的第三方应用里直接使用JSC的JIT能力，也不允许第三方JS运行时支持JIT（相关问题）。

甚至V8专门出了一个去掉JIT的JIT-less V8版本来在iOS上集成，Hermes似乎也不太可能完全没考虑到这一点。

c. 取长补短

在讨论了V8的JIT和Hermes的预编译之后，我们再来看看ArkCompiler，截取一段官方博客里的描述：

还记得上面说的“TS的类型信息被浪费了”吗？TS的类型信息只在开发时有用，在编译阶段就被丢弃了，而ArkCompiler就是利用了这一点，直接在App构建阶段，利用TS的类型信息直接预编译为字节码以及优化机器码。

即在ArkCompiler中，不存在TS->JS的这一步转译，而是直接从TS编译为了字节码和优化机器码（这里存疑，官网文档没有找到很明确的说法，不是特别确定是否有TS->JS的转译。详见评论区，如果有知道的大佬可以在评论区交流一下）。

同时由于鸿蒙应用也是一个App而不是Web应用，所以ArkCompiler和Hermes一样，也是在构建App时就进行了预编译，而不是在运行阶段做这个事情。

简单总结下来，ArkCompiler像Hermes一样支持生成字节码，同时又将V8引擎JIT生成机器码的工作也提前在预编译阶段做了。是比Hermes只生成字节码的AOT更进一步的AOT（同时生成字节码和部分优化后的机器码）。

LiteActor轻量化并发

到这里其实已经可以回答上面讲到的第二个问题了，ArkTS还是单线程语言吗？

答案是：是的，还是单线程语言。但是ArkTS里通过Worker和TaskTool这两种方式支持并发。

同时ArkCompiler对现有的Worker进行了一些优化，直接看官网博客：

这里的Actor是什么呢？Actor是一种并发编程里的线程模型。

线程模型比较常见的就是共享内存模型，多个线程之间共享内存，比如Java里多个线程共享内存数据，需要通过synchronized同步锁之类的来防止数据一致性的问题。

Actor模型是另一种线程模型，“Actor”是处理并发计算的基本单位，每个Actor都有自己的状态，并且可以接收和发送消息。当一个Actor接收到消息时，它可以改变自己的状态，发送消息给其他Actor，或者创建新的Actor。

这种模型可以帮助开发者更好地管理复杂的状态和并发问题，因为每个Actor都是独立的，它们之间不会共享状态，这可以避免很多并发问题。同时，Actor模型也使得代码更易于理解和维护，因为每个Actor都是独立的，它们的行为可以被清晰地定义和隔离。

到这里大家应该已经比较明白了，前端里的Web Worker就是这种线程模型的一种体现，通过Worker来开启不同的线程。

源码安全

按照官网的说法，ArkCompiler会把ArkTS编译为字节码，并且ArkCompiler使用多种混淆技术提供更高强度的混淆与保护，使得HarmonyOS应用包中装载的是多重混淆后的字节码，有效提高了应用代码安全的强度。

2. Question2 - ArkTS还是单线程语言吗

这个刚刚已经回答了，还是单线程语言，借用官网的描述：

HarmonyOS应用中每个进程都会有一个主线程，主线程有如下职责：

1. 
   
2. 执行UI绘制；
   
3. 管理主线程的ArkTS引擎实例，使多个UIAbility组件能够运行在其之上；
   
4. 管理其他线程（例如Worker线程）的ArkTS引擎实例，例如启动和终止其他线程；
   
5. 分发交互事件；
   
6. 处理应用代码的回调，包括事件处理和生命周期管理；
   
7. 接收Worker线程发送的消息；
   

除主线程外，还有一类与主线程并行的独立线程Worker，主要用于执行耗时操作，但不可以直接操作UI。Worker线程在主线程中创建，与主线程相互独立。最多可以创建8个Worker。

3. Question3 - 基于TS拓展了什么

当前，ArkTS在TS的基础上主要扩展了如下能力：

• 
  
• 基本语法：ArkTS定义了声明式UI描述、自定义组件和动态扩展UI元素的能力，再配合ArkUI开发框架中的系统组件及其相关的事件方法、属性方法等共同构成了UI开发的主体。
  
• 状态管理：ArkTS提供了多维度的状态管理机制。在UI开发框架中，与UI相关联的数据可以在组件内使用，也可以在不同组件层级间传递，比如父子组件之间、爷孙组件之间，还可以在应用全局范围内传递或跨设备传递。另外，从数据的传递形式来看，可分为只读的单向传递和可变更的双向传递。开发者可以灵活地利用这些能力来实现数据和UI的联动。
  
• 渲染控制：ArkTS提供了渲染控制的能力。条件渲染可根据应用的不同状态，渲染对应状态下的UI内容。循环渲染可从数据源中迭代获取数据，并在每次迭代过程中创建相应的组件。数据懒加载从数据源中按需迭代数据，并在每次迭代过程中创建相应的组件。
  

而上面这些，也就是我们接下来要介绍的ArkTS+ArkUI的语法。

四、 ArkTS & ArkUI

首先，在聊ArkUI之前，还有一个问题大家可能比较感兴趣：ArkUI是怎么渲染我们写的UI呢？

答案是自绘，类似于Flutter，使用自己的渲染引擎（应该是发展于Skia），而不是像RN那样将UI转为不同平台上的底层UI。

不管是从官网的描述[1]、[2]来看，还是社区里的讨论来看，ArkUI的渲染无疑是自绘制的，并且ArkUI和Flutter之间的联系很密切：

1. 基本语法

从前端的角度来看，ArkTS和ArkUI的定位其实就是类似于前端中TS+React+配套状态管理工具（如Redux），可以用TS写声明式UI（有点像写jsx），下面是基本语法：

• 
  
• 装饰器
  
  

  用于装饰类、结构、方法以及变量，并赋予其特殊的含义。

  
  

  如上述示例中@Entry、@Component和@State都是装饰器，@Component表示自定义组件，@Entry表示该自定义组件为入口组件，@State表示组件中的状态变量，状态变量变化会触发UI刷新

  
  
• 自定义组件
  
  

  可复用的UI单元，可组合其他组件，如上述被@Component装饰的struct Hello

  
  
• UI描述
  
  

  以声明式的方式来描述UI的结构，例如build()方法中的代码块

  
  
• 系统组件
  
  

  ArkUI框架中默认内置的基础和容器组件，可直接被开发者调用，比如示例中的Column、Text、Divider、Button

  
  
• 事件方法
  
  

  组件可以通过链式调用设置多个事件的响应逻辑，如跟随在Button后面的onClick()

  
  
• 属性方法
  
  

  组件可以通过链式调用配置多项属性，如fontSize()、width()、height()、backgroundColor()等

  
  

2. 数据驱动UI

作为一个声明式的UI框架，ArkUI和其他众多UI框架（比如React、Vue）一样，都是通过数据来驱动UI变化的，即UI = f(State)。我们这里引用一下官网的描述：

在声明式UI编程框架中，UI是程序状态的运行结果，用户构建了一个UI模型，其中应用的运行时的状态是参数。当参数改变时，UI作为返回结果，也将进行对应的改变。这些运行时的状态变化所带来的UI的重新渲染，在ArkUI中统称为状态管理机制。

自定义组件拥有变量，变量必须被装饰器装饰才可以成为状态变量，状态变量的改变会引起UI的渲染刷新。如果不使用状态变量，UI只能在初始化时渲染，后续将不会再刷新。 下图展示了State和View（UI）之间的关系。

View(UI)：UI渲染，指将build方法内的UI描述和@Builder装饰的方法内的UI描述映射到界面。
State：状态，指驱动UI更新的数据。用户通过触发组件的事件方法，改变状态数据。状态数据的改变，引起UI的重新渲染。

在ArkUI中，提供了大量的状态管理相关的装饰器，比如@State、@Prop、@Link等。

更多细节详见状态管理。

3. 渲染控制

在ArkUI中，可以像React那样，通过if else，for each等进行跳转渲染、列表渲染等，更多细节详见渲染控制。

ArkUI通过自定义组件的build()函数和@builder装饰器中的声明式UI描述语句构建相应的UI。在声明式描述语句中开发者除了使用系统组件外，还可以使用渲染控制语句来辅助UI的构建，这些渲染控制语句包括控制组件是否显示的条件渲染语句，基于数组数据快速生成组件的循环渲染语句以及针对大数据量场景的数据懒加载语句。

4. 更多语法

语法其实不是我们这篇文章的重点，上面是一些大概的介绍，更多语法可以详见官网，或者我的另外一篇专门讲解语法的笔记《前端视角下的ArkTS语法》(先留个占位符，有时间了补充一下)。

5. ArkTS & ArkUI小结

从前面的内容其实可以看到，ArkUI和RN相似点还挺多的：

不同的是RN是将JS声明的UI，转换成iOS、Android原生的组件来渲染，而ArkUI则是采用自绘制的渲染引擎来自绘UI。

从这点来看，鸿蒙更像是Flutter，只不过把开发语言从Dart换成了JS/TS（ArkTS），和Flutter同样是自绘制的渲染引擎。

社区里其实也有类似的思考：其它方向的探索：JS Engine + Flutter RenderPipeLine。而ArkUI则是对这种思路的实现。

感觉这也可以从侧面解释为什么ArkUI的语法和Flutter比较像，应该参考了不少Flutter的实现（比如渲染引擎）。

而华为宣称鸿蒙可以反向兼容Flutter甚至是RN也就没有那么难以理解了，毕竟ArkUI里Flutter和RN的影子确实不少。

另外,除了ArkUI以外，华为还提供了一个跨平台的开发框架ArkUI-X，可以像Flutter那样，跨HarmonyOS、Android、iOS三个平台。

这么看来，ArkTS&ArkUI从开发语言、声明式UI的语法、设计思想来看，不管是前端、iOS、安卓、或者Flutter、RN，鸿蒙应用开发都是比较入门友好的。

五、 其他

1. 包管理工具

HarmonyOS开发中，使用的包管理工具是ohpm，目前看来像是一个借鉴pnpm的三方包管理工具，详见官方文档。

另外，鸿蒙也提供了第三方包发布的仓库：ohpm.openharmony.cn。

2. 应用程序结构

在鸿蒙系统中，一个应用包含一个或者多个Module，每一个Module都可以独立进行编译和运行。

发布时，每个Module编译为一个.hap后缀的文件，即HAP。每个HarmonyOS应用可以包含多个.hap文件。

在应用上架到应用市场时，需要把应用包含的所有.hap文件打包为一个.app后缀的文件用于上架。

但是.app包不能直接安装到设备上，只是上架应用市场的单元，安装到设备上的是.hap。

鸿蒙应用的整体开发调试与发布部署流程大概是这样的：

HAP可分为Entry和Feature两种类型：

• 
  
• Entry类型的HAP：是应用的主模块
  在同一个应用中，同一设备类型只支持一个Entry类型的HAP，通常用于实现应用的入口界面、入口图标、主特性功能等。
  
• Feature类型的HAP：是应用的动态特性模块
  一个应用程序包可以包含一个或多个Feature类型的HAP，也可以不包含；Feature类型的HAP通常用于实现应用的特性功能，可按需下载安装
  

而设计成多hap，主要是有3个目标：

多说一句：从这些描述来看，给我的感觉是每个.hap有点类似于前端项目中Mono-repo仓库中的一个package，各个package之间有一定的依赖，同时每个package可以独立发布。

另外，HarmonyOS也支持类似RN热更新的功能，叫做快速修复（quick fix）。

六、 总结

现在再回到最开始那个问题：什么是鸿蒙？从前端视角来看，它是这样一个系统：

• 
  
• ArkTS作为应用开发语言
  
• 类Flutter、Compose、Swift的声明式UI语法
  
• 和React有些相似的数组驱动UI的设计思想
  
• ArkCompiler进行字节码和机器码的AOT编译 + 方舟运行时
  
• 类似Flutter Skia渲染引擎的自绘制渲染引擎
  
• 通过提供一系列ohos.xxx的系统内置包来提供TS访问系统底层的能力（比如网络、媒体、文件、USB等）
  

所以关于HarmonyOS是不是安卓套壳，个人感觉其实已经比较明了了：以前应该是，但快要发布的HarmonyOS NEXT大概率不再是了。

其他一些讨论

其实在华为宣布了HarmonyOS NEXT不再兼容安卓后，安卓套壳的声音越来越少了，但现在网上另外一种声音越来越多了：

1. 
   
2. HarmonyOS NEXT是一个大号的小程序底座，上面的应用都是网页应用，应用可以直接右键查看源码，没有安全性可言
   
3. HarmonyOS NEXT上的微信小程序就是在小程序里运行小程序
   
4. 因为使用的是ArkTS开发，所以的HarmonyOS NEXT上的应用性能必然很差
   

这种说法往往来自于只知道鸿蒙系统应用开发语言是TS，但是没有去进一步了解的人，而且这种说法还有很多人信。其实只要稍微看下文档，就知道这种说法是完全错误的。

首先它的View层不是DOM，而是类似Flutter的自绘制的渲染引擎，不能因为使用了TS就说是网页，就像可以说React Web是网页应用，但不能说React Native是网页应用，同样也不是说Flutter是网页应用。

另外开发语言本身并不能决定最终运行性能，还是要看编译器和运行时的优化。同样是JS，从完全的解释执行（JS->AST->字节码->执行），到开启JIT的V8，性能都会有质的飞跃。从一些编程语言性能测试中可以看到，开启JIT的NodeJs的性能，甚至和Flutter所使用的Dart差不多。

而ArkCompiler是结合了Hermes和V8 JIT的特点，AOT编译为字节码和机器码，所以理论上讲性能应该相当不错。

（当然我也没有实机可以测试，只能根据文档来分析）。

上面这种HarmonyOS NEXT是网页应用的说法还有可能是由于，最早鸿蒙应用支持使用HTML、CSS、JS三件套进行兼容Web的开发，导致了刻板印象。这种开发方式使用的是FA模型，而目前这种方式已经不是鸿蒙主推的开发方式了。

到这里这篇文章就结束了，整体上是站在一个前端开发的视角下来认识和了解鸿蒙开发的，希望能帮助一些像我一样对鸿蒙开发感兴趣的前端开发入门。大家如果感兴趣可以到鸿蒙官网查看更多的了解。

如果感觉对你有帮助，可以点个赞哦~