【HarmonyOS - ArkTS - 状态管理】

概述

本文主要是从页面和应用级两个方面介绍了ArkTS中的状态管理的一些概念以及如何使用。可能本文比较粗略,细节化请前往官网(【状态管理】)学习,若有理解错误的地方,欢迎评论指正。

装饰器总览

由于下面会频繁提及到装饰器,所以来头就将会提及到了列举出来,做个简单介绍。

  • @State 定义组件的响应式数据,这个状态发生改变会触发UI更新,定义时必须要赋予一个默认值。
  • @Prop: 定义由父组件传递过来的参数,是单向的,子组件改变该值不会影父组件 父组件通过prop = this.state.prop来传值,复制的数据源
  • @Link 定义一个双向绑定的值,子组件也可以改变父组件的值,类似Vue中的v-modal,父组件使用$来传递值的引用 prop = $prop,使用的是数据源的引用
  • @Provide 在上级组件通过该装饰器定义需要共享的数据(双向的,子组件也可以更新值)
  • @Consume 上级组件通过@Provide提供了共享数据,在下级组件就可以通过@Consume来获取,其中值的key要一致。
  • @Watch 状态监听,第一次初始化的时候不会调用。@Watch不能单独使用,需要和其他装饰器一起,常见于@Prop、@State、@Link来监听状态 。@Watch在ArkUI框架内部判断数值有无更新使用的是严格相等(===)
  • @Observed / @ObjectLink :用于解决通过@State定义嵌套对象/数组等复杂变量时,只能通过将整体替换来触发更新的问题。其中@Observed 用来修饰class,表示该类中的属性需要被监控,然后在组件中通过@ObjectLink来接收一个@Observed 修饰的class类型的变量,这样当class中的属性变化时,就会触发UI更新。原理就是当使用@Observed 修饰一个class的时候,会对这个class进行代理,代理setter、getter。当子组件通过@ObjectLink接收该class的类型变量时,会自动将@ObjectLink本身注册到@Observed修饰的代理class中,当class的属性改变,就会通过代理来通过所有订阅该class类型变量更新。
  • $$语法:内置组件双向同步,其实就是将变量通过$$运算符传递给内置的ArkUI内置组件后,内置组件就可以改变组件内我们通过@State、@Prop、@Link定义的变量值。目前只支持Refresh组件的refreshing参数。
  • @LocalStorageProp: 单向流,复杂数据的方式,组件内部改变不会影响源LocalStorage值,只会影响并更新自身组件。
    @LocalStorageLink: 双向流,添加数据引用的方式,组件内部改变会写会到LocalStorage中并同步其他订阅(@LocalStorageProp、@LocalStorageLink)了该数据的组件更新。
  • @StorageProp、@StorageLink:同上面一样,@Prop是单向状态,@Link是双向的,用于获取AppStorage的状态

不管单向还是双向初始化时,都必须设置默认值,以便当LocalStorage/AppStorage中没有该key时,通过get能获取到正确的值(设定的默认值)

PS: 使用Link这种双向数据,需要注意UI渲染更新的成本。

页面组件(单个页面组件树的上级层共享)的状态管理

这个比较简单,就是通过@Prop、@Link的方式由父组件传递给子组件。

@Prop:单向传递,值的复制。通过this.xxx传递到子组件,子组件通过@Prop接收状态,修改prop不会影响到夫组件

@Link: 双向传递,值的引用。通过$prop的方式来将值的引用传递给子组件。子组件通过@Link的方式接收,值改变会同步父组件改变并触发渲染。

@Provide/@Consume:用于单个组件树的上下级状态共享。类比Vue中的(Provide/inject)或者React中的上下文(Context)。上层组件通过@Provide提供状态,以该组件为root的组件树中其他下层组件都可以通过@Consume来订阅需要的状态。

APP应用级别的状态管理

LocalStorage - 单个UIAbility

根据不同的注入方式,LocalStorage可以作为UIAbility级别(跨组件)的状态共享(类似Vuex),也可以作为组件内部单个树上下层共享(类似上面的@Provide、@Consume)

应用(单个UIAbility)级别状态共享 - 类似Vuex

在启动应用程序时,会先创建一个Stage,然后加载页面,在onWindowStageCreate生命周期(UIAbility的生命周期)中,将LocalStorage注入,这时候在LocalStorage所有的数据都可以跨组件共享。

// EntryAbility.ts
import UIAbility from '@ohos.app.ability.UIAbility';
import window from '@ohos.window';

export default class EntryAbility extends UIAbility {
   
  para:Record<string, number> = {
    'PropA': 47 };
  storage: LocalStorage = new LocalStorage(this.para);

  onWindowStageCreate(windowStage: window.WindowStage) {
   
    windowStage.loadContent('pages/Index', this.storage);
    }
}

全局注入之后,在组件内通过GetShared根据key获取值然后将获取到的storage通过@Entry参数的形式注入到组件内部。

import router from '@ohos.router';

let storage &#
### 关于 CVE-2025 漏洞复现的信息 CVE-2025-1094 被描述为一个需要紧急关注和处理的关键漏洞[^2]。此漏洞可能允许攻击者通过特定条件下的输入验证不足来执行恶意操作,从而危及系统的安全性。为了有效应对这一威胁,组织应采取一系列措施,包括但不限于应用官方发布的补丁更新、强化输入数据的校验逻辑以及遵循行业内的最佳安全实践。 尽管具体的 CVE-2025 复现步骤未在现有资料中明确提及,但从其他类似案例(如 CVE-2021-3493 和脏牛漏洞 CVE-2016-5195)可以看出,通常涉及以下几个方面: #### 1. **环境准备** 对于大多数漏洞复现而言,构建合适的测试环境至关重要。例如,在 Linux 系统上的某些漏洞复现过程中,开发者可能会依赖 OverlayFS 来模拟权限提升场景[^3];而在 Windows 平台上,则需配置开发工具链,比如 Visual Studio 及其 C++ 支持组件[^5]。 #### 2. **编写 PoC (Proof of Concept)** PoC 是证明漏洞存在的重要手段之一。以下是基于假设情景的一个简单代码片段用于演示目的: ```cpp #include <iostream> using namespace std; int main() { char buffer[10]; cout << "Enter up to 9 characters: "; cin.getline(buffer, sizeof(buffer)); // Potential vulnerability point due to lack of proper validation. cout << "You entered: " << buffer; return 0; } ``` 上述例子展示了缓冲区溢出的可能性,如果用户输入超过预期长度的数据而缺乏严格控制的话,就可能导致程序行为异常甚至崩溃[^4]。 #### 3. **分析与调试** 利用调试器跟踪目标应用程序运行期间的状态变化情况可以帮助深入理解漏洞的工作机理。这一步骤往往结合静态代码审查一起完成,旨在发现潜在的安全隐患所在位置及其成因。 #### 4. **修补方案探讨** 针对已知缺陷提供有效的缓解策略同样重要。正如之前所提到过的那样,及时部署厂商推荐的安全升级包是最直接也是最可靠的方法之一。除此之外,加强前端/后端交互环节中的参数过滤机制亦能起到一定防护作用。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值