合理使用布局

ArkUI框架执行流程

在使用ArkUI开发中，我们通过布局组件和基础组件进行界面描述，这些描述会呈现出一个组件树的结构，基础组件在其中为叶子结点，布局组件则是中间节点，可以把这棵树称之为应用组件树。当用户执行交互（滑动，点击等行为）时会触发界面修改，界面的修改本质上是通过触发这棵组件树的重新渲染，来实现应用界面更新的过程。

UI更新过程

UI更新过程包含组件标脏过程以及布局过程。在初次加载时，所有的组件都会经历这几个阶段（除去if/else条件为否的分支以及LazyForEach中未在可视区的内容），而在界面更新时（如列表滑动，切换显示隐藏状态，触发页面元素内容样式位置大小等变化等场景下），并不需要把页面所有的组件对象重新创建一遍，而是只需要对需要更新部分进行更新，而需要更新部分则是脏节点数组里包含的内容，UI线程处理过程会先将脏节点进行Build，Build的过程会按照组件id，依次更新组件设置的属性，如果属性发生改变，则进行组件标脏，其中布局属性（width、height、padding、margin等）发生改变会标记为布局脏，找到布局边界，进行子树更新，而非布局（Color、BackgroundColor、opacity等）属性仅会影响自身属性，不会进行子树查找。

精简节点数

布局阶段是采用递归遍历所有节点的方式进行组件位置和大小的计算， 如果嵌套层级过深，将带来了更多的中间节点，在布局测算阶段下，额外的节点数将导致更多的计算过程，造成性能劣化。我们通过模拟了10、100、500、1000层Row嵌套的情况下，通过Profiler工具抓取Launch数据查看对应的首帧绘制，以及页面Measure/Layout时间进行对比。

  Row() {
    ... // 10、100、500、1000层Row容器嵌套
    Row() {
      Text('Inner Text')
    } 
    ... 
  }

然后进一步对比了在平铺的情况下，Row内组件个数在10、100、500、1000的条件下，使用Profiler工具抓取Launch的数据情况，得到如下结果如表1所示。

 Row() {
    Row() {} 
    ... // 10、100、500、1000层Row容器并排
    Text('Inner Text')
  }

根据以上数据对比发现，组件平铺和嵌套在相同组件个数的情况下，其性能差异不大，并且整体上趋势保持一致，随着组件数量增加呈现线性增长的劣化，由此可以得到结论，真正影响布局性能的因素是参与布局的节点数量。所以在进行布局时，应该尽量减少整体的节点数，来减少布局的性能劣化。

针对减少总节点，主要有两个方向：

• 移除冗余的节点。
• 使用扁平化布局减少节点数。

移除冗余节点

对于常出现冗余的情况，例如可能会在Row容器包含一个同样也是Row容器的子级。这种嵌套实际是多余的，并且会给布局层次结构造成不必要的开销。

Row() {
  Row(){
    Image()
    Text()
  }
  Image()
}

由于其中Row容器父子布局方向相同，所以可以去掉Image和Text外层的Row来减少层级，如果视图更加复杂，布局在渲染时，会产生没有必要的计算。

Row() {
  Image()
  Text()
  Image()
}

尽管在这里只是多了一层，但是实际开发中的布局往往非常复杂，冗余带来的开销可能非常影响布局性能，尤其是在列表中动态创建组件时，带来的性能影响是显著的。

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

在某些情况下，开发者所实现的布局在嵌套层级上是没有冗余的，但是嵌套层级仍然较深，可能无法通过调整现有的布局方案，使其不包含多余的布局，唯一的解决方案可能是，通过切换到完全不同的布局类型来实现层次结构的扁平化。

例如图1中元素结构示意图，传统使用线性布局的情况下，总共存在4层嵌套、共15个节点，并且其中并没有冗余的嵌套节点。而扁平化布局是一种让页面结构变浅变宽的方式，通过一些高级组件如RelativeContainer、Grid等容器，可以让元素在平面上展开。这种布局方式能够有效减少由于使用线性布局带来的嵌套深度，将其用于描述布局的容器节点进行优化，达到精简节点数的目的。图一中将线性布局改成相对布局的情况下，嵌套2层、总共10个节点，相比之下前后少了5个节点。

图1 扁平化布局示意图

这种方式对于布局的影响主要体现在：

1. 页面创建时，扁平化减少了中间的嵌套层级，使总的组件节点的数量越少，在进行布局时所需要进行的计算相对越少。
2. 页面更新时，当要更新的结构是嵌套子树的结构，其树内包含过多节点时，整体更新会导致更新的节点数过多，造成布局性能劣化。

所以当页面不存在冗余节点时，可以考虑是否能够通过替换为更高级的布局使得页面扁平化，来达到减少节点数的目的。主要方式可以参考：

• RelativeContainer 通过相对布局实现扁平化。
• 绝对定位 通过锚点定位实现扁平化。
• Grid 通过二维布局实现扁平化。

利用布局边界减少布局计算

对于组件的宽高不需要自适应的情况下，建议在UI描述时给定组件的宽高数值，当其组件外部的容器尺寸发生变化时，例如拖拽缩放等场景下，如果组件本身的宽高是固定的，理论上来讲，该组件在布局阶段不会参与Measure阶段，其节点中保存了对应的大小信息，如果组件内容较多时，由于避免了其中组件整体的测算过程，性能会带来较大的提升。

Column() {
  Button("修改宽度").onClick(() => {
    this.testWidth = '90%'
  }).height('20%')

  Row() {
    // 400条文本数据
  }
}.width(this.testWidth )

对比的结果如下：

由上数据可以发现：

• 首次绘制时，三种情况数据相差不大。
• 重新绘制时，限定容器宽高为固定值的情况下，性能提升明显。

分析原因可以得到，这是由于首次绘制的情况下，无论是否设置宽高属性，都会对所有组件进行布局和测算的过程，来得到最终的组件大小和位置。而当触发按钮修改外层Column的宽度时，也就是触发重新绘制的情况下，给定容器宽高为固定值的性能远远优于未设置宽高和设置百分比宽高，这是由于对于未设置宽高以及设置百分比宽高的情况下，在外层容器宽高发生变化时，组件本身也会触发重新进行Measure的过程，对组件的宽高进行重新测算，导致其布局时间很长，而设置了固定宽高的组件，则不会经过这一过程，而是直接使用初次绘制时保留的节点大小数据，减少了测算的时间，这对于性能的提升是尤为明显的，尤其是当组件内的内容十分复杂的情况下。

所以对于能够在初期给定宽高的组件，在进行UI描述时尽量给定宽高数值，能够减少由于容器尺寸变化造成的重新测算过程的性能。

合理使用渲染控制语法

合理控制元素显示与隐藏

控制元素显示与隐藏是一种常见的场景，使用Visibility.None、if条件判断等都能够实现该效果。其中if条件判断控制的是组件的创建、布局阶段，visibility属性控制的是元素在布局阶段是否参与布局渲染。使用时如果使用的方式不当，将引起性能上的问题。

对于不同的场景下，需要选择合适的手段，根据性能或者内存要求选择不同的实现方式：

• 只有初始的一次渲染或者交互次数很少的情况下，建议使用if条件判断来控制元素的显示与隐藏效果，对于内存有较大提升。
• 如果会频繁响应显示与隐藏的交互效果，建议使用切换Visibility.None和Visibility.Visible来控制元素显示与隐藏，提高性能。

通过对一个复杂的视图结构，例如以下示例代码中，对包含100个Image组件的Column容器进行显示与隐藏控制，分别采用if条件判断和visibility属性的方式进行控制。

 Row() {
    Text("Hello World")
    if(this.visible) {
      Column() {
        ... // 100个Image组件
      }
    }
  }

 Row() {
    Text("Hello World")
    Column() {
      ... // 100个Image组件
    }.visibility(this.visible?Visibility.Visible:Visibility.None)
  }

在相同的测试环境下，分别测试在初次加载页面，以及改变状态变量this.visible的值来修改显示隐藏的情况下，通过Profiler工具抓取的布局时Measure、Layout以及组件创建的时长。

在初次加载的情况下的测试结果如下：

通过以上数据可以发现：

• 通过if条件判断控制显示与隐藏的方式：
  • 对比判断值为true和false时，初次加载过程中Measure、Layout时间明显存在区别，并且从组件创建时间可以判断，加载时会根据初始值判断是否创建对应组件内容。
  • 当条件为false时，对应的组件内容不参与创建、Measure和Layout阶段。
• 通过visibility控制显示与隐藏的方式：
  • 在初次加载时，无论visibility的值为Visibility.None还是Visibility.Visible都会创建对应组件内容。
  • visibility属性控制的是Measure和Layout阶段，当visibility属性为Visibility.None时，对应的组件不参与Layout。

在切换显示状态的情况下的结果如下：

在切换显示状态的情况下：

• 使用if条件判断切换显示时，组件会因为条件改变而判断是否参与创建、布局过程，切换过程会出现较大的Measure的性能消耗，原因是创建了新的组件，重新进行了Measure和Layout的过程。

• 使用visibility的情况下，无论是否隐藏，组件在初次已经创建完成，并一直都存在组件树上，不会出现组件重新创建的过程，并且在Measure和Layout阶段的性能消耗比使用if/else的方式性能小很多，原因是组件的计算在首帧时已经计算过，不需要重复计算。

综上所述，在控制组件显示与隐藏时，建议遵循以下原则来选择使用控制方式：

• 在对性能要求较高，并且会频繁切换元素的显示与隐藏的情况下，应该避免使用if条件判断，而改为通过visibility的属性控制，这样在切换Visibility.None和Visibility.Visible时，可以省去组件创建的时间，直接进入渲染过程。
• 如果组件的创建非常消耗资源，且不会立即使用，也并非频繁切换交互的情况下，只在特定条件下才会出现时，可以通过if/else来进行内容的显示与隐藏控制，来达到懒加载的效果。

长列表使用懒加载与组件复用

在列表场景下会采用List、Grid、WaterFlow等组件配合ForEach或者LazyForEach来实现，ForEach适合内容长度确定，内容在两屏以内的列表。LazyForEach适合长度超过两屏的列表情况，并且当内容布局相对固定的情况下，配合组件复用的方式来减少滑动过程中的组件创建。在长列表加载性能优化中，介绍了较为详细的实践案例，这里我们仅引用一些关键性能收益数据。

懒加载

针对长列表这一场景，在本地模拟了10、100、1000、10000条数据，分别使用ForEach、LazyForEach，来测试关闭和开启懒加载情况下的完全显示所用时间、列表挂载时间、独占内存，并分析了其滑动过程中的丢帧率。其中，列表挂载时间是指创建组件和组件挂载数据的总时长。最终，使用IDE的Profiler工具检测下述指标，得到的数据如下所示：

从测试数据可以看出：

1. 在100条数据范围内ForEach和LazyForEach差距不大，总体而言两者各项性能指标都在可接受范围内，而ForEach代码逻辑比LazyForEach简单，此场景下使用ForEach即可。
2. 当数据大于1000条，特别是当数据达到10000条时，ForEach在列表渲染、应用内存占用、丢帧率等各个方面都会有“指数级别”的显著劣化，滑动会出现明显的卡顿，甚至会出现应用crash等现象。
3. 使用LazyForEach除了最后内存稍微增大以外，其列表渲染时间、丢帧率都不会出现明显变化，具有较好的性能。

组件复用

对于使用LazyForEach的情况下，在滑动过程中由于要动态创建组件，会出现BuildLazyItem的耗时，通过组件复用能力，可以减少滑动过程中的组件创建耗时，进一步优化滑动时的性能。

对比长列表案例中开启组件复用和未开启的情况下，其数据如下：

可以发现列表滑动时丢帧率明显降低，这是因为，List列表开启了组件复用，不会执行BuildLazyItem这个耗时操作（耗时10.277ms），后续创建新组件节点时，会直接复用缓存区中的节点（耗时0.97ms），这样就大幅节约了组件重新创建的时间。

合理使用布局组件

选择合适的布局组件

在布局时，子组件会根据父组件的布局算法得到相应的排列规则，然后按照规则进行子组件位置的摆放。不同的布局容器使用的布局算法对性能带来的影响不同。开发者应该根据场景选用合适的布局，除非必须，尽量减少使用性能差的布局组件。

我们常用的基础布局组件包含以下组件：

• 使用Row、Column构建线性布局。
• 使用Stack构建层叠布局。

上述布局都属于线性布局，顾名思义，在线性布局中排布的组件是按照特定的方向线性放置，如横向/纵向/Z序方向。除上述布局类型外，还有一些复杂布局能力，如Flex、List、Grid、RelativeContainer和自定义布局等。

• 使用Flex构建弹性布局。

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

复杂布局提供了场景化的能力，解决一种或者多种布局场景。但是在一些场景下，不恰当的使用这些高级组件，可能带来更多的性能消耗。

我们通过对不同的布局方式，设置对应容器相同的嵌套深度为5、总元素节点为20个Text的情况下，来对比其性能消耗。通过Profiler工具获取其首帧绘制时间进行对比。对比结果如下表：

可以发现，在布局深度和节点数相同的情况下：

• 使用基础组件如Column和Row容器的性能明显高于其他布局。
• Flex的性能明显低于Column和Row容器，这是由于Flex本身带来的二次布局的影响。
• Grid/GridItem布局、相对布局RelativeContainer的性能消耗高于基础组件Column、Row、Stack等容器。

以上数据都是基于相同布局层数和节点数的情况下的对比结果，反应了布局本身的相对性能消耗，并不意味着使用了该组件性能就一定差，也并非任何情况下使用基础组件都能够保持良好的性能，因为在一些情况下，使用高级组件能够大大减少嵌套层数和节点数，其带来的性能提升反而高于组件本身的性能消耗。所以在使用布局时尽量遵循以下原则：

• 在相同嵌套层级的情况下，如果多种布局方式可以实现相同布局效果，优选低耗时的布局，如使用Column、Row替代Flex实现相同的单行布局。
• 在能够通过其他布局大幅优化节点数的情况下，可以使用高级组件替代，如使用RelativeContainer替代Row、Column实现扁平化布局，此时其收益大于布局组件本身的性能差距。
• 仅在必要的场景下使用高耗时的布局组件，如使用Flex实现折行布局、使用Grid实现二维网格布局等。

Scroll嵌套List场景下，给定List组件宽高

在使用Scroll容器组件嵌套List组件加载长列表时，若不指定List的宽高尺寸，则默认全部加载。

在如下代码案例中，通过Scroll嵌套List，对比List设置宽度和不设置的情况下：

问题定位工具

性能是一个涉及许多方面的复杂问题。DevEco Studio提供了工具可以为您提供关于性能瓶颈发生位置的明确提示，使用工具Profiler 查看性能参数可以参考使用DevEco Profiler进行性能调优，使用ArkUI Inspector查看组件树结构可以参考布局分析。