HarmonyOS 关于@Track的设计

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

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

HarmonyOS 关于@Track的设计 -鸿蒙开发者社区

HarmonyOS
20h前
浏览
收藏 0
回答 1
待解决
回答 1
按赞同
/
按时间
Heiang

以下是不把@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装饰器时需要谨慎考虑其影响,并根据具体需求进行选择和适配。器时需要谨慎考虑其影响,并根据具体需求进行选择和适配

分享
微博
QQ
微信
回复
18h前
相关问题
HarmonyOS 关于ui设计出稿
365浏览 • 1回复 待解决
关于无限步骤数据库表设计
1947浏览 • 1回复 待解决
@Track装饰器有什么作用?
763浏览 • 1回复 待解决
HarmonyOS 关于怎么还原设计图问题?
288浏览 • 1回复 待解决
HarmonyOS 原生应用UI设计问题
455浏览 • 1回复 待解决
应用导航设计遇到问题
319浏览 • 1回复 待解决
设计稿单位转换问题
874浏览 • 1回复 待解决
HarmonyOS 设计图尺寸对应关系
26浏览 • 1回复 待解决
应用设计时候如何分包?
242浏览 • 1回复 待解决
HarmonyOS JsBridge分层设计思想
675浏览 • 1回复 待解决
HarmonyOS 项目架构搭建和设计
106浏览 • 1回复 待解决
HarmonyOS 主页面设计选型问题
433浏览 • 1回复 待解决
HarmonyOS RNOH RNAbility代码设计问题
36浏览 • 1回复 待解决
组合索引应该如何设计
2495浏览 • 1回复 待解决
有鸿蒙系统界面设计规范吗?
12487浏览 • 1回复 待解决