End

URL编码 URLEncoder 示例

本文地址


目录

从TypeScript到ArkTS的适配指导

从TypeScript到ArkTS的适配指导

ArkTS语法适配背景

ArkTS在保持TypeScript基本语法风格的基础上,进一步通过规范强化静态检查和分析,使得在程序开发期能检测更多错误,提升程序稳定性,并实现更好的运行性能。

程序稳定性

动态类型语言,例如JavaScript,可以使得开发者非常快速地编写代码,但是同时,它也使得程序容易在运行时产生非预期的错误。

如果能在代码开发阶段检查此类问题是更有好处的。TS通过标注类型帮助开发者检查错误,许多错误在编译时可以被编译器检测出来,不用等到程序运行时。但是,即使是TS也有局限性,它不强制要求对变量进行类型标注,导致很多编译时检查无法开展。ArkTS尝试克服这些缺点,它强制使用静态类型,旨在通过更严格的类型检查以减少运行时错误。

class Person {
  name?: string // 可能为undefined

  setName(n: string): void {
    this.name = n
  }

  getNameWrong(): string {
    return this.name // 编译时错误
  }

  getName(): string | undefined {
    return this.name // 编译成功
  }
}

let buddy = new Person()
buddy.getName().length; // 编译时错误
buddy.getName()?.length; // 编译成功

程序性能

为了保证程序的正确性,动态类型语言不得不在运行时检查对象的类型,这就使得程序变慢了。由于TS总是先被编译成JS,所以在TS代码中,也会面临相同的问题。ArkTS解决了这个问题。由于使能了静态类型检查,ArkTS代码将会被编译成方舟字节码文件,而不是JS代码。因此,ArkTS运行速度更快,更容易被进一步地优化。

function notify(who: string, what: string) {
  console.log(`Dear ${who}, ${what}`)
}

notify('Jack', 'You look great today')
notify(null, 'You look great today') // 编译时错误
notify('Jack', undefined) // 编译时错误

方舟运行时兼容TS/JS

在API version 11上,HarmonyOS SDK中的TypeScript版本为4.9.5,target字段为es2017。在应用中,开发者可以使用ECMA2017+的语法进行TS/JS开发。

应用环境限制

  • 强制使用严格模式 use strict
  • 禁止使用eval()
  • 禁止使用with() {}
  • 禁止以字符串为代码创建函数

适配规则

强制使用静态类型

静态类型是ArkTS最重要的特性之一。如果程序采用静态类型,即所有类型在编译时都是已知的,那么开发者就能够容易理解代码中使用了哪些数据结构。同时,由于所有类型在程序实际运行前都是已知的,编译器可以提前验证代码的正确性,从而可以减少运行时的类型检查,有助于提升性能。

基于上述考虑,ArkTS中禁止使用any类型。

禁止在运行时变更对象布局

为实现最佳性能,ArkTS要求在程序执行期间不能更改对象的布局。换句话说,ArkTS禁止以下行为:

  • 向对象中添加新的属性或方法
  • 从对象中删除已有的属性或方法
  • 将任意类型的值赋值给对象属性

TypeScript编译器已经禁止了许多此类操作。然而,有些操作还是有可能绕过编译器的。在ArkTS中,严格类型检查不是可配置项。ArkTS强制进行部分严格类型检查,并通过规范禁止使用any类型,禁止在代码中使用@ts-ignore。

修改对象布局会影响代码的可读性以及运行时性能。从开发者的角度来说,在某处定义类,然后又在其他地方修改实际的对象布局,很容易引起困惑乃至引入错误。此外,这点还需要额外的运行时支持,增加了执行开销。这一点与静态类型的约束也冲突:既然已决定使用显式类型,为什么还需要添加或删除属性呢?

当前,只有少数项目允许在运行时变更对象布局,一些常用的代码检查工具也增加了相应的限制规则。这个约束只会导致少量代码重构,但会提升性能。

限制运算符的语义

为获得更好的性能并鼓励开发者编写更清晰的代码,ArkTS限制了一些运算符的语义。详细的语义限制,请参考约束说明

使用额外的语义重载语言运算符会增加语言规范的复杂度,而且,开发者还被迫牢记所有可能的例外情况及对应的处理规则。在某些情况下,产生一些不必要的运行时开销。

当前只有不到1%的代码库使用该特性。因此,尽管限制运算符的语义需要重构代码,但重构量很小且非常容易操作,并且,通过重构能使代码更清晰、具备更高性能。

不支持 structural typing

目前TypeScript支持structural typing,而ArkTS不支持。

structural typing是否有助于生成清晰、易理解的代码,关于这一点并没有定论。那为什么ArkTS不支持structural typing呢?

因为对structural typing的支持是一个重大的特性,需要在语言规范、编译器和运行时进行大量的考虑和仔细的实现。另外,由于ArkTS使用静态类型,运行时为了支持这个特性需要额外的性能开销。

鉴于此,当前我们还不支持该特性。根据实际场景的需求和反馈,我们后续会重新加以考虑。

2016-12-27
2024.11.03

posted @   白乾涛  阅读(4984)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· 上周热点回顾(2.17-2.23)
点击右上角即可分享
微信分享提示