HarmonyOS NEXT应用开发性能优化从入门到精通指南~-易微帮

概述

在开发HarmonyOS NEXT应用时，优化应用性能是至关重要的。本文将介绍应用开发过程中常见的一些性能问题，并提供相应的解决方案，配合相关参考示例，帮助开发者解决大部分性能问题。

我们把应用性能分析的方法划分为了性能分析四板斧，下面将介绍如何使用性能分析四板斧，解决应用开发过程中的性能问题。

第一板斧：合理使用并行化、预加载和缓存，我们需要合理地使用并行化、预加载和缓存等方法，例如使用多线程并发、异步并发、Web预加载等能力，提升系统资源利用率，减少主线程负载，加快应用的启动速度和响应速度。
第二板斧：尽量减少布局的嵌套层数，在进行页面布局开发时，应该去除冗余的布局嵌套，使用相对布局、绝对定位、自定义布局、Grid、GridRow等扁平化布局，减少布局的嵌套层数，避免系统绘制更多的布局组件，达到优化性能、减少内存占用的目的。
第三板斧：合理管理状态变量，应该合理地使用状态变量，精准控制组件的更新范围，控制状态变量关联组件数量，控制对象级状态变量的成员变量关联组件数，减少系统的组件渲染负载，提升应用流畅度。
第四板斧：合理使用系统接口，避免冗余操作，应该合理使用系统的高频回调接口，删除不必要的Trace和日志打印，避免注册系统冗余回调，减少系统开销。

第一板斧：合理使用并行化、预加载和缓存

我们需要合理地使用并行化、预加载和缓存等方法，提升系统资源利用率，减少主线程负载，加快应用的启动速度和响应速度。

使用并行化提升启动速度

自定义组件创建完成之后，在build函数执行之前，将先执行aboutToAppear()生命周期回调函数。此时若在该函数中执行耗时操作，将阻塞UI渲染，增加UI主线程负担。因此，应尽量避免在自定义组件的生命周期内执行高耗时操作。在aboutToAppear()生命周期函数内建议只做当前组件的初始化逻辑，对于不需要等待结果的高耗时任务，可以使用多线程处理该任务，通过并发的方式避免主线程阻塞；也可以把耗时操作改为异步并发或延后处理，保证主线程优先处理组件绘制逻辑。

使用多线程执行耗时操作

在日常开发过程中经常会碰到这样的问题：主页的开发场景中有多个Tab页展示不同内容，在首次加载完主页后，切换到第二个Tab页时需要加载和处理网络数据，导致第二个Tab页的页面显示较慢，有较大的完成时延。

碰到此类问题，我们可以在生命周期aboutToAppear中，使用多线程并发（详细介绍可参考文章：高效并发编程、多线程能力场景化示例实践）的方法执行第二个Tab页的网络数据访问解析、数据加载等耗时操作，既可以提前完成数据加载，也不会影响主线程UI绘制和渲染。

使用TaskPool进行耗时操作的示例代码如下：

import taskpool from '@ohos.taskpool';

aboutToAppear() {
  ...
  // 在生命周期中，使用TaskPool加载和解析网络数据
  this.requestByTaskPool();
}

@Concurrent
getInfoFromHttp(): string[] {
  // 从网络加载数据
  return http.request();
}

requestByTaskPool(): void {
  // 创建任务项
  let task: taskpool.Task = new taskpool.Task(this.getInfoFromHttp);
  try {
    // 执行网络加载函数
    taskpool.execute(task, taskpool.Priority.HIGH).then((res: string[]) => {
    });
  } catch (err) {
     logger.error(TAG, "failed, " + (err as BusinessError).toString());
  }
}

其他多线程并发相关文章：

利用native的方式实现跨线程调用

使用异步执行耗时操作

问题：在aboutToAppear生命周期函数中，运行了业务数据解析和处理等耗时操作，影响了上一页面点击跳转该页面的响应时延。

可以把耗时操作的执行从同步执行改为异步或者延后执行（详细介绍可参考文章：提升应用冷启动速度），比如使用setTimeOut执行耗时操作，示例如下：

aboutToAppear() {
  ...
  // 在生命周期中，使用异步处理数据，延时大小视情况确定
  setTimeout(() => {
    this.workoutResult();
  }, 1000)
}

workoutResult(): string[] {
  // 处理需要展示的业务数据
  let data: Data[] = [];
  for(let i = 1; i < 100; i++) {
    result += data[i];
  }
  return result;
}

使用预加载提升页面启动和响应速度

应该合理使用系统的预加载能力，例如Web组件的预连接、预加载、预渲染，使用List、Swiper、Grid、WaterFlow等组件的cachedCount属性实现预加载，使用条件渲染实现预加载）等，提升页面的启动和响应速度。

使用Web组件的预连接、预加载、预渲染能力

当我们碰到Web页面加载慢的场景，我们可以使用Web组件的预连接、预加载、预渲染能力（详细介绍可参考文章：Web组件开发性能提升指导），在应用空闲时间提前进行Web引擎初始化和页面加载，提升下一页面的启动和响应速度。

示例代码如下：

import webview from '@ohos.web.webview';

preload() {
  // Web组件引擎初始化
  webview.WebviewController.initializeWebEngine();
  // 启动预连接，连接地址为即将打开的网址
  webview.WebviewController.prepareForPageLoad('https://gitee.com/harmonyos-cases/cases', true, 2);
}
...

使用cachedCount属性实现预加载

推荐在使用List、Swiper、Grid、WaterFlow等组件时，配合使用cachedCount属性实现预加载（详细介绍可参考文章：WaterFlow高性能开发指导、Swiper高性能开发指导、Grid高性能开发指导、应用列表场景性能提升实践），示例代码如下所示：

  private source: MyDataSource = new MyDataSource();

  build() {
    List() {
      LazyForEach(this.source, item => {
        ListItem() {
          Text("Hello" + item)
            .fontSize(50)
            .onAppear(() => {
              console.log("appear:" + item)
            })
        }
      })
    }.cachedCount(3) // 扩大数值appear日志范围会变大
  }

使用条件渲染实现预加载

问题：页面布局复杂度较高，导致跳转该页面的响应时延较高。

可以使用条件渲染（详细介绍可参考文章：合理选择条件渲染和显隐控制）的方式，添加页面的简单骨架图作为默认展示页面，等数据加载完成后再显示最终的复杂布局，加快点击响应速度。

示例代码如下：

import skeletonComponent from "./skeletonComponent"
import businessComponent from "./businessComponent"

@State isInitialized: boolean = false

build() {
  // 当数据未就位时展示骨架图，提升点击响应速度，减少页面渲染时间
  if(!this.isInitialized) {
    // 网络数据未获取前使用骨架图
    skeletonComponent();
  } else {
    // 数据获取后再刷新显示内容
    businessComponent();
  }
}

使用缓存提升启动速度和滑动帧率

在列表场景中，我们推荐使用LazyForEach+组件复用+缓存列表项的能力，替代Scroll/ForEach实现滚动列表场景的实现，加快页面启动速度，提升滑动帧率；在一些属性动画的场景下，我们可以使用renderGroup缓存提升属性动画性能；也可以使用显隐控制对页面进行缓存，加快页面的显示响应速度。

组件复用

HarmonyOS应用框架提供了组件复用能力，可复用组件从组件树上移除时，会进入到一个回收缓存区。后续创建新组件节点时，会复用缓存区中的节点，节约组件重新创建的时间。

若业务实现中存在以下场景，并成为UI线程的帧率瓶颈，推荐使用组件复用（详细介绍可参考文章：组件复用实践、应用列表场景性能提升实践）：

列表滚动（本例中的场景）：当应用需要展示大量数据的列表，并且用户进行滚动操作时，频繁创建和销毁列表项的视图可能导致卡顿和性能问题。在这种情况下，使用列表组件的组件复用机制可以重用已经创建的列表项视图，提高滚动的流畅度。
动态布局更新：如果应用中的界面需要频繁地进行布局更新，例如根据用户的操作或数据变化动态改变视图结构和样式，重复创建和销毁视图可能导致频繁的布局计算，影响帧率。在这种情况下，使用组件复用可以避免不必要的视图创建和布局计算，提高性能。
地图渲染：在地图渲染这种场景下，频繁创建和销毁数据项的视图可能导致性能问题。使用组件复用可以重用已创建的视图，只更新数据的内容，减少视图的创建和销毁，能有效提高性能。

示例代码如下：

// xxx.ets
class MyDataSource implements IDataSource {
  private dataArray: string[] = [];
  private listener: DataChangeListener | undefined;
  ...
}

@Entry
@Component
struct MyComponent {
  private data: MyDataSource = new MyDataSource();

  aboutToAppear() {
    for (let i = 0; i < 1000; i++) {
      this.data.pushData(i.toString());
    }
  }

  build() {
    List({ space: 3 }) {
      LazyForEach(this.data, (item: string) => {
        ListItem() {
          ReusableChildComponent({ item: item })
        }
      }, (item: string) => item)
    }
    .width('100%')
    .height('100%')
  }
}

@Reusable
@Component
struct ReusableChildComponent {
  @State item: string = ''
  // 复用时触发的生命周期
  aboutToReuse(params: ESObject) {
    this.item = params.item;
  }

  build() {
    Row() {
      Text(this.item)
        .fontSize(20)
        .margin({ left: 10 })
    }.margin({ left: 10, right: 10 })
  }
}

使用renderGroup缓存提升属性动画性能

页面响应时，可能大量使用属性动画和转场动画，当复杂度达到一定程度之后，就有可能出现卡顿的情况。renderGroup(详细介绍可参考文章:合理使用renderGroup)是组件通用方法，它代表了渲染绘制的一个组合。

具体原理是在首次绘制组件时，若组件被标记为启用renderGroup状态，将对组件及其子组件进行离屏绘制，将绘制结果合并保存到缓存中。此后当需要重新绘制相同组件时，就会优先使用缓存而不必重新绘制了，从而降低绘制负载，进而加快响应速度。

示例代码如下：

// Index.ets

import { IconItem } from './IconItem'

// IconItem相关数据
class IconItemSource {
  image: string | Resource = ''
  text: string | Resource = ''
  ...
}

@Entry
@Component
struct Index {
  private iconItemSourceList: IconItemSource[] = [];

  aboutToAppear() {
    // 遍历添加IconItem的数据
    this.iconItemSourceList.push(
      new IconItemSource($r('app.media.img1'), `label1`),
      new IconItemSource($r('app.media.img2'), `label2`),
      new IconItemSource($r('app.media.img3'), `label3`),
    );
  }

  build() {
    Column() {
      // IconItem放置在grid内
      GridRow({}) {
        ForEach(this.iconItemSourceList, (item: IconItemSource) => {
          GridCol() {
            IconItem({ image: item.image, text: item.text })
              .transition(
                TransitionEffect.scale({})
                  .animation({})
                  .combine(TransitionEffect.rotate({})
                  .animation({ }))
              )
          }
        })
      }
    }
  }
}

// IconItem.ets

@Component
export struct IconItem {
  ...
  build()  {
    Flex()  {
      Image(this.image)
      Text(this.text)
    }
    // 在IconItem内开启renderGroup
    .renderGroup(true)
  }
}

使用显隐控制进行页面缓存

控制元素显示与隐藏是一种常见的场景，使用Visibility.None、if条件判断等都能够实现该效果。其中if条件判断控制的是组件的创建、布局阶段，visibility属性控制的是元素在布局阶段是否参与布局渲染。使用时如果使用的方式不当，将引起性能上的问题。
如果会频繁响应显示与隐藏的交互效果，建议使用切换Visibility.None和Visibility.Visible来控制元素显示与隐藏(详细介绍可参考文章: 合理选择条件渲染和显隐控制)，在组件无需展示的时候进行缓存，提高性能。

示例代码如下：

@State isVisible: boolean = true;

build() {
  Column() {
    Button("Switch visible and hidden").onClick(() => {
        this.isVisible = !(this.isVisible);
    })
    Stack() {
      Scroll() {
        Column() {
          Image($r('app.media.icon'))
        }
      }.visibility(this.isVisible ? Visibility.Visible : Visibility.None)// 使用显隐控制切换，不会频繁创建与销毁组件
    }  
  }  
}

第二板斧：尽量减少布局的嵌套层数

在进行页面布局开发时，应该去除冗余的布局嵌套，使用相对布局、绝对定位、自定义布局、Grid、GridRow等扁平化布局，减少布局的嵌套层数，避免系统绘制更多的布局组件，达到优化性能(详细介绍可参考文章: 优化布局性能)、减少内存占用的目的。

移除冗余节点

应该删除冗余的布局嵌套，例如build最外层的无用容器嵌套、无用的Stack或Column嵌套等，减少布局层数。

删除无用的Stack/Column/Row嵌套

例如可能会在Row容器包含一个同样也是Row容器的子级。这种嵌套实际是多余的，并且会给布局层次结构造成不必要的开销。示例代码如下：

// 反例
Row() {
  Row() {
    Text()
    Text()
  }
  Text()
}

// 正例
Row() {
  Text()
  Text()
  Text()
}

删除build函数中最外层无用容器嵌套

在开发过程中，布局的实现往往嵌套使用大量的自定义组件，build中冗余的最外层无用容器会大大增强嵌套层级，应该删除。

反例代码如下：

@Component
struct ComponentA {
  build() {
    Column() {
      ComponentB();
    }
  }
}

@Component
struct ComponentB {
  build() {
    Column() {
      Text('');
    }
  }
}

正例代码如下：

@Component
struct ComponentA {
  build() {
    Column() {
      ComponentB();
    }
  }
}

@Component
struct ComponentB {
  build() {
    Text('');
  }
}

使用扁平化布局减少节点数

使用Column/Row替代Flex构建线性布局

由于Flex本身带来的二次布局的影响，Flex的性能明显低于Column和Row容器，因此推荐使用Column/Row替代Flex构建线性布局(详细介绍可参考文章: Flex布局性能提升使用指导)。

反例代码如下：

@Entry
@Component
struct MyComponent {
  build() {
    Flex({ direction: FlexDirection.Column }) {
      Flex().width(300).height(200).backgroundColor(Color.Pink)
      Flex().width(300).height(200).backgroundColor(Color.Yellow)
      Flex().width(300).height(200).backgroundColor(Color.Grey)
    }
  }
}

正例代码如下：

@Entry
@Component
struct MyComponent {
  build() {
    Column() {
      Row().width(300).height(200).backgroundColor(Color.Pink)
      Row().width(300).height(200).backgroundColor(Color.Yellow)
      Row().width(300).height(200).backgroundColor(Color.Grey)
    }
  }
}

使用Flex、List、Grid、RelativeContainer、绝对布局和自定义布局等构建复杂布局

复杂布局提供了场景化的能力(详细介绍可参考文章: 优化布局性能)，解决一种或者多种布局场景：

使用Flex构建弹性布局；
List既具备线性布局的特点，同时支持懒加载和滑动的能力；
Grid/GridItem提供了宫格布局的能力，同时也支持懒加载和滑动能力；
RelativeContainer是一种相对布局，通过描述各个内容组件间相互关系来指导内容元素的布局过程，可从横纵两个方面进行布局描述，是一种二维布局算法；

反例代码如下：

@Entry
@Component
struct AspectRatioExample12 {
    @State children: Number[] = Array.from(Array<number>(900), (v, k) => k);

    build() {
      Scroll() {
      Grid() {
        ForEach(this.children, (item: Number[]) => {
          GridItem() {
            Stack() {  
              Stack() {  
                Stack() {  
                  Text(item.toString())  
                }.size({ width: "100%"})  
              }.backgroundColor(Color.Yellow)  
            }.backgroundColor(Color.Pink)  
          }  
        }, (item: string) => item)  
      }  
      .columnsTemplate('1fr 1fr 1fr 1fr')  
      .columnsGap(0)  
      .rowsGap(0)  
      .size({ width: "100%", height: "100%" })  
    }  
  }  
}

正例代码如下：

@Entry  
@Component  
struct AspectRatioExample11 {  
  @State children: Number[] = Array.from(Array<number>(900), (v, k) => k);  

  build() {  
    Scroll() {  
      Grid() {  
        ForEach(this.children, (item: Number[]) => {  
          GridItem() {  
            Text(item.toString())  
          }.backgroundColor(Color.Yellow)  
        }, (item: string) => item)  
      }  
      .columnsTemplate('1fr 1fr 1fr 1fr')  
      .columnsGap(0)  
      .rowsGap(0)  
      .size({ width: "100%", height: "100%" })  
    }  
  }  
}

第三板斧：合理管理状态变量

应该合理地使用状态变量，精准控制组件的更新范围(详细介绍可参考文章: 精准控制组件的更新范围)，控制状态变量关联组件数量上限，控制对象级状态变量的成员变量关联组件数，减少系统的组件渲染负载，提升应用流畅度。

精准控制组件的更新范围

在复杂页面开发的场景下，精准控制组件更新的范围对提高应用运行性能尤为重要。我们应该避免状态变量的滥用引起的容器组件的刷新，进而影响帧率。

使用Stack包裹条件渲染组件，减小更新范围

用条件渲染的方式控制组件的显示，在条件发生变化时会引起父组件的重新渲染。如果在同个父组件下存在复杂组件，在高频操作场景会产生性能问题。因此，对于该场景，我们应该用父容器组件包裹可能会频繁条件变化的组件

反例代码如下：

@State isVisible: boolean;
@State realData: Data[] = [];

aboutToAppear() {
  // 更新状态变量
  this.realData = [...]
}

build() {
  Column() {
    if(this.isVisible) {
      Text()
    }
    ForEach(this.realData,(item: Data) => {
      Text(`${item.label}`)
    })
  }
}

正例代码如下：

@State isVisible: boolean;
@State realData: Data[] = [];

aboutToAppear() {
  // 更新状态变量
  this.realData = [...]
}

build() {
  Column() {
    Stack() {
      if(this.isVisible) {
        Text()
      }
    }
    ForEach(this.realData,(item: Data) => {
      Text(`${item.label}`)
    })
  }
}

减少不必要的参数层次传递

@State+@Prop、@State+@Link、@State+@Observed+@ObjectLink三种方案的实现方式是逐级向下传递状态，当共享状态的组件间层级相差较大时，会出现状态层层传递的现象。对于没有使用该状态的中间组件而言，这是“额外的消耗”。因此，对于跨越多层的状态变量传递，使用@Provide+@Consume方案更为合理。

反例代码如下：

// 父组件
@Component
struct componentParent{
  @State data: Data = {}

  aboutToAppear() {
    // 获取子组件数据
    this.data = getData()
  }

  build() {
    Column() {
      componentSon({data: this.data})
    }
  }
}

// 子组件
@Component
struct componentSon{
  // 获取传递参数
  @Prop data: Data;

  build() {
    Column() {
      Text(data.text)
      componentGrandSon({data: this.data})
    }
  }
}

@Component
struct componentGrandSon{
  // 获取传递参数
  @Prop data: Data;

  build() {
    Column() {
      Text(data.text)
    }
  }
}

正例代码如下：

// 父组件
@Component
struct componentParent{
  @Provide('data') data: Data = {};

  aboutToAppear() {
    // 获取子组件数据
    this.data = getData()
  }

  build() {
    Column() {
      componentSon({data: this.data})
    }
  }
}

// 子组件
@Component
struct componentSon{
  // 获取传递参数
  @Consume("data") data: Data;

  build() {
    Column() {
      Text(data.text)
      componentGrandSon({data: this.data})
    }
  }
}

@Component
struct componentGrandSon{
  // 获取传递参数
  @Consume("data") data: Data;

  build() {
    Column() {
      Text(data.text)
    }
  }
}

避免滥用@Provide+@Consume

在父子组件关联的场景下，@Provide+@Consume开销要大于@State+@Prop/@Link，因此在该场景下推荐使用@State+@Prop/@Link的组合。

反例代码如下：

// 父组件
@Component
struct componentParent{
  @Provide("data") data: Data = {};

  aboutToAppear() {
    // 获取子组件数据
    this.data = getData();
  }

  build() {
    Column() {
      componentSon()
    }
  }
}

// 子组件
@Component
struct componentSon{
  // 获取传递参数
  @Consume("data") data: Data;

  build() {
    Column() {
      Text(data.text)
    }
  }
}

正例代码如下：

// 父组件
@Component
struct componentParent{
  @State data:Data = {};

  aboutToAppear() {
    // 获取子组件数据
    this.data = getData();
  }

  build() {
    Column() {
      componentSon({data: this.data})
    }
  }
}

// 子组件
@Component
struct componentSon{
  // 获取传递参数
  @Prop data:Data;

  build() {
    Column() {
      Text(data.text)
    }
  }
}

精准控制状态变量关联组件数量

应该控制状态变量关联的组件数量，如果一个状态关联过多的组件，当这个变量更新时会引起过多的组件重新绘制渲染，建议关联数量限制在20个以内(详细介绍可参考文章: 精准控制组件的更新范围)。

控制状态变量关联组件数量

反例代码如下：

@Observed
class Translate {
  translateX: number = 20;
}
@Component
struct Title {
  @ObjectLink translateObj: Translate;
  build() {
    Row() {
      Image($r('app.media.icon'))
        .translate({
          x:this.translateObj.translateX // this.translateObj.translateX used in two component both in Row
        })
      Text("Title")
        .translate({
          x: this.translateObj.translateX
        })
    }
  }
}
@Entry
@Component
struct Page {
  @State translateObj: Translate = new Translate();
  build() {
    Column() {
      Title({
        translateObj: this.translateObj
      })
      Stack() {
      }
      .translate({
        x:this.translateObj.translateX //this.translateObj.translateX used in two components both in Column
      })
      Button("move")
        .translate({
          x:this.translateObj.translateX
        })
        .onClick(() => {
          animateTo({
            duration: 50
          },()=>{
            this.translateObj.translateX = (this.translateObj.translateX + 50) % 150
          })
        })
    }
  }
}

正例代码如下：

@Observed
class Translate {
  translateX: number = 20;
}
@Component
struct Title {
  build() {
    Row() {
      Image($r('app.media.icon'))
      Text("Title")
    }
  }
}
@Entry
@Component
struct Page1 {
  @State translateObj: Translate = new Translate();
  build() {
    Column() {
      Title()
      Stack() {
      }
      Button("move")
        .onClick(() => {
          animateTo({
            duration: 50
          },()=>{
            this.translateObj.translateX = (this.translateObj.translateX + 50) % 150
          })
        })
    }
    .translate({ // the component in Column shares the same property translate
      x: this.translateObj.translateX
    })
  }
}

控制对象级状态变量成员数量

应该控制对象级状态变量的成员变量关联的组件数量。开发者封装一个数据结构类用于进行状态变量关联时，应该避免过多的成员变量关联大量ArkUI组件，这种情况下，当这个大对象的一个成员变量更新时，会导致所有关联这个大对象的组件都同时进行刷新，造成不必要的性能损耗，从而影响帧率。

反例代码如下：

@Observed
class AnimationParams {
  translateX: number = 0;
  translateY: number = 0;
  alpha: number = 1;
  rotationX: number = 0;
  rotationY: number = 0;
  centerX: number = 0;
  centerY: number = 0;
  angle: number = 0;
  scaleX: number = 1;
  scaleY: number = 1;
}

@Entry
@Component
struct Page {
  @State animationParam: AnimationParams = new AnimationParams();

  build() {
    Column() {
      Row() {
        Image($r('app.media.startIcon'))
          .translate({
            x: this.animationParam.translateX,
            y: this.animationParam.translateY
          })
          .rotate({
            x: this.animationParam.rotationX,
            y: this.animationParam.translateY,
            centerX: this.animationParam.centerX,
            centerY: this.animationParam.centerY,
            angle: this.animationParam.angle
          })
          .opacity(this.animationParam.alpha)
          .scale({
            x: this.animationParam.scaleX,
            y: this.animationParam.scaleY,
            centerX: this.animationParam.centerX,
            centerY: this.animationParam.centerY
          })
          .animation({
            duration: 3000
          })
      }

      Button('点击播放动画')
        .onClick(() => {
          this.animationParam.translateX = 300;
          this.animationParam.translateY = 200;
          this.animationParam.rotationX = 90;
          this.animationParam.rotationY = 90;
          this.animationParam.centerX = 20;
          this.animationParam.centerY = 20;
          this.animationParam.angle = 270;
          this.animationParam.alpha = 0.5;
          this.animationParam.scaleX = 3;
          this.animationParam.scaleY = 3;
        })
    }
  }
}

正例代码如下：

@Observed
class RotationAnimationParams {
  rotationX: number = 0;
  rotationY: number = 0;
  centerX: number = 0;
  centerY: number = 0;
  angle: number = 0;
}

@Observed
class TranslateAnimationParams {
  translateX: number = 0;
  translateY: number = 0;
}

@Observed
class AlphaAnimationParams {
  alpha: number = 1;
}

@Observed
class ScaleAnimationParams {
  scaleX: number = 1;
  scaleY: number = 1;
  centerX: number = 0;
  centerY: number = 0;
}

@Entry
@Component
struct Page {
  @State rotationAnimation: RotationAnimationParams = new RotationAnimationParams();
  @State translateAnimation: TranslateAnimationParams = new TranslateAnimationParams();
  @State alphaAnimation: AlphaAnimationParams = new AlphaAnimationParams();
  @State scaleAnimation: ScaleAnimationParams = new ScaleAnimationParams();

  build() {
    Column() {
      Row() {
        Image($r('app.media.startIcon'))
          .translate({
            x: this.translateAnimation.translateX,
            y: this.translateAnimation.translateY
          })
          .rotate({
            x: this.rotationAnimation.rotationX,
            y: this.rotationAnimation.rotationY,
            centerX: this.rotationAnimation.centerX,
            centerY: this.rotationAnimation.centerY,
            angle: this.rotationAnimation.angle
          })
          .opacity(this.alphaAnimation.alpha)
          .scale({
            x: this.scaleAnimation.scaleX,
            y: this.scaleAnimation.scaleY,
            centerX: this.scaleAnimation.centerX,
            centerY: this.scaleAnimation.centerY
          })
          .animation({
            duration: 3000
          })
      }

      Button('点击播放动画')
        .onClick(() => {
          this.rotationAnimation.rotationX = 90;
          this.rotationAnimation.rotationY = 90;
          this.rotationAnimation.centerX = 20;
          this.rotationAnimation.centerY = 20;
          this.rotationAnimation.angle = 270;

          this.translateAnimation.translateX = 300;
          this.translateAnimation.translateY = 200;

          this.alphaAnimation.alpha = 0.5;

          this.scaleAnimation.scaleX = 3;
          this.scaleAnimation.scaleY = 3;
          this.scaleAnimation.centerX = 20;
          this.scaleAnimation.centerY = 20;
        })
    }
  }
}

避免不必要的创建和读取状态变量

避免不必要的创建和读取状态变量，减少性能损耗。

删除冗余的状态变量标记

状态变量的管理有一定的开销，应在合理场景使用，普通的变量用状态变量标记可能会导致性能劣化

反例代码如下：

@Component
struct component {
  @State bgcolor: string | Color = '#ffffff';
  @State selectColor: string | Color = '#007DFF';

  build() {
  }
}

正例代码如下：

@Component
struct component {
  bgcolor: string | Color = '#ffffff';
  selectColor: string | Color = '#007DFF';

  build() {
  }
}

避免在For/while等循环函数中重复读取状态变量

状态变量的读取耗时远大于普通变量的读取耗时，因此要避免重复读取状态变量，而是应该放在循环外面读取，例如在打印For/while循环中打印状态变量的日志信息

反例代码如下：

@Component
struct Page {
  @State message: string = '';

  build() {
    Column() {
      Button('点击打印日志')
        .onClick(() => {
          for (let i = 0; i < 10; i++) {
            console.debug(this.message);
          }
        })
    }
  }
}

正例代码如下：

@Component
struct Page {
  @State message: string = '';

  build() {
    Column() {
      Button('点击打印日志')
        .onClick(() => {
          let logMessage: string = this.message;
          for (let i = 0; i < 10; i++) {
            console.debug(logMessage);
          }
        })
    }
  }
}

第四板斧：合理使用系统接口，避免冗余操作

应该合理使用系统的高频回调接口，删除不必要的Trace和日志打印，避免冗余操作，减少系统开销（详细介绍可参考文章: 避免开发过程中的冗余操作）。

避免在系统高频回调用进行冗余和耗时操作

应该避免在onScroll、onAreaChange等系统高频的回调接口中进行冗余和耗时操作，这些接口在系统的每一帧绘制中都会执行回调操作，因此在这些接口中进行冗余和耗时操作会大量消耗系统资源，影响应用运行性能。

避免在系统高频回调用打印Trace

Trace的打印是会额外消耗系统性能的，因此应该避免在这些系统高频回调接口中打印Trace，示例代码如下：

// 反例
Scroll() {
  ForEach(this.arr, (item: number) => {
    Text("ListItem" + item)
    .width("100%")
    .height("100%")
  }, (item: number) => item.toString())
}
.width('100%')
.height('100%')
.onScroll(() => {
  hitrace.startTrace("ScrollSlide", 1002);
  // 业务逻辑
  // ...
  hitrace.finishTrace("ScrollSlide", 1002);
})

// 正例
@Component
struct PositiveOfOnScroll {
  private arr: number[] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

  build() {
    Scroll() {
      List() {
        ForEach(this.arr, (item: number) => {
          ListItem() {
            Text("TextItem" + item)
          }
          .width("100%")
          .height(100)
        }, (item: number) => item.toString())
      }
      .divider({ strokeWidth: 3, color: Color.Gray })
    }
    .width('100%')
    .height('100%')
    .onScroll(() => {
      // 业务逻辑
      // ...
    })
  }
}

避免在系统高频回调用打印日志

日志的打印是会额外消耗系统性能的，特别是有些日志还读取了状态变量的信息，会加剧资源开销，因此应该避免在这些系统高频回调接口中打印日志，示例代码如下：

// 反例
@Component
struct NegativeOfOnScroll {
  private arr: number[] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

  build() {
    Scroll() {
      List() {
        ForEach(this.arr, (item: number) => {
          ListItem() {
            Text("TextItem" + item)
          }
          .width("100%")
          .height(100)
        }, (item: number) => item.toString())
      }
      .divider({ strokeWidth: 3, color: Color.Gray })
    }
    .width('100%')
    .height('100%')
    .onScroll(() => {
      hilog.info(1002, 'Scroll', 'TextItem');
      // 业务逻辑
      // ...
    })
  }
}

// 正例
@Component
struct PositiveOfOnScroll {
  private arr: number[] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

  build() {
    Scroll() {
      List() {
        ForEach(this.arr, (item: number) => {
          ListItem() {
            Text("TextItem" + item)
          }
          .width("100%")
          .height(100)
        }, (item: number) => item.toString())
      }
      .divider({ strokeWidth: 3, color: Color.Gray })
    }
    .width('100%')
    .height('100%')
    .onScroll(() => {
      // 业务逻辑
      // ...
    })
  }
}

删除冗余Trace和日志打印

Trace和日志打印会比较消耗系统性能，因此我们应该避免冗余的Trace和日志打印。推荐在Release版本中，尽量删除所有Trace信息，删除Debug日志，减少额外的系统开销。

在Release版本中删除Trace

Trace会比较消耗系统性能，建议在Release版本删除Trace打印。

反例代码如下：

@Component
struct NegativeOfTrace {
  aboutToAppear(): void {
    hitrace.startTrace("HITRACE_TAG_APP", 1003);
    // 业务代码
    // ...
    hitrace.finishTrace("HITRACE_TAG_APP", 1003);
  }
  build() {
    // 业务代码
  }
}

正例代码如下：

@Component
struct PositiveOfTrace {
  aboutToAppear(): void {
    // 业务代码
    // ...
  }
   build() {
    // 业务代码
  }
}

在Release版本中删除Debug日志

虽然在Release版本中不会打印debug级别日志，但是如果在日志的入参中进行了参数拼接，字符串拼接的逻辑还是会执行（详细介绍可参考文章: 避免开发过程中的冗余操作），会有冗余开销，因此建议在Release版本删除Debug日志打印。

反例代码如下：

@Component
struct NegativeOfDebug {
  @State string1: string = 'a';
  @State string2: string = 'b';

  aboutToAppear(): void {
    hilog.debug(1004, 'Debug', (this.string1 + this.string2));
    // 业务代码
    // ...
  }

  build() {
    // 业务代码
    // ...
  }
}

正例代码如下：

@Component
struct PositiveOfDebug {
  aboutToAppear(): void {
    // 业务代码
    // ...
  }
  build() {
    // 业务代码
    // ...
  }
}

避免设置冗余系统回调监听

冗余的系统回调监听，会额外消耗系统开销去做计算和函数回调消耗。比如设置了onAreaChange，就算回调中没有任何逻辑，系统也会在C++侧去计算该组件的大小和位置变化情况，并且把结果回调到TS侧，额外消耗了系统开销。

反例代码如下：

@Component
struct NegativeOfOnClick {
  build() {
    Button('Click', { type: ButtonType.Normal, stateEffect: true })
      .onClick(() => {
        hitrace.startTrace("ButtonClick", 1004);
        hilog.info(1004, 'Click', 'ButtonType.Normal')
        hitrace.finishTrace("ButtonClick", 1004);
        // 业务代码
        // ...
      })
      .onAreaChange((oldValue: Area, newValue: Area) => {
        // 无任何代码
      })
   }
}

正例代码如下：

@Component
struct PositiveOfOnClick {
  build() {
    Button('Click', { type: ButtonType.Normal, stateEffect: true })
      .onClick(() => {
        // 业务代码
        // ...
    })
}

使用性能工具分析和定位问题

学会合理使用工具进行问题分析和定位，提升问题解决效率。

学会使用IDE的Profier工具定位问题

通过使用Profier工具，定位应用开发过程中的各种性能问题，详细的使用方法可以参考下列文章：性能分析工具CPU Profiler、页面布局检查器ArkUI Inspector、内存分析器Allocation Profiler、帧率分析工具 Frame Profiler、启动分析工具Launch Profiler、内存快照Snapshot Profiler、耗时分析器Time Profiler。

使用SmartPerf-Host分析应用性能

SmartPerf-Host是一款深入挖掘数据、细粒度展示数据的性能功耗调优工具，可采集CPU调度、频点、进程线程时间片、堆内存、帧率等数据，采集的数据通过泳道图清晰地呈现给开发者，同时通过GUI以可视化的方式进行分析。工具当前为开发者提供了五个分析模板，分别是帧率分析、CPU/线程调度分析、应用启动分析、TaskPool分析、动效分析。

使用状态变量组件定位工具分析状态变量关联信息

开发者可以使用状态变量组件定位工具获取状态管理相关信息，例如自定义组件拥有的状态变量、状态变量的同步对象和关联组件等，了解状态变量影响UI的范围，写出高性能应用代码。

使用常用trace使用指导协助定位性能问题

本文旨在介绍OpenHarmony中常用的Trace，解释它们的含义和用途，并阐述如何通过这些Trace来识别潜在的性能问题。同时，我们还将详细介绍Trace的工作原理，帮助读者更好地理解这些Trace及如何实现性能数据的采集和分析。通过本文的阅读，读者将对OpenHarmony中的Trace有一个深入的了解，为应用程序性能优化提供有力支持。

性能文章总览

性能优化概览

写在最后

如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：
点赞，转发，有你们的『点赞和评论』，才是我创造的动力。
关注小编，同时可以期待后续文章ing🚀，不定期分享原创知识。
想要获取更多完整鸿蒙最新学习资源，请移步前往小编：https://gitee.com/MNxiaona/733GH

HarmonyOS NEXT应用开发性能优化从入门到精通指南~

概述

第一板斧：合理使用并行化、预加载和缓存

使用并行化提升启动速度

使用多线程执行耗时操作

使用异步执行耗时操作

使用预加载提升页面启动和响应速度

使用Web组件的预连接、预加载、预渲染能力

使用cachedCount属性实现预加载

使用条件渲染实现预加载

使用缓存提升启动速度和滑动帧率

组件复用

使用renderGroup缓存提升属性动画性能

使用显隐控制进行页面缓存

第二板斧：尽量减少布局的嵌套层数

移除冗余节点

删除无用的Stack/Column/Row嵌套

删除build函数中最外层无用容器嵌套

使用扁平化布局减少节点数

使用Column/Row替代Flex构建线性布局

使用Flex、List、Grid、RelativeContainer、绝对布局和自定义布局等构建复杂布局

第三板斧：合理管理状态变量

精准控制组件的更新范围

使用Stack包裹条件渲染组件，减小更新范围

减少不必要的参数层次传递

避免滥用@Provide+@Consume

精准控制状态变量关联组件数量

控制状态变量关联组件数量

控制对象级状态变量成员数量

避免不必要的创建和读取状态变量

删除冗余的状态变量标记

避免在For/while等循环函数中重复读取状态变量

第四板斧：合理使用系统接口，避免冗余操作

避免在系统高频回调用进行冗余和耗时操作

避免在系统高频回调用打印Trace

避免在系统高频回调用打印日志

删除冗余Trace和日志打印

在Release版本中删除Trace

在Release版本中删除Debug日志

避免设置冗余系统回调监听

使用性能工具分析和定位问题

学会使用IDE的Profier工具定位问题

使用SmartPerf-Host分析应用性能

使用状态变量组件定位工具分析状态变量关联信息

使用常用trace使用指导协助定位性能问题

性能文章总览

写在最后

网站公告

今日签到

热门文章

最新发布