HarmonyOS 鸿蒙Next ArkTS和TS混编是否会导致性能损耗？
HarmonyOS 鸿蒙Next ArkTS和TS混编是否会导致性能损耗？
根据文档描述：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/arkts-migration-background-V5
“为了保证程序的正确性，动态类型语言不得不在运行时检查对象的类型。例如，JS不允许访问undefined的属性。但是检查一个值是否为undefined的唯一的办法是在运行时进行一次类型检查。所有的JS引擎都会做如下的事：如果一个值不是undefined，那么可以访问其属性，否则抛出异常。现代JS引擎可以很好地对这类操作进行优化，但是总有一些运行时的检查是无法被消除的，这就使得程序变慢了。由于TS总是先被编译成JS，所以在TS代码中，也会面临相同的问题。ArkTS解决了这个问题。由于使能了静态类型检查，ArkTS代码将会被编译成方舟字节码文件，而不是JS代码。因此，ArkTS运行速度更快，更容易被进一步地优化。”
和
“TS通过打开编译选项strictNullChecks来实现此特性。但是TS是被编译成JS的，而JS没有这个特性，因此严格null检查只在编译时起作用。从程序稳定性和性能角度考虑，ArkTS将“null-safety”视为一个重要的特性。这就是为什么ArkTS强制进行严格null检查，在ArkTS中，上面的代码总是编译报错。作为交换，这样的代码可以给ArkTS引擎带来更多的信息和有关值的类型保证，这有助于更好地优化性能。”
可以理解为ArkTS通过在编译器严格的类型检查，从而避免了在方舟运行时类型检查的消耗。但对于ets和ts混编的场景，这类优化是否会生效？方舟运行时会根据源码来自ets或者ts来进行类型检查策略执行的依据从而提高性能吗？
“为了保证程序的正确性，动态类型语言不得不在运行时检查对象的类型。例如，JS不允许访问undefined的属性。但是检查一个值是否为undefined的唯一的办法是在运行时进行一次类型检查。所有的JS引擎都会做如下的事：如果一个值不是undefined，那么可以访问其属性，否则抛出异常。现代JS引擎可以很好地对这类操作进行优化，但是总有一些运行时的检查是无法被消除的，这就使得程序变慢了。由于TS总是先被编译成JS，所以在TS代码中，也会面临相同的问题。ArkTS解决了这个问题。由于使能了静态类型检查，ArkTS代码将会被编译成方舟字节码文件，而不是JS代码。因此，ArkTS运行速度更快，更容易被进一步地优化。”
和
“TS通过打开编译选项strictNullChecks来实现此特性。但是TS是被编译成JS的，而JS没有这个特性，因此严格null检查只在编译时起作用。从程序稳定性和性能角度考虑，ArkTS将“null-safety”视为一个重要的特性。这就是为什么ArkTS强制进行严格null检查，在ArkTS中，上面的代码总是编译报错。作为交换，这样的代码可以给ArkTS引擎带来更多的信息和有关值的类型保证，这有助于更好地优化性能。”
可以理解为ArkTS通过在编译器严格的类型检查，从而避免了在方舟运行时类型检查的消耗。但对于ets和ts混编的场景，这类优化是否会生效？方舟运行时会根据源码来自ets或者ts来进行类型检查策略执行的依据从而提高性能吗？
2 回复
HarmonyOS 鸿蒙Next ArkTS和TS混编确实可能会导致性能损耗。
ArkTS引入了静态类型检查，代码会被编译成方舟字节码文件，这使得ArkTS运行速度更快，且更容易被进一步优化。然而，当ArkTS与TS混编时，如果混编代码中存在动态类型，编译器可能无法进行与纯ArkTS代码相同的优化。这是因为静态类型检查的ArkTS代码能够给编译器提供更多关于值的类型保证，从而有助于优化性能，而动态类型的TS代码则不具备这一优势。
此外，ArkTS为了获得更好的性能，还限制了一些运算符的语义，并不支持structural typing，这些特性在混编场景中可能会引发额外的性能开销。
因此，在开发过程中，建议尽量避免混用动态和静态类型的代码，以确保最佳性能。如果必须混编，应仔细测试并优化代码，以减少性能损耗。
如果问题依旧没法解决请联系官网客服，官网地址是：https://www.itying.com/category-93-b0.html
