1、ArkTS、TypeScript (TS) 和 JavaScript (JS) 之间存在层层递进的关系：
- JavaScript (JS) ：是一种广泛用于 Web 应用开发的高级脚本语言，主要为网页添加动态功能。
- TypeScript (TS) ：是 JavaScript 的一个超集。它在 JavaScript 的基础上添加了静态类型定义，扩展了 JavaScript 的语法，是一个开源的编程语言。 TS 可以在编译时检查类型错误，提供类型安全性，适合大型项目。
- ArkTS ：是 HarmonyOS 优选的主力应用开发语言。它在 TypeScript 的生态基础上做了进一步扩展，继承了 TS 的所有特性，是 TS 的超集。
ArkTS 专为 HarmonyOS 系统开发而设计， 匹配了鸿蒙的 ArkUI 框架，扩展了声明式 UI、状态管理、并发任务等能力。 ArkTS 强化了静态检查和分析，旨在在开发期检测更多错误并提升运行时性能。
简单来说，它们的关系可以概括为： JS ⊂ TS ⊂ ArkTS 。
ArkTS 相对于 TS 的一些主要区别和特点包括：
- 更严格的类型系统和静态检查 ：ArkTS 对类型做了更进一步的限制，强化了静态检查和分析能力。
- 不支持在运行时动态增删对象的属性。
- 对象字面量必须标注类型。
- 不支持 var 、 any 、 unknown 、 Symbol 。
- 不支持使用 # 符号开头的私有字段，改用 private 关键字。
- 声明式 UI 和状态管理 ：ArkTS 扩展了声明式 UI 描述、自定义组件、事件方法、属性方法以及多维度的状态管理机制，这是其核心特性之一，用于构建 HarmonyOS 应用界面。
- 并发能力增强 ：针对 JS/TS 并发能力支持有限的问题，ArkTS 对并发编程 API 和能力进行了增强。
- 性能优化 ：通过更严格的规范和静态检查，减少运行时类型检查，有助于提升执行性能。
- 生态兼容 ：ArkTS 支持与 JS/TS 高效互操作，兼容 JS/TS 生态。
需要注意的是，前端开发中常用的 DOM/WebAPI 在 ArkTS 中是不存在的，例如 document.querySelector 或 window.location 。
2、if条件渲染和visibility属性控制组件的显示和隐藏有什么区别
在鸿蒙开发中， if 条件渲染和 visibility 属性都是用来控制组件的显示和隐藏，但它们的工作方式和适用场景有所不同：
1. if 条件渲染:
- 工作方式 : 当 if 的条件为 false 时，对应的组件及其子组件 不会被创建和渲染 到UI树中。当条件变为 true 时，组件才会被创建和渲染。
- 特点 :
- 销毁和重建 : 组件在显示和隐藏切换时会经历完整的生命周期（创建、销毁）。
- 性能开销 : 对于频繁切换显示状态的组件，或者内部状态复杂的组件，反复销毁和重建可能会带来一定的性能开销。
- 布局影响 : 组件不渲染时，不占用任何布局空间。
- 适用场景 :
- 组件在某个条件下完全不需要显示，或者很少需要显示。
- 组件的初始状态依赖于异步数据，在数据加载完成前不需要显示。
- 希望彻底移除组件以减少内存占用。
2. visibility 属性:
- 工作方式 : 组件始终存在于UI树中， visibility 属性控制其是否可见。它有几个常用的值：
- Visibility.Visible (默认值): 组件可见。
- Visibility.Hidden : 组件不可见，但 仍然占据布局空间 。
- Visibility.None : 组件不可见，且 不占据布局空间 (效果类似于 if 条件为 false ，但组件实例依然存在)。
- 特点 :
- 保留状态 : 组件在隐藏时其内部状态会被保留，再次显示时可以恢复之前的状态。
- 性能较优 : 对于频繁切换显示状态的组件，使用 visibility 通常比 if 条件渲染性能更好，因为它避免了组件的销毁和重建过程。
- 布局影响 : 取决于 visibility 的具体值。 Hidden 会占据空间， None 不会。
- 适用场景 :
- 需要频繁切换组件的显示和隐藏状态。
- 希望保留组件的内部状态，例如用户输入、滚动位置等。
- 组件结构相对简单，即使隐藏也对整体性能影响不大。
总结与选择建议:
- if 条件渲染 : 真正的“条件性渲染”，组件的有或无。适用于组件在特定条件下完全不需要存在的情况，或者为了优化初始加载性能。
- visibility 属性 : 控制的是组件的“可见性”。
- 如果希望组件隐藏但仍占据位置（例如，避免布局抖动），使用 Visibility.Hidden 。
- 如果希望组件隐藏且不占据位置，同时又想保留组件实例和状态（或者避免重建开销），可以使用 Visibility.None 。
选择哪种方式取决于具体的业务需求、组件的复杂程度、状态保持的需求以及对性能的考量。
一般而言，对于不常变化或初始条件决定的显示/隐藏， if 更直观；对于频繁切换或需要保留状态的场景， visibility (尤其是 Visibility.None ) 可能是更好的选择。
3、装饰器有哪些，分别说一下理解和使用方法
1. 组件定义装饰器
@Component :
声明一个自定义组件。被此装饰器修饰的 struct 将成为一个可复用的UI单元。
@Entry :
标记一个自定义组件为页面的入口组件。一个页面有且仅有一个 @Entry 组件
@Preview :
用于在IDE中预览当前组件的UI效果，方便开发调试。可以添加多个 @Preview 来预览不同状态或配置下的组
2. 状态管理装饰器
@State:
声明一个组件内部的状态变量。当 @State 变量的值发生改变时，UI会自动更新以反映这些变化。它是组件私有的，不可从父组件初始化。
@Prop:
声明一个从父组件接收的属性（单向数据流）。父组件传递给 @Prop 变量的值发生变化时，子组件会更新。子组件不能直接修改 @Prop 变量。
@Link:
声明一个与父组件中 @State 变量双向绑定的属性。子组件可以修改 @Link 变量，这个修改会同步回父组件的 @State 变量，反之亦然。
@Provide / @Consume:
用于跨层级组件状态共享（依赖注入）。 @Provide 在祖先组件中提供一个值， @Consume 在后代组件中消费这个值。避免了逐层传递 @Prop 。
@Observed 和 class (以前的 @ObservedObject ):
@Observed 用于修饰一个类，使其成为可观察对象。当这个类的实例被 @ObjectLink 或 @Observed (在组件中作为属性)修饰的变量引用时，其属性的改变可以触发UI更新。主要用于管理复杂对象状态。
@ObjectLink:
用于在组件中引用一个由 @Observed 修饰的类的实例，并建立双向数据绑定。类似于 @Link ，但用于对象。
3. 应用级别状态和存储
@StorageLink(key) / @LocalStorageLink(key):
@StorageLink 用于将组件内的变量与 AppStorage (应用级单例存储) 中的某个键值对进行双向绑定。 @LocalStorageLink 类似，但绑定到页面级的 LocalStorage 。
@StorageProp(key) / @LocalStorageProp(key):
与 @StorageLink 类似，但提供单向数据绑定（从 AppStorage 或 LocalStorage 到组件）。
@Environment:
用于获取应用运行环境的一些预定义属性，如颜色模式、字体大小、语言等。
4. 其他常用装饰器
@Builder:
定义一个可复用的UI构建函数。这个函数可以返回一段UI描述，并且可以被其他组件调用。
@Styles:
定义一组可复用的样式规则，可以应用于组件，减少样式代码的重复。
@Extend(UIComponentName):
允许你扩展现有组件的样式或属性，创建新的自定义样式。
@Watch(variableName):
监听某个状态变量的变化，并在其变化时执行一个回调函数。
