乐趣区

关于harmonyos:浅析eTS的起源和演进

引言 
Mozilla 发明了 JS,Microsoft 创立了 TS,Huawei 进一步推出了 eTS。
从最后的根底的逻辑交互能力,到具备类型零碎的高效工程开发能力,再到交融申明式 UI、多维状态治理等丰盛的利用开发能力,独特组成了相干的演进脉络。
eTS(extended TypeScript)是鸿蒙生态的一种利用开发语言。它在 TypeScript(简称 TS)的根底上,扩大了申明式 UI、状态治理等相应的能力,让开发者能够以更简洁、更天然的形式开发高性能利用。TS 是 JavaScript(简称 JS)的超集,eTS 则是 TS 的超集。eTS 会联合利用开发和运行的需要继续演进,包含但不限于引入分布式开发范式、并行和并发能力加强、类型零碎加强等方面的语言个性。本期咱们联合 JS 和 TS 以及相干的开发框架的倒退,为大家介绍 eTS 的起源和演进思路。

一、JS

JS 语言由 Mozilla 发明,最后次要是为了解决页面中的逻辑交互问题,它和 HTML(负责页面内容)、CSS(负责页面布局和款式)独特组成了 Web 页面 / 利用开发的根底。随着 Web 和浏览器的遍及,以及 Node.js 进一步将 JS 扩大到了浏览器以外的环境,JS 语言失去了飞速的倒退。在 2015 年相干的规范组织 ECMA 公布了一个次要的版本 ECMAScript 6(简称 ES6),这个版本具备了较为残缺的语言能力,包含类(Class)、模块(Module)、相干的语言根底 API 加强(Map/Set 等)、箭头函数(Arrow Function)等。从 2015 年开始,ECMA 每年都会公布一个规范版本,比方 ES2016/ES2017/ES2018 等,JS 语言越来越成熟。
为了晋升利用的开发效率,相应的 JS 前端框架也一直地涌现进去。其中比拟典型的有 Facebook 发动的 React.js,以及集体开发者尤雨溪发动的 Vue.js。React 和 Vue 的次要出发点都是将响应式编程的能力引入到利用开发中,实现数据和界面内容的主动关联解决。具体的实现形式上,React 对 JS 做了一些扩大,引入了 JSX(JavaScript XML)语法,能够将 HTML 的内容对立示意成 JS 来解决;Vue 则是通过扩大的模板语法(Template)的形式来解决。
上面通过两个示例,为大家简要介绍 React 和 Vue。(示例来源于 w3schools 网站:https://www.w3schools.com/wha…)
1. React 示例

                                         图 1 React

示例以上代码形容了 React 怎么在指定的页面元素(id 为 id01 的 div 元素)中扭转相应的字符串内容(从 ”Hello World!” 到 ”Hello John Doe!”)。其中第 5 行的 ReactDOM.render()是 React JS 库提供的一个办法,它能够将相应的内容刷新到指定的 HTML 元素中。第 6 行是合乎 JSX 语义的一段代码,它蕴含了一个相似 HTML 构造的字符串(<h1>…</h1>),以及一个表白数据绑定语义的字段({name}),会关联到第 4 行定义的 name 变量。通过这种形式,JSX 把 HTML 的语义以及数据绑定机制和 JS 语言联合起来,能够不便地在 JS 语言中应用。
2. Vue 示例

                                        图 2 Vue 示例

以上 Vue 示例代码也形容了相似的性能。其中第 1~3 行是相似 HTML 的语法,形容一个 id 为 app 的 div 页面元素,其中的 {{message}} 是数据绑定的语义,在 Vue 中示意为 Template。第 6~9 行是 JS 代码,形容了一个 Vue 对象,对应了上述的 app 页面元素以及所需的数据变量 message 的内容信息。第 11~13 行则是 JS 函数,它扭转 message 变量的值为 ”John Doe”。执行这个函数时 Vue 会主动实现相应的 UI 界面刷新。
如上所示,React 和 Vue 所表白的能力是相似的,不过侧重点略微有所不同。React 次要是基于 JSX 的语法,将类 HTML 的语法交融到 JS 语言中;Vue 则是基于 Template 机制,在 HTML 的根底上扩大相应的语义。当然,下面这两个例子只是简要地形容了 React 和 Vue 的根底信息,更具体的语法以及 CSS 相干的应用等都没波及。
从运行时的维度来看,基于 React 以及 Vue 的利用都可运行在 Web 引擎上。为了进一步晋升相应的性能体验,2015 年 Facebook 在 React 根底上推出了 React Native, 在渲染架构上没有采纳传统的 Web 引擎渲染门路,而是桥接到相应 OS 平台的原生 UI 组件上。2019 年 Facebook 引入全新实现的 JS 引擎 Hermes,并推出一系列架构改良来进一步晋升 React Native 的性能体验。2016 年阿里巴巴开源的 Weex 则是基于 Vue 做了一些相似的改良,也是采纳了桥接到原生 UI 组件的渲染门路。

二、TS

随着 JS 生态的倒退,如何更无效地撑持大型的利用工程开发变成了一个重要的课题。大型的利用工程个别会波及较简单的代码以及较多的团队合作,对语言的规范性,模块的复用性、扩展性以及相干的开发工具都提出了更高的要求。为此,Microsoft 在 JS 的根底上,创立了 TS 语言,并在 2014 年正式公布了 1.0 版本。TS 次要从以下几个方面做了进一步的加强:
● 引入了类型零碎,并提供了类型查看以及类型主动推导能力,能够进行编译时谬误查看,无效的晋升了代码的规范性以及谬误检测范畴和效率。
● 在类型零碎根底上,引入了申明文件(Declaration Files)来治理接口或其余自定义类型。申明文件个别是以 d.ts 的模式来定义模块中的接口,这些接口和具体的实现做了相应的拆散,有助于各模块之间的分工协作。另外,TS 通过接口,泛型(Generics)等相干个性的反对,进一步加强了设计简单的框架所需的扩大以及复用能力。
在工具层面,TS 也有相应的编辑器、编译器、IDE(Integrated Development Environment)插件等相干的工具,来进一步晋升开发效率。
TS 在兼容 JS 生态方面也做了较好的均衡,TS 利用通过相应编译器能够编译出纯 JS 利用,能够在规范的 JS 引擎上运行。同时,TS 定位为 JS 的超集,即 JS 利用也是非法的 TS 利用。此外,在规范层面上,TS 兼容 ECMA 的相应规范,并保护那些还未成为 ECMA 规范的新个性。

三、eTS

如上所述,基于 JS 的前端框架以及 TS 的引入,进一步晋升了利用开发效率,但仍然存在一些有余。
从开发者维度来看:
写一个利用须要理解三种语言(JS/TS、HTML 和 CSS)。这对 Web 开发者绝对敌对,但对非 Web 开发者来说,累赘较重。
从运行时维度来看:
● 在语言运行时方面,只管 TS 有了类型的加持,但也只是用于编译时查看,而后通过 TS Compiler 转成 JS,运行时引擎还是无奈利用到基于类型零碎的优化。
● 在渲染方面,支流 Web 引擎因为自身复杂度以及历史起因,性能、资源占用方面与常见 OS 原生框架都有肯定的差距,尤其在挪动平台上。React Native 通过渲染架构的改良肯定水平上晋升了性能体验,但在平台渲染成果和能力的一致性,以及 JS 语言性能等方面还是存在肯定的有余。
Google 在 2018 年底推出的 Flutter 则走了另外一条路,联合新的语言 Dart,引入新的申明式开发范式,基于 Skia 的自绘制引擎构建可跨平台的独立的渲染能力。这是一种较为翻新的计划,不过也有几点有余:
● Dart 语言生态。只管 Dart 语言 2011 年就已推出,而且指标是取代 JS,但整个生态还是十分强大,Dart 语言公布 7 年后随着 Flutter 的推出才有所改善。整体而言,Dart 和支流语言生态相比还是有十分大的差距。
● 开发范式。Flutter 裸露了很多细粒度的 Widget 接口,整体开发的简洁度,开发门槛,尤其是和 Apple 推出的 SwiftUI 相比,存在肯定的差距。
有意思的是,Google 在 2021 年又推出了新的开发框架 Jetpack Compose,联合了 Kotlin 的语言生态,设计了新的申明式 UI 开发范式。
2019 年,咱们在思考如何构建新的利用开发框架的时候,从以下几个维度进行了重点思考:
● 语言生态
● 开发效率
● 性能体验
● 跨设施 / 跨平台能力
因为 JS/TS 有比较完善的开发者生态,语言也比拟中立敌对,有相应的规范组织能够逐渐演进,JS/TS 语言成了比拟天然的抉择。以 JS/TS 为根底,在开发框架的维度,咱们做了如下的架构演进设计:
● 通过基于 JS 扩大的类 Web 开发范式,来反对支流的前端开发形式。同步的,在运行时方面,通过渲染引擎的加强(平台无关的自绘制机制、申明式 UI 后端设计、动静布局 / 多态 UI 组件等),语言编译器和运行时的优化加强(代码预编译、高效 FFI-Foreign Function Interface、引擎极小化等),进一步晋升相干的性能体验,并可部署到不同设施上(包含百 KB 级内存的轻量设施)。另外,通过平台适配层的设计,构建了跨 OS 平台的基础设施。
● 通过基于 TS 扩大的申明式 UI 开发范式,提供了更简洁更天然的开发体验。在运行时方面,在上述的根底上,联合语言运行时的类型优化,以及渲染运行时的扁平化流水线技术等,进一步晋升性能体验。

                                   图 3 ArkUI 开发框架

图 3 形容了 ArkUI 开发框架的整体架构,其中,基于 TS 扩大的申明式 UI 范式中所用的语言就是 eTS。上面联合一个具体示例,从利用开发视角简略介绍下基于 eTS 的全新申明式开发范式。
如图 4 所示的代码示例,UI 界面会显示一个“Hello World”的文本和一个“Click me”按钮。当用户点击“Click me”按钮时,字符串变量 myText 的值会从“World”变为“ACE”,文本最终显示为“Hello ACE”。

                                  图 4 eTS 申明式开发范式

这个示例中所蕴含的 eTS 申明式开发范式的根本组成阐明如下:
(1) 装璜器
用来装璜类、构造体、办法以及变量,赋予其非凡的含意,如上述示例中 @Entry、@Component、@State 都是装璜器。具体而言,@Component 示意这是个自定义组件;@Entry 则示意这是个入口组件;@State 示意组件中的状态变量,这个状态变动会引起 UI 变更。
(2) 自定义组件
可复用的 UI 单元,可组合其它组件,如上述被 @Component 装璜的 struct Hello。
(3) UI 形容
申明式的形式来形容 UI 的构造,如上述 build() 办法外部的代码块。
(4) 内置组件
框架中默认内置的根底和布局组件,可间接被开发者调用,比方示例中的 Column、Text、Divider、Button。
(5) 事件办法
用于增加组件对事件的响应逻辑,对立通过事件办法进行设置,如追随在 Button 前面的 onClick()。
(6) 属性办法
用于组件属性的配置,对立通过属性办法进行设置,如 fontSize()、width()、height()、color() 等,可通过链式调用的形式设置多项属性。
从 UI 框架的需要角度,eTS 在 TS 的类型零碎的根底上,做了进一步的扩大:定义了各种装璜器、自定义组件和 UI 形容机制,再配合 UI 开发框架中的 UI 内置组件、事件办法、属性办法等独特形成了利用开发的主体。在利用开发中,除了 UI 的结构化形容之外,还有一个重要的方面:状态治理。如上述示例中,用 @State 装璜过的变量 myText,蕴含了一个根底的状态管理机制,即 myText 的值的变动会主动触发相应的 UI 变更(Text 组件)。ArkUI 中进一步提供了多维度的状态管理机制。和 UI 相关联的数据,不仅能够在组件内应用,还能够在不同组件层级间传递,比方父子组件之间,爷孙组件之间,也能够是全局范畴内的传递,还能够是跨设施传递。另外,从数据的传递模式来看,可分为 只读的单向传递和可变更的双向传递。开发者能够灵便的利用这些能力来实现数据和 UI 的联动。
总体而言,ArkUI 开发框架通过扩大成熟语言、联合语法糖或者语言原生的元编程能力、以及 UI 组件、状态治理等方面设计了对立的 UI 开发范式,联合原生语言能力共同完成利用开发。这些形成了以后 eTS 基于 TS 的次要扩大。
ArkUI 残缺的开发范式可参考这里:
https://gitee.com/openharmony…

四、下一步演进

接下来,除 UI 框架需要之外,eTS 也会联合利用开发及运行的其余方面需要继续演进:
1. 更欠缺的类型零碎
咱们曾经设计并实现了专门运行时,利用 eTS 的类型输出,在程序执行一开始就取得较高的运行性能(不像其它传统 JS 引擎须要预热能力获取高性能)。然而目前的类型零碎在运行时的设计上依然思考了兼容模式,即在运行时,当对象类型发生变化时会走 Bailout 机制,以使程序在类型不匹配时仍能失常运行。一种更极致的形式是:引入一种特定模式来反对确定类型的表白,当开发者能够明确类型时,提供相应的信息,这样运行时能够通过针对性设计,进一步晋升性能体验。另外,eTS 未来也会在类型零碎中拓展一些新的类型,在与运行时联合的优化中会提供更好的性能体验。
2. 更灵便的并行化解决
目前的挪动设施根本都是多核设施(包含同一配置的多核以及不同配置的大小核),有些设施还会携带多种计算芯片(CPU/GPU/NPU/…)。语言在并发个性上如何充沛利用多核设施甚至异构芯片是一个重要的课题。目前咱们采纳的依然是业界常见的类 Actor 模型的并发接口——Worker,它补救了 Actor 模型的些许劣势,即容许用户转移和共享大量的 Buffer 以防止通信时拷贝的开销。然而开发者仍需本人去治理 Worker 的生命周期,利用 Worker 也不能十分不便地触发一个异步并行任务。咱们曾经在尝试在 Actor 模型上封装一种工作接口,不便用户更容易利用多核触发异步并行任务。咱们也始终在关注 Swift、Dart、Kotlin、Go 这些语言并发个性的倒退和运行时的实现,eTS 的特定模式中动态类型模型的引入也会给并发机制带来更多高性能实现的可能性,比方对象的解冻、所有权转移、值语义等等。咱们将继续致力于提供简洁高效的并发 API,帮忙利用开发者更容易开发出高性能的利用。
当然,eTS 以及 ArkUI 开发框架还很年老,还有很多其它方面也会继续演进,比方 UI 自定义能力的进一步欠缺,语言运行时以及跨语言交互的进一步优化,跨 OS 平台能力的扩大(包含 Android、iOS 等),分布式开发范式等等。
作为利用生态的底座,利用开发框架的翻新永无止境。咱们心愿和宽广的开发者一起,继续围绕着开发效率、运行体验、跨设施 / 跨平台等相干方面一起单干,一起翻新,共建凋敝的利用生态!

退出移动版