大家好，我是 V 哥。在鸿蒙原生应用开发中，当一个复杂的界面加载数据或发生变化时，布局可能会发生调整，为了提高布局变化带来的性能问题，V 哥在实际开发中，总结了一些优化技巧，来提高布局性能，笔记分享给大家。
1. 避免不必要的二次布局
在 ArkTS 中，二次布局通常发生在容器的子元素尺寸或位置需要重新计算时。在测试中，V 哥发现以下一些情况可能导致二次布局。
场景 1：动态改变子元素尺寸
示例代码：
@Entry@Componentstruct 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@Componentstruct 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@Componentstruct 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：动态改变子元素尺寸
优化措施：
优化后的代码：
@Entry@Componentstruct 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@Componentstruct 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 布局时子元素尺寸不确定
优化措施：
优化后的代码：
@Entry@Componentstruct 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）
在 Flex 布局中，如果子组件的主轴尺寸长度总和小于容器主轴尺寸长度，且包含设置有效的flexGrow属性的子组件，这些子组件会触发二次布局，拉伸布局以填满容器。同样，如果子组件的主轴尺寸长度总和大于容器主轴尺寸长度，且包含设置有效的flexShrink属性的子组件，这些子组件也会触发二次布局，压缩布局以填满容器。
@Entry@Componentstruct OriginalFlexLayout { build() { Flex() { Text("Item 1").flexGrow(1) Text("Item 2").flexGrow(2) } }}
复制代码
如果容器空间不足以容纳两个文本元素，它们会根据flexGrow属性进行拉伸，可能导致二次布局。
优化后的代码（使用layoutWeight）
使用layoutWeight属性替代flexGrow和flexShrink属性可以更有效地控制子组件的布局权重，从而提高布局性能。layoutWeight属性在分配剩余空间时，两次遍历都只布局一次组件，不会触发二次布局。
@Entry@Componentstruct OptimizedLayoutWithLayoutWeight { build() { Row() { Text("Item 1").layoutWeight(1) Text("Item 2").layoutWeight(2) } }}
复制代码
在这个优化后的代码中，我们使用了Row布局和layoutWeight属性来替代Flex布局中的flexGrow属性。这样，当容器空间不足以容纳两个文本元素时，它们会根据layoutWeight属性的比例分配空间，而不会引起二次布局。
使用layoutWeight属性的主要优势在于它简化了布局计算过程。与flexGrow和flexShrink相比，layoutWeight不需要在容器空间不足时进行额外的拉伸或压缩计算，因为它直接根据权重分配空间。这种方法减少了布局的复杂度，特别是在子组件数量较多或者布局较为复杂的情况下，能够显著提高布局性能。通过这种方式，我们可以避免不必要的二次布局，从而提升应用的响应速度和用户体验。
3. 响应式布局设计
响应式布局设计不当可能会导致布局重排，特别是在不同屏幕尺寸或方向变化时。以下是一个没有使用响应式设计，导致在不同设备上可能出现布局问题的原始代码案例：
原始代码案例
@Entry@Componentstruct 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@Componentstruct 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@Componentstruct 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@Componentstruct 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. 优化大型对象的更新
在 ArkTS 中，如果一个大型对象的属性发生变化时，没有使用细粒度更新，那么整个对象可能会被重新渲染，这会导致性能问题，尤其是在对象属性很多或者对象很大时。
原始代码案例
以下是一个没有使用@Observed和@ObjectLink的原始代码案例，其中包含一个大型对象，每次对象更新时，整个对象都会被重新渲染：
@Entry@Componentstruct 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@Componentstruct 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@Componentstruct 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@Componentstruct 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 中的布局性能，提升应用的响应速度和用户体验。欢迎关注威哥爱编程，鸿蒙开发你我他。
评论