• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1# ArkTS语法适配背景
2
3ArkTS在保持TypeScript（简称TS）基本语法风格的基础上，进一步通过规范强化静态检查和分析，使得在程序开发期能检测更多错误，提升程序稳定性，并实现更好的运行性能。本文将进一步解释为什么建议将TS代码适配为ArkTS代码。
4
5**程序稳定性**
6
7动态类型语言，例如JavaScript（简称JS），可以使得开发者非常快速地编写代码，但是同时，它也使得程序容易在运行时产生非预期的错误。例如在代码中，如果开发者没有检查一个值是否为`undefined`，那么程序有可能在运行时崩溃，给开发者造成不便。如果能在代码开发阶段检查此类问题是更有好处的。TS通过标注类型帮助开发者检查错误，许多错误在编译时可以被编译器检测出来，不用等到程序运行时。但是，即使是TS也有局限性，它不强制要求对变量进行类型标注，导致很多编译时检查无法开展。ArkTS尝试克服这些缺点，它强制使用静态类型，旨在通过更严格的类型检查以减少运行时错误。
8
9**程序性能**
10
11为了保证程序的正确性，动态类型语言不得不在运行时检查对象的类型。例如，JS不允许访问`undefined`的属性。但是检查一个值是否为`undefined`的唯一的办法是在运行时进行一次类型检查。所有的JS引擎都会做如下的事：如果一个值不是`undefined`，那么可以访问其属性，否则抛出异常。现代JS引擎可以很好地对这类操作进行优化，但是总有一些检查是无法被消除的，这就使得程序变慢了。由于TS总是先被编译成JS，所以在TS代码中，也会面临相同的问题。ArkTS解决了这个问题。由于使能了静态类型检查，ArkTS代码将会被编译成某种可执行的字节码文件，而不是JS代码。因此，ArkTS运行速度更快，更容易被进一步地优化。
12
13下面通过一些例子解释为什么ArkTS可以帮助提升程序的稳定性和性能。
14
15
16**显式初始化类的属性**
17
18ArkTS要求类的所有属性在声明时或者在构造函数中显式地初始化。这和TS中的`strictPropertyInitialization`模式一致。
19
20来看以下的TS代码：
21
22```typescript
23class Person {
24  name: string // undefined
25
26  setName(n: string): void {
27    this.name = n
28  }
29
30  getName(): string {
31  // 开发者使用"string"作为返回类型，这隐藏了name可能为"undefined"的事实。
32  // 更合适的做法是将返回类型标注为"string | undefined"，以告诉开发者这个API所有可能的返回值的类型。
33    return this.name
34  }
35}
36
37let buddy = new Person()
38// 假设代码中没有对name的赋值，例如没有调用"buddy.setName('John')"
39console.log(buddy.getName().length); // 运行时异常：name is undefined
40```
41
42由于ArkTS要求属性显式初始化，代码应该像下面这样写。
43
44```typescript
45class Person {
46  name: string = ''
47
48  setName(n: string): void {
49    this.name = n
50  }
51
52  // 类型为"string"，不可能为"null"或者"undefined"
53  getName(): string {
54    return this.name
55  }
56}
57
58let buddy = new Person()
59// 假设代码中没有对name的赋值，例如没有调用"buddy.setName('John')"
60console.log(buddy.getName().length); // 0, 没有运行时异常
61```
62
63如果`name`可以是`undefined`，那么它的类型应该在代码中被精确地标注。
64
65```typescript
66class Person {
67    name?: string // 可能为undefined
68
69    setName(n: string): void {
70        this.name = n
71    }
72
73    // 编译时错误：name可能为"undefined"，所以不能将这个API的返回类型标注为"string"
74    getNameWrong(): string {
75        return this.name
76    }
77
78    getName(): string | undefined { // 返回类型匹配name的类型
79        return this.name
80    }
81}
82
83let buddy = new Person()
84// 假设代码中没有对name的赋值，例如没有调用"buddy.setName('John')"
85
86// 编译时错误：编译器认为下一行代码有可能访问"undefined"的属性，报错
87console.log(buddy.getName().length);  // 编译失败
88
89console.log(buddy.getName()?.length); // 编译成功，没有运行时错误
90```
91
92这个例子展示了ArkTS是如何通过强制更严格的类型检查来提高代码稳定性和正确性的。
93
94
95**Null Safety**
96
97再来看一个例子。
98
99```typescript
100function notify(who: string, what: string) {
101  console.log(`Dear ${who}, a message for you: ${what}`)
102}
103
104notify('Jack', 'You look great today')
105```
106
107在大多数情况下，函数`notify`会接受两个`string`类型的变量作为输入，产生一个新的字符串。但是，如果将一些特殊值作为输入，例如`notify(null, undefined)`，情况会怎么样呢？
108程序仍会正常运行，输出预期值：`Dear undefined, a message for you: null`。一切看起来正常，但是请注意，为了保证该场景下程序的正确性，引擎总是在运行时进行类型检查，执行类似以下的伪代码。
109
110```typescript
111function __internal_tostring(s: any): string {
112  if (typeof s === 'string')
113    return s
114  if (s === undefined)
115    return 'undefined'
116  if (s === null)
117    return 'null'
118  // ...
119}
120```
121
122现在想象一下，如果函数`notify`是某些复杂的负载场景中的一部分，而不仅仅是打印日志，那么在运行时执行像`__internal_tostring`的类型检查将会是一个性能问题。
123
124如果可以保证在运行时，只有`string`类型的值（不会是其他值，例如`null`或者`undefined`）可以被传入函数`notify`呢？在这种情况下，因为可以确保没有其他边界情况，像`__internal_tostring`的检查就是多余的了。对于这个场景，这样的机制叫做“null-safety”，也就是说，保证`null`不是一个合法的`string`类型变量的值。如果ArkTS有了这个特性，类型不符合的代码将无法编译。
125
126```typescript
127function notify(who: string, what: string) {
128  console.log(`Dear ${who}, a message for you: ${what}`)
129}
130
131notify('Jack', 'You look great today')
132notify(null, undefined) // 编译时错误
133```
134
135TS通过打开编译选项`strictNullChecks`来实现此特性。但是TS是被编译成JS的，而JS没有这个特性，因此严格`null`检查只在编译时起作用。从程序稳定性和性能角度考虑，ArkTS将“null-safety”视为一个重要的特性。这就是为什么ArkTS强制进行严格`null`检查，在ArkTS中，上面的代码总是编译报错。作为交换，这样的代码可以给ArkTS引擎带来更多的信息和有关值的类型保证，这有助于更好地优化性能。
136
137
138**.ets代码兼容性**
139
140在API version 10之前，ArkTS（.ets文件）完全采用了标准TS的语法。从API version 10 Release起，ArkTS的语法规则基于上述设计考虑进行了明确定义，同时，SDK增加了在编译流程中对.ets文件的ArkTS语法检查，通过编译告警或编译失败提示开发者适配新的ArkTS语法。
141
142根据工程的compatibleSdkVersion，具体策略如下：
143
144  - compatibleSdkVersion >= 10 为标准模式。在该模式下，对.ets文件，违反ArkTS语法规则的代码会导致工程编译失败，需要完全适配ArkTS语法后方可编译成功。
145  - compatibleSdkVersion < 10 为兼容模式。在该模式下，对.ets文件，以warning形式提示违反ArkTS语法规则的所有代码。尽管违反ArkTS语法规则的工程在兼容模式下仍可编译成功，但是需要完全适配ArkTS语法后方可在标准模式下编译成功。
146