- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

在ArkTS中，如何优化布局以提高性能？

威哥爱编程发表于 2024/12/03 10:50:44 2024/12/03

【摘要】大家好，我是 V 哥。在鸿蒙原生应用开发中，当一个复杂的界面加载数据或发生变化时，布局可能会发生调整，为了提高布局变化带来的性能问题，V 哥在实际开发中，总结了一些优化技巧，来提高布局性能，笔记分享给大家。 1. 避免不必要的二次布局在Flex布局中，如果子组件的主轴尺寸总和不等于容器的主轴尺寸长度，可能需要进行二次布局。为了避免这种情况，可以确保子组件的主轴尺寸总和等于容器的主轴尺寸长度，...

大家好，我是 V 哥。在鸿蒙原生应用开发中，当一个复杂的界面加载数据或发生变化时，布局可能会发生调整，为了提高布局变化带来的性能问题，V 哥在实际开发中，总结了一些优化技巧，来提高布局性能，笔记分享给大家。

1. 避免不必要的二次布局

在Flex布局中，如果子组件的主轴尺寸总和不等于容器的主轴尺寸长度，可能需要进行二次布局。为了避免这种情况，可以确保子组件的主轴尺寸总和等于容器的主轴尺寸长度，或者合理设置flexGrow、flexShrink属性，以减少不必要的布局重排。

在ArkTS中，二次布局通常发生在容器的子元素尺寸或位置需要重新计算时。在测试中，V 哥发现以下一些情况可能导致二次布局。

场景 1：动态改变子元素尺寸

示例代码：

@Entry
@Component
struct DynamicResizeExample {
    private isLarge = false;

    build() {
        Column() {
            Text("Toggle Size").onClick(() => {
                this.isLarge = !this.isLarge;
            }).padding(10);
            Text("Dynamic Text").fontSize(this.isLarge ? 24 : 16).padding(10);
        }
    }
}

解析：
在这个例子中，有一个文本元素的字体大小会根据按钮的点击事件动态改变。当字体大小改变时，文本元素的尺寸也会随之改变，这可能导致父容器（Column）需要重新布局以适应新的尺寸，从而发生二次布局。

场景 2：异步加载内容导致的尺寸变化

示例代码：

@Entry
@Component
struct AsyncContentExample {
    private content: string = '';

    build() {
        Column() {
            Text("Load Content").onClick(() => {
                this.loadContent();
            }).padding(10);
            Text(this.content).padding(10);
        }
    }

    private async loadContent() {
        // 模拟异步加载数据
        this.content = await fetchContent();
        this.update(); // 手动触发更新
    }

    private async fetchContent(): Promise<string> {
        // 模拟网络请求
        return new Promise(resolve => {
            setTimeout(() => {
                resolve("Loaded Content");
            }, 1000);
        });
    }
}

解析：
在这个例子中，点击按钮会异步加载内容，加载完成后更新文本元素的内容。由于异步加载的内容尺寸可能与原始内容不同，这会导致父容器需要重新布局以适应新的尺寸，从而可能发生二次布局。

场景 3：使用Flex布局时子元素尺寸不确定

示例代码：

@Entry
@Component
struct FlexLayoutExample {
    private items: string[] = ['Item 1', 'Item 2', 'Item 3'];

    build() {
        Flex() {
            this.items.forEach(item => {
                Text(item).width('auto').margin(5);
            });
        }
    }
}

解析：
在这个例子中，使用了Flex布局，并且每个文本元素的宽度设置为’auto’，这意味着它们的宽度将根据内容自动调整。如果文本内容发生变化或者字体大小动态改变，这可能导致Flex容器需要重新计算子元素的尺寸和位置，从而发生二次布局。

这些场景在ArkTS中可能导致二次布局的常见情况，通常与动态尺寸变化、异步内容加载或不确定的子元素尺寸有关。为了避免二次布局，可以采取一些优化措施。下面我们来看一下如何进行优化。

为了避免二次布局带来的性能问题，我们可以采取以下优化措施：

场景 1：动态改变子元素尺寸

优化措施：

使用matchContent()替代fontSize()动态变化，以避免触发二次布局。
使用动画平滑过渡尺寸变化，减少布局的触发。

优化后的代码：

@Entry
@Component
struct DynamicResizeExample {
    private isLarge = false;

    build() {
        Column() {
            Text("Toggle Size").onClick(() => {
                this.isLarge = !this.isLarge;
            }).padding(10);
            Text("Dynamic Text").matchContent().fontSize(this.isLarge ? 24 : 16).padding(10).transition({ duration: 300 });
        }
    }
}

场景 2：异步加载内容导致的尺寸变化

优化措施：

预先设定一个最大尺寸，以减少因内容变化导致的布局调整。
使用占位符显示内容加载中的状态，避免内容突然变化导致的布局调整。

优化后的代码：

@Entry
@Component
struct AsyncContentExample {
    private content: string = '...Loading';

    build() {
        Column() {
            Text("Load Content").onClick(() => {
                this.loadContent();
            }).padding(10);
            Text(this.content).maxWidth(300).padding(10); // 预设最大宽度
        }
    }

    private async loadContent() {
        // 模拟异步加载数据
        this.content = await fetchContent();
        this.update(); // 手动触发更新
    }

    private async fetchContent(): Promise<string> {
        // 模拟网络请求
        return new Promise(resolve => {
            setTimeout(() => {
                resolve("Loaded Content");
            }, 1000);
        });
    }
}

场景 3：使用Flex布局时子元素尺寸不确定

优化措施：

为Flex子项设置最小和最大宽度，减少因内容变化导致的布局调整。
使用wrapContent()替代width('auto')，以适应内容变化。

优化后的代码：

@Entry
@Component
struct FlexLayoutExample {
    private items: string[] = ['Item 1', 'Item 2', 'Item 3'];

    build() {
        Flex() {
            this.items.forEach(item => {
                Text(item).wrapContent().minWidth(50).maxWidth(200).margin(5); // 设置最小和最大宽度
            });
        }
    }
}

通过这些优化措施，我们可以减少因动态变化导致的二次布局，提高应用的性能和用户体验。这些措施包括使用动画过渡、预设尺寸、设置最小和最大宽度等，以减少布局的不确定性和频繁变化。

2. 优先使用layoutWeight属性

替代flexGrow属性和flexShrink属性，layoutWeight属性可以更有效地控制子组件的布局权重，从而提高布局性能。

原始代码案例（使用`flexGrow`和`flexShrink`）

在Flex布局中，如果子组件的主轴尺寸长度总和小于容器主轴尺寸长度，且包含设置有效的flexGrow属性的子组件，这些子组件会触发二次布局，拉伸布局以填满容器。同样，如果子组件的主轴尺寸长度总和大于容器主轴尺寸长度，且包含设置有效的flexShrink属性的子组件，这些子组件也会触发二次布局，压缩布局以填满容器。

@Entry
@Component
struct OriginalFlexLayout {
  build() {
    Flex() {
      Text("Item 1").flexGrow(1)
      Text("Item 2").flexGrow(2)
    }
  }
}

如果容器空间不足以容纳两个文本元素，它们会根据flexGrow属性进行拉伸，可能导致二次布局。

优化后的代码（使用`layoutWeight`）

使用layoutWeight属性替代flexGrow和flexShrink属性可以更有效地控制子组件的布局权重，从而提高布局性能。layoutWeight属性在分配剩余空间时，两次遍历都只布局一次组件，不会触发二次布局。

@Entry
@Component
struct OptimizedLayoutWithLayoutWeight {
  build() {
    Row() {
      Text("Item 1").layoutWeight(1)
      Text("Item 2").layoutWeight(2)
    }
  }
}

在这个优化后的代码中，我们使用了Row布局和layoutWeight属性来替代Flex布局中的flexGrow属性。这样，当容器空间不足以容纳两个文本元素时，它们会根据layoutWeight属性的比例分配空间，而不会引起二次布局。

使用layoutWeight属性的主要优势在于它简化了布局计算过程。与flexGrow和flexShrink相比，layoutWeight不需要在容器空间不足时进行额外的拉伸或压缩计算，因为它直接根据权重分配空间。这种方法减少了布局的复杂度，特别是在子组件数量较多或者布局较为复杂的情况下，能够显著提高布局性能。通过这种方式，我们可以避免不必要的二次布局，从而提升应用的响应速度和用户体验。

3. 响应式布局设计

通过条件渲染和自定义Builder函数，可以创建适应不同设备的界面，减少因设备差异导致的布局重排。

响应式布局设计不当可能会导致布局重排，特别是在不同屏幕尺寸或方向变化时。以下是一个没有使用响应式设计，导致在不同设备上可能出现布局问题的原始代码案例：

原始代码案例

@Entry
@Component
struct ResponsiveLayoutIssue {
  build() {
    Column() {
      Text("Header").fontSize(24) // 大标题
      Row() {
        Text("Menu Item 1") // 菜单项
        Text("Menu Item 2") // 菜单项
        Text("Menu Item 3") // 菜单项
      }.width('100%') // 强制菜单宽度为100%
      Text("Content") // 主内容区域
    }
  }
}

在这个例子中，Row中的菜单项在小屏幕上可能会显示拥挤，因为它们被设置为width('100%')，这可能导致布局重排和内容溢出。

优化后的代码

为了优化上述代码，我们可以采用条件渲染和自定义Builder函数来创建适应不同设备的界面：

@Entry
@Component
struct ResponsiveLayoutOptimized {
  build() {
    Column() {
      Text("Header").fontSize(24) // 大标题
      if (this.isSmallScreen()) {
        // 小屏幕上，菜单项垂直排列
        ForEach(['Menu Item 1', 'Menu Item 2', 'Menu Item 3'], (item) => {
          Text(item).width('100%') // 每个菜单项宽度为100%
        })
      } else {
        // 大屏幕上，菜单项水平排列
        Row() {
          Text("Menu Item 1") // 菜单项
          Text("Menu Item 2") // 菜单项
          Text("Menu Item 3") // 菜单项
        }.width('100%') // 菜单整体宽度为100%
      }
      Text("Content") // 主内容区域
    }
  }
  
  isSmallScreen() {
    // 假设这个函数根据屏幕尺寸返回true或false
    return window.width < 600; // 假设宽度小于600px为小屏幕
  }
}

性能优化解释

使用响应式布局设计的主要优势在于它可以根据设备的屏幕尺寸和方向动态调整布局，减少因设备差异导致的布局重排：

减少布局重排：通过条件渲染，我们可以为不同屏幕尺寸提供不同的布局结构，从而减少因屏幕尺寸变化导致的布局重排。
提高用户体验：适应不同设备的界面可以提供更好的用户体验，尤其是在移动设备和桌面设备之间切换时。
优化性能：减少布局计算和重排可以提高应用的性能，尤其是在动态内容更新和设备方向变化时。

所以，通过响应式布局设计，我们可以创建适应不同设备的界面，减少因设备差异导致的布局重排，从而提高应用的性能和用户体验。

4. 懒加载

对于复杂或资源密集型的组件，使用懒加载可以提高应用的启动速度，仅在需要时才加载和渲染这些组件。

懒加载带来的问题

在应用开发中，如果所有组件都在应用启动时一次性加载，可能会导致启动时间过长，特别是对于包含复杂或资源密集型组件的应用。这会影响用户体验，因为用户需要等待所有资源加载完成后才能使用应用。

原始代码案例

以下是一个没有使用懒加载的原始代码案例，其中包含一个大型列表，列表中的每个项都是一个复杂的组件：

@Entry
@Component
struct NonLazyLoadingExample {
  private items: any[] = this.generateItems(100); // 假设生成了100个复杂项

  generateItems(count: number): any[] {
    let items: any[] = [];
    for (let i = 0; i < count; i++) {
      items.push({
        id: i,
        // 假设每个项包含大量数据和资源
        data: this.generateLargeData()
      });
    }
    return items;
  }

  generateLargeData(): any {
    // 生成大量数据的模拟函数
    return new Array(1000).fill(null).map((_, index) => ({ index }));
  }

  build() {
    Column() {
      ForEach(this.items, (item) => {
        // 渲染复杂组件，假设每个组件都需要加载大量资源
        this.renderComplexItem(item);
      });
    }
  }

  renderComplexItem(item: any) {
    // 复杂组件的渲染逻辑
    Column() {
      Text(`Item ID: ${item.id}`).fontWeight(FontWeight.Bold);
      // 假设这里有更多复杂的UI和资源加载
    }
  }
}

在这个例子中，所有复杂组件都在应用启动时一次性渲染，这可能导致应用启动缓慢。

优化后的代码

使用懒加载，我们可以只在组件需要显示时才加载和渲染它们。以下是使用懒加载优化后的代码：

@Entry
@Component
struct LazyLoadingOptimizedExample {
  private items: any[] = this.generateItems(100); // 假设生成了100个复杂项

  generateItems(count: number): any[] {
    let items: any[] = [];
    for (let i = 0; i < count; i++) {
      items.push({
        id: i,
        // 假设每个项包含大量数据和资源
        data: this.generateLargeData()
      });
    }
    return items;
  }

  generateLargeData(): any {
    // 生成大量数据的模拟函数
    return new Array(1000).fill(null).map((_, index) => ({ index }));
  }

  build() {
    Column() {
      // 使用懒加载ForEach
      LazyForEach(this.items, (item) => {
        // 仅在需要时才渲染复杂组件
        this.renderComplexItem(item);
      });
    }
  }

  renderComplexItem(item: any) {
    // 复杂组件的渲染逻辑
    Column() {
      Text(`Item ID: ${item.id}`).fontWeight(FontWeight.Bold);
      // 假设这里有更多复杂的UI和资源加载
    }
  }
}

性能优化解释

使用懒加载的主要优势在于：

提高启动速度：应用不需要在启动时加载所有资源，从而减少了启动时间。
减少内存消耗：懒加载可以减少同时加载的资源数量，从而减少内存消耗。
按需加载：只有当用户滚动到某个部分时，相关的组件才会被加载和渲染，这提高了资源的使用效率。
改善用户体验：用户可以更快地看到应用的初始内容，而不需要等待所有资源加载完成。

所以要切记，通过使用懒加载，我们可以优化应用的启动速度和性能，提高用户体验。

5. 优化大型对象的更新

对于包含多个属性的复杂对象，使用@Observed和@ObjectLink可以实现细粒度的更新，只有发生变化的部分会触发UI更新，而不是整个对象。

在ArkTS中，如果一个大型对象的属性发生变化时，没有使用细粒度更新，那么整个对象可能会被重新渲染，这会导致性能问题，尤其是在对象属性很多或者对象很大时。

原始代码案例

以下是一个没有使用@Observed和@ObjectLink的原始代码案例，其中包含一个大型对象，每次对象更新时，整个对象都会被重新渲染：

@Entry
@Component
struct LargeObjectUpdateIssue {
  private largeObject: any = this.createLargeObject();

  createLargeObject(): any {
    // 创建一个包含多个属性的大型对象
    let obj: any = {};
    for (let i = 0; i < 100; i++) {
      obj[`property${i}`] = `value${i}`;
    }
    return obj;
  }

  build() {
    Column() {
      Text(`Property1: ${this.largeObject.property1}`)
      Text(`Property2: ${this.largeObject.property2}`)
      // ...更多属性
    }
  }

  updateObject() {
    // 更新对象的某个属性
    this.largeObject.property1 = 'new value';
    // 这将导致整个对象重新渲染
  }
}

在这个例子中，updateObject方法更新了largeObject的一个属性，但由于没有使用细粒度更新，整个对象都会被重新渲染。

优化后的代码

使用@Observed和@ObjectLink，我们可以只更新发生变化的部分，而不是整个对象：

@Entry
@Component
struct LargeObjectUpdateOptimized {
  @Observed largeObject: any = this.createLargeObject();

  createLargeObject(): any {
    // 创建一个包含多个属性的大型对象
    let obj: any = {};
    for (let i = 0; i < 100; i++) {
      obj[`property${i}`] = `value${i}`;
    }
    return obj;
  }

  build() {
    Column() {
      Text(`Property1: ${this.largeObject.property1}`)
      Text(`Property2: ${this.largeObject.property2}`)
      // ...更多属性
    }
  }

  updateObject() {
    // 更新对象的某个属性
    this.largeObject.property1 = 'new value';
    // 只有property1相关的UI会更新
  }
}

性能优化解释

使用@Observed和@ObjectLink的主要优势在于：

减少不必要的渲染：只有发生变化的部分会触发UI更新，而不是整个对象，这减少了不必要的渲染。
提高性能：减少了渲染次数，提高了应用的性能，尤其是在对象属性很多或者对象很大时。
优化用户体验：用户界面的响应更快，因为只有相关的部分被更新，而不是整个对象。
降低内存消耗：减少了因为渲染整个对象而可能产生的额外内存消耗。

所以，通过使用@Observed和@ObjectLink，我们可以优化大型对象的更新，提高应用的性能和用户体验。

6. 内存管理和避免内存泄漏

使用对象池模式管理频繁创建和销毁的对象，如粒子系统、游戏中的敌人等，可以减少内存压力并提高性能。

内存管理和避免内存泄漏的问题

在应用开发中，频繁创建和销毁对象（如粒子系统、游戏中的敌人等）可能会导致内存压力增大，并增加垃圾回收（GC）的频率，从而影响应用性能。此外，如果对象没有被正确销毁，还可能导致内存泄漏。

原始代码案例

以下是一个没有使用对象池模式的原始代码案例，其中包含频繁创建和销毁对象的操作：

@Entry
@Component
struct MemoryLeakExample {
  private enemies: any[] = [];

  createEnemy() {
    // 模拟创建一个敌人对象
    let enemy = {
      id: Date.now(),
      name: `Enemy ${this.enemies.length + 1}`,
      // 假设这里有更多复杂的属性和方法
    };
    this.enemies.push(enemy);
  }

  build() {
    Button("Create Enemy").onClick(() => {
      this.createEnemy();
    });
  }
}

在这个例子中，每次点击按钮都会创建一个新的敌人对象，并将其添加到数组中。如果这些对象没有被正确管理，可能会导致内存泄漏。

优化后的代码

使用对象池模式，我们可以重用对象，减少内存压力并提高性能：

@Entry
@Component
struct MemoryManagementOptimized {
  private enemyPool: any[] = []; // 对象池

  createEnemy() {
    if (this.enemyPool.length > 0) {
      // 从对象池中获取一个对象
      let enemy = this.enemyPool.pop();
      enemy复活();
      this.enemies.push(enemy);
    } else {
      // 创建一个新的敌人对象
      let enemy = {
        id: Date.now(),
        name: `Enemy ${this.enemies.length + 1}`,
        // 假设这里有更多复杂的属性和方法
       复活: () => {
          // 复活逻辑，重置对象状态
        }
      };
      this.enemies.push(enemy);
    }
  }

  destroyEnemy(enemy: any) {
    // 将敌人对象状态重置后放回对象池
    enemy.复活();
    this.enemyPool.push(enemy);
  }

  build() {
    Button("Create Enemy").onClick(() => {
      this.createEnemy();
    });
    Button("Destroy Enemy").onClick(() => {
      if (this.enemies.length > 0) {
        let enemy = this.enemies.pop();
        this.destroyEnemy(enemy);
      }
    });
  }
}

性能优化解释

使用对象池模式的主要优势在于：

减少内存压力：通过重用对象，减少了频繁创建和销毁对象导致的内存压力。
提高性能：减少了垃圾回收（GC）的频率，从而提高了应用的性能。
避免内存泄漏：通过正确管理对象的生命周期，避免了内存泄漏的风险。
提高资源利用率：对象池可以提高对象的利用率，减少资源浪费。

咱们通过使用对象池模式，可以优化内存管理，减少内存压力，提高应用的性能，并避免内存泄漏。

最后

以上 V 哥总结的小小优化心得，可以有效地优化ArkTS中的布局性能，提升应用的响应速度和用户体验。欢迎关注威哥爱编程，鸿蒙开发你我他。

点赞
收藏
关注作者

0/1000

抱歉，系统识别当前为高风险访问，暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称，即可参与社区互动！

*长度不超过10个汉字或20个英文字符，设置后3个月内不可修改。

确认取消

加入云驻计划，成为创作者

华为云周边好礼
免费体验产品
特殊身份标识
线下官方门票
内部专家零距离
与10000+优质创作者共同成长

立即加入

在ArkTS中，如何优化布局以提高性能？

1. 避免不必要的二次布局

场景 1：动态改变子元素尺寸

场景 2：异步加载内容导致的尺寸变化

场景 3：使用Flex布局时子元素尺寸不确定

场景 1：动态改变子元素尺寸

场景 2：异步加载内容导致的尺寸变化

场景 3：使用Flex布局时子元素尺寸不确定

2. 优先使用layoutWeight属性

原始代码案例（使用`flexGrow`和`flexShrink`）

优化后的代码（使用`layoutWeight`）

3. 响应式布局设计

原始代码案例

优化后的代码

性能优化解释

4. 懒加载

原始代码案例

优化后的代码

性能优化解释

5. 优化大型对象的更新

原始代码案例

优化后的代码

性能优化解释

6. 内存管理和避免内存泄漏

内存管理和避免内存泄漏的问题

原始代码案例

优化后的代码

性能优化解释

最后

全部回复

设置昵称

关于作者

目录

加入云驻计划，成为创作者

在ArkTS中，如何优化布局以提高性能？

1. 避免不必要的二次布局

场景 1：动态改变子元素尺寸

场景 2：异步加载内容导致的尺寸变化

场景 3：使用Flex布局时子元素尺寸不确定

场景 1：动态改变子元素尺寸

场景 2：异步加载内容导致的尺寸变化

场景 3：使用Flex布局时子元素尺寸不确定

2. 优先使用layoutWeight属性

原始代码案例（使用flexGrow和flexShrink）

优化后的代码（使用layoutWeight）

3. 响应式布局设计

原始代码案例

优化后的代码

性能优化解释

4. 懒加载

原始代码案例

优化后的代码

性能优化解释

5. 优化大型对象的更新

原始代码案例

优化后的代码

性能优化解释

6. 内存管理和避免内存泄漏

内存管理和避免内存泄漏的问题

原始代码案例

优化后的代码

性能优化解释

最后

全部回复

设置昵称

关于作者

目录

加入云驻计划，成为创作者

推荐阅读

相关产品

原始代码案例（使用`flexGrow`和`flexShrink`）

优化后的代码（使用`layoutWeight`）