HarmonyOS（四）ArkUI性能优化

1. 布局性能优化

• 隐藏显示组件使用visible，减少if使用

• 给组件固定宽高，减少计算

• 精简节点数

• 推荐使用布局组件RelativeControl 和 Graid 减少布局层级

2.长列表加载性能优化

• 懒加载 LazyForEach

• 缓存列表项，预加载
  cachedCount 设置缓存数量n/2

@Component
Struct MyComponent {
  build () {
    list() {
      //…
      LazyForEach(…)
    }.cachedCount(n/2)
  }
}

• 组件复用
  只销毁数据，复用样式
  1. @Resusable标识其具备组件复用能力
  2. aboutToReuse 实现自定义组件的生命周期回调
  3. 设置可复用组件的reuseId，多个组件需要设置多个id

@Component
@Reusable
Export struct ArticleCardView {
  @Prop isCollected: boolean = false;
  @Prop isLiked: boolean = false;
  @Prop articleItem: LearningResource = new LearningResource();
  onCollected?: () => void;
  onLiked?: () => void;

  aboutToReuse(params) {
     this.onCollected = params.onCollected;
     this.onLiked = params.onLiked;
  }

  build() {
    ......
  }
}

@Component
export struct DiscoverView {
  private data: ArticleListData = new ArticleListData();
  ......
  build() {
    List() {
      Column() {
        LazyForEach(this.data, (item: LearningResource) => {
          ListItem() {
            Column() {
              ArticleCardView({
                articleItem: item
                ......
              })
            }
          }
          .reuseId(‘ArticleCardView')
        }, (item: LearningResource) => item.id)
      }
    }.cachedCount(3);
  }
}

• 布局优化
  减少堆叠组件

状态管理

ArkUI提供了一系列装饰器实现ViewModel的能力，如@Prop、@Link、@Provide、LocalStorage等。当自定义组件内变量被装饰器装饰时变为状态变量，状态变量的改变会引起UI的渲染刷新。
在ArkUI的开发过程中，如果没有选择合适的装饰器或合理的控制状态更新范围，可能会导致以下问题：
1. 状态和UI的不一致，如同一状态的界面元素展示的UI不同，或UI界面展示的不是最新的状态。
2. 非必要的UI视图刷新，如只修改局部组件状态时导致组件所在页面的整体刷新。
当用户与界面产生交互行为时，状态的修改是通过事件驱动处理的。事件的处理可以在应用的任何地方，如果没有进行适当的逻辑处理管理也会导致代码冗余和不利于维护。

合理选择装饰器

组件间需要共享的状态，按照共享范围从小到大依次有三种场景：父子组件间共享状态，不同子树上组件间共享状态和不同组件树间共享状态。ArkUI提供了@State+@Prop、@State+@Link、@State+@Observed+@ObjectLink、@Provide+@Consume、AppStorage、LocalStorage六种装饰器组合以解决不同范围内的组件间状态共享。按照共享范围能力从小到大

截屏2024-09-18 16.40.03.png

由于@State+@Prop、@State+@Link、@State+@Observed+@ObjectLink三种方案的实现方式是逐级向下传递状态, 当遇到跨层级较多的情况，@Provide+@Consume方案更为合理。

按照状态复杂度选择装饰器

image.png

结合三个方案的特性，在选择时有如下建议：
需要观察嵌套类对象的深层属性变化的场景，选择

• @State+@Observed+@ObjectLink。
• [图片上传中...(截屏2024-09-18 16.49.31.png-a4c1f4-1726649373914-0)]
  状态是复杂对象、类或其类型数组的场景，选择@State+@Link。

• 状态是简单数据类型时，使用@State+@Link和@State+@Prop均可。在功能层面上，依据@Prop单向绑定的特性，@State+@Prop适合用于非实时修改的场景，如编辑电话薄联系人信息时，展示编辑界面的子组件信息的修改要求不实时同步回父组件，需要等到编辑完成后点击“确认”按钮时才会以事件驱动的方式修改父组件的状态。依据@Link双向绑定的特性，@State+@Link适合用于实时修改的场景，如组件嵌套时的滚动条同步。

  
  截屏2024-09-18 16.49.40.png