前言有同学遇到了一个问题他是使用ArrayList来存储的数据在动态给集合添加数据后UI并未更新代码如下import { ArrayList } from kit.ArkTS; Entry Component struct Index { State numItems: ArrayListstring new ArrayList(); aboutToAppear(): void { this.numItems.add(数据一) } build() { Column() { ForEach(this.numItems.convertToArray(), (item: string) { Text(item) .height(30) }) Button(添加数据) .onClick(() { this.numItems.add(数据二) }) }.width(100%) .alignItems(HorizontalAlign.Center) } }貌似以上的代码看着没太大问题ForEach中由于支持的是Array类型便使用convertToArray()方法做了转换但是在点击添加数据按钮之后UI并没有按照理想的状态去增加数据。这就是我们需要了解的一个知识点不要用Android的那一套思维来开发鸿蒙也许在Android中ArrayList非常常见也常用但是在鸿蒙开发中牵扯到UI更新却不能使用ArrayList这一点对于初学者务必牢记。首先我们要知道ArrayList是kit.ArkTS提供的线性容器类并非原生ArrayV1装饰器下的State装饰器只能观测原生 Array的增删改等操作对于ArrayList的相关的API变化如add()是无法观测的。目前State可以观测变化如下表类型可观测的变化基础类型number、string 等值变化原生Array整体赋值、push、pop、splice、arr[i] value等class对象仅整体赋值第一层属性修改不触发刷新ArrayList等容器类无法观测 API 调用带来的变化所以如果只是基础类型的数组观测可以直接使用原生的数组就可以比如State numItems: Arraystring new Array();或者如下State numItems: string[] [];不能在继续使用ArrayList。为什么不能观测ArrayList里的API调用一句话概括根本原因在于观测机制Proxy代理与ArrayList的底层实现方式不兼容。状态管理的观测原理鸿蒙状态管理框架无论是V1版本下的的State还是V2版本下的Local他们的核心观测机制是Proxy代理当变量被状态装饰器装饰时框架会在数据对象外层包裹一层代理对象代理会拦截对数据的属性访问和修改操作从而感知变化并触发 UI 刷新。我们以原生Array为例它其中的push、pop、splice 等方法操作其实是 JavaScript 引擎层面的属性如length、索引元素Proxy可以拦截这些操作因此State和Local能观测到变化。ArrayList 为什么无法被代理拦截ArrayList是kit.ArkTS提供的容器类其关键特征是使用静态语言C实现这意味着第一数据存储在原生内存中ArrayList的内部元素存储在 C 层的连续内存空间中而不是JavaScript 可访问的对象属性。Proxy只能拦截 JavaScript 层面的属性操作无法感知原生内存中的数据变化第二API 方法是原生绑定ArrayList的add()、remove()、insert()等方法直接调用 C 实现方法执行过程中的数据增删改发生在原生层面完全绕过了Proxy的拦截能力第三不支持自定义属性和方法ArrayLis 限制了存储位置和属性不支持自定义属性和方法 这进一步限制了框架对其进行代理包装的可能性。我们简单做下对比对比项原生ArrayArrayList实现层面JavaScript 引擎内置C 静态语言实现数据存储JavaScript 对象属性索引、length原生内存空间API 执行JavaScript 层面Proxy 可拦截原生层面Proxy 无法拦截自定义属性支持不支持Proxy 代理可正常包装拦截无法有效拦截一句话总结ArrayList作为 C 静态语言实现的容器类其数据存储和 API 调用均在原生层面完成Proxy 无法介入拦截因此框架感知不到add()、remove() 等调用带来的数据变化UI 自然不会刷新。以后应当这么做前边在前言中已经诉说了基本类型数组的观测这里就不再过多赘述如果在实际的开发中遇到的不是基本类型的数组比如对象数组V1装饰器下需要结合Observed/ObjectLink装饰器来使用。第一步给对象加上Observed装饰器Observed class TestBean { name?: string constructor(name: string) { this.name name } }第二步视图抽取子组件Component struct TextView { ObjectLink item: TestBean build() { Text(this.item.name) .height(30) } }第三步改为子组件Entry Component struct Index { State items: TestBean[] [ new TestBean(条目一), new TestBean(条目二), new TestBean(条目三)] build() { Column() { ForEach(this.items, (item: TestBean) { TextView({ item: item }) }) Button(添加数据) .onClick(() { this.items.push(new TestBean(条目四)) }) }.width(100%) .alignItems(HorizontalAlign.Center) } }如果是使用的V2装饰器那对象数组更新就比较简单了直接使用ObservedV2即可如果你想继续类属性变化观测可以给对象中的属性设置TraceObservedV2和Trace一般配套使用。Entry ComponentV2 struct Index { Local items: TestBean[] [ new TestBean(条目一), new TestBean(条目二), new TestBean(条目三)] build() { Column() { ForEach(this.items, (item: TestBean) { Text(item.name) .height(30) }) Button(添加数据) .onClick(() { this.items.push(new TestBean(条目四)) }) }.width(100%) .alignItems(HorizontalAlign.Center) } } ObservedV2 class TestBean { Trace name?: string constructor(name: string) { this.name name } }还推荐使用ArrayList吗在UI更新操作中是不能使用的但是毫不影响其他非UI的操作。ArrayList 的适用与不适用场景场景是否推荐 ArrayList推荐替代方案频繁按索引随机访问元素推荐—增删操作频率较低的有序数据管理推荐—UI 状态管理State/Local驱动刷新不推荐原生ArrayT[]需要 API 级观测 并发安全不推荐collections.Array makeObserved跨线程传递数据不支持collections.Array频繁插入删除元素不推荐LinkedList两端频繁增删元素不推荐Deque比如纯数据逻辑层无 UI 绑定、无跨线程需求的情况下且需要频繁按索引随机访问还是很推荐使用的如下代码所示import { ArrayList } from kit.ArkTS; class DataProcessor { private data: ArrayListstring new ArrayList(); // 频繁按索引读取ArrayList 的随机访问效率高 getItem(index: number): string { return this.data[index]; } addItem(item: string): void { this.data.add(item); } }相关总结在实际开发中大多数涉及 UI 的场景应优先使用原生Array它语法简洁、状态管理兼容性好、ForEach直接支持而ArrayList适合用在纯数据逻辑层中需要频繁随机访问的场景所以大家一定要区分开来。抛出一个疑问如果我硬要使用ArrayList那么如何来更新UI呢