HarmonyOS 关于@Track的设计？

Question

官方文档中关于实践的案例，如附件里面讲到@Track的设计能使得大的复杂对象不需要拆分的情况下就能够实现按属性变化才更新。

那为什么不把@Track设计成默认的机制，而是要开发者手动去标注，是不是标记@Track比起拆分对象这种开发方式在性能表现上会差一点？影响有多大？

Answer 1

以下是不把@Track设计为默认机制的原因：

1.性能开销

使用@Track装饰器会在属性变化时触发UI更新，这可能会导致性能开销。尤其是在处理复杂的UI组件时，这种开销可能会变得显著。

2.行为限制

@Track装饰器仅适用于class对象的非静态成员属性，且未被标记的属性不能在UI中使用。这意味着在使用@Track装饰器时，必须确保所有需要在UI中使用的属性都被标记。

3.不兼容问题

从API version 11开始，@Track装饰器支持在ArkTS卡片中使用，但在此之前，@Track装饰器主要用于状态变量。因此，在旧的API版本中，如果对象中没有被@Track装饰的属性，行为将与原先保持一致，可能导致意外的行为或冗余刷新。

4.使用限制

建议开发者不要混用包含@Track的class对象和不包含@Track的class对象，如联合类型中、类继承中等。这种混用可能导致UI行为不一致或编译错误。

不默认支持的原因

由于@Track装饰器在性能、行为和兼容性方面存在一定的限制，为了确保应用的稳定性和性能优化，HarmonyOS没有将其作为默认支持的装饰器。开发者在使用@Track装饰器时需要谨慎考虑其影响，并根据具体需求进行选择和适配。器时需要谨慎考虑其影响，并根据具体需求进行选择和适配