Harmony OS （eTS语言）的起源和演进

Harmony OS（eTS语言）的起源和演进

1.eTS语言的起源和演进

1.1.概括

  Mozilla创造了JS，Microsoft创建了TS，Huawei进一步推出了eTS。eTS（extended TypeScript）是鸿蒙(Harmony)生态的一种应用开发语言。也是Harmony系统（Harmony开发语言java、js、eTS,Harmony3.0后java语言废弃了）主推的一种开发语言。它在TypeScript（简称TS）的基础上，扩展了声明式UI、状态管理等相应的能力，让开发者可以以更简洁、更自然的方式开发高性能应用。TS是JavaScript（简称JS）的超集，eTS则是TS的超集。eTS会结合应用开发和运行的需求

1.2 js

  JavaScript最初受Java启发而开始设计的，目的之一就是“看上去像Java”，因此语法上有类似之处，一些名称和命名规范也借自Java。js语言由Mozilla创造，最初主要是为了解决页面中的逻辑交互问题，它和HTML（负责页面内容）、CSS（负责页面布局和样式）共同组成了Web页面/应用开发的基础。javaScript （简称“js”） 是一种轻量级解释型的编程语言（代码不进行预编译）。JavaScript是一种属于网络的高级脚本语言,已经被广泛用于Web应用开发,常用来为网页添加各式各样的动态功能,为用户提供更流畅美观的浏览效果。通常JavaScript脚本是通过嵌入在HTML中来实现自身的功能的。JavaScript也可以用于其他场合，如服务器端编程（Node.js）。随着Web和浏览器的普及，以及Node.js进一步将JS扩展到了浏览器以外的环境，js语言得到了飞速的发展。在2015年相关的标准组织ECMA发布了一个主要的版本ECMAScript 6（简称ES6），这个版本具备了较为完整的语言能力，包括类（Class）、模块（Module）、相关的语言基础API增强（Map/Set等）、箭头函数（Arrow Function）等。从2015年开始，ECMA每年都会发布一个标准版本，比如ES2016/ES2017/ES2018等，js语言越来越成熟。
  j为了提升应用的开发效率，相应的js前端框架也不断地涌现出来。其中比较典型的有Facebook发起的React.js，以及个人开发者尤雨溪发起的Vue.js。React和Vue的主要出发点都是将响应式编程的能力引入到应用开发中，实现数据和界面内容的自动关联处理。具体的实现方式上，React对js做了一些扩展，引入了JSX（JavaScript XML）语法，可以将HTML的内容统一表示成js来处理；Vue则是通过扩展的模板语法（Template）的方式来处理。

1.2.1 React

  React 起源于 Facebook 的内部项目，因为该公司对市场上所有 JavaScript MVC 框架，都不满意，就决定自己写一套，用来架设Instagram 的网站。做出来以后，发现这套东西很好用，就在2013年5月开源了。
  React 是一个用于构建用户界面的JavaScript 库。React主要用于构建UI，很多人认为 React 是 MVC 中的 V（视图）。React 拥有较高的性能，代码逻辑非常简单，越来越多的人已开始关注和使用它。
  React 是用于动态构建用户界面的 JavaScript 库(只关注于视图)

1.2.1 Vue

  Vue是一款前端渐进式框架，可以提高前端开发效率。
  Vue可以说是MVVM架构的最佳实践，是一个JavaScript MVVM库，是一套构建用户界面的渐进式框架。专注于 MVVM 中的 ViewModel，不仅做到了数据双向绑定，而且也是一款相对比较轻量级的JS 库，API 简洁。
  Vue用于构建用户界面的渐进式框架，渐进式代表的含义是：主张最少。每个框架都不可避免会有自己的一些特点，从而会对使用者有一定的要求，这些要求就是主张，主张有强有弱，它的强势程度会影响在业务开发中的使用方式。

1.3. TS

  在类型系统基础上，引入了声明文件（Declaration Files）来管理接口或其他自定义类型。声明文件一般是以d.ts的形式来定义模块中的接口，这些接口和具体的实现做了相应的分离，有助于各模块之间的分工协作。另外，TS通过接口，泛型（Generics）等相关特性的支持，进一步增强了设计复杂的框架所需的扩展以及复用能力。
在工具层面，TS也有相应的编辑器、编译器、IDE（Integrated Development Environment）插件等相关的工具，来进一步提升开发效率。
  TS在兼容JS生态方面也做了较好的平衡，TS应用通过相应编译器可以编译出纯JS应用，可以在标准的JS引擎上运行。同时，TS定位为JS的超集，即JS应用也是合法的TS应用。此外，在标准层面上，TS兼容ECMA的相应标准，并维护那些还未成为ECMA标准的新特性。
持续演进，包括但不限于引入分布式开发范式、并行和并发能力增强、类型系统增强等方面的语言特性。

1.3. eTS

  从UI框架的需求角度，eTS在TS的类型系统的基础上，做了进一步的扩展：定义了各种装饰器、自定义组件和UI描述机制，再配合UI开发框架中的UI内置组件、事件方法、属性方法等共同构成了应用开发的主体。在应用开发中，除了UI的结构化描述之外，还有一个重要的方面：状态管理。如上述示例中，用 @State 装饰过的变量 myText ，包含了一个基础的状态管理机制，即 myText 的值的变化会自动触发相应的 UI 变更 （Text组件）。ArkUI 中进一步提供了多维度的状态管理机制。和 UI 相关联的数据，不仅可以在组件内使用，还可以在不同组件层级间传递，比如父子组件之间，爷孙组件之间，也可以是全局范围内的传递，还可以是跨设备传递。另外，从数据的传递形式来看，可分为只读的单向传递和可变更的双向传递。开发者可以灵活的利用这些能力来实现数据和 UI 的联动。
  总体而言，ArkUI开发框架通过扩展成熟语言、结合语法糖或者语言原生的元编程能力、以及UI组件、状态管理等方面设计了统一的UI开发范式，结合原生语言能力共同完成应用开发。这些构成了当前eTS基于TS的主要扩展。
  当然，eTS以及ArkUI开发框架还很年轻，在渲染方面，主流Web引擎由于本身复杂度以及历史原因，性能、资源占用方面与常见OS原生框架都有一定的差距，尤其在移动平台上。React Native通过渲染架构的改进一定程度上提升了性能体验，但在平台渲染效果和能力的一致性，以及JS语言性能等方面还是存在一定的不足。还有很多其它方面也会持续演进，比如UI自定义能力的进一步完善，语言运行时以及跨语言交互的进一步优化，跨OS平台能力的扩展（包括Android、iOS等），分布式开发范式等等。

2. Harmony OS的起源和演进

2.1. 鸿蒙概念阶段

  2012年9月：华为开始规划自有操作系统“鸿蒙”，其初衷是为了防范于未然，确保在关键时刻有备用系统可以使用。2016年：鸿蒙项目正式启动，被命名为“HarmonyOS”，华为开始全力投入操作系统的研发工作。2017年至2019年间：鸿蒙内核经历了多个版本的开发与完善。2019年5月24日：华为申请了“华为鸿蒙”商标。这个时候大家思想都还没有统一，这个名字甚至都是自媒体扒出来的。

2.2. HarmonyOS 1

  2019年8月9日：华为正式发布了鸿蒙系统（HarmonyOS 1.0）,开发语言是java,只能在模拟器pad上运行,开发一些简单功能。这个阶段其实只有OpenHarmony 1.0，而且主要还是liteos改。Liteos是华为用在路由器等iot设备的操作系统。真实情况是:鸿蒙的完全体还没开发完，只拿出了liteos部分。

2.3. HarmonyOS 2

  2020年：华为发布了鸿蒙HarmonyOS 2.0版本，该版本支持多种设备，包括智能手机、平板电脑、智能电视、智能穿戴等，此时HarmonyOS开发语言为java、js并存，后期HarmonyOS 2.1偏重于js语言开发。
  这个阶段手机叫HarmonyOS 2，正式改名。此时的手机鸿蒙是双框架一一同时支持AOSP的APK和鸿蒙的HAP格式，带有OpenHarmony，但是其中后者只有开发者用DevEco才能在手机上运行，所以事实上鸿蒙2是“真鸿蒙”但是“未启用”的状态。
  这种状态造成的最大尴尬是，你说这是鸿蒙，那鸿蒙HAP生态默认不开启;你说不是鸿蒙，但又具备完整的鸿蒙能力。这种尴尬类似于“九岁的男孩是不是男人一样。
  此时的HarmonyOS最大问题是因为安卓只能运行APK，所以HAP格式解压缩后需要有一个APK的入口(并非软件实体)。同时根据评论区可知，部分api的实现是通过映射aosp实现的，这不意外。另一位开发者透露，通过对代码进行追踪，当时的iava代码是通过安卓实现的，这也合理。这造成了广泛的误解:鸿蒙app是套壳安卓app。真实的情况是:临时为开发者能在手机鸿蒙上运行而做的入口和映射，包中APK并非程序本体。DevEco其实可以佐证这个不是APK套壳想要编译出完整的APK需要AndroidSDK，但DevEco使用的HarmonyOS SDK并不包含Android SDK，具体的文件都是清晰可查看对比的。这个阶段的最大问题是，API本身的不稳定一这对开发者来说不是特别友好，但也是技术探索中的必要弯路。这个阶段的OepnHarmony已经初步能刷到开发板、带有桌面了，源代码6GB，容量是上一阶段的30倍。

2.4. HarmonyOS 3

  2022年7月27日晚，HarmonyOS 3.0系统正式发布，整体还是JS/TS语言，非常适合低成本开发APP。其中，基于TS扩展的声明式UI范式中所用的语言就是eTS。这个阶段手机叫HarmonyOS 3.0仍然是双框架，更加成熟。
  ArkTS是HarmonyOS优选的主力应用开发语言，围绕应用开发在TypeScript（简称TS）生态基础上做了进一步扩展。扩展能力包含声明式UI描述、自定义组件、动态扩展UI元素、状态管理和渲染控制。状态管理作为基于ArkTS的声明式开发范式的特色，通过功能不同的装饰器给开发者提供了清晰的页面更新渲染流程和管道。状态管理包括UI组件状态和应用程序状态，两者协作可以使开发者完整地构建整个应用的数据更新和UI渲染。ArkTS语言的基础知识请参考学习ArkTS语言。
  尽管这时候可以推进鸿蒙HAP生态了，但是这时候由于华为使用高通芯片没有驱动OpenHarmony是否能部署到高通芯片上取决于高通，仅有已经停售的高通芯片高通会开放驱动以供开发者自行匹配。此时的华为消费者业务萎靡不振，软件厂商配合的意愿也要打问号。

2.5. HarmonyOS 4

  HarmonyOS 4.0于2023年8月4日正式发布。这个阶段的鸿蒙仍然是双框架。OpenHarmony已经演进到API10一一个非常成熟的系统了。这个阶段华为推出了HarmonyOS NEXT，top200的app在推进适配。
  此时的HarmonyOS可以打成app、hap包。app包仅用于上架应用市场，是最终release上架包；hap包为调试版本，您调试应用过程中可以使用hap进行运行，同时app包无法通过hdc命令安装，hap调试包可通过hdc app install xxx.hap进行安装。
  该版本为开发者提供了一系列功能和工具，旨在提升应用开发的便捷性和效率。其中的一些重要更新包括ArkTS语言、Stage模型、ArkUI增强组件以及DevEcoStudio功能的增强。
  HarmonyOS NEXT开发者预览版。据了解，HarmonyOS NEXT开发者预览版8月面向合作企业开发者开放，2024年第一季度面向所有开发者开放。HarmonyOS NEXT不再兼容安卓应用，如果打开安卓APK文件，会提示“无法打开此文件”。
  值得注意的是，HarmonyOS NEXT 系统底座全线自研，去掉了传统的 AOSP 代码，仅支持鸿蒙内核和鸿蒙系统的应用，减少了 40% 的冗余代码，使系统的流畅度、能效、纯净安全特性大为提升。未来一年HarmonyOS NEXT开发者预览版的升级用户将突破1亿，也就是说未来会有越来越多的鸿蒙原生应用推出。